Mobile ad fraud prevention means stopping fake activity before it earns attribution, ad revenue or an in-app reward. Most fraud follows a handful of schemes: click injection and click spamming steal credit for installs, SDK spoofing forges installs that never happened, device and emulator farms produce fake users at scale, and automation farms rewards. Platform records settle many cases on their own. App signals fill the gap by telling your backend whether a real person ran a genuine copy of your app on a real device when the event was reported. This article explains each scheme, what catches it, and how to respond without penalising real users.
How the schemes work
Advertising pays for outcomes it cannot see directly. An attribution provider decides which ad gets credit for an install, usually the last click before it. A rewarded ad grants coins or lives when a view completes. Each decision rests on reports that a fraudster can try to fake, time or repeat.
| Scheme | What the fraudster fakes | What it steals |
|---|---|---|
| Click injection | A click fired just before an install finishes | Credit for an install that would have happened anyway |
| Click spamming | Large numbers of clicks for people who never saw an ad | Credit for organic installs |
| SDK spoofing | Install and event reports sent from a server, with no app involved | Payment for installs that never happened |
| Device and emulator farms | Many “users” from racks of phones or virtual devices, with identifiers reset between runs | Install payouts and rewards |
| Automation | Taps and views produced by scripts, auto-clickers or hooked code | Ad revenue and engagement payouts |
| Reward farming | Rewarded views and offer completions repeated at scale | In-app currency, items and referral bonuses |
Click injection
Click injection is an Android scheme. A malicious app already on the phone watches for another app being installed. Just before the new app opens for the first time, it fires a click to the attribution provider, so it becomes the last click and takes the credit.
User installs an app
From Google Play, after an organic search or a genuine ad.
Malware sees the install
An app already on the phone notices the new package.
Injected click
It reports a click before the first open, becoming the last click.
Referrer timestamps
The Play Install Referrer shows the click arrived after the install began.
Credit refused
The attribution decision rejects clicks that follow install start.
The Google Play Install Referrer API returns when the referrer click happened and when the install began. A click that arrives after the install began cannot have caused it. Make sure your attribution set-up uses those timestamps.
Click spamming
Click spamming fires clicks for huge numbers of devices, often from an app or page running in the background. Some of those people install the advertised app later by themselves, and the spammer collects credit. The pattern is visible in aggregate: many clicks, few installs, and a long, flat spread of time between click and install.
SDK spoofing
In SDK spoofing, the fraudster studies the traffic an attribution or ad SDK sends, then forges the same reports from a server. No phone and no app are involved. Signed SDK requests raise the bar. Stronger still, platform attestation lets your server ask whether a request came from your genuine app: the Play Integrity API on Android and App Attest on iOS. A report without a valid attestation, or with one bound to a different request, deserves no credit.
Farms, automation and reward farming
Device farms use real phones; emulator farms use virtual devices. Both reset advertising and device identifiers between runs so each pass looks like a new user. Automation drives taps through scripts, auto-clickers built on Android accessibility services, or hooking frameworks that call the app’s own ad and reward code directly. Reward farming points all of this at rewarded ads, offerwalls and referral schemes, where the payout goes to the fraudster’s accounts.
For rewarded ads, use your ad network’s server-side verification callback where it offers one. Your server then learns about a completed view from the network itself and stops trusting a “reward earned” message from the client alone.
What Apple and Google already give you
On iOS, App Tracking Transparency and Apple’s privacy-preserving attribution changed how installs are attributed. Apple-signed postbacks make some forgery much harder, because the fraudster cannot sign them.
- March 2018
SKAdNetwork in iOS 11.3
Ad networks sign ads and receive install-validation postbacks from Apple.
- April 2021
App Tracking Transparency enforced in iOS 14.5
Apps must ask permission before tracking people across other companies' apps and websites.
- March 2024
AdAttributionKit in iOS 17.4
A newer attribution framework that works across the App Store and alternative marketplaces.
Platform records answer “was this install attributed correctly”. They do not answer “was the person who earned this reward real, on a genuine device, using an unmodified app”. That second question is where app signals help.
Where app signals help
The app sees its own process and its own environment. Your backend sees accounts, ledgers and attribution records. The ad network sees serving and click history. Each covers a different part of the decision.
The app can tell you
- Whether it is running on an emulator or virtual device
- Whether taps came from an automation tool rather than a touch
- Whether its ad and reward code is hooked
- Whether it is a repackaged copy with swapped ad identifiers
Other systems must tell you
- Whether the click came before the install began
- Whether the ad network confirms the completed view
- Whether this reward was already granted
- Whether the account's history fits the claim
Otukan recognises emulators and virtual devices used to collect rewarded views or generate installs, detects hooks on the code paths that report ad views and clicks, and recognises repackaged copies of your app, including copies with replaced ad identifiers. On Android, it also detects accessibility services and input tools that produce taps without a user’s touch. Otukan attaches a session verdict to rewarded views, clicks and first opens sent to your backend, so the decision is made before value is granted. For the product view, see click and ad fraud.
Respond before value is granted
The best place to stop ad fraud is the point where a reported event becomes something valuable: credit, payout or reward. Write down what makes an event eligible before credit is given: the session it belongs to, the source it came from, and a single operation reference so a retry is never counted twice.
- Hold, do not punish. Keep a flagged reward pending while the server checks it. Ads and the rest of the app keep working.
- Withhold the payout, not the account. A farmed reward is refused; the account stays open unless other evidence supports more.
- Never ask for another ad click. A recovery path must not create more billable traffic or teach people to repeat a suspicious action.
- Use the provider’s process. Where your team does not control settlement, record the evidence and use the ad network’s documented review route.
Test it safely
Run every test against test ad units, a non-billable placement or your own event collector. Never generate fake activity against live ads to see what happens.
| Test | Boundary you are checking | Legitimate comparison |
|---|---|---|
| Submit the same reward event twice | Duplicate handling before credit | A retry after a dropped connection |
| Send an event without a valid session | Session and eligibility checks | Normal session renewal |
| Change the reward amount in a test client | Server validation of client fields | A real higher-value placement |
| Drive the reward flow from an emulator | Emulator signal and server policy | Your own QA emulators, allow-listed |
| Tap with an auto-clicker | Automation signal and reward hold | A screen reader or switch access user |
Before your next release
- Attribution uses install referrer timestamps on Android and signed postbacks on iOS.
- Rewarded ads use server-side verification wherever the network offers it.
- Every reward and conversion carries an operation reference and is granted once.
- App signals travel with the reward, conversion or first-open request they describe.
- Android and iOS results are recorded separately.
- Accessibility users, retries and interrupted sessions complete the flow without a false hold.
Purchase and in-app currency abuse is covered on purchase and reward abuse.
Further reading
- Google Play Install Referrer — Android Developers
- Overview of the Play Integrity API — Android Developers
- Establishing your app’s integrity — Apple Developer Documentation
- AdAttributionKit — Apple Developer Documentation
- Validate server-side verification (SSV) callbacks — Google AdMob
- Invalid traffic — Google AdSense Help