Self-Attributing Networks: Why SAN and MMP Numbers Differ
A self-attributing network is an ad platform that grades its own homework. Google, Meta, TikTok, Apple, and Snap each decide internally which installs they caused, then report those claims to your mobile measurement partner. Your SAN dashboards will almost always show more installs than your MMP does, and that gap usually isn't fraud. It's the deduplication working exactly as designed.
A client once forwarded me a Meta invoice with a one-line note: "they're stealing from us." Meta's dashboard claimed 4,120 installs for the month. AppsFlyer credited Meta with 3,050. To him, that 1,070-install hole read like inflation, roughly 26%, call it a few thousand dollars of spend pointed at the wrong channel. He wanted a fraud audit and a refund.
There was no fraud. Two systems counted the same event with different rules, and only one of them had the full picture. That's the whole story of self-attributing networks in one paragraph, and it's worth understanding before you accuse anyone of anything.
What a self-attributing network actually is
Most ad networks are dumb pipes as far as measurement goes. They send a click, your MMP records it, and later the MMP decides whether that click earned the install. The network never sees your app's install event. It just waits to be told.
SANs don't work that way. They refuse to hand over raw click-level data, so the flow gets inverted. Your MMP sends the app's install and event data to the network. The network runs the match on its own device graph, decides whether it deserves credit, and sends back a yes-or-no claim. Adjust's glossary describes the mechanic plainly: the network performs attribution internally using its own identity graph and returns conversion claims to the MMP through an API, rather than exposing the click that would let the MMP check the work.
So the SAN is player and referee. It knows things your MMP can't see, like whether a user scrolled past an ad three days ago on a different device signed into the same account. And it has an obvious incentive to interpret every ambiguous case in its own favor. Nobody at Meta gets promoted for crediting an install to organic.
That's not a conspiracy. It's just what happens when you let a vendor mark its own exam.
Why the SAN number runs high
Here's the part people miss. The SAN is answering a different question than your MMP.
The SAN asks: did this user touch one of my ads inside my window? If yes, it claims the install. Meta will claim an install where the user clicked a link. Google will claim one where the user searched and tapped. Each network answers only for itself, in isolation, and none of them knows the others exist.
Your MMP asks a harder question: of everyone claiming this install, who actually gets the credit? One device. One install. Many hands raised. The MMP has to pick a single winner, and by default it picks the last qualifying touch. Every other claimant loses, even though from their own vantage point they did nothing wrong and their number stays high.
Multiply that across a portfolio. Meta claims 4,120. Google claims some overlapping set. A DSP claims another. Add them up and you'd "explain" 130% of your installs, which is nonsense. The MMP is the thing that forces the arithmetic back to 100%. The SAN dashboard never has to.
Linkrunner's 2026 guidance calls a 10-20% gap between SAN-reported and MMP-attributed installs "typical and expected." I'd widen that in practice. On accounts running three or more SANs against a lot of organic demand, I've seen steady-state gaps north of 25% with zero fraud in the pipe. The overlap is just that dense.
The last-touch dedup order
When several sources claim the same install, the MMP runs a waterfall. Not a coin flip, a ranked set of tie-breakers applied in order until one source survives. The exact rules are configurable, but the shape is standard across AppsFlyer, Adjust, and Singular.
| Step | Tie-breaker | What wins |
|---|---|---|
| 1 | Attribution window | Only touches inside the click/view window survive; everything expired is dropped |
| 2 | Engagement type | Click beats view. A tap outranks an impression, every time |
| 3 | Match certainty | Deterministic (device-ID or ID-matched) beats probabilistic (fingerprint) |
| 4 | Recency | Among survivors, the most recent qualifying touch takes the install |
| 5 | Source class | If still tied, network click beats SAN self-report beats organic fallback |
Read top to bottom, stop at the first rule that breaks the tie. A view-through claim from a SAN loses to a click from a regular network even if the SAN's impression happened later, because engagement type is evaluated before recency. That single ordering explains most "why did organic eat my Meta install" tickets I get.
And the ranking genuinely moves. Adjust reclassified Meta's Engaged Views to sit at the same priority as clicks in its waterfall as of July 21, 2025, which quietly handed Meta more wins overnight without a single new install existing. If your Meta-attributed numbers jumped that week, that's why. The installs didn't change. The referee's rulebook did.
What changed in 2025 and 2026
Two shifts widened the SAN-versus-MMP gap for almost everyone, and both are recent enough that stale mental models are still causing arguments.
TikTok pulled the biggest lever. It discontinued its legacy MMP integration on March 31, 2025, and moved fully to self-attribution. Before that, TikTok behaved more like a dumb pipe. After, it became a proper SAN that reports claims and keeps its click data to itself. If your TikTok reconciliation broke in spring 2025 and nobody could say why, that's the date on the death certificate.
Meta then rewrote its windows. Per Dataslayer's reporting, Meta removed the 7-day-view and 28-day-view windows in January 2026, then in March 2026 redefined what even counts as a click, shunting soft social interactions into a separate lower-priority bucket. Both changes shrink the set of touches Meta can legitimately claim. Which means Meta's own dashboard now reports fewer installs than it used to, and the direction of your discrepancy may have flipped depending on how your MMP mirrored the change.
The lesson I'd tattoo on every growth team: a reconciliation gap that suddenly moves is almost never fraud and almost always a policy change at the network or a config change at the MMP. Check the changelog before you check for crime.
When the gap actually is a problem
Fine, so most discrepancy is boring and expected. When should you care?
Care when the shape is wrong, not the size. A stable 20% gap is a rounding error you report around. A gap that's climbing week over week on one source, or a source claiming installs your MMP can barely find, is the tell.
The classic culprit is click flooding. A shady sub-publisher fires millions of low-quality clicks at random device IDs, betting that some of those users organically install your app later. When they do, the fraudster's stale click sits in the attribution window and steals the credit. Linkrunner's fraud teardown lists the fingerprints: absurd click-to-install ratios, and a flat time-to-install distribution instead of the natural spike you'd see right after a real click. If installs trickle in evenly for seven days after the "click," no human clicked anything.
Then there's the counterintuitive one. If your MMP blocks 8% of a network's installs as fraudulent, that network's dashboard will report roughly 8% more installs than your MMP credits, because it counted the junk your MMP threw out. So a widening gap on a specific source can mean your fraud protection is doing its job, not failing. I've watched teams "fix" a discrepancy by loosening their fraud rules, which is like fixing a smoke alarm by taking the battery out.
The uncomfortable truth is that dedup logic and fraud detection produce the same symptom, a lower MMP number, from opposite causes. You can't tell them apart from the topline. You have to open the source-level breakdown and look at the distribution.
Which number do you actually report?
The MMP number. Almost always the MMP number.
It's the only view that enforces one-install-one-owner, so it's the only one that sums to reality across your whole mix. SAN dashboards are useful for optimizing inside that network, since Meta's own signal is what Meta's algorithm learns from. But the second you're comparing channels or reporting blended CAC to a finance team, summing SAN dashboards will double-count every overlapping user and make your best channels look better than they are.
One caveat, and it's a real one. The MMP is still just picking a last-touch winner. It answers "who to credit," not "what actually drove the install." A user who'd have installed anyway, but happened to tap a retargeting ad on the way, gets counted as a paid win by every last-touch model on earth, MMP included. If you need to know which spend is genuinely causal rather than merely last-in-line, deduplication can't tell you and neither can any SAN. That's a job for holdout tests, and it's why incrementality testing and attribution answer genuinely different questions. One tells you whom to thank. The other tells you what to cut.
If you're rebuilding measurement from the SDK up and want the touchpoint layer to survive a privacy audit, the same last-touch logic sits underneath it all in a privacy-first attribution reference architecture. Get the dedup order right there and the reporting arguments mostly disappear.
FAQ
Is a self-attributing network the same as an MMP? No, and they're often on opposite sides of a disagreement. A SAN is an ad platform (Meta, Google, TikTok) that reports which installs it thinks it caused. An MMP is the neutral referee that collects every network's claim and picks one winner per install. The SAN is a claimant. The MMP is the judge.
Why does Meta show more installs than AppsFlyer? Because Meta counts every install it can plausibly claim in isolation, while AppsFlyer deduplicates that claim against every other source and often awards the install to a later touch or to organic. A gap of 10-20%, sometimes more, is normal and doesn't mean anyone is lying.
Can I make the two numbers match? Not exactly, and chasing a perfect match is a waste of a quarter. You can shrink the gap by aligning attribution windows between the SAN and the MMP, but they'll never converge fully because the SAN has device-graph signal your MMP can't see. Aim to explain the gap, not close it.
Does SKAdNetwork change any of this? It changes the plumbing, not the principle. SANs still self-report, and your MMP still reconciles their claims against its own view. On iOS the signal is coarser and delayed, so the discrepancy is often larger and noisier, but the who-claims-versus-who-gets-credit split is exactly the same.