Anatomy of an ad fraud incident, buyer side

The fraud incident that damages a UA budget in 2026 does not look like fraud. The devices are real, the sessions are real, the retention through day three is often better than the blended figure. The fraud tooling passes it. What the traffic lacks is any chance of producing a payer. Somebody paid or nudged or automated the people behind those installs, and none of them has any interest in the game, so the defect is the absence of incrementality, and no filter built to catch device farms and click injection so much as looks for that.

The argument here is that buyer-side protection against this class of loss is not a vendor decision. It is a payment structure and a contract clause. Teams that treat fraud as a tooling problem end up with a clean fraud report and a hole in their D30 revenue, and the incident that follows costs more in analyst time and relationship damage than the money at stake.

How the incident unfolds

The pattern is consistent enough to describe as a timeline.

A network or DSP campaign that has been running steadily starts delivering more volume at the same CPI. Nobody objects, because more installs at target is exactly what the campaign optimises toward. The volume comes from a new sub-publisher or a new traffic source inside the network's aggregated reporting, which the buyer cannot see by default.

D1 retention holds or improves. D3 looks fine. The MMP's fraud module flags a small fraction, a few percent at most, for the usual signals, and the buyer strikes those off at invoice time without friction. Everything else passes.

Around week three, a measurement analyst notices that the campaign's D7 payer conversion has fallen sharply while its install volume rose. Cohort revenue at D14 confirms it. Backing out the new volume, the original traffic is performing as before. The incremental installs have close to zero revenue.

What follows is the expensive part. The buyer freezes the campaign, asks the network for sub-publisher level data, and enters a negotiation about what was fraud and what was merely low quality. The network's position, which is defensible under a CPI contract, is that it delivered installs from real devices that met the agreed event, and that quality variance is the buyer's risk. The MMP's fraud report supports the network, because the MMP's definition of fraud is the one its filters implement.

The incentive that produces it

Nothing in this chain requires a villain. A CPI contract pays the network for an install. The network pays its sources for installs. A source that can produce real installs from real devices at scale, whether through incentivised offer walls and reward apps or through lightly disguised paid-to-install schemes, is a good source under that contract. Post-install quality is the buyer's problem unless the buyer has written otherwise.

Fraud detection tooling sharpens this rather than fixing it. Each generation of filters removes the crude sources and leaves the ones that produce traffic indistinguishable from real users on every dimension the filters check. The result is that a clean fraud report is a weaker signal than it was three years ago, because the filters themselves select for traffic that can survive them. This spring's "Mobile ad fraud: the lessons from Uber's own lawsuit" covered how long that kind of traffic ran undetected at an advertiser with far more resources than most game studios.

The runbook, once it has happened

An incident needs a sequence, agreed in advance, because the people running it will be angry and short of time.

• Freeze the source, not the whole network, if the network can identify it. Freezing the network entirely destroys the evidence of which traffic was fine.
• Quantify in cohort revenue, not install counts. The claim is that a defined block of installs produced revenue far below the campaign's established baseline. State the baseline, the block, the gap, and the confidence.
• Assemble the evidence pack: cohort curves for baseline and suspect traffic, the volume step change, any sub-publisher IDs, and the MMP's raw data for the period. Ask for the network's sub-publisher breakdown in writing.
• Decide the pursuit threshold before the meeting. If the disputed amount is below the cost of the analyst and legal hours to recover it, take the lesson, write it off, and change the terms. Pursuing a small clawback to make a point rarely pays.
• Record the outcome and the source identifiers, and share them with the other buyers in your studio or group. Sources move between networks.

An illustrative example, numbers for arithmetic only. A campaign running at 800 installs a day with a D14 payer conversion of 2.5 percent jumps to 1,900 installs a day at the same CPI. The blended D14 payer conversion falls to 1.1 percent. Back out the incremental 1,100 daily installs and the baseline holds at 2.5, which means the new block is converting at roughly a tenth of a percent. Over three weeks that block is around 23,000 installs. The MMP flagged roughly 900 of them. The buyer's real loss is the CPI on the other 22,000, and under a plain CPI contract the network owes none of it.

The prevention that actually binds

Three contractual and structural changes do more than any detection vendor.

Pay on a post-install event with a delay, not on the install. A D3 or D7 retention event, or a first-session-length threshold, moves the quality risk to the party that controls the sources. Networks will price this higher. The premium is the insurance cost, and it is usually cheaper than the incident.

Require sub-publisher transparency as a term, with the right to blacklist at the source level and a cap on the share of volume any new source can contribute in its first fortnight. Most of the damage in these incidents comes from a source that went from nothing to a majority of volume in a week.

Set a volume-step alert on every campaign, independent of the fraud module. A rise in daily installs of more than a fixed share at flat CPI is an investigation trigger, not a win. This is the cheapest control on the list and the one most often missing.

The trade-off is that post-install payment terms and source caps reduce the volume a network is willing to deliver and slow down scaling on the networks that can genuinely scale. That is a cost worth paying on any network where you cannot see the sources. On the platforms where the inventory is first-party and the source is the platform itself, none of that is necessary; insisting on it there just makes you a smaller customer.

The one place to spend money on tooling is the D14 cohort revenue view broken down by source and by week, refreshed daily. It is not a fraud tool. It is the thing that would have caught the incident in week one instead of week three, and it doubles as the evidence pack.

Related archive reading

These articles provide related context and remain subject to their stated review status.

• Incrementality testing for hybrid-casual games that works
• Server side events: why studios are moving