How Install Hijacking Works
Install hijacking does not create fake users. It steals credit for real ones. A person decides to install your app, perhaps after seeing a creator's video, a search ad or a friend's recommendation. While the download is in progress, a fraudulent actor fires a click on its own tracking link for your app. When the app opens for the first time, the attribution system sees a recent click from that source and credits the install to it.
The fraudster needs a way to know an install is happening. On Android, malware or a malicious SDK inside another app can listen for signals that a package is being added or updated, or watch for store activity. Once it sees your app's package name, it sends the click immediately. Because the click lands right before the first open, it looks like the last touch.
The result is a real, engaged user attributed to the wrong place, and a payout to someone who did nothing to earn it.
Why It Damages Your Data
Install hijacking is hard to notice because the users are genuine. They retain, they buy, they behave like your best organic users, because often that is exactly what they are. A hijacking source therefore looks like a high-quality channel with strong downstream metrics.
That is the damage. Organic installs shrink in your reports, the true source of growth loses its credit, and budget flows toward the fraudster's channel because its cohort data looks excellent. Over time, decisions about where to spend are built on stolen attribution.
Detection Signals
Click-to-install time (CTIT) is the clearest signal. Genuine clicks lead to installs over a natural spread of minutes and hours. Hijacked installs cluster at very short intervals, often under ten seconds, because the click was fired during the download rather than before it.
The Google Play Install Referrer API makes this checkable on Android. It reports when the user clicked through to the store and when the install began. A click recorded after the download started is not a click that caused the install. Comparing your attribution click with the referrer timestamps exposes most hijacking.
Source-level patterns help too. A sub-publisher with very short CTIT, organic-looking retention and installs that track your organic trend rather than its own click volume is a strong candidate.
How Linkrunner Handles Install Hijacking
Linkrunner's Fraud Control includes a template for install hijacking alongside click injection, SDK spoofing and installs from fraudulent clicks. Rules can be written in plain English, previewed on past traffic before you turn them on, and set to tag matching installs or withhold their postbacks so the network's algorithm stops optimising toward that source. Flagged installs remain in reporting totals so you can audit them. Because Linkrunner matches installs deterministically first, using the Google Play Install Referrer on Android, the referrer timestamps are available for these checks. See fraud protection.
Prevention Practices
Shorter attribution windows do not help much here, because hijacking clicks are recent by design. Focus instead on timing rules and source accountability. Set a minimum CTIT threshold for your rules, review sources that cross it, and require networks to pass sub-publisher IDs so you can act on the specific source rather than the whole network.
Keep your organic baseline in view. If organic installs drop while one paid source grows without a matching rise in its click volume or spend, investigate before scaling that source. Share findings with partners promptly, since most networks will remove a sub-publisher once the evidence is clear.
Install Hijacking vs Other Attribution Fraud
It helps to place install hijacking among its neighbours, because each needs a different response. Click spamming, or click flooding, fires huge numbers of clicks in advance and hopes some land before an organic install. Its signature is a flat click-to-install time curve and a tiny conversion rate. Install hijacking fires one click at the right moment, so its signature is the opposite: a spike of very short click-to-install times.
SDK spoofing and device farms are different again. They create installs that should not exist, rather than stealing credit for installs that would have happened anyway. Spoofed installs have no real user; farm installs have real phones but no real interest. Both show weak retention, while hijacked installs often retain well because the users are genuine.
That difference shapes how you talk to partners. With fake installs, the conversation is about refunds for users who never existed. With install hijacking, it is about credit: the install was real, but it belonged to another channel, often organic. Showing the referrer timestamps next to the attributed click usually settles the question quickly.