Short answer: When one network's installs are cheap and plentiful but its users never sign up or come back, check three things against your other paid sources: how fast installs follow clicks, how many clicks it takes to get one install, and whether those users do anything on day 1. A pattern that differs sharply on all three is the usual sign of install fraud rather than a bad audience.
What does "too good to be true" mean here?
Install fraud: traffic that makes an ad network or affiliate look responsible for installs it did not drive, or that creates installs from bots, emulators or device farms rather than real people.
The symptom is a mismatch between the top and the bottom of the funnel. The network's install count and cost per install look excellent, but the installs it is credited with produce few sign-ups, purchases or returning users. Your MMP's fraud protection exists to catch exactly this, but it only rejects what its rules are set to catch.
How do I check whether I'm paying for fake installs?
Pull a week of raw install data from your MMP for the suspect network and for one or two trusted paid sources, then compare the three signals below. You are looking for a pattern, not a single odd install.
Signal 1: click-to-install time
Click-to-install time: the gap between the attributed click and the install or first open.
- Very short gaps (installs that begin within seconds of the click) point to click injection, where a malicious app fires a click just as another app is being installed.
- A long, flat spread of gaps, with no peak in the first hour, points to click spamming: the network sends huge numbers of clicks so that some happen to sit before organic installs.
On Android, the Google Play Install Referrer API returns both the referrer click time and the install begin time (getReferrerClickTimestampSeconds and getInstallBeginTimestampSeconds in Android's documentation), which is what most MMPs use to measure this gap.
Signal 2: clicks per install
Divide the network's clicks by its installs. Click spamming needs a very large number of clicks, so a network with far more clicks per install than your other sources, and a rising organic install count while it runs, deserves a closer look.
Signal 3: what users do after installing
- No day-1 opens or events across a large share of installs suggests bots or emulators.
- Many installs from the same few device models, OS versions or IP ranges suggests a device farm.
- Installs that convert but never pay can be real low-quality traffic, so treat this signal as supporting evidence only.
Likely causes
- Click injection on Android, stealing credit for installs that were already happening.
- Click spamming, claiming organic installs through sheer click volume.
- Bots and SDK spoofing, where fake install and event calls are sent without a real device.
- Device farms, where real phones are installed and opened by hand or by script.
- Not fraud: a genuinely low-intent placement, such as incentivised traffic you didn't ask for. Ask the network for its placement or sub-publisher list before you accuse it.
How to confirm it
- Export raw installs with click time, install time, sub-publisher and device fields from your MMP.
- Plot click-to-install time for the suspect network next to a trusted source.
- Compare clicks per install and day-1 activity for the same week.
- Break the suspect network down by sub-publisher. Fraud usually sits in a few sub-publishers, not the whole network.
- Check your MMP's fraud or rejection report for the same period.
What MMP fraud tools can and can't do
MMPs differ in what they include, so check your plan before you assume you're covered. From each vendor's public pricing page:
| MMP | Fraud protection on public plans |
|---|---|
| Adjust | Fraud Prevention Suite, a paid add-on for Core and Enterprise |
| AppsFlyer | Basic and advanced (Protect360) rows; per-plan mapping not shown |
| Kochava | Fraud prevention included; Fraud Console on Enterprise |
| Linkrunner | Fraud Control included on every plan |
| Singular | Core fraud prevention on all plans |
| Tenjin | Fraud prevention in the all-inclusive feature list |
Rule-based tools are only as good as their rules. Linkrunner's Fraud Control, for example, ships 8 rule templates (including click injection, click flooding by IP or by device, install hijacking and SDK spoofing) and lets you either tag a flagged install or tag it and withhold the postback to the ad network. Withholding the postback is what stops the network being credited and its bidding being trained on fake installs; tagging alone only labels it in your reports. Whatever MMP you use, check which response its rules are set to.
How to fix it
- Pause or cap the worst sub-publishers while you investigate, rather than the whole network.
- Switch your MMP's fraud rules from report-only to withholding postbacks for the patterns you confirmed.
- Ask the network for a refund or make-good for installs your MMP rejected, with the raw data attached.
- Optimise on a down-funnel event, such as sign-up or first purchase, rather than installs, so fake installs stop looking cheap.
If the network also reports more installs than your MMP, see Meta reports more installs than the MMP or install claimed by two networks. For how fraud and reinstalls distort cost metrics, the cost per install guide on App Metrics Library explains which installs belong in the denominator.