One network's installs look too good to be true: they land almost instantly after the click, nobody opens the app twice, and nothing downstream ever turns into revenue. MMPs detect install fraud by checking each click, install and event against rules: click-to-install timing (click injection), click volume with no matching installs (click spamming), failed SDK signature checks (SDK spoofing), and device, IP or behaviour patterns (bots and device farms). Ad networks filter some invalid traffic on their own side, but that does not replace your MMP's checks across every source you buy from.
Below: each fraud type mapped to its signal, real cases from Linkrunner data, and a five-step check for your own data.
How is install fraud detected?
Install fraud detection: the process of checking clicks, installs and in-app events against timing, volume, signature and behaviour rules to find traffic that was not generated by a real user.
Each fraud type leaves a different trace, so each needs a different rule:
| Fraud type | What it does | Signal that catches it | What an MMP can do |
|---|---|---|---|
| Click injection | Fires a fake click as a real install starts (Android) | Install begins moments after the click; referrer click recorded late | Flag the install, withhold the postback |
| Click spamming | Fires mass clicks hoping one lands in a real install's window | Huge click volume per IP or device with almost no installs | Flag the clicks and the installs that follow them |
| SDK spoofing | Sends fake install or event requests with no real app | Failed SDK signature check, IP mismatch, impossible event sequences | Exclude or flag the request |
| Bots and device farms | Real or emulated devices installing at scale | Clusters of identical devices and IPs, no behaviour after install | Flag by source, suppress postbacks, tell the affiliate |
How do you detect click injection?
Click injection is detected by the gap between the click and the install: a real user takes a moment to read a store page, while an injected click is fired as the install begins. It affects Android only.
- Timing: installs that open almost immediately after the click are suspect. Linkrunner's template flags Android installs that open within 3 seconds of their Play referrer click.
- Not every fast open is fraud: on one fintech app's affiliate traffic in 2026, about three quarters of installs opened within 10 seconds of the click, at roughly 15 installs per IP. The 3 second rule flagged around 16k of about 200k installs, yet about half of those still signed up. That points to users paid to install rather than fake devices, so they are tagged and under review, not written off.
- Set the limit per channel: the same rule also flagged WhatsApp and referral links opened by users who already had the app. With no download, these open in seconds, so one global threshold catches real users.
- Referrer order: install hijacking is the sibling pattern, where the Play referrer click is recorded after the install had already started.
- Response: flag the installs, withhold their postbacks, then raise the evidence with the network.
The mechanics and dispute process are in our guide to click injection detection and blocking. The glossary entry for click injection has the short definition.
What is click spamming, and how do MMPs detect it?
Click spamming (also called click flooding) is firing large volumes of fake or unviewed clicks so that one lands inside the attribution window of a real install. See the click spamming definition for the long form.
MMPs detect it from the click side, since the installs it steals look normal:
- Volume against outcome: a very large number of clicks from one IP or device with a tiny click-to-install rate.
- Unusual timing spread: clicks that convert long after they were fired, in a pattern that does not match your other sources.
- Taint by association: installs credited to a click that was already flagged.
What it looked like in Linkrunner data: two apps on the same affiliate network, an entertainment app and a social app, each received between 1M and 1.7M clicks over five weeks in autumn 2026. Only about 0.5% became installs. A few hundred thousand of those clicks came from a small group of cloud server IPs that hit both apps. An IP reputation rule flagged about a fifth of the installs, and they were tagged for review.
In Linkrunner, click rules (for example by IP or by device) always run as Tag only, since a click has no postback to suppress. A flagged click passes its flag to the linked install, and the "install from a fraudulent click" rule decides whether that install is flagged too. For more on the topic, see click flooding and fraud prevention.
How do MMPs detect SDK spoofing and fake in-app events?
SDK spoofing is sending fake install or event requests to an MMP's servers without a real app install, usually from a script or emulator. See SDK spoofing in the glossary.
The core defence is proving the request came from your real SDK:
- Signature check: each request from a genuine SDK carries a signature. Linkrunner's SDK spoofing template flags installs that failed the signature check, and unverified requests are excluded.
- IP mismatch: an install request and the matching click arriving from unrelated networks or countries.
- Impossible sequences: purchases with no session, or dozens of events in the same second.
- Event rules: rules that look at in-app events, not just installs. In Linkrunner, events from a flagged install are marked "inherited from install".
If you pay on sign-ups or purchases, check that your tool's rules cover events as well as installs. Fake installs are only half of the problem.
How do you spot bot and device-farm traffic, and stop paying affiliates for it?
Bot and device farm traffic is spotted by what the installs have in common and by what they never do afterwards. Bot traffic rarely behaves like a mix of real users.
Signals to look for:
- Tight clustering of device models, OS versions or IP ranges.
- Many installs from the same IP.
- Near-zero day-one retention and no events after install.
- High install volume from a sub-publisher with no revenue.
- Click bursts no person could produce. In one case, a single cloud server sent about 4 clicks a second to a tracking link. Across Linkrunner, scanners and bots sent about 39k clicks to 95 apps' links over two weeks in spring 2026. Linkrunner filters bots that identify themselves.
What to do about it, in order:
- Tag first, then read the split by network or sub-publisher.
- Suppress postbacks for the rules you trust, so the ad network or affiliate stops receiving the conversion.
- Use the partner's rejection route. In Linkrunner, an affiliate with a rejection URL receives a one-time call with the reasons, and its normal postback URL is not called. The call carries reason codes from the rule type and matched property, not your rule name or threshold. Setup is in the affiliate partner docs and postback docs.
- Gather evidence and dispute. The process is in the click injection guide. Credit and refund terms depend on your contract with the network.
For the affiliate setup side, see deep linking for influencer and affiliate campaigns.
Do Meta and Google already filter install fraud, or do I still need my MMP's protection?
Both filter invalid traffic inside their own ad systems, but that is a different job from checking the installs reaching your app from every source you buy. You still need your MMP's checks, especially on affiliates and non-self-attributing networks.
- Google: its own help page says clicks it determines to be invalid are filtered out of campaign metrics and removed from billing, with a credit on your next invoice where appropriate and possible. The same page notes that a valid conversion can remain after the invalid click is removed, so conversions can occasionally exceed clicks.
- Meta: its Self-Serve Ad Terms say Meta has systems that attempt to detect and filter certain click activity, but that it is not responsible for click fraud or other potentially invalid clicks that affect ad costs.
- What neither page covers: neither is written around your other channels. A filter inside one network can only judge that network's own traffic, while an MMP sees every source side by side with raw timestamps and event quality.
Self-attributing networks report their own numbers, which is why they often differ from your MMP's; see why self-attributing network numbers differ. Your MMP's fraud layer is the one place all of your sources are judged by the same rules.
How do you check whether one network's installs are fake?
Compare the suspect network with your other sources on five cuts. Fake traffic stands out on several of them at once, not on one.
- Click-to-install time by network. Look at the spread, not the average. See the click-to-install timing benchmarks for what normal looks like on Android and iOS.
- Installs per IP and per device model. Heavy repetition is a flag.
- D1 and D7 retention by sub-publisher. Fake installs rarely come back.
- Events and revenue per install. A network with plenty of installs and no sign-ups is a red flag.
- Android against iOS mix. Click injection is Android only, so an Android-only spike on one network points that way.
If the network's numbers also disagree with your dashboard, read why your attribution numbers do not match first, since not every gap is fraud.
How to run this in Linkrunner: Fraud Control is included on every plan of Linkrunner, a mobile and web attribution platform. Start from a template, use the impact preview to test it on the last 7, 14 or 30 days, set the response to Tag only, and read the By channel view. Move to suppression one rule at a time. Linkrunner's docs warn that a rule flagging a large share of all traffic is almost always too broad, and that one which is too broad "can hurt the network's optimisation without any visible error".
FAQ
What is click spamming in mobile app campaigns, and how do MMPs detect it? Click spamming is firing masses of fake or unviewed clicks so one lands in a real install's attribution window. MMPs detect it by very high click volume per IP or device with almost no installs, and by installs tied to clicks already flagged.
How do MMPs detect SDK spoofing and fake in-app events? They check whether each request came from your real SDK, using a signature, and look for IP mismatches and impossible event sequences. Rules that cover in-app events, not just installs, catch fake sign-ups and purchases.
Do Meta and Google already filter install fraud? They filter invalid clicks within their own systems, and Google says it removes them from billing. Neither covers your other networks, so your MMP's checks are still needed.
How do I stop paying affiliate networks for bot installs? Tag first, check by sub-publisher, then suppress postbacks and use rejection calls so the affiliate stops paying its publishers. Dispute with evidence under your contract.
Can fraud affect iOS installs? Yes. Click injection is Android only, but click spamming, bots and SDK spoofing can affect both platforms.
What to do next
Run the five cuts on your most suspicious network this week, then set one template rule to Tag only and watch what it flags. To compare tools by when they act and what they cost, read our guide to the best mobile ad fraud prevention tools, and for AI-assisted detection see how AI can boost attribution accuracy and stop ad fraud. If you want Fraud Control on your own traffic, request a demo from Linkrunner or read the Fraud Protection page.