Which fraud types should MMP fraud protection cover, and what do you pay extra for?

If you buy paid traffic for a mobile app, you probably have two lines on your MMP invoice: attribution and fraud protection. Renewal is a good moment to ask what the second line actually covers. A fraud module that blocks one type of fraud while missing the type your channels are exposed to is still a cost, not protection. And if fraudulent installs are counted as paid conversions before they are rejected, you may be paying twice: once to the network and once to the measurement vendor.

Click injection and install hijacking steal credit for installs you already earned

Install hijacking is the outcome. A fraudulent source claims credit for an install that someone else drove, either another paid channel or organic demand. Click injection is the best-known technique. A malicious app on an Android device detects that another app is being installed and fires a click just before the install completes, so it wins last-click attribution.

What it does to your data: total installs stay roughly the same, but credit moves from organic or honest partners to the fraudulent source. Your CPI on that source looks attractive, and your organic share appears to shrink.

• Very short click-to-install times that are not physically plausible for a store download.
• Clicks recorded after the download started, visible when install referrer timestamps are compared with click timestamps.
• A source that performs well on paper while organic installs drop in the same markets.

Click flooding and SDK spoofing distort volume rather than timing

Click flooding, also called click spamming, sends large volumes of clicks for devices that never saw an ad. The bet is that some of those users will install organically and the flooding source will hold the last click. The trace is a very low click-to-install conversion rate and a flat, long-tailed click-to-install time distribution. Hypothetical example: you pause a network in one country and organic installs rise by roughly the same amount that network used to report. That pattern points to flooding.

SDK spoofing goes further. No device exists at all. Fraudsters send requests to measurement servers that imitate legitimate SDK traffic and generate installs and in-app events. The trace is installs with no follow-up sessions, device and OS combinations that do not match your real audience, and events that fail signature or validation checks. Spoofed events can also corrupt the purchase and ad revenue signals that you optimise toward.

Device farms and incent abuse can inflate ad revenue, not only installs

Device farms use real devices or emulators to install apps repeatedly and reset device identifiers between runs. Unlike spoofing, the installs really happen. For an app monetised by ads, farms can also generate impressions. That inflates ad revenue on the cohort, makes eROAS for the source look healthy and can later be reversed when the ad network removes invalid traffic. If you attribute ad revenue to acquisition source, this is the fraud type that matters most to you. See How to attribute ad revenue to user acquisition source in a mobile app.

• New installs clustered on the same IP ranges, data centre addresses or a narrow set of device models.
• Retention curves that are unusually uniform, or that collapse after the first session.
• Ad revenue per user that is high on day zero and disappears after network adjustments.

Incent abuse sends incentivised traffic, where users are rewarded for installing, through campaigns sold as non-incentivised. The installs are real, but the users have no intent. Retargeting abuse is the re-engagement version of this. A source claims credit for existing users who would have returned anyway, often by firing clicks at known users within the reattribution window. The trace is reattributions rising without any change in engagement or revenue per returning user. If you are planning re-engagement campaigns, set this up first. See How to set up measurement before your first app retargeting campaign.

Your MMP contract should answer three questions about fraud

If you are on Adjust, AppsFlyer or Kochava today, or comparing them with other vendors, do not compare fraud modules by name. Compare them on terms you can verify in the order form and in a trial account.

1. Scope. Which of the types above are covered, and is detection applied before attribution (the install is never credited) or after it (the install is reclassified later)? Ask whether coverage differs between install attribution, in-app events and re-engagement.
2. Billing. Is fraud protection a separate module, a tier or included? Are rejected installs or conversions excluded from the billable count, and is that written in the contract? Under MTU or per-conversion pricing, this decides whether fraud raises your measurement bill.
3. Access to rejected data. Can you see rejected installs at row level, with the rejection reason, source, campaign and timestamps? Can you export them? Without that, you cannot dispute invoices with networks or check for false positives.

For context on how this fits into a wider vendor comparison, see Understanding MMPs and AdShift. AdShift includes fraud prevention without a surcharge and charges per conversion rather than per MTU. Whichever vendor you choose, the three questions above apply in the same way.

Measurement does not solve the commercial side of fraud

An MMP can flag and reject fraudulent installs. It cannot recover money already paid to a network. Clawbacks depend on your insertion orders and on the network's willingness to accept the evidence. Ad revenue reversals for invalid traffic are decided by the ad networks, not by your measurement vendor. Fraud techniques also change, so a rule set that works this quarter needs review. Detection produces false positives too, which is another reason to insist on access to rejected data. Finally, no fraud module will fix traffic that is legitimate but poor. A real user with no intent is a media buying problem, not a measurement one.