Mobile ad fraud and attribution

What is mobile ad fraud?

Mobile ad fraud is the manipulation of ad interactions, installs or in-app events so that a fraudster's source receives attribution credit, and payment, it did not earn. Some fraud fakes the users themselves; some steals credit for real users who would have installed anyway.

The second kind is easy to miss. The installs are real and the users behave normally, so the damage shows up only as organic installs quietly being relabelled as paid, and paid budget going to a partner who did nothing.

How does fraud exploit attribution?

It exploits last-click rules: whoever has the most recent eligible click inside the window wins the install, so fraud tries to place a click at the right moment. That is why several fraud types never touch the install itself.

Click spam

Click spam, also called click flooding, sends huge numbers of clicks for devices that never saw or tapped an ad, hoping some of those devices install later and the fake click wins.

Patterns that suggest it:

• very low click-to-install conversion rates from one source;
• installs spread evenly over the whole window instead of clustering soon after the click;
• a source's installs rising when organic installs fall;
• clicks with impossible volumes per device.

Shorter click windows reduce how much a spammed click can win, which is one reason attribution window choices matter beyond reporting.

Click injection

Click injection is an Android technique in which an app already on the device detects that another app is being installed and fires a click just before the install completes, so it becomes the last click.

The Google Play Install Referrer returns both the referrer click timestamp and the install begin timestamp, as covered in chapter 7. A click recorded after the install began, or only seconds before the first open, is a classic warning sign. Attribution systems use these timestamps to reject clicks that could not have caused the install.

Bots and fake installs

Bots simulate users, either on emulators or with scripts that send fake install and event data straight to an attribution endpoint. They often show:

• identical or rotating device details;
• events firing in perfectly regular sequences;
• installs with no meaningful engagement afterwards;
• revenue events that never match a real payment.

Server-side checks, such as validating purchases with the app store before counting them as revenue, make fake revenue much harder.

Device farms

Device farms are rooms of real phones operated by people or scripts to install apps and perform events. Because the devices are real, single installs look normal. The patterns show up in aggregate:

• many installs from the same network ranges or locations;
• devices that reset their advertising IDs repeatedly;
• unusual concentrations of one device model and OS version;
• users who complete exactly the events that trigger payouts, and nothing else.

A worked example

An affiliate network reports 20k installs for a shopping app in a month, about a third of all paid installs. The team looks closer:

1. Click-to-install conversion for the affiliate is under 0.1%, far below other sources.
2. Install times are spread evenly across the 7-day window rather than clustering in the first hour.
3. When the affiliate is paused for a week, organic installs rise by roughly the same number.
4. Day-7 purchase rates for affiliate users match organic users exactly.

Together, these point to click spam claiming organic installs. The team withholds payment for that period, removes the source and sees organic return to its earlier level. The users were real all along; only the credit was fake.

Fake in-app events

Fraud is not limited to installs. Where advertisers pay for, or optimise towards, in-app events such as registrations or purchases, fraudsters fake those events too.

• Fake sign-ups: scripted registrations with throwaway details, triggered to meet a cost-per-action payout.
• Fake purchases: revenue events sent without a real payment behind them, which inflate ROAS and mislead bidding algorithms.
• Event stuffing: a burst of events from one device in an implausibly short time.

These are especially harmful because they also poison optimisation. When fake events are sent to an ad network as postbacks, the network learns to find more traffic like the fraud. Validating revenue before sending it, as described in events, postbacks and ROAS, keeps fake value out of both your reports and the networks' models.

Who pays for fraud?

The advertiser pays, through budget spent on fake or stolen installs and through worse optimisation, even when the network or affiliate is the one that benefits. Some contracts let advertisers withhold payment for installs later judged fraudulent, which is why clear fraud rules agreed before a campaign starts are general practice.

Prevention basics

General practice for keeping fraud in check:

• Use deterministic signals where available, such as the Play Install Referrer, rather than loose probabilistic matching.
• Keep windows short for sources with a history of low-quality traffic.
• Reject impossible timings, such as clicks after install begin.
• Validate revenue with the store or payment provider before counting it.
• Pay on events, not installs, where you can, so fake installs earn nothing.
• Watch cohorts: a source whose users never retain or pay is suspect, whatever its install count.
• Check that fraud protection is in your plan. Some MMPs include fraud protection on every tier, while others sell it as an add-on or reserve it for higher plans. The choosing an MMP chapter compares this.

Ad networks also clean their own data. Google, for example, removes some invalid conversions after the fact, so totals in Google Ads can fall slightly after they first appear.

For definitions of every term, see the glossary.