Short answer: do not start by comparing totals. Read the shape of the gap first: only recent days, only some days, only one network, only iOS, or a steady percentage. Each shape points to one likely cause, so you check one thing instead of ten.
What a count mismatch actually is
Count mismatch: a difference between the installs or conversions two tools report for the same campaigns and dates, usually caused by different counting rules rather than lost data.
Google says discrepancies with third-party reports are expected, and Meta says MMP results may differ, typically because of attribution windows. The job is to separate the expected gap from a broken set-up. Deciding which number to use is covered in which install number to trust; this page finds out why they differ.
Step 1: describe the gap before you explain it
Pull the same campaigns from both tools, by day, for at least 14 days, and match the pattern.
| Gap shape | Most likely cause | Check first |
|---|---|---|
| Only the last two or three days | Processing or postback delay | Re-pull the same days later |
| Daily numbers differ, weekly totals close | Time zone or date basis | Account time zones, interaction day vs install day |
| Steady percentage every day | Windows or install definition | Click and view windows, download vs first open |
| One network high, others fine | That network claims installs the MMP gave elsewhere | Per-install touchpoints in the MMP |
| iOS only | SKAN delay, ATT, modelled results | SKAN cohorts by install date |
| Sudden step on one date | A setting or integration changed | Change history in both tools |
| Network shows zero or near zero | Integration or postbacks broken | Integration status, postback log |
If two rows apply, work through them in the order below.
Step 2: rule out data that is not final yet
Data delay: the time between an install or event and the moment it appears in a report.
Google says app conversion processing can take up to 24 hours. Apple delays the first SKAN postback by a random 24 to 48 hours, and the second and third by 24 to 144 hours.
Leave out the most recent three days, and label SKAN cohorts incomplete until about six days after the last conversion window closes. If the gap closes when you re-pull older days, it was a delay; see attribution data delayed.
Step 3: line up time zone and date basis
- Time zone. New Meta ad accounts default to Pacific time; Google uses the account's local time zone; TikTok's is fixed at creation, according to its help centre.
- Date basis. Google and TikTok report on the ad interaction day, and Meta on impression or click time by default. Your MMP usually reports on the install day (general practice).
Use Google's Conversions (by conv. time) column and Meta's time-of-conversion reporting. If daily gaps shrink, you have found the cause, as in daily numbers differ but weekly totals match.
Step 4: compare windows and view-through
Attribution window: how long after a click or view an install can still be credited to an ad.
| Platform | Install click window | View-through |
|---|---|---|
| Google Ads App campaigns | 30 days by default | Fixed at 1 day; engaged-view 2 days by default for installs |
| TikTok | 7 days by default, per its help centre | 1 day by default |
| Meta app installs | 1, 7 or 28-day click options | Check the ad set's attribution setting |
| SKAN | 30 days for StoreKit-rendered ads | 24 hours |
A longer network window, or view-through installs your MMP ignores, gives the "steady percentage" row. Write each network's settings next to your MMP's before changing anything; the attribution windows guide explains each one.
Step 5: check what each tool calls an install
- Download vs first open. Google Play installs are recorded on download; third parties measure the first open.
- Reinstalls. Google Ads counts Android reinstalls as installs, and Firebase does by default. Many MMPs count a reinstall as new only after a re-attribution window (general practice; Linkrunner, for example, lists a default reattribution eligibility window of 90 days).
- One vs Every. Google conversion actions set to Every record more than tools that count One.
Step 6: find the overlapping claims
Self-attributing network (SAN): an ad network that decides for itself whether it drove an install and reports that claim to the MMP.
Each SAN claims every install it touched inside its own windows and cannot see other networks; the MMP picks one winner, usually the last click (general practice). When the MMP total is below the sum of all networks, the difference is overlap, not loss. An install with no qualifying interaction inside the MMP's windows is organic there, even if a network claims it.
Step 7: treat iOS as its own reconciliation
Without ATT permission the IDFA is all zeros, and Meta may model iOS results. Compare SKAN cohorts with network aggregates by install date, and do not expect parity with Android.
When the gap is a real fault
If no step explains the gap, or a network shows zero, check integrations and postbacks; the Meta vs MMP troubleshooter walks through the Meta case. For a side-by-side of how Meta and MMPs count, see this Meta vs MMP install discrepancy explainer. A longer list of causes is in Linkrunner's guide to attribution discrepancy causes and fixes.