When you pay for installs, someone has an incentive to make installs appear, or to make real ones look like their work. Mobile ad fraud is the set of ways that happens. It rarely announces itself. Usually a source looks excellent in the dashboard, with cheap installs and plenty of volume, while the money and the players never quite show up.
There are two broad kinds. Attribution fraud steals credit for real users who would have installed anyway, often from organic search. Fake users invents installs and activity that never involved a real person. They show up differently and call for different responses.
How attribution makes fraud possible
Most Android and many web-driven campaigns use last-click attribution: when an app is opened for the first time, the install is credited to the most recent recorded click within a window, often several days. That is simple and mostly works, but it means whoever gets a click on record last gets paid, even when that click changed nothing. Much of the fraud below is a way to be that last click.
The main types
Click spamming
Also called click flooding. A bad actor generates huge numbers of clicks for people who never saw an ad, perhaps through an app running in the background or impressions reported as clicks. With enough volume, some of those people will happen to install your app, and the fraudster collects credit for an organic user.
The sign is a very low click-to-install conversion rate, combined with installs spread evenly across the whole attribution window rather than bunched soon after the click. Organic installs often fall when the source is switched on and recover when it is switched off.
Click injection
An Android technique. A malicious app on the phone notices that another app is being installed, then fires a click just before the install finishes, so it is the last click on record. It is more precise than spamming, and the user is still real. It usually steals credit from organic installs or other campaigns.
The sign is an abnormally short click-to-install time: a large share of installs arriving within seconds of the click, which is too fast for someone to see an ad, visit the store, download and open. Google's Play Install Referrer gives measurement systems timestamps for the click and the start of the install, so a click recorded after the install began can be rejected outright.
Install hijacking
Close to click injection, this is a broader term for a malicious app or a compromised step in the journey claiming credit for an install that another source drove. You may see it as one source's numbers rising at the exact rate another's fall.
SDK spoofing
Also called replay attacks. Rather than manipulate a real install, the fraudster sends made-up messages to the measurement servers, copying the format that the app's own measurement code would use. Nothing is installed, yet installs and even in-app events appear. Because the data can be built from real device details, it can look convincing.
The signs are installs that do not match store numbers, purchases with no valid store receipt, and unusually tidy event patterns. Signing the messages sent by the SDK, plus validating purchases with the store's own receipts, closes off a lot of this.
Fake installs and device farms
Real phones in racks, emulators, or scripts installing apps and pretending to use them. They can be programmed to reach whatever event you pay for, like a tutorial finish or a level, which is why paying on a shallow event offers less protection than it seems.
The signs are clusters of the same device model and OS version, unusual locations or data centre IP addresses, near-zero retention after a short burst of events, and no purchases or ad revenue.
Impression and placement fraud
This hits the ad itself: ads stacked on top of each other, shrunk to a single pixel, or shown in the background. You pay for impressions nobody saw, and those fake views can also feed view-through attribution. If you notice a high impression count with no matching engagement in a playable, this is one possibility.
Incentive misrepresented as organic intent
Rewarded user acquisition is legitimate when declared: people are openly offered a reward to try an app. It becomes a problem when that traffic is sold as ordinary non-incentivised traffic, because those users came for the reward, and their behaviour will look different.
How privacy changes on iOS affect it
Apple's SKAdNetwork and AdAttributionKit send attribution through Apple itself, with cryptographically signed postbacks. That makes it far harder to forge a claim or steal one the way click fraud does on Android. It does not remove fraud from iOS: it limits one route, and it gives you less user-level data with which to spot other problems. See AdAttributionKit vs SKAdNetwork.
How to investigate a suspicious source
- Plot click-to-install time for the source. A healthy curve rises soon after the click and tails off. A spike in the first seconds suggests injection, and a nearly flat line across days suggests spamming.
- Compare installs against store figures and against other sources. Ask whether total installs actually rose when this source started.
- Follow the users. Retention, revenue and events by source are hard to fake together. A source with lots of installs and almost no day 7 users deserves attention, though poor targeting can look the same.
- Look at the devices and locations. Check for unusual concentration of device models, OS versions, IP ranges or time-of-day patterns.
- Pause it, if you can, in a controlled way. If paid installs vanish and organic installs rise by a similar amount, the source was not bringing you anyone new. Incrementality testing makes this formal.
Suspicious does not mean proven
Low quality and fraud look alike in a chart. Bad targeting, an ad promising something the app does not have, or an unusual country mix can all produce poor retention. Bring the evidence to your partner and ask for an explanation before calling something fraud.
How to reduce it
- Use a measurement partner with fraud tools. Most mobile measurement partners can reject installs by rule, including click-time checks and known bad IP ranges, and some sign SDK traffic. Turn those protections on rather than assuming they are on by default.
- Optimise and pay on deep events. Revenue, purchases and long-term retention are expensive to fake. Paying for an install, or a shallow event like a tutorial finish, invites fakes.
- Validate purchases on the server. Check every in-app purchase receipt with the store before you count it as revenue, or before you pass it to any ad network.
- Shorten attribution windows for risky sources. A long window gives click spam more chance to catch an organic install. Keep it reasonable for the channel.
- Be careful with long reseller chains. Every extra layer between you and the inventory reduces what you can see. Ask where the traffic actually runs, and get source or placement reports.
- Put it in the contract. Agree on what counts as invalid traffic, how it will be measured, and how you recover payment for it, before you start buying.
- Watch for a suspicious lift in cheap volume. An offer that looks far better than your other partners may be real, but check before scaling.
Why it matters beyond the wasted money
Stolen credit is doubly harmful, because it distorts your decisions. If a fraudulent source claims organic installs, your report says it is your cheapest channel. You give it more budget and take budget from the channel doing the real work. Creative testing suffers too, since a winning ad can be one that simply caught the most stolen credit. Clean data is what lets you find out whether a new playable ad is actually better. That is why fraud checks belong in routine reporting rather than an annual audit.
Create playable end cards in minutes—no code required.
Open Playable Ads Maker