Why has AppsFlyer's Protect360 fraud prevention tool flagged 50% more installs as potentially fraudulent compared to the previous quarter?

Direct answer

A 50% quarter-over-quarter increase in installs flagged by AppsFlyer Protect360 is an observation, not a root cause. I would first establish whether “50% more” means a larger count or a higher rate, whether the denominator and reporting window are comparable, and whether the total combines real-time blocks with post-attribution detections.

That distinction matters because AppsFlyer's Protect360 guide documents both real-time blocking and fraud identified after attribution. Its raw-data guide also explains that reports include different event types and blocking reasons. A change in report composition, late detection, traffic volume, or rules can therefore move the number without proving that underlying fraud rose by the same amount.

I would investigate four hypothesis groups in order:

1. Measurement or reporting change: time zone, lookback window, late labels, duplicate extraction, denominator, or reason-code mapping changed.
2. Detection or configuration change: a model, rule, validation setting, or enforcement mode changed what becomes flagged.
3. Traffic-mix change: apps, media sources, campaigns, geographies, operating systems, or acquisition volumes shifted toward segments with different flag rates.
4. Real threat change: existing attacks increased or a new pattern appeared.

Decompose the result by detection timing, reason code, app, media source, site ID, campaign, geography, OS, and SDK/app version. Then compare both counts and rates on a like-for-like cohort. Review an appropriately sampled set with fraud analysts and independent evidence; advertiser or partner disagreement alone is not a truth label.

Do not lower thresholds or roll back protection simply to restore the old number. The response depends on the evidence: repair reporting, recalibrate a changed detector, fix an integration, isolate low-quality traffic, or strengthen protection against a confirmed attack. Measure validated detection precision and coverage, legitimate-install impact, prevented invalid spend, detection latency, and reversal or dispute outcomes.

Source review: August 5, 2026. The scenario is hypothetical; no cause is asserted without AppsFlyer data.