Meta Says 4,000 Installs. Your MMP Says 2,600.

Because they are not measuring the same event, and at least four systems in your stack each define the word "install" differently — all of them documented, none of them wrong. The discrepancy you are looking at is not a bug to be fixed. It is a translation problem to be understood once and then managed.

Line up the definitions and the argument usually ends inside ten minutes:

Google's own Play Console documentation makes that last contrast explicitly, noting that its first-time installer metric differs from Google Ads data because the Ads figure includes all install events, including reinstalls and installs on multiple devices. Two Google products, one company, two different numbers by design.

Once you accept that, the question changes from "which dashboard is lying" to "which definition do I want for this decision". In our portfolio, the teams that argue about attribution for months are almost always teams that never wrote the four definitions down. The ones that resolve it in an afternoon are the ones who did.

An app activation, not a store install — and that single fact explains a large share of every Meta-versus-MMP gap you will ever see. Most founders assume Meta is counting downloads from the store. It is not; it is counting the SDK waking up.

Meta's documentation on getting started with app events on Android defines its automatically logged App Install event as the first time a new person activates your app, or the first time your app starts on a particular device. There is no store transaction in that definition anywhere.

Three consequences follow directly, and each one moves the number:

• A device that installs but never opens is not a Meta install. It is a Play Console install. This gap is real and it is larger than teams expect, especially on low-end devices and slow connections.
• The same person on a second device is a second Meta install and a second Google Ads install event, but still one Play Console first-time installer.
• Meta counts activations it can see, whether or not your MMP attributes them to Meta. Your MMP is deciding source; Meta is counting events. These are different jobs.

The same page is worth reading for two more automatically logged events, because they cause their own confusion later. App Launch is logged when someone opens your app, with a specific rule that a second app launch event within 60 seconds of the first is not logged. And In-App Purchase is automatically logged when a purchase processed by Google Play has been completed — which is the beginning of the double-counting problem covered below.

Store installs, Meta-reported installs, MMP-attributed installs, and MMP total installs from all sources — in that order, over the same date range, in the same time zone. Skipping this step is why most attribution debugging goes nowhere: teams start comparing individual campaigns before establishing whether the totals are even close.

Fix the time zone before you start. Meta, your MMP and the stores can each be reporting on a different day boundary, and a one-day offset on a growing campaign manufactures a discrepancy that has nothing to do with attribution. It is the single most common false alarm we see, and it costs teams days.

The order matters because each step localises the fault. If step one and step two disagree, your measurement is broken and no amount of window-tuning will help. If they agree and steps three and four disagree, you have a genuine attribution question — which is the rest of this article. Our comparison of AppsFlyer, Adjust and Singular covers where each MMP's defaults sit, and our attribution guide covers the underlying model.

Because the Meta SDK logs purchases automatically, your MMP logs them, and someone on your team probably logs them manually as well — three independent reporters of the same event, with no shared deduplication. Revenue that looks too good is the symptom, and it is far more damaging than an install discrepancy because it corrupts your unit economics.

Meta's Android app events documentation states that certain app events are automatically logged and collected for Events Manager unless you disable automatic app event logging, and that In-App Purchase is automatically logged when a purchase processed by Google Play has been completed. Nobody has to write that code for it to fire.

The failure pattern is predictable. A developer integrates the Meta SDK — purchases now log automatically. A growth lead integrates the MMP and maps purchase events — purchases now log again. Then someone adds an explicit purchase call because the dashboard "seemed to be missing some". The result is a revenue figure inflated by an integer multiple, discovered months later when the finance number and the marketing number are put on the same slide.

This is the part of measurement worth paying attention to early, because an install discrepancy costs you an argument and a revenue discrepancy costs you a strategy. We treat event ownership as a design decision rather than an integration detail in our analytics work.

The advertiser-tracking flag, the client token, and the consent state that gates both — and skipping any of them degrades what Meta will do with your events. On iOS the gap between "the SDK is installed" and "the SDK is working as intended" is wide, and nothing on your dashboard announces which side you are on.

Meta's iOS app events setup documentation is specific. You supply an App ID and a client token — the token found under Settings, Advanced, Client Token in the App Dashboard. From iOS 14.5 you must set Settings.shared.isAdvertiserTrackingEnabled = true if the device provides consent, and false if tracking is not authorised. Separately, FacebookAdvertiserIDCollectionEnabled controls advertiser ID collection and can be managed in the Info.plist or programmatically.

The consequence of getting this wrong is stated by Meta plainly in its guidance on the advertising tracking flag: if you do not set the Advertiser Tracking Enabled parameter indicating that an iOS 14.5 and later event is opted in for tracking, Meta may restrict its use of that event.

Read that as it is written. Your event still fires. Your SDK still reports. What changes is what Meta is permitted to do with it downstream — which shows up as weaker optimisation and a wider gap, with no error message anywhere in the chain. This is why an iOS campaign can look structurally worse than its Android twin for reasons that have nothing to do with the audience.

On Android it is the closest thing to a neutral referee you have, because the data comes from Google Play rather than from any advertising party — and it includes server-side timestamps that a client cannot fake. When two dashboards disagree on Android, this is the tiebreaker.

Google's Play Install Referrer API returns the referrer URL of the installed package, the timestamp of when a referrer click happened, the timestamp of when installation began — both of those available client-side and server-side — the app's version at first install, and whether the user interacted with your instant experience in the past 7 days.

The server-side timestamps are the underused part. Client-side timestamps come from a device whose clock can be wrong or deliberately manipulated; the server-side pair comes from Google. When you are trying to establish whether a click genuinely preceded an install by a plausible interval — which is the core question in both attribution disputes and click-injection fraud — those are the numbers to reason from.

Two operational details from Google's Install Referrer Library documentation matter for implementation. The referrer information is available for 90 days and will not change unless the application is reinstalled. And you should invoke the API only once, during the first execution after install, to avoid unnecessary calls.

There is no equivalent on iOS. That asymmetry is not a gap in your setup — it is the platform, and it is why iOS attribution debates end in probability while Android debates can end in evidence. Our post on the Play Install Referrer covers implementation in full.

Any stable gap explained by the definitions above is normal; a gap that changes shape suddenly, or that has the wrong internal structure, is the one to investigate. We deliberately do not publish a "normal discrepancy percentage" here, because the honest answer is that it depends entirely on your platform mix, your consent rate, your windows and your app's open rate — and every published benchmark we could find traced back to a vendor with no methodology attached.

What is diagnostic is not the size of the gap but its behaviour:

• Stable gap, consistent direction. Almost always definitional. Document it, apply it as a known factor, move on.
• Gap that changed on a specific date. Something shipped. A release, an SDK update, a window change, a consent-prompt change. Find the date first, then find what happened on it — this is far faster than reasoning about attribution theory.
• Installs with implausible click-to-install intervals. On Android, compare the server-side referrer click and install-begin timestamps. Clicks arriving in the seconds before an install that the user could not have initiated is the signature pattern worth escalating.
• A source whose installs convert to nothing. Volume that never produces a second session or an in-app event is the oldest signal there is.

The last two are where measurement questions become fraud questions, and they need a different response from anything else on this page. Our guide to mobile ad fraud prevention covers the patterns and what to do about them. The important discipline is not to reach for fraud as an explanation before the definitional and configuration causes are ruled out — in our experience most suspected fraud in a first paid campaign turns out to be a lookback-window difference and a time-zone offset.

Six steps, run in order, ending with a written statement of your known gap that you can reuse every month instead of re-litigating it. The output is not agreement between the systems — that is not achievable — it is a documented, stable relationship between them.

Do it once properly and the recurring cost drops to near zero, because next month's question is answered by comparing against the documented relationship rather than by starting again. Across the 300+ apps we have managed since 2013, this document is the single cheapest artefact in growth measurement and one of the rarest.

If the numbers still do not reconcile after this, the problem is almost certainly integration rather than attribution, and it is worth getting a second pair of eyes on the implementation before spending more money against data you do not trust. That is a short conversation — tell us what the four numbers are and we will usually know where to look.

The store number for growth, your MMP for channel decisions, and never the ad platform's own figure as your headline. The reporting choice matters more than the reconciliation, because it determines whether next quarter's decisions are made on a defensible basis.

The reasoning is straightforward. The store is the only party with no incentive in the outcome and the only one that observes the actual transaction, which makes Play Console first-time installers or App Store Connect units the right top-line growth number. Your MMP is the only system that applies one consistent methodology across every channel, which makes it the right basis for deciding where the next rupee goes. And the ad platform is marking its own homework — useful for optimising inside that platform, and structurally the wrong choice for a headline.

Two practices make this survivable in front of an audience:

• Name the source on the slide. "Installs (Play Console, first-time installers)" ends an entire category of meeting. A bare number invites the argument.
• Never change source between updates. A switch from MMP to platform numbers between two board decks reads as a growth jump that did not happen, and it is very hard to recover credibility from once noticed.

The deeper point is that no attribution system answers whether the spend caused the growth — they all answer where to file installs that already happened. When the stakes get high enough, the question becomes incrementality, which is a different measurement entirely and the subject of our guide to incrementality testing and MMM. Our Meta app install campaigns guide covers the build side once the measurement is trustworthy.