Your MMP and your network will never agree

Every UA team at some point commissions the discrepancy project: a spreadsheet, an analyst, a fortnight spent working out why the network says 12,000 installs and the MMP says 9,400. The project ends with a list of partial explanations and a residual nobody can account for. A month later the numbers drift again.

My position: this work is mostly wasted, and the expectation behind it is wrong. An MMP and an ad network are not two instruments measuring the same quantity with different error, but two systems built by parties with different interests, answering different questions, on different data. Their disagreement is permanent. The useful skill is reading the gap rather than closing it. Some measurement leads will find that defeatist; I think it is the only position that survives contact with how the systems actually work.

Different questions, not different answers

Ask what each system is actually trying to establish.

The network's question is: which of the installs in this app can we plausibly connect to an ad we served? Its data is its own impression and click log, its own user graph where it has one, and whatever install signal it gets back. Its default windows are generous, its view-through logic is permissive, and its modelling fills gaps on iOS. It sees nothing of any other network's activity.

The MMP's question is: across every source we can see, which single touchpoint gets credit for each install under the priority rules this client configured? Its data is every partner's click and impression postbacks, the Apple postbacks from SKAN and AdAttributionKit, referrer data from Google Play, and the client's own configured windows. It de-duplicates, then applies a hierarchy.

A network can be entirely honest and still report a number the MMP will never reproduce, because the network is counting plausible connections and the MMP is counting winners of a contest. Add the ordinary technical differences on top, in time zones, install definitions, re-install handling, postback failures. The residual then stops being a mystery. It is the sum of a dozen small structural choices, each defensible.

The incentive that keeps the gap open

If the gap were purely technical it would narrow over time as both sides fixed bugs. It does not narrow, and the reason is that neither party benefits from closing it.

The network benefits from a larger reported number. The MMP benefits from being the arbiter, which means its value depends on the client believing the network number is unreliable. Both are commercial vendors, and the arbiter's commercial value rests on the two sides continuing to disagree; an arbiter is worth less in a world where the parties agree without it. The client is the only party who wants agreement, and the client is the only party without control of either system.

What the gap tells you when you stop fighting it

Once you accept the gap as structural, its movement becomes informative. Three readings.

A stable gap is healthy. If the network consistently reports twenty to thirty per cent more installs than the MMP credits, that ratio is a property of that network's claiming logic and your window configuration. You can budget through it. Track it as a per-network ratio and move on.

A widening gap with rising network-reported performance is the pattern to worry about. It usually means the network has changed something in its matching or modelling that lets it claim more installs the MMP will not confirm. The network's dashboard improves, its share of your budget rises in the next review if anyone is planning off dashboard numbers, and the real cohort has not moved at all. Look for a product changelog or a quiet default change around the inflection date.

A narrowing gap with falling network-reported performance is often a postback or SDK issue on your side, rather than a real deterioration. The network is receiving fewer install signals to claim against. So check the integration before you cut the budget.

A worked illustration

Take an illustrative network at fifteen per cent of spend. Its dashboard shows 12,000 installs at a reported CPI of two dollars fifty; the MMP credits 9,400, a ratio of 0.78 that has held within a few points for six months.

A month on, the dashboard shows 14,500 installs at a CPI of two dollars ten, which reads as an improvement, while the MMP credits 9,600 and the ratio drops to 0.66. Nothing on your side changed. MMP-attributed CPI has barely moved, and day-seven retention of the MMP-credited cohort is flat.

Reconciling those numbers is impossible and pointless. Reading them is straightforward: the network is claiming roughly 2,500 more installs it cannot substantiate to a third party, and its efficiency story is a reporting change. Hold spend flat, ask the account manager what changed, and raise the question of view-through eligibility in your MMP configuration. The piece Reading an MMP dashboard without fooling yourself covered the configuration side.

The honest approach carries a further trade-off, and it is worth stating. Running the operation on MMP numbers alone has a cost. Networks optimise their bidders partly on the install signal you send back through the MMP. If your configuration is strict, running short windows without view-through, the network sees fewer conversions, its algorithm has less to learn from, and delivery can genuinely worsen. Strict measurement and strong delivery pull in opposite directions, and no configuration maximises both.

The resolution is to separate the two roles. Configure postbacks to give the network enough signal to optimise, including view-through where it demonstrably helps delivery. Configure your reporting layer, whether that is the MMP's own dashboards or a warehouse on top, to use the stricter definition for budget decisions. The network gets its signal; the studio makes decisions on a number the network did not write.

The one reconciliation worth doing

Kill the monthly discrepancy project and replace it with a single annual exercise: for each of your top three or four networks, run an incrementality holdout and compute the ratio of incremental installs to MMP-credited installs. That ratio, not the network-to-MMP gap, is the correction that matters, because it measures the distance between what the MMP credited and what actually would not have happened otherwise.

Everything else is two vendors disagreeing about a contest neither of them entered on your behalf.

Related archive reading

These articles provide related context and remain subject to their stated review status.

• The hook is a promise; retention is the invoice
• Reading your MMP dashboard after AppsFlyer's round: nothing changes, and everything