Click Injection vs Click Flooding vs SDK Spoofing: A Taxonomy
Click injection and click flooding both steal attribution credit for installs the fraudster didn't drive. SDK spoofing and install farms manufacture the installs themselves. That's the whole taxonomy in one line: some attacks steal the credit for a real install, others fake the install. Each leaves a different fingerprint in a single number, the time between the last click and the install.
Last year I pulled a report for a mid-size gaming client who'd been happily scaling one sub-publisher on Android. The publisher looked great on paper. Cheap CPI, high install volume, decent day-1 retention. Then I bucketed their click-to-install times. Sixty-one percent of installs landed under eight seconds after the click. Real humans don't download, open, and register a game in eight seconds. That's not a traffic source. That's a rootkit sitting on the device firing a click the instant it detects a Play Store download. We clawed back a five-figure invoice and cut the partner the same afternoon.
Here's the thing about mobile fraud taxonomy. The scary-sounding names all blur together until you sort them by what the fraudster is actually forging. Once you do that, the detection signal for each falls out almost mechanically.
The one distinction that organizes everything
Attribution-stealing fraud needs a real install to exist. The fraudster's whole game is to be the last click of record before that organic or competitor-driven install completes, so the CPI payout routes to them. Click injection and click flooding live here. No fake installs, just hijacked credit.
Install fraud doesn't wait for a real install. It fabricates the event. SDK spoofing builds a signed payload that tells your measurement partner an install happened when no device ever ran your app. Device farms and install farms go one worse and run the app on racks of real (or emulated) hardware to survive behavioral checks. Here the install itself is the lie.
Why this matters for detection: you catch attribution theft by looking at the timing of the click relative to the install, and you catch install fraud by looking at the authenticity of the device and the signal. Different question, different signal, different fix.
| Attack | What it fakes | How it steals credit | The signal that catches it |
|---|---|---|---|
| Click flooding | A flood of clicks | Sprays huge click volume so it wins last-click on organic installs by luck | Flat, decay-free CTIT distribution; abysmal click-to-install conversion rate |
| Click injection | A single perfectly-timed click | Detects a download in progress and injects a click seconds before install completes | CTIT spike under ~10 seconds; clicks that arrive after install-begin |
| SDK spoofing | The install event itself | Replays or forges a signed payload to the MMP endpoint, no device involved | Broken or reused HMAC signatures; impossible CTIT; installs with no device telemetry |
| Device / install farms | Real-looking installs at scale | Runs the app on farms of devices or emulators to pass behavioral checks | Low device-attribute entropy; emulator fingerprints; reset-then-reinstall loops |
Every serious MMP runs some version of these checks. The value in knowing the taxonomy yourself is that you can read your own dashboards and argue with a partner before the postback clears.
Click flooding: spray clicks, pray one sticks
Click flooding, sometimes called click spam, is the low-effort end of attribution theft. The fraudster generates a massive volume of clicks for users who never actually engaged with an ad. Most of those clicks lead nowhere. But if one of those phantom-clicked users later installs the app organically, or after seeing a legitimate ad elsewhere, the flood's click can win last-touch attribution and grab the payout.
The tell is in the shape of the click-to-install time curve. Real traffic decays. Most genuine installs happen between 30 seconds and 2 hours after the click, with a long thin tail stretching toward 24 hours, per Opticks Security's breakdown of CTIT. Plot that and you get a curve that rises fast and falls off. Click flooding produces the opposite: a flat line. Equal install counts across every time bucket out to 24 hours, because the clicks were random and had no causal relationship to the installs.
Two more flooding signatures worth watching. The click-to-install conversion rate craters, because you're dividing real installs by an ocean of junk clicks. And the sub-publisher shows enormous click volume against modest install volume. When I see a source pushing millions of clicks with a 0.01% install rate and a pancake-flat CTIT chart, I don't need a fraud vendor to tell me what it is.
Click injection: the click that fires during the install
Click injection is click flooding's precise, nastier cousin. Instead of spraying clicks and hoping, the fraudster's malware sits on the victim's Android device and watches for install broadcasts. The moment it sees a new app being downloaded, it fires a click for that app. The click lands in the two-to-ten-second window right before the install finishes, so it wins last-click for an install the user was already making.
This is an Android story, mostly, and the reason is architectural. For years Android announced installs through a broadcast intent that any app on the device could hear, which is exactly the hole injection exploited. Google's Play Install Referrer API closed it. The API returns three fields straight from Google Play rather than from a device broadcast: the referrer URL, the referrer click timestamp, and the install-begin timestamp. That install-begin timestamp is the weapon. It marks when the download actually started, so any click that arrives after install-begin can't have caused the install. It's physically too late.
Subtract referrer-click time from install-begin time and you have CTIT computed from a source the fraudster can't touch. Opticks puts a usable threshold on it: if more than 40% of a sub-publisher's installs show CTIT under 10 seconds, you're almost certainly looking at injection. My gaming client's 61% wasn't subtle. Most real cases sit at 45-55% and still hold up.
One caveat the vendor docs gloss over. On iOS there's no Install Referrer equivalent, and post-ATT the timing signal is muddier because much of measurement moved to SKAdNetwork's coarse, delayed postbacks. Injection as classically defined is largely an Android problem. iOS fraudsters mostly moved to faking the install outright, which brings us to the second half of the taxonomy.
SDK spoofing: skip the device, forge the receipt
SDK spoofing is the one that unsettles engineers, because it doesn't need a victim, a device, or a real install anywhere in the loop. The attacker reverse-engineers your measurement SDK's communication with its backend, then constructs valid-looking payloads and sends them straight to the attribution endpoint. Each payload claims an install (or an in-app purchase) that never happened.
There are two flavors. Replay captures one legitimate signed request and re-sends it repeatedly inside the signature's validity window. Forge goes deeper, extracts the signing salt from the SDK, and mints brand-new signatures at will. AdSafee's technical writeup on SDK spoofing detection describes the standard defense well: MMPs sign each request with a hashed signature keyed on a salt that rotates roughly every 24 hours, with a 60-to-120-minute overlap so in-flight requests aren't dropped at the boundary. Rotate the salt and any secret a fraudster extracted becomes worthless within a cycle. Replay attacks die the same way, because a captured signature expires.
When forgery does slip through, the CTIT signal catches what the signature missed. Spoofed installs cluster at suspiciously precise intervals, or arrive at a CTIT that's flatly impossible, sometimes before the click timestamp. No physical install does that. Add device-level telemetry checks, because a spoofed install has no sensor data, no real session, no crash logs, nothing that a phone actually produces.
The scale here isn't theoretical. iOS fraud used to run heavy on store validation fraud, fabricating App Store receipts to claim credit for fake installs. According to RocketShip HQ's summary of AppsFlyer's 2025 fraud data, that receipt-faking accounted for up to 73% of detected iOS fraud in 2025 before fraudsters started blending it with fake in-app behavior to dodge detection.
Device and install farms: real hardware, fake intent
The brute-force option is to just install the app for real, thousands of times, on racks of phones or emulators. These installs pass a lot of naive checks because there's a genuine install event and a genuine (if throwaway) session. Roughly 46% of mobile fraud traces back to bots and install farms, per 24Metrics' 2025 mobile fraud trends.
You catch farms with entropy and fingerprints, not timing. Real user bases have messy, high-entropy device attributes: a wide spread of models, OS versions, screen sizes, locales, carriers, IP ranges. A farm collapses that spread. You'll see the same handful of device models, factory-reset device IDs cycling through install-uninstall-reinstall loops, missing hardware sensors that betray an emulator, and custom ROMs or debugging flags that a normal retail phone never ships with. When a "region" of your acquisition suddenly shows a thousand installs from four device models and one IP block, that's not a market. That's a warehouse.
Reading a CTIT chart the way an analyst does
If you internalize one artifact from this whole taxonomy, make it the CTIT histogram per sub-publisher.
Healthy sources look like a wave. A sharp rise in the first couple of minutes, a peak somewhere under an hour, then a decaying tail. Injection dents the left wall of that chart with an ugly spike under 10 seconds. Flooding flattens the whole thing into a plateau. Spoofing pokes impossible bars into the timeline, including anything at or before zero. You can eyeball all three before you've read a single fraud-vendor label.
I'd pair that with a second habit: never judge a partner on blended numbers. Fraud hides in the sub-publisher breakdown. A source can look clean at the aggregate and be 90% injection inside one bundle ID. Segment, then look at CTIT, then argue.
If you're building the detection into your own stack rather than outsourcing it wholesale, it's worth thinking about where the timing signal and the device signal actually live in your pipeline. I sketched that layering in our privacy-first attribution reference architecture, since the same install-begin timestamp that catches injection is also the one that survives privacy changes.
How big is the bill, really
Numbers vary wildly by source and methodology, so treat any single figure as a rough order of magnitude. Juniper Research put global mobile ad fraud losses at $17.2 billion for 2025, as compiled by Business of Apps. AppsFlyer's data has around 22% of non-organic installs carrying fraud signals through 2025 into 2026. The one stat that reframed how I audit accounts: organic traffic is now the single largest channel for fraudulent installs, at 52% of the total. Fraud migrated to the bucket nobody scrutinizes, precisely because nobody scrutinizes it.
One genuinely good piece of news from that same data set. iOS fraud dropped about a third year over year, from 17.5% in Q1 2025 to 11.7% a year later, crossing below Android for the first time. ATT and the SKAdNetwork plumbing, whatever else you think of them, took some oxygen away from the easy attacks.
FAQ
Is click injection worse than click flooding? Per fraudulent install, yes. Injection almost always wins last-click because its timing is surgical, so it steals a higher share of the installs it targets. Flooding is spray-and-pray and mostly wastes its own clicks. But flooding scales cheaper, so at the campaign level either can dominate your wasted spend.
Does CTIT catch SDK spoofing? Sometimes. A careful spoofer sets a plausible CTIT, so signatures and salt rotation are the first line, not timing. But sloppy spoofing produces impossible CTIT values, including installs timestamped before their click, and those it catches instantly.
Is mobile ad fraud mostly an Android problem? It was. Android historically ran roughly several times the iOS fraud rate, largely because the old install broadcast enabled injection. That gap closed in 2025-2026 as iOS fraud fell and Android's exploit surface narrowed. Both platforms have plenty of install fraud now.
Can my MMP block all of this automatically? It blocks a lot of it, and it should. What it can't do is know your business. Thresholds that make sense for a hyper-casual game are wrong for a banking app with a 20-minute onboarding. Read your own CTIT charts so you can tune, and challenge, what the platform decides.
Sort every new fraud buzzword by the same question and you'll rarely be lost: is the fraudster stealing credit for a real install, or faking the install? The first shows up in timing. The second shows up in the device. Everything after that is which chart to open.