Attribution fraud is the manipulation of mobile attribution data to claim advertising credit for installs or events that the fraudster did not actually cause. It is a large and persistent problem: estimates from the industry put global mobile ad fraud losses at several billion dollars per year, with a significant portion coming from attribution-specific fraud rather than impression or click fraud.
Understanding how each fraud type works mechanically makes it possible to detect and defend against it. This guide covers the main attack vectors and the countermeasures that work.
Why Attribution Fraud Happens
Attribution fraud is economically rational for bad actors. Most mobile user acquisition is paid on a cost-per-install (CPI) or cost-per-action (CPA) basis. If a fraudster can convince your attribution system that they drove an install or in-app purchase, they collect the payout. At scale, across thousands of installs per day, this is highly profitable.
Fraudsters operate through compromised apps (often ad-supported apps with large install bases), fake device farms, automated bot networks, and, increasingly, sophisticated SDK manipulation. They are not going away. The economics are too favorable.
The countermeasures described here are not perfect defenses. They are detection and deterrence tools that raise the cost of fraud against your campaigns enough that fraudsters shift to easier targets.
Click Injection
Click injection is one of the most technically sophisticated forms of mobile attribution fraud, and it is specific to Android.
How it works:
On Android, apps with the INSTALL_PACKAGES permission or broadcast receivers registered for PACKAGE_ADDED events can detect when other apps are being installed. A malicious app on the device monitors for package install broadcasts. When it detects that your app is being installed, it fires a fake click on one of your tracked links just before the install completes.
Your attribution system receives a click event from the device, followed almost immediately by an install event from the same device. Without fraud detection, this looks like a normal click-to-install. The malicious app's affiliate network collects the CPI payout, even though no real ad interaction occurred.
Detection signals:
- Extremely short click-to-install time (seconds or under a minute). Legitimate installs from clicking an ad take time: the user goes to the Play Store, the app downloads and installs. Sub-60-second click-to-install times are a strong fraud signal.
- Device time anomalies where the click timestamp postdates the install initiation in your server logs.
- High volume of installs from specific app sources with uniform click-to-install distributions.
Prevention:
Set a minimum click-to-install threshold in your attribution system. Any install where the attributed click is less than 10-30 seconds old is likely injected. Most legitimate platforms including Tolinku apply this check automatically, but you should verify your settings.
Google addressed part of this attack vector by restricting PACKAGE_ADDED broadcasts in Android 11+, but the vulnerability exists on older devices still in circulation.
Click Spamming (Click Flooding)
Click spamming is simpler than click injection. Fraudsters fire massive volumes of fake clicks across a large pool of device IDs. The bet is probabilistic: if they can spam enough clicks, some percentage of real users who later install your app organically will happen to have a matching click in your system within the attribution window.
How it works:
A fraudulent app or SDK fires hundreds of clicks per device per day to multiple ad networks. Most of these clicks do not lead to installs. But for users who organically discover your app and install it, there is a chance that a fake click from the same device ID is sitting in your attribution system, waiting to claim credit.
Unlike click injection, click spamming is not trying to beat the install timing. It is betting on volume.
Detection signals:
- Click-to-install time distribution that is unusually long. Legitimate clicks convert within hours. Click spam conversions happen days or weeks after the click, because the click preceded any real user interest.
- Very high click volumes from specific sources with low install rates (click-to-install rates of 0.001% or less are suspicious).
- Device IDs that appear in click records for many different apps and campaigns simultaneously.
Prevention:
Apply a statistical filter that flags sources with anomalously low click-to-install conversion rates combined with high volume. Also apply a lookback window appropriate to your app's consideration cycle. A 30-day window dramatically increases click spam exposure. Shortening it to 7 days significantly reduces the surface area.
Install Farms
Install farms use real devices (or emulators pretending to be real devices) operated by humans or automated scripts to install your app, trigger in-app events, and collect CPI or CPA payouts. Unlike bots, install farm traffic often passes basic device and behavioral checks because it involves actual device hardware.
How it works:
An install farm might be a warehouse of physical phones, tablets, or a cloud-based device emulation service. Each device downloads your app, creates an account, and completes enough in-app actions to trigger the payout event (a first purchase, a registration, a specific milestone). The device then resets its advertising ID, reinstalls your app under a new identity, and repeats.
Detection signals:
- Unusually high density of installs from small geographic areas or specific IP ranges.
- Device IDs that appear fresh (newly created advertising IDs are common in farms as devices reset frequently).
- Post-install behavior that is too perfect: every user completing exactly the events needed to trigger the payout and nothing more.
- Session data with unusual patterns: uniform session lengths, identical navigation paths, no organic in-app exploration.
Prevention:
Anomaly detection on post-install behavior is the most effective defense against install farms. If you can track in-app behavior (session depth, navigation patterns, purchase behavior over time), users who look like robots because their behavior is too uniform or too targeted can be flagged and removed from attribution counts.
Shifting from CPI to CPA for campaign payouts also helps. Paying for installs is easier to farm. Paying for qualified users who reach a meaningful milestone (a subscription renewal, a second purchase) raises the cost and effort for farms significantly.
SDK Spoofing
SDK spoofing is the most sophisticated attribution fraud type. It requires no real devices and no real installs. Instead, the fraudster reverse-engineers your attribution SDK's API calls and manufactures fake SDK signals that appear to originate from real devices.
How it works:
By analyzing network traffic from a legitimate app with the attribution SDK, a fraudster can determine the API calls that fire on install, on first open, and on in-app events. They then write code to replicate those calls at scale using fake device identifiers, generating thousands of "installs" and "events" per day without any real user involvement.
If the API calls are not cryptographically signed or verified, the attribution server has no way to distinguish genuine SDK signals from manufactured ones.
Detection signals:
- Unusual patterns in device metadata (OS versions that are statistically over-represented, device models that don't match expected market distribution).
- SDK signal anomalies: installs without the expected app store receipts, events firing in unexpected sequences.
- IP addresses associated with data centers or VPN providers rather than consumer ISPs.
Prevention:
SDK integrity verification is the primary defense. This involves signing SDK payloads with device-level secrets that cannot be easily replicated outside of the actual SDK running on a real device. App attestation APIs on both iOS (DeviceCheck and App Attest) and Android (Play Integrity API) provide cryptographic device attestation that makes SDK spoofing significantly harder.
Implementing a Fraud Detection Stack
Effective fraud detection combines multiple signals because no single signal is reliable on its own. Here is a layered approach:
Layer 1: Click quality filters
- Minimum click-to-install time threshold (30 seconds minimum, flag under 2 minutes)
- Click volume rate limits per device ID and IP
- Attribution window length appropriate to your consideration cycle
Layer 2: Device and network signals
- Device integrity via App Attest (iOS) and Play Integrity (Android)
- IP reputation: flag data center IPs, known VPN providers, and IP ranges with historically high fraud rates
- Device fingerprint consistency checks (does the device's attributes change between click and install?)
Layer 3: Post-install behavioral signals
- Engagement rate (session depth, return visits) in the first 7 days
- In-app event sequence anomalies (are users completing payout events but nothing else?)
- Geographic distribution of post-install activity (install farm traffic often has geographic clusters)
Layer 4: Statistical anomaly detection
- Source-level click-to-install rate monitoring (flag sources with rates under 0.01%)
- Cohort behavioral comparisons (do users from a specific source behave differently than users from other sources of the same type?)
- Time-series anomaly detection on install volume (sudden spikes from specific sources)
Working with Fraud-Affected Data
If you identify a fraudulent traffic source in your data, you have two options: reject the installs retroactively or flag them for exclusion going forward. Both have implications.
Retroactive rejection changes your historical attribution numbers, which affects campaign performance comparisons. Going forward exclusion keeps your historical data intact but means the fraudulent data stays in your historical records.
The cleanest approach is to segment fraud-flagged installs into a separate cohort in your reporting rather than deleting them. This lets you see the impact on your metrics without corrupting your historical data.
For ongoing campaigns, add fraudulent sources to your blocklist and report them to the ad network. Most networks have fraud claim processes, and for larger spend amounts, pursuing credits is worth the effort.
Tolinku's Approach to Fraud Detection
Tolinku applies click quality analysis on attributed installs, including click-to-install time filtering and IP reputation scoring, as part of the attribution pipeline. For deep link-driven attribution specifically, the signed link infrastructure makes many forms of click manufacturing significantly harder.
For a broader discussion of attribution setup and configuration, see the Tolinku attribution documentation and the analytics user guide.
Further Reading
Get deep linking tips in your inbox
One email per week. No spam.
