Install fraud rules, dispute files and clawback negotiation

Click injection leaves one signature you can read out of your own raw exports without buying anything: a click-to-install-time distribution with a hard spike under ten seconds on Android, in markets where the honest median sits between roughly forty seconds and several minutes. Click flooding leaves the opposite, a flat tail stretching past twenty-four hours with a conversion rate an order of magnitude below the account average. In the last three sets of raw exports I went through, between four and eleven percent of installs on non-self-attributing sources failed at least one rule I would defend in a call with the network. The networks credited back well under half of that until the insertion orders were rewritten, which is the part of this work that most fraud vendors do not sell you. What the rules are built from: Your data, not a template. I take ninety days of raw exports and build the click-to-install-time distribution per source, per platform and per country, because a rule calibrated on United States iOS traffic will reject honest installs in markets with slower networks and different device mixes. On Android I cross-check against the Play Install Referrer timestamps, which give an independent account of when the store session actually began and are the strongest single piece of evidence against injection. The rules themselves: Time-based floors and ceilings set per source rather than globally. SDK signature verification enforced rather than logged, so spoofed installs are rejected at the point of attribution instead of counted and argued about later. New-device rate and limit-ad-tracking rate by sub-publisher, which is where device farms show first. Install-to-first-event ratios that expose sources delivering installs that never open the app twice. Datacentre and anonymised IP ranges. Sub-publisher rotation detection, because the response to a blocklist is a new identifier by Monday. Every rule ships in shadow mode for two weeks before it blocks anything. I have seen an over-tight time floor reject a meaningful share of legitimate installs in Latin America on mid-range handsets, and a rule that rejects real users is more expensive than the fraud it prevents. The contract half: Detection without contractual language is a spreadsheet nobody pays out against. I write the definitions into the insertion order: what counts as a rejected install, the rejection window in days, the evidence format, the arbitration route when the network disputes, and whether rejection is credited or invoiced back. Then I sit in the calls where the network pushes back, because the first response is always that the methodology is proprietary. The disputes: Each case is filed with the distribution, the sample size, the comparison against your own account baseline and the specific rows. Networks settle far more readily against a distribution than against a percentage in an email, and I do not send the email. What I will not claim: I do not promise a recovery percentage, because it depends on contracts I have not read and networks I do not control. I will not enable blocking rules before shadow mode has run. And I will not run a fraud programme as the reason a channel stays in the plan when it is failing incrementality anyway. Clean traffic that does not cause conversions is still not worth buying. Not for you if: Almost all your spend sits with self-attributing networks, where these rules have little to bite on and your money is better spent on holdouts. Or the insertion orders cannot be reopened this year, in which case the detection is real and the recovery is not, and you should wait for the renewal and hire me then.