A paid network's installs jump overnight. The cost per install looks great, the dashboard says the campaign is working, and then day-one activation for that source falls through the floor. Someone in the Slack channel types "fraud?" and the conversation splits into two camps: pause everything now, or stop being paranoid.
Both instincts skip the useful question. Suspicious install traffic can come from at least four different places, and they need different owners:
Attribution: the installs are real, but credit is going to the wrong source.
Platform filtering: the ad platform or measurement partner has already removed invalid interactions, and your reports disagree because they count different things.
Implementation: an SDK release, consent change, broken link, or event mapping error is making genuine users look worthless.
Genuine traffic quality: the source is delivering users, or signals, that do not represent real interest in the app.
Mobile app install fraud detection is the work of separating those four explanations with evidence before anyone moves budget or accuses a partner. This guide gives you a way to do that: an evidence ladder, a diagnostic table, a seven-step investigation, a worked fictional example, and a media decision rule.
Fake installs versus hijacked real installs
Two patterns get called "install fraud," and they behave differently in your data.
Fake installs are installs, or install signals, that do not correspond to a real person choosing your app. Bots, emulators, device farms, and fabricated SDK traffic fall here. Their signature is usually downstream emptiness: installs with little or no believable activity afterward.
Install hijacking takes credit for installs that were going to happen anyway. A real person installs your app, and a fraudulent click or injected engagement claims the attribution. AppsFlyer's Protect360 guide makes the distinction explicit: in fraud attempts involving real users, "app installs complete normally, and only attribution recording is affected" (AppsFlyer Protect360 anti-fraud guide). The same guide says hijacked installs blocked in real time have attribution corrected to the last valid source (AppsFlyer).
That difference changes what you look for. Hijacked users often retain and pay perfectly well. The damage is that a partner collects credit, and budget, for demand it did not create, while your organic or another paid channel looks weaker than it is. If you only check post-install quality, hijacking can look like a great source.
Anomalies are not verdicts
An anomaly is a pattern that deserves a question. Fraud is a conclusion about intent and mechanism. Most of the damage in these investigations comes from treating the first as the second.
Google's own invalid-traffic documentation is a useful corrective. It notes that third-party tools might flag traffic as invalid, such as duplicate IP addresses or bot activity, that Google already filtered and excluded from the bill (Google Ads Help: About invalid traffic). When Google asks advertisers to request an investigation, it wants evidence: dates, campaign names, logs, click identifiers, and a trend explanation such as a click spike without more conversions (Google Ads Help). A spike is the start of a case file, not the end of one.
Common anomalies with ordinary explanations:
a shared IP range, because carrier networks, offices, and campuses put many real users behind a few addresses;
very short sessions, because a user opened the app, saw a login wall, and left;
a burst of installs in one hour, because a creative started spending or a feature placement went live;
low activation from one source, because that source sends a broader, colder audience.
None of these prove fraud. All of them justify a closer look.
The Install Evidence Ladder
The mobile app marketing audit uses an evidence ladder to diagnose the whole growth system. This one is narrower. It ranks the evidence about one question: is this paid install traffic genuine, correctly credited, and worth paying for? Each rung answers something the rung below cannot.
Rung 1: Platform-filtered invalid interactions
Ad platforms filter some invalid activity before it reaches your bill. Google states that invalid traffic detected before the end of the month is automatically removed from billing and campaign reports, and that invalid traffic found after billing is credited "where appropriate and possible" (Google Ads Help).
What this rung tells you: a platform has already discounted some interactions. What it does not tell you: whether the remaining installs are valuable, or whether other networks apply comparable filtering. Treat one platform's filtering description as that platform's statement, not an industry rule.
Rung 2: MMP real-time rejected attribution
Mobile measurement partners with fraud modules can refuse to attribute an install to a source. Adjust documents rejected install and rejected reattribution callbacks, available when a client has activated its Fraud Prevention Suite, with reasons such as anonymoustraffic, distributionoutlier, toomanyengagements, engagementinjection, incorrectsignature, and malformedadvertisingid (Adjust Help Center: Rejected install or reattribution callbacks). Adjust also notes that one install matched to two clicks can produce both a rejected install callback for the fraudulent click and an install callback for the valid click (Adjust).
That last point matters: a rejection is a decision about attribution credit, not always a statement that no user exists.
Rung 3: Post-attribution flags
Some patterns only become visible after an install is attributed. AppsFlyer describes a layered approach of real-time blocking plus post-attribution identification, with post-attribution installs marked in a separate report (AppsFlyer). Adjust's Protection Dashboard focuses on rejected and unverified attributions, flagged based on SDK signature validation, fraud filters, and conversion rules, and shows spikes in rejected or unverified installs over time (Adjust Help Center: Protection Dashboard).
These reports are vendor-specific. Each uses its own definitions, and their existence is not independent proof of detection accuracy. The practical consequence: your "installs" number for a given day can change after the fact.
Rung 4: First-party install, open, and activation continuity
This is the rung you control. Do the attributed installs from a source become first opens, then sessions, then an activation event your product team would recognise, in a sequence and at a pace that looks like human behaviour? Your own backend, product analytics, and transaction ledger are the most direct evidence you have that a person used the app.
On Android, the Play Integrity API can help your backend check that requests come from your genuine app, installed by Google Play, running on a genuine and certified Android device (Android Developers: Play Integrity API overview). That is a device and app integrity signal. It is not ad attribution and it does not prove which campaign caused an install.
On Apple platforms, AdAttributionKit transactions are cryptographically signed and verified by Apple, and postbacks include a unique transaction ID to detect replays of valid conversion events (Apple Developer: Ad Attribution). That protects the postback's integrity. It does not tell you whether the user was valuable, and the data is deliberately limited for privacy.
Rung 5: Causal and business judgment
The top rung asks whether the source creates value you would not otherwise get, at a cost you can afford. That needs cohort economics, and ideally a holdout or pause-based test. The incrementality testing guide covers experiment design. Fraud tooling cannot answer this question for you, and a source can pass every rung below and still fail here.
How to use the ladder: write down the highest rung your evidence reaches before you act. "Rung 1 and 2 are clean, rung 4 collapses for one sub-publisher" is a far stronger position than "the CPI looked too good."
Accepted versus rejected denominators
Many arguments with partners are really arguments about the denominator.
The network reports installs it believes it drove.
The MMP reports accepted attributed installs, and may separately report rejected ones.
Post-attribution reports can reclassify some accepted installs later.
Your product data counts first opens and activations regardless of source.
When someone says "the rejection rate is high," ask: rejected out of what? Rejected divided by accepted plus rejected gives a different number from rejected divided by accepted. Adjust's dashboard itself includes a "rejected installs to installs ratio" view (Adjust); know which ratio your team is quoting. Agree the formula in writing before comparing sources, and never compare a rejection rate from one vendor with one from another.
Attribution timing and cohort reconciliation
Timing mismatches create phantom fraud. Three are common:
Postback latency. Apple says advertisers and developers can receive an AdAttributionKit postback within 24–48 hours of a user launching the app (Apple). A day of "missing" iOS installs may simply not have arrived.
Report date versus install date. A network may report on click date, the MMP on install date, and finance on transaction date.
Late reclassification. Post-attribution flags and platform credits land after the original report.
Before judging a source, reconcile by install cohort: take all installs attributed to the source on a given install date and follow them forward. Do not mix yesterday's installs with this week's revenue. The attribution architecture guide explains how to assign each measurement system a decision right; use that structure here rather than arguing about which dashboard is "true."
A practical diagnostic table
Signal Benign alternative explanation Confirming evidence Owner Action --- --- --- --- --- Install spike from one source New creative, placement, or budget change Spike concentrated in one sub-publisher with no matching spend change; first opens flat UA lead Segment by sub-publisher; request placement data from partner Very short click-to-install times Fast devices on Wi-Fi; small app size Pattern concentrated in one source and persisting; MMP injection rejections Analytics owner Review MMP rejection reasons for the source Long, flat click-to-install spread Users bookmarking the store page Distribution outlier rejections; high click volume per install Analytics owner Compare click volume with installs by source Installs with no first open SDK not initialising, consent gate before SDK start Gap isolated to one source while other sources on the same app version are normal Engineering Check SDK version and init order before blaming media First opens but no activation Onboarding break, paywall change, login failure Activation normal for other sources on same build and country Product Compare activation by source within the same release Strong retention, suspicious click patterns Genuinely good source Organic installs dip when the source scales; last-click patterns cluster Head of growth Test pause or holdout to check incrementality MMP and network install counts diverge Different windows, reporting dates, view-through rules Divergence persists after aligning dates and windows Analytics owner Reconcile by install cohort using documented rules Rejected installs rising New fraud filter enabled; rule change Rejections concentrated in one partner and reason code UA lead Share rejection report with partner; hold scaling
Every row names a benign explanation first. If you cannot rule it out, you are not ready to escalate.
A seven-step investigation workflow
Freeze the question. Write one sentence: which source, which dates, which metric changed, what decision is at stake. Keep scope to one source at a time.
Check implementation first. Confirm the app release, SDK version, consent flow, and link paths for the affected window. If the deep-link destination broke, users can look fake when they are simply lost.
Align definitions. Record each system's attribution window, reporting date, and whether it counts accepted, rejected, or both. Agree the denominator.
Walk the ladder. Collect what rungs 1 to 3 say: platform invalid-traffic reporting, MMP rejections with reason codes, post-attribution flags.
Test continuity. Follow the source's install cohort through first open, session, activation, and payment in your own data. Compare with other sources on the same build, OS, and country.
Look for displacement. If quality looks fine but click patterns look odd, check whether organic or another channel dipped when this source scaled. That is the hijacking question.
Decide and document. Pick a media action from the rule below, name what evidence would change it, and set a review date.
A fictional worked example
This example is invented to show the arithmetic. It is not a client case, and the numbers are not benchmarks.
A meditation app runs a network campaign for one week. The network reports 2,000 installs. The MMP shows 1,600 accepted attributed installs and 400 rejected, of which 300 carry a click-injection reason and 100 an anonymous-traffic reason.
Rejection share of all install claims: 400 ÷ 2,000 = 20%.
Rejected per accepted install: 400 ÷ 1,600 = 25%. Same data, different denominator.
Later, 160 of the 1,600 accepted installs appear in a post-attribution report, leaving 1,440 installs with no flag.
Product data for those 1,440 installs shows 1,296 first opens (90%) and 518 activations, defined as finishing the first session. That gives 518 ÷ 1,440 ≈ 36% activation per unflagged install. The team's other paid source, on the same build and markets, shows 38% on the same definition. Continuity looks broadly comparable.
But the 160 flagged installs produced only 8 activations, 8 ÷ 160 = 5%. And when the team splits by sub-publisher, one placement accounts for 140 of the 160 flags.
Reading the ladder: rung 2 and 3 concentrate in one placement; rung 4 says the rest of the source behaves like other paid traffic. The conclusion is not "the network is fraudulent." It is "one placement shows repeated attribution problems; the remaining traffic has not failed on quality." The action: exclude the placement, share the rejection and flag data with the partner, and hold budget flat until the next weekly cohort confirms the pattern.
Stop, hold, repair, or escalate
Choose one action per source, based on the highest rung of evidence you reached.
Stop: multiple rungs agree the source, or a placement, fails. Rejections and flags concentrate there, and first-party continuity collapses compared with other sources on the same build. Stop the placement, not necessarily the partner.
Hold: signals conflict or data is still arriving. Freeze budget increases, keep spend steady, and re-read the cohort after late postbacks and reclassifications land.
Repair: the evidence points to your implementation. Fix the SDK, consent order, link, or event mapping, then re-measure before judging media.
Escalate: you have documented, specific evidence concentrated in one partner. Share reason codes, dates, and cohort data with the partner. For Google Ads click issues, Google's investigation request asks for customer ID, dates, campaigns, logs, click identifiers, and a trend explanation, and limits review to the past 60 days (Google Ads Help).
Any credit or refund conversation belongs to the partner's own terms. Do not assume one will follow.
Evaluating an anti-fraud tool
If you are considering a tool or a paid fraud module, ask questions the vendor can answer with documentation, not a demo:
Which fraud types does it address in real time, and which only post-attribution?
How are rejected installs reported, and can your partners receive the reason codes?
Does it distinguish fake installs from attribution hijacking?
What happens to in-app events tied to a flagged install? AppsFlyer, for example, documents a 30-day correction window for events after hijacked installs (AppsFlyer).
Can you export raw rejected and flagged records to reconcile against your own data?
What is its false-positive handling process, and who can dispute a flag?
Vendor documentation describes how a product works. It does not prove how well it works on your traffic. Judge a tool by whether it improves decisions you can check in your own cohorts.
Privacy and consent limits
Fraud detection does not override privacy rules. Apple states that you may not derive data from a device for the purpose of uniquely identifying it, and that fingerprinting cannot be used alongside AdAttributionKit (Apple). Apple also says some postback fields only appear when privacy thresholds are met (Apple), so low-volume iOS campaigns will have less detail by design.
Consent choices will also reduce what you can see. Missing device-level detail is a limitation to record, not evidence of fraud. Involve your privacy or legal owner before adding new data collection for investigation purposes.
When not to accuse a network, and when not to buy a tool
Do not accuse a partner when:
you have not ruled out an app release or SDK change in the same window;
the evidence is one metric, such as a low CPI or a single spike;
you are comparing a rejection rate from one vendor with another's;
the cohort is still maturing and postbacks are still arriving;
quality problems appear across every source on the same build.
Do not buy a tool yet when:
your install, open, and activation events are not reliably instrumented;
nobody owns reviewing rejection reports each week;
your spend is concentrated on platforms that already filter and report invalid activity, and you have no unexplained gaps;
the real problem is attribution rules or onboarding, which a fraud tool will not fix.
A tool adds evidence. It does not add ownership. If no one acts on rung 2 and 3 today, a new dashboard will not change that.
Limitations of this guide
This article describes a diagnostic process, not a forensic standard. Platform and vendor behaviour described here comes from their own documentation as accessed on 23 September 2026 and can change. It does not provide fraud rates, loss estimates, or comparisons between vendors, because no reliable universal figure exists for your traffic. Final judgments about intent sit with the partner relationship and, where relevant, legal advice.
Get a second read on your acquisition measurement
If suspicious installs are driving budget debates on your team, Sharply Labs can run a bounded acquisition-measurement reconciliation and QA conversation for mobile app teams. We review how your network, MMP, and first-party data define and count installs, where they disagree, and which rungs of evidence you actually have.
What you receive: a prioritized diagnostic plan that separates attribution, platform-filtering, implementation, and traffic-quality questions, with a named owner and next check for each.
What we do not promise: fraud certification, recovered spend, refunds, or a lower CAC or CPA. We are a performance marketing team, not a fraud-forensics firm. If the evidence points to a partner dispute, we will say so and help you prepare it; the outcome sits with the partner.
Explore how this fits a wider growth engagement, or book a 15-minute conversation to scope it.