How Ad Fraud Shows Up in Mobile Game Data: 2026 Signals for Click Spamming, Click Injection, SDK Spoofing, and Device Farms, What MMP Tools Miss, and How to Structure Payouts

Ad fraud is anything that makes an advertiser pay for results that never happened, or that happened somewhere else. In mobile game UA it takes two forms. One steals credit for installs that would have come anyway, through organic discovery or another channel. The other manufactures installs and in-app events from users who don't exist.

The problem has not shrunk. The 2026 edition of AppsFlyer's The State of Fraud for Marketers, which covers 106.4 billion installs across 246,000 apps, found that Android's fraud rate stayed in a 14% to 15% range from Q1 2025 through Q1 2026, and that the absolute volume of fraudulent installs grew as marketing investment grew. Gaming's Android fraud rate was lower than average at 7%. But over the same period, emulator-based fraud in Android gaming fell 32% year over year while device-farm fraud rose 72%. Fraud is shifting from software that imitates devices to real devices run at scale, which pass device-authenticity checks more easily.

The impression side tells a similar story. In Pixalate's Q2 2026 benchmarks, published in August 2026, 41% of global programmatic mobile app impressions were invalid traffic (IVT), compared with 20% for web and 26% for CTV, and up from 33% for mobile apps in Q3 2025. These are impression-level figures, not install fraud rates, but they show that mobile app inventory is the most exposed environment.

As of November 2026, this article covers the main fraud types at the install and event stage, the signals that expose each one in a studio's own data, how far Android platform tools and MMP fraud tools go, and how contract and payout terms can reduce the economic incentive to commit fraud. We covered reward-driven fraud inside one specific placement, the offerwall, in How to Prevent Offerwall Fraud in Mobile Games: Understanding the Risk Is Where Effectiveness Begins. This article looks across all UA channels.

Where does mobile game ad fraud happen in 2026?

The core message of the 2026 data is that fraud concentrates in particular channel types, and that the assumption "we only need to watch paid channels" no longer holds.

Two numbers deserve attention. First, 80% to 84% of gaming fraud sits in the organic channel. Fake installs from bots and farms are mixed into installs that no ad network claimed credit for. They don't take ad spend directly, but they distort organic installs and retention, muddying incrementality judgments and lookalike seed data. Second, 87% of Android fraud consists of fake installs. Credit hijacking is still around, but by volume, users who don't exist dominate.

Fraud and low-quality traffic need to be kept apart. Users who know they'll receive a reward, or who churn quickly, may deliver weak results, but they aren't fraud. Fraud is misrepresenting what the traffic is: reporting something that isn't a person as a person, or reporting an install from another source as your own. Incentivized traffic is a disclosed traffic type, and its quality is something you manage through price and payout events. Blur the two and the rule becomes "cut any low-retention channel," while fraud that mimics retention slips through. We covered how to design and evaluate incentivized traffic in Incentivized Traffic for Games: A Strategic Approach to User Acquisition.

What types of ad fraud happen at the install and event stage?

Install- and event-stage fraud becomes much easier to detect once you split it into two branches: schemes that steal credit for real users' installs, and schemes that create fake users.

The definitions follow the AppsFlyer glossary. Click injection also makes the fraudulent source look better and the real source worse, so next month's budget moves the wrong way. SDK spoofing uses real device information and can forge purchases, which makes it especially dangerous for CPA campaigns.

The reason to split the two branches is that their data signals point in opposite directions. In credit theft the user is real, so retention and purchases look normal, and you have to catch it through timing data and shifts in organic installs. With fake users the timing can be dressed up convincingly, but post-install behavior doesn't look human, so you catch it through device composition and behavior patterns.

How do click spamming and click injection show up in your data?

Credit theft shows up first in the distribution of click-to-install time (CTIT) and in how organic installs move as a source's spend changes.

Normal traffic has CTIT heavily concentrated at the front. The AppsFlyer glossary notes that about 75% of installs happen within an hour of the click and about 94% within 24 hours. Against that baseline, two abnormal shapes stand out.

Click spamming produces a long, flat tail. Clicks sprayed in advance land inside the attribution window when a user installs the game for some other reason, so installs spread evenly across hours and days. AppsFlyer adds two more signals: a very low click-to-install conversion rate, and a source that shows up abnormally often as an assisting contributor in multi-touch data. The same glossary also notes that video ads and large apps naturally have longer CTIT, so a long CTIT alone is not proof.

Click injection does the opposite and piles up at abnormally short CTIT. Because the click is created just before the install finishes, a large game can show CTIT shorter than the download itself would take, which is a physically impossible sequence. On Android you can make this call from records rather than inference, because Google Play reports when the install began (see the next section).

Organic installs are a strong signal too. If installs from a source rise as you increase its spend, while organic installs fall by the same amount and total installs stay flat, that source is probably not bringing new users. It is putting its label on installs you were already getting. The reliable way to confirm this is a holdout or geo experiment. We set out the design in How to Design an Incrementality Test for Mobile Game UA: Holdouts, Geo-Lift, Sample Size, and Reading the Result.

Read CTIT at the sub-publisher (site ID) level, not as a network-wide average. Combined, the clean sources cover up the problem ones. The table below compares three sub-publishers within one network. It is an illustrative example and the figures are assumptions.

Sub-publisher C will probably show normal retention and purchases, because the users behind hijacked installs are real people who were going to install the game anyway. A team watching only cohort quality can mistake hijacking for a strong source; timing data is the only clue. For B, switching the source off for a week and watching what happens to total and organic installs will tell you fairly precisely whether it was adding anything. We explained why the same install gets counted differently across dashboards, and how attribution windows work, in Why Every Dashboard Shows a Different Install Count: A Game Marketer's Guide to Mobile Attribution in 2026.

Which signals catch bots, device farms, SDK spoofing, and fake events?

Fake users give themselves away through skewed device composition, inhumanly regular post-install behavior, and a sharp drop-off right after the payout event.

The retention cliff is the easiest signal to read. A real cohort drops sharply on D1 and then declines gradually. A fake cohort holds up unnaturally until the payout condition is met and then falls almost to zero. If the payout event is "reach level 10 within three days," you see a level-10 rate higher than other channels, alongside almost no level-11 completions and almost no D7 retention. When comparing channels, use the same retention definition (classic, rolling, or bracket) for all of them.

Event timing separates people from programs. Human play varies. Bots show near-identical gaps between levels and near-identical session lengths. SDK spoofing shows up, as AppsFlyer's warning signs suggest, as installs from SDK versions you don't use or install spikes that don't match your release schedule. Purchase events should be reconciled with server records that have passed store receipt validation. A purchase the SDK reported with no receipt behind it is a forged event.

None of these signals is proof on its own. New-device rates rise in new markets, model concentration is normal where low-cost phones dominate, and a retention cliff can mean the game simply doesn't suit that audience. The practical trigger for an investigation is two or three signals going wrong at once for the same sub-publisher.

What do Play Install Referrer and the Play Integrity API protect against on Android?

On Android, two official Google Play tools give you a basis for judging credit theft and fake devices. As of November 2026, Google's documentation says both should be used alongside other signals.

Google launched the Play Install Referrer API in 2017. It deprecated the old install_referrer intent broadcast on March 1, 2020 and asked developers to move to the API. At the time, the Android Developers Blog said the API uses a secure channel to the Play Store and is more robust against spoofing and attribution fraud. According to the developer documentation, the response includes the referrer URL, the referrer click time and the install begin time (each in client-side and server-side versions), and the app version at first install. The information is available for 90 days and doesn't change unless the app is reinstalled.

The key value is the install begin time. A genuine ad click has to come before the install starts, so there is no reason to credit a click recorded afterward. Server-side timestamps also guard against device clock manipulation. If you receive raw data, counting "clicks after install begin" by sub-publisher shows your exposure directly. Note that this applies only to installs that come through Google Play.

The Play Integrity API addresses the fake-user side. According to Google's documentation, it uses hardware-backed security signals to determine whether a request comes from your genuine app, installed from Google Play, on a genuine certified device. Opt-in verdicts add whether the device has recent security updates (MEETS_STRONG_INTEGRITY, Android 13 and later), whether apps that can capture or control the screen are running, recent device activity (recentDeviceActivity), and device recall (deviceRecall, in beta). Recent device activity counts the integrity tokens a device generated for your app in the last hour; Google notes that abusers often pass valid real-device verdicts to bots on rooted devices and emulators. Device recall lets you recognize a device you previously flagged even after a reinstall or factory reset, which maps directly onto farms that reset device IDs. The default quota is 10,000 requests per day across all installs, and you can request an increase.

The limits are clear as well. Google says not to use the Play Integrity API as your only anti-abuse mechanism, to observe how your existing audience's verdicts are distributed before enforcing, and to tier your response by trust level. Most importantly, device farms use real certified devices and can pass device integrity checks. AppsFlyer's finding that Android gaming fraud is moving from emulators to farms means device-authenticity checks are not enough on their own. You also need post-install behavior analysis.

What do MMP fraud tools catch, and what do they miss?

MMP fraud tools are strong at blocking known patterns in real time and at post-attribution detection based on post-install behavior. They are structurally weak against fraud hidden in organic traffic, credit with no incremental effect, sophisticated farms using real devices, and events with no server-side validation.

AppsFlyer says its product detects and blocks fake installs, bots, and click farms in real time, identifies fraudulent installs and events even after attribution, and lets teams use those findings to reconcile with media partners. Both layers matter because sophisticated fraud looks normal at install and reveals itself only in later behavior.

The last row causes the most trouble in practice. Even if the MMP flags fraud after attribution, you can only recover money already paid if the contract says which criteria apply, what detection deadline counts, and how deductions work. The tool produces evidence. The contract protects the money. MMP tools also catch invalid traffic, not real people who simply don't fit the game; that is a targeting and payout problem.

How should contracts and payouts be structured to reduce the incentive to commit fraud?

The most reliable way to reduce fraud is to pay for events that are hard to fake, give yourself time to detect problems, and write into the contract that detection results feed into settlement.

The first lever is payout event depth. Under CPI, the cost of producing one fake install is the fraudster's cost of goods, and farms and SDK spoofing can push that cost very low. Moving the payout to events that take real play and real time, such as tutorial completion, reaching a level, or hitting a playtime threshold, raises the cost of each fake user and pushes the payout later, giving post-attribution detection time to work. Some farms perform actions only up to the payout event, so set next-step conversion and D7 retention as quality conditions alongside it. If you pay on purchases, count only purchases that pass store receipt validation. We compared when to choose CPI and when to choose CPE in CPI Gets You Installs. CPE Gets You Players. Here's How to Choose.

The second lever is the validation window. Confirm payouts after detection results have had time to accumulate, not right after the install, and deduct anything flagged later from the next settlement. The deeper the payout event, the further past that event the window needs to run. The third lever is detection criteria and clawback terms. If the CTIT floor and ceiling, allowed countries, and app versions you set in your MMP's validation rules appear in the contract with the same numbers, detection and settlement will line up.

In AppsFlyer's 2026 edition, gaming's affiliate fraud rate nearly halved, from 29% to 14%. Fraud is a variable that depends on management, not a fixed cost. As an operating routine, we recommend reviewing CTIT distribution, click-to-install conversion, new-device rate, and conversion before and after the payout event by sub-publisher on a single sheet every week. Before each monthly settlement, reconcile the MMP's post-attribution report against Play Console installs and receipt records to confirm deductions. Each quarter, run a holdout or geo test on your main channels to check incrementality.

From this angle, it also helps to include in your comparison set a channel that can tie payout timing to real play. Playio is an Android-based community of 5 million people who love games. It uses genre preferences, play history, and in-game behavior data to connect games with gamers whose tastes match. CPI is the default pricing model, but Playio also supports CPE based on in-game actions such as tutorial completion, reaching a level, or hitting a playtime target. That lets you compare cohorts side by side with other channels on the same events and the same quality bar. We suggest applying the signal tables above to Playio cohorts as well.

You can find more details here. (https://playioadsen.oopy.io/bizdeck)

Key Takeaways

Mobile game ad fraud splits into credit theft (click spamming, click injection) and fake users (bots and emulators, device farms, SDK spoofing, fake in-app events), and the two produce opposite signals. Credit theft involves real users with normal retention, so you catch it with sub-publisher CTIT distributions (normally about 75% within an hour, about 94% within 24 hours), click-to-install conversion, organic shifts, and incrementality tests. Fake users show up in new-device rates, device composition, a retention cliff after the payout event, overly regular event timing, and SDK-versus-store mismatches. As of November 2026, AppsFlyer's 2026 edition puts Android fraud at a flat 14% to 15%, gaming Android at 7% with device-farm fraud up 72%, and 80% to 84% of gaming fraud in the organic channel. On Android, the install begin time in the Play Install Referrer API is the basis for detecting click injection, and the Play Integrity API helps against fake devices, though farms running real devices can pass it. MMP tools catch a great deal, but recovering money requires contract terms: payout events, quality conditions, receipt validation, a detection basis, a validation window, and clawbacks. The most fundamental defense is to keep fraud and low-quality traffic separate, and to pay for real play that is hard to fake.

For inquiries about Playio's advertising solutions, reach out at: [email protected]