- Attribution fraud and web-side invalid clicks are not the same problem. The former takes credit rather than budget: the install is genuine, it simply should not have been attributed to that source.
- Click flooding is a volume strategy; click injection is a timing strategy. Flooding blankets as many devices as possible and waits for some of them to install on their own; injection fires one click at the moment an install has already begun, arriving at the head of the queue.
- The click-to-install time distribution is the most discriminating single signal, because it has a physical lower bound. Leaving an ad, reaching a store listing, downloading, installing and opening rarely takes a real user less than a dozen seconds; injected clicks cluster in the single-digit seconds.
- Volume on its own carries almost no information, since an effective source and a fabricated one both produce large numbers. The discriminating information is in the distributions: intervals, dispersion of device models and OS builds, the click-to-install ratio, and whether anyone opens the app again the next day.
- The larger cost is contamination rather than the money itself. Budget follows measured performance and automated bidding learns from the same conversion feed. Correcting the spend is quick; retraining a bidding system on a corrected signal is not.
Why this is a different problem from web-side invalid clicks
Web-side invalid clicks share a common structure: an ad is clicked, money is charged, and the party clicking never intended to buy anything. The loss is direct and additive, and the response is reasonably clear — identify the traffic, seek a credit, block the source. The full version of that logic is set out in what click fraud is, with the vocabulary defined precisely in click fraud terms explained.
The mobile attribution side is structured differently. App campaigns usually settle on installs rather than clicks, and which source receives an install is decided by a last-click-within-the-window rule. The rule itself is reasonable, but it has an exploitable property: what it evaluates is the timestamp on a click record, not whether that click had any influence on the user's decision. The problem therefore shifts from manufacturing clicks that consume a budget to arranging for genuine installs to land inside someone's attribution window.
Two consequences follow. First, the numbers do not look anomalous; they look excellent, because the stolen installs come from real users whose retention and downstream behaviour may be entirely normal. Second, the damage is not confined to one channel's budget. Organic installs get counted as paid, paid sources take credit from one another, and eventually every allocation decision in the account rests on a distorted measurement. The formal industry grading of this class of traffic is covered in GIVT versus SIVT.
Click flooding: covering the probability space with volume
Click flooding, also called click spamming, works from a simple observation: if attribution follows the last click, then submit click records for as many devices as possible regardless of whether those devices were ever shown an ad. The reports can originate from a background request inside an app, a hidden element on a web page, or a script embedded in some inventory slot. The user is doing something entirely unrelated, and in the course of it their device identifier is written into a batch of ad click records.
Then it becomes a matter of probability. Some share of those devices will, over the following hours or days, install the app for reasons of their own — a recommendation seen elsewhere, a friend mentioning it, or a genuinely effective campaign on another channel. If that install falls inside the attribution window and the flooded click is the most recent one on record, the install is credited to the flooder.
Flooding leaves a characteristic shape: enormous click counts against a very low conversion rate, together with a click-to-install interval distribution carrying a long, heavy tail, with substantial numbers of installs landing hours or even a day or two after the click. Real ad clicks concentrate near the front with a thin tail. A flooded distribution is close to flat, because there is no causal relationship between the click time and the install time at all — only the window length constraining it.
Click injection: winning the queue on timing
Click injection addresses the efficiency problem in flooding. Flooding has to submit an enormous number of clicks to capture a small number of installs, which is expensive and highly visible. Injection instead relies on an app already present on the device that can observe that another app has begun installing — on some platforms the installation process broadcasts signals that installed apps can receive. Having observed it, the app submits a click record during the short window before the install completes.
The timestamp on that click is therefore always later than any advertisement the user genuinely clicked, and earlier than the completion of the install. Under a last-click rule it sits at the head of the queue and takes the install. The conversion rate on injected clicks approaches one, because a click is only ever fired once the install is already certain to happen.
That property is also what makes injection comparatively easy to identify. The click-to-install interval has a physical floor: the user has to leave the ad, reach a store listing, start a download, wait for the transfer, complete the installation and open the app. Even on a good connection that sequence rarely compresses below a dozen seconds or so, and genuine intervals are dispersed across a wide range. Injected intervals cluster in single-digit seconds, because the click was created after the download had already started. A source with an unusual proportion of installs in that band is difficult to explain any other way.
Forced clicks: interactions the user did not choose
Forced clicks are interactions recorded as a click that the user did not choose to make. Common forms include a transparent layer over an entire page or player area so that any touch triggers a redirect, a close control whose actual hit area sits on the advertisement, an interstitial appearing at the instant a finger is already descending, or an automatic jump to a store listing at the end of a video without any interaction at all.
From an advertiser's perspective a forced click causes two losses at once. The click itself may be chargeable while the user has no interest in the product, which is structurally the same as web-side invalid clicks. The click also enters the attribution queue, so it competes for installs that were going to happen anyway, which is structurally the same as flooding. Forced clicks and flooding are consequently hard to separate in the data, and the main difference is whether a genuine impression record exists on the device side.
A further observable characteristic of forced clicks is a collapse in post-click dwell time. Where the path includes a landing page, users carried there involuntarily return almost immediately, and dwell times bunch at one or two seconds. The same signal applies on the web-side affiliate case, and how to read those distributions is covered in how affiliate click fraud is detected.
SDK spoofing: when the install itself is not real
The three mechanics above share one property: the install genuinely happened and only the credit is wrong. SDK spoofing is a different category. It fabricates the communication between a measurement SDK and its server, generating installs and subsequent events from nothing, with no requirement that the device exist at all. The usual approach is to analyse the structure of genuine traffic and then replay constructed requests at volume so the server records a batch of installs.
The main defence measurement platforms apply here is signed communication with rotating keys, so that requests cannot simply be replayed. That defence works well, but it is a continuing contest rather than a settled problem. What an advertiser can usually observe is the regularity of the event sequences: fabricated event streams tend to be too clean, with every install triggering an identical sequence at even intervals and none of the abandonment and out-of-order behaviour that real populations produce. Genuine behavioural data is messy, and excessive tidiness is itself a signal.
The signals that separate the four
In practice the workable method is to read several distributions per source rather than to look at whether one metric is high or low.
The click-to-install interval comes first. Injection appears as an anomalous mass in the single-digit seconds; flooding appears as a very long flat tail; a normal source produces a front-loaded curve over a plausible range. That distribution alone will often separate injection from flooding.
The ratio of clicks to installs comes second. Injection produces an implausibly high ratio because it only acts when success is certain; flooding produces an implausibly low one because it trades enormous volume for a few hits. Extremes in either direction are worth investigating, and a middling value proves nothing.
Dispersion across device and environment comes third. A real audience spreads across handset models, OS builds, screen sizes, languages and regions. Heavy concentration is not automatically fabrication — some markets genuinely have a dominant handset — but it requires an explanation. Where the line falls between data-centre traffic and ordinary users is less intuitive than it appears, and it is covered in identifying bot traffic.
Post-install behaviour comes fourth and is the hardest to fabricate. Installs whose credit was stolen come from real users, so retention and usage look normal. Installs produced by SDK spoofing have no user behind them, and next-day opens, deeper events and payment behaviour collapse together. Putting install counts next to next-day active counts, by source, usually says more than any single anti-fraud metric.
What automated filtering catches, and what it does not
The major measurement platforms all apply a filtering layer, principally by rejecting installs whose interval falls under a threshold and by discounting sources with implausible click volumes. That layer is quite effective against unsophisticated activity and removes a large share of it. Its boundary is also clear: thresholds are inferable, and an operation that deliberately keeps its timing above one will pass consistently. The same applies to keeping click volume inside an unremarkable band to avoid volume-based checks.
The reasonable position is to treat platform filtering as a first layer rather than the whole defence. It is worth reading the same distributions independently on the advertiser side, particularly once they are broken out by source, because platform filtering applies global rules while anomalies frequently hold only within a few sub-sources. How the protective layers fit together is covered in click fraud protection, and the full definition and scope of invalid traffic in what invalid traffic is.
A final point about the structure of the cost. The misattributed spend can be quantified and often partly recovered, and that loss is bounded. The expensive part is the distortion of decisions. Budget follows measured performance, so a source taking credit for organic installs looks extremely efficient and keeps attracting more of it, while genuinely effective sources look mediocre by comparison and get cut. Automated bidding is learning from the same contaminated conversion feed. Spend can be adjusted within a day; a bidding system that has learned from a distorted signal takes considerably longer to recover. The policy dimension of the same issue is covered in invalid clicks in Google Ads.
FAQ
What is the difference between click flooding and click injection?
Flooding is a volume strategy and injection is a timing strategy. Flooding submits click records for large numbers of devices that were never shown an ad, waiting for some of them to install on their own so that the flooded click is the most recent one. Injection uses an app already on the device to detect that an install has started and fires one click just before it completes, arriving at the head of the attribution queue. Flooding shows enormous click counts with a very low conversion rate; injection shows very few clicks with a very high one.
Why is click-to-install time the most useful signal?
Because it has a physical floor. A real user must leave the ad, reach a store listing, start a download, wait for the transfer, install and open the app, and even on a good connection that rarely compresses below a dozen seconds, with genuine values dispersed over a wide range. Injection compresses the interval to a few seconds because the click was created after the download had begun, so an unusual mass at the very short end is hard to explain otherwise. Flooding produces the opposite shape, a flat tail extending to hours or a day or two.
Does a high install volume from one source prove there is a problem?
No. A total carries almost no information, because an effective source and a fabricated one both produce large numbers. The information is in the shape behind the total: click-to-install intervals, dispersion across device models and OS builds, the ratio of clicks to installs, and post-install behaviour such as how many users open the app the next day. A conclusion should rest on several signals pointing the same way rather than on a volume.
Can measurement platforms filter this automatically?
The major platforms all apply rules that remove a significant share, mainly rejecting installs whose interval is below a threshold and discounting sources with implausible click volumes. That layer works well against unsophisticated activity and less well against operations that deliberately keep their timing and volume inside the accepted band. It is best treated as a first layer, with the same distributions reviewed independently by source on the advertiser side.
What damage does attribution fraud do beyond the wasted spend?
The larger cost is usually distortion rather than direct loss. Budget follows measured performance, so a source that takes credit for organic installs looks efficient and keeps attracting budget while genuinely effective sources look worse by comparison and get cut. Automated bidding learns from the same contaminated conversion feed. Correcting spend afterwards is quick; bringing a bidding system that has learned from a distorted signal back to sound judgement takes much longer.