Blog · Signals

A 25 percent lead rate at half the CPA is not a supply win. It is an optimization signal fraudsters can manufacture.

Performance marketers are trained to celebrate a falling cost per lead. An investigation published on Bizcommunity on August 26 describes a pet-insurance campaign where one cluster of third-party mobile app placements produced roughly 70 percent of lead volume at a fraction of the cost of Facebook feed inventory, with reported form completion rates between 15 percent and 25 percent. The dashboard called it an optimization breakthrough. Call-centre agents calling those leads heard something else: consumers who had never requested pet insurance, or who did not own a pet at all. A significant share of the questionable leads arrived between 11pm and 6am, when the Android phones that generated them were likely idle on bedside tables.

The conversion event is not the customer

Most programmatic stacks end measurement when the platform records a success event. For a lead campaign, that event is usually a completed form: contact fields populated, questions answered, a pixel or postback fired. The media report closes. Finance sees a cheap acquisition. The optimization engine receives a positive label and searches for more inventory that can reproduce the same event at lower cost.

Commercial reality starts later. Did the person answer the phone? Did they confirm the enquiry? Did they qualify, pay, or renew? Those downstream facts live in CRM, dialler, and billing systems the ad platform never reads unless you wire them back in. When they disagree with the frontend conversion, you are not looking at a targeting miss. You are looking at conversion-event fraud: technology that produces the event the buyer defined as success without the human intent that event was supposed to represent.

The investigation traced part of the pattern to a utility app whose stated purpose was spam-call protection. Evidence suggested ads could load in the background, interactions could be generated, and information already held by the app could populate marketer forms while the user was not consciously engaging with an advertisement. The consumer denied making the enquiry. The platform had already logged a conversion and treated it as training data.

Real devices, real bid requests, fabricated outcomes

Pre-bid invalid-traffic filters often ask a narrow question: does this request look like a bot farm or a datacenter? A genuine Android handset with a valid IFA, a plausible IP, and an installed app that remains connected for hours answers yes to the device question while still producing traffic unrelated to attention or purchase intent. Dr Augustine Fou's work through FouAnalytics has made that distinction for years: the phone can be real, the utility app can be real, the network request can be technically valid, yet the advertising activity may have no relationship to a person choosing to act.

Documented fraud operations show what that looks like at bid-request scale. Human Security's September 2025 disclosure of SlopAds described 224 Android applications downloaded more than 38 million times across 228 countries and territories, using hidden WebViews to navigate threat-actor sites and generate fraudulent impressions and clicks. At peak, Human recorded 2.3 billion fraudulent bid requests per day. In 2026, Human's Trapdoor operation involved 455 malicious applications with more than 24 million downloads; many first-stage apps presented as ordinary utilities such as PDF readers and device cleaners, with peak volume of 659 million bid requests per day attributed to the operation.

Pareto, another Human disclosure cited in the same investigation, infected nearly one million Android phones that pretended to be consumers watching advertising on connected televisions, generating an average of 650 million bid requests per day while spoofing more than 6,000 CTV apps. One involved application was a flashlight utility advertised as ad-free; analysis found code generating fraudulent advertising activity without visible ads to users. The bidstream sees app identity and device class. It does not see whether a hidden browser is open behind the UI.

{
  "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "imp": [{ "id": "1", "banner": { "w": 320, "h": 50 } }],
  "app": {
    "bundle": "com.example.utility.spamshield",
    "name": "Spam Shield",
    "storeurl": "https://play.google.com/store/apps/details?id=com.example.utility.spamshield"
  },
  "device": {
    "ua": "Mozilla/5.0 (Linux; Android 14; ...)",
    "ifa": "38400000-8cf0-11bd-b23e-10b96e40000d",
    "os": "Android",
    "devicetype": 4
  }
}

Nothing in that skeleton flags fraud by syntax alone. app.bundle resolves to a store listing. device.ifa is present. devicetype may read as phone or tablet. Buyers who block only anonymous traffic or datacenter IPs will still bid. The failure arrives later, when the same environment also manufactures the post-click event the buyer sends back as a positive optimization label.

Why optimization amplifies the fraud

Click flooding and click spam are old names for a related pattern: background apps fabricating clicks so an fraudulent source steals attribution or wastes spend. AppsFlyer and Adjust both document utility tools that invisibly load and click ads, producing convincing device and campaign metadata without user interaction. Conversion-event fraud raises the stakes because it does not stop at stealing credit for someone else's sale. It teaches the platform where to spend next.

Modern buying systems optimize toward whichever event the advertiser declares. If that event is a completed lead form, the engine searches for placements that produce more completed forms at lower cost. Unless higher-quality downstream outcomes are returned, a fabricated form and a genuine enquiry look identical in the training signal. A placement reporting 15 percent to 25 percent lead rates at unusually low cost does not merely flatter a dashboard; it can pull budget toward the source that manufactured the events.

That is Goodhart's law in operational form. Once the proxy becomes the target, participants learn to produce the proxy. The marketer believes they are buying demand. The system may be buying the appearance of demand. Fraud creates its own feedback loop: manufacture the conversion, receive a success label, receive more spend, repeat until a human outside the platform notices that CRM callbacks contradict the media report.

Google Play's ad-fraud policy is explicit that apps must not render ads invisible to users, auto-generate clicks without user intention, or display advertising when the user is not actively in the app. The offence is misrepresenting user interest. Digital advertising depends on that assumption at every layer: an impression is an opportunity to see something, a click reflects interaction, a lead form means someone asked to continue the conversation. Divorce those signals from intent and the auction still clears while the measurement stack reports fiction.

What disagreement between systems actually looks like

There was no single dashboard alert in the pet-insurance case described above. Media metrics said the campaign was efficient. Form data looked plausible. Cost per lead was attractive. The contradiction lived in call-centre conversations: people who did not recognize the product, who denied submitting details, who were probably asleep when the record claimed they converted.

That pattern generalizes beyond one vertical. Lead-generation fraud schemes documented by partners such as impact.com include publishers obtaining genuine personal information and automatically populating advertiser forms, so automated activity resembles legitimate lead gen with real identities attached to fake acquisition events. Identity can be authentic while the event is not. Pre-bid filters focused on synthetic IDs miss that entirely.

SlopAds also illustrates conditional behaviour: Human found fraudulent activity activated only for certain installs tied to the threat actor's acquisition path. Static app review or a one-time store inspection can show a benign build while a different entry path loads the hidden WebView stack. Supply-path diligence on ads.txt and sellers.json does not reach inside the APK behaviour that fires after install.

What to check before you scale the placement

Treat an unusually cheap cost per lead as a hypothesis, not proof of skill. Compare frontend conversion timestamps to business hours and to dialler contact rates. Split performance by app.bundle and by seller, not only by campaign line item in the DSP UI. If downstream systems cannot be reconciled to the platform event, stop sending the platform a blind success signal for that inventory.

  • Require post-conversion validation (contact, qualification, revenue) before feeding an event back as an optimization target, or segment fabricated and verified conversions in separate line items.
  • Inspect bid requests for app supply with high conversion rates and low CPM: confirm app.bundle, app.storeurl, and device.devicetype are internally consistent and match the inventory you intended to buy.
  • Monitor time-of-day concentration on lead events; bulk overnight activity on Android utility inventory is a routing signal, not proof of fraud by itself, but it is worth isolating before budget scales.
  • Do not treat pre-bid IVT clearance as proof of human intent; real-device bid requests are compatible with background WebView and form-automation fraud.
  • When source.schain and seller authorization check out but outcomes disagree with CRM, the problem is likely event fabrication inside authorized app supply, not a missing hop in the chain.

Bid-request shape checks will not detect fraud intent. They do catch the inconsistent app metadata and malformed device blocks that make it harder to attribute suspicious supply back to a bundle or store URL when you investigate. Paste suspicious requests into RTBlint validate or follow the OpenRTB validation guide before you promote a placement from test to scaled spend.

The honest limit

Not every cheap lead is fraudulent, and not every overnight form is fabricated. Utility apps are not inherently suspicious; Android is not the problem. The argument is narrower: when the only success signal the platform sees is the conversion event you defined, any supply that can manufacture that event cheaply will look like your best partner until another system contradicts it.

The delivery-side version of hidden WebView inflation (attention scores and engagement beacons divorced from the surface the user watched) is covered on vastlint. This piece is the bidstream mirror: the same environments can pass as real devices in the auction while corrupting the optimization feedback that decides where the next dollar goes.

Sources

Field names refer to OpenRTB as published by IAB Tech Lab. Human Security, AppsFlyer, Adjust, and Google Play policy citations appear in the primary investigation article below. RTBlint is independent and not affiliated with Bizcommunity, Offernet, Human Security, or IAB Tech Lab.