What Install Validation Is
Install validation is the quality check between "an install was reported" and "an install counts". Every install arrives as a request from the app's SDK, a postback from a partner or a claim from a network. Validation asks whether that install is real: the right app, a genuine device, a person, and an ad interaction that could plausibly have led to it.
Installs that pass are attributed and reported normally. Installs that fail are flagged for review, rejected for affiliate payouts, or kept out of the postbacks that train ad network bidding, depending on the platform and the rules you set.
What It Protects Against
- SDK spoofing. Fake install and event requests sent straight to the attribution server, imitating the real SDK.
- Emulators and device farms. Installs from virtual devices or racks of real phones operated to generate payouts.
- Click injection. A fake click fired just before a real install completes, stealing credit.
- Click spamming. Large volumes of fake clicks that happen to precede organic installs.
- Install hijacking. Interfering with the install flow to claim an install another source drove.
Signals Used in Validation
Request authenticity. Signed SDK requests prove the install came from your real app build, not a script. Request signing is the main defence against SDK spoofing.
Store evidence. On Android, the Google Play Install Referrer carries timestamps for the store visit and install start. A click that arrives after those timestamps is not the click that drove the install. On iOS, Apple's frameworks sign their own attribution data.
Timing. Click-to-install time exposes injection, where installs follow clicks within seconds, and spamming, where the distribution is unusually long and flat.
Network and device. Installs from data-center or Tor IP addresses, many installs from one IP or device, mismatches between the click's IP and the install's IP, and inconsistent device or OS details are all warning signs.
Platform attestation. Google Play Integrity and Apple App Attest let an app check that it is a genuine build running on a genuine device. Apps that use them can pass the result into their own fraud logic.
Behavior after install. Fake installs rarely retain, purchase or follow normal event sequences. Post-install signals catch what install-time checks miss, though they arrive later.
Flag, Block or Withhold
Platforms handle failed validation differently:
- Flag: the install stays in reporting with a fraud label, and you decide what to do.
- Reject for payout: affiliates and networks are told the install will not be paid.
- Withhold postbacks: the network is not told about the install, so its bidding does not optimize toward that traffic.
Whatever the approach, keep a record of why each install was flagged, so you can review rules and settle disputes with partners.
Install Validation in Linkrunner
Linkrunner's Fraud Control, live on every plan, flags suspicious installs with rules and templates. Templates cover click injection, install hijacking, SDK spoofing and installs from fraudulent clicks, and the dashboard library adds click flooding by IP and by device, SDK spoofing with IP mismatch, and reinstalls from fraudulent clicks. Rules can be written in plain English, and an impact preview shows what a rule would flag before you turn it on.
Flagged installs can be tagged or have their postbacks withheld, so networks do not optimize toward bad traffic; installs are not removed from reporting totals. Affiliate rejections and change history are included. SDK request signing protects against spoofed traffic, and the engine maintains data-center and Tor IP lists. See fraud protection.