Click Injection, Click Spamming & SDK Spoofing: The Three Frauds Everyone Confuses

Mobile attribution runs on a rule so simple it fits in three words: last click wins. Whoever delivered the final click before an install gets the credit, and the payout.

An entire criminal economy exists to be that last click.

The three techniques that economy uses get discussed as if they were interchangeable — three names for "mobile ad fraud". They are not. They differ in method, in cost, in who is being deceived and, most usefully, in how you catch them. Defend against the wrong one and you will congratulate yourself on filters that the actual attack walks straight past.

Click spamming: the brute-force approach

Click spamming — also called click flooding — is the least sophisticated and, by volume, still among the most common. The method is exactly what the name suggests. The fraudster generates enormous quantities of clicks that no human ever made, attributed to thousands or millions of device identifiers, and waits.

The bet is statistical. Somewhere in that flood, some of the fake clicks will happen to be associated with a device that genuinely installs the advertised app during the attribution window — typically seven days. When the install fires, the measurement partner looks for the most recent click and finds the fraudster's. The install was organic. The credit is not.

The device identifiers matter here, and they are the part people underestimate. These are not invented strings. They are real advertising IDs, harvested at scale from ad exchange traffic and from SDK data — every ad request a device makes carries its identifier, and a party sitting in the request path sees a great many of them. The fraudster is not guessing which devices exist. They know, because those devices announced themselves.

That is why click spamming survives naive filtering. The clicks reference real devices with real identifiers in plausible geographies. What is fake is the human intent behind them.

The economics that keep it alive

Click spamming is cheap in the way that matters: the marginal cost of one more fake click is approximately nothing. There is no device to compromise, no malware to distribute, no app to get past store review. It is HTTP requests, and HTTP requests are free at the scale that counts.

That asymmetry is why the technique refuses to die despite being the crudest of the three. A fraudster who captures even a small fraction of a percent of a large app's organic installs is profitable, and the cost of being wrong on the other 99.9% of clicks is zero. Nobody pays for an unattributed click.

It also explains the volumes involved. When the hit rate is deliberately near-zero, the only lever is volume, so a spamming operation produces click counts that look absurd next to the installs they claim — thousands or tens of thousands of clicks per attributed install. That ratio, conversion rate, is the first thing to look at on a source you are suspicious of, and it is usually visible in an MMP dashboard without any special tooling.

Why advertisers rarely notice on their own

The insidious property of click spamming is that it steals credit for installs that were going to happen anyway. The advertiser's install count does not look wrong — the installs are real. What changes is the attribution mix, and the budget quietly reallocating toward the fraudulent source because it appears to be the best performer.

A campaign can look like it is working beautifully while paying for organic growth it already had.

There is a second-order effect that makes this worse over time. Attribution data feeds optimisation. A source that appears to convert well gets more budget, and more budget means more clicks, which means more organic installs captured, which improves its apparent performance further. The feedback loop rewards the fraud specifically because the fraud is invisible to the metric doing the rewarding.

Click injection: the surgical version

Click injection solves the accuracy problem that click spamming brute-forces. Rather than firing millions of clicks and hoping, it fires exactly one — at exactly the right moment.

The mechanism is Android-specific and depends on the operating system being helpful. Android broadcasts system events, including events around package installation. An app already on the device, carrying the malicious code, listens for those broadcasts. When it detects that a new application is being installed, it fires a click referencing that app, milliseconds before the install completes.

The measurement partner then does exactly what it is supposed to do: it looks for the last click before the install and finds one, timestamped a fraction of a second earlier. Attribution goes to the fraudster.

That last point deserves emphasis, because it inverts the usual detection instinct. With most ad fraud you are hunting for something fake in the traffic. With click injection there is nothing fake in the traffic at all. The user is real, the device is real, the install is real, the engagement afterwards is real. The fraud is a single injected event in a sequence of otherwise honest ones, and it hides inside genuine activity precisely because that activity is genuine.

What the malware actually needs

Click injection has a prerequisite that click spamming does not: code already running on the victim's device. Usually that arrives as an app which does something genuinely useful — a flashlight, a battery tool, a file manager, a small game — and which also happens to register a broadcast receiver it has no legitimate reason to need.

This is why permission and behaviour audits matter more than they appear to. An app requesting the ability to know when other apps are installed, with no feature that could plausibly use that information, is describing its business model whether it means to or not.

Google has narrowed the surface over successive Android releases, restricting install broadcasts and tightening what background apps can observe. That has raised the cost of the technique without ending it — as with every defensive change in this field, it filtered out the least capable operators and left the ones willing to keep up.

SDK spoofing: no clicks, no installs, no devices

SDK spoofing is the most technically demanding of the three, and the most complete. It does not hijack real activity. It manufactures activity that never happened.

Attribution works because a measurement SDK inside an app reports events — install, first open, registration, purchase — to the measurement provider's servers. Those reports are signed, because an unsigned report would be trivially forgeable. The provider signs a payload containing the timestamp, the click identifier, the network identifier and device parameters, using an HMAC and a rotating salt that only its own servers know.

The attacker's job, therefore, is not to fake a device. It is to reverse-engineer the signing scheme. Once the payload structure and the salt derivation are understood, the fraudster can generate valid, correctly signed payloads on their own servers — no phones, no emulators, no clicks — and post them straight to the attribution endpoint.

If the signature validates, the provider records an install. The advertiser pays for it. No app was ever downloaded.

Why this one scales so brutally

Every other fraud in this article is bounded by something physical. Click spamming needs harvested device identifiers. Click injection needs malware installed on real handsets, one at a time. Both have a ceiling set by how much of the real world the attacker has managed to touch.

SDK spoofing has no such ceiling. Once the signing scheme is understood, generating one fake install and generating a million are the same job with a different loop count. The constraint stops being access to devices and becomes only plausibility — how many installs can be claimed before the numbers stop resembling anything an app could actually be experiencing.

That is also the defence. Because the fraud is unconstrained by reality, it tends to drift away from reality: install volumes that do not correspond to store rankings, device models in proportions that do not match the market, event sequences with suspiciously little variation between users, geographies that do not match where the app is actually promoted.

There is a defensive property worth understanding here. Because the whole attack rests on the signature scheme, a provider that rotates its salt frequently and per-app forces the attacker to re-derive it continuously. That does not end the attack, but it changes it from a one-time reverse-engineering job into an ongoing operational cost — which is the most reliable way to make a fraud unprofitable.

The arms race nobody talks about

There is an uncomfortable dynamic in how spoofing gets fought. The measurement partner cannot publish how its signing works, because publishing it hands the attacker the specification. So the industry's most technically serious fraud is also the one with the least public documentation, and advertisers are asked to trust a defence they cannot inspect.

That is a defensible position — the alternative genuinely is worse — but it has a cost worth naming. It means an advertiser cannot independently verify that their measurement partner's signature scheme is sound, and it means comparing two vendors on this dimension is close to impossible. You are choosing on reputation, not on evidence.

How you actually catch them: the timing distribution

Here is the single most useful idea in this article, and it generalises well past mobile.

Click-to-install time — CTIT, the gap between the recorded click and the install — is the signal. Not because any one value proves anything, but because the shape of the distribution does.

The short tail: injection

A genuine install takes time. A person taps an ad, waits for the store page, decides, taps install, waits for the download, waits for the install to complete. Even on a fast connection with a small app, that sequence takes several seconds; five to ten seconds is a reasonable working floor.

An install recorded one or two seconds after the click is not a fast user. It is almost certainly an injected click fired during an install that was already in progress. The distribution near zero is where injection lives, and it is the easiest fraud in this article to detect once you know to look.

The long tail: spamming

Click spamming produces the opposite anomaly. Because the fake clicks are fired independently of any real user action, the gap between click and install is essentially random within the attribution window — hours, sometimes days. A source whose CTIT distribution is spread flat across seven days is not converting users; it is catching organics.

The tell that catches machines generally: uniformity

The most transferable idea here has nothing to do with mobile. Humans produce messy distributions. Some people install immediately, some get distracted, some come back after dinner. Real behaviour has variance, and that variance has a characteristic shape — a peak somewhere sensible with a long, irregular tail.

Machines produce uniformity. A generated distribution is usually too smooth, too evenly spread, or too tightly clustered — because it came from a loop with a delay parameter rather than from thousands of independent human decisions.

Note what the CTIT approach does not catch: SDK spoofing. A forged payload carries whatever timestamp the attacker chose, so it can present a perfectly plausible CTIT. Catching spoofing means validating the signature scheme and watching for statistical impossibilities in the reported data — devices that never appear anywhere else, event sequences with no variation, install volumes that do not correspond to any observable app-store activity.

Why averages hide all of this

A single number cannot express any of the shapes above, and reporting on attribution fraud is almost always delivered as single numbers. An average CTIT of forty seconds is consistent with a healthy campaign; it is equally consistent with half the installs arriving at one second and the other half arriving at eighty. The mean is the same. One of those campaigns is being robbed.

This generalises past mobile, and it is worth carrying into any conversation about traffic quality: when someone gives you an average as evidence that a source is clean, they have not answered the question. Ask for the distribution. If they cannot produce one, they are not measuring what they claim to be measuring.

What to actually do with a suspicious source

The practical sequence, in the order that costs least:

1. Look at conversion rate first. Clicks per install is free to check and catches crude spamming immediately. A source three orders of magnitude off the campaign average is not a slow-converting audience.
2. Then look at CTIT shape, not the average. An average CTIT is nearly meaningless — a bimodal distribution of injected clicks and genuine ones can average out to something entirely reasonable. The histogram is the artefact that matters.
3. Then look at what happens after the install. Fraudulent installs tend to have thin or absent post-install behaviour, because generating convincing ongoing engagement costs the fraudster real effort for no additional payout. A source with normal install numbers and near-zero day-7 retention is telling you something.
4. Only then argue with the network. Arriving with a distribution and a retention curve is a different conversation from arriving with a suspicion.

Why a web publisher should care about any of this

Most publishers reading this do not run mobile install campaigns. The reason it belongs in a publisher's mental model anyway is the principle underneath, which is the most durable idea in fraud detection generally:

A click can claim any device, any geography, any referrer. A signed payload can claim an install that never occurred. What none of them can easily fake is a coherent behavioural distribution across thousands of events — because doing so requires modelling human variance, and generated variance almost always looks generated.

The same logic drives traffic-quality detection on the open web. A session can declare a residential IP, a normal browser and an Indian city. What is harder to fabricate is engagement depth that matches the click pattern, a timing distribution that looks like a population rather than a loop, and a traffic-source composition that changes at a speed an audience plausibly changes at.

That is the design principle rather than a claim about results — but it is the reason detection works at network level in a way it cannot inside a single account. A distribution needs a population to be a distribution.

The same three questions, for web traffic

Translated out of mobile, the questions this article's detection logic asks are:

• Is the ratio plausible? Clicks per install becomes clicks per session, sessions per user, pages per session. Any ratio wildly off the property's own baseline is the cheapest possible signal and almost nobody checks it weekly.
• Is the distribution human-shaped? Session length, time-of-day, gaps between visits. Real audiences produce lumpy, irregular curves. Generated traffic produces curves that look designed.
• Does the behaviour after arrival match the behaviour on arrival? A visitor who clicked like an interested reader and then behaved like nothing at all is the web equivalent of an install with zero day-7 retention.