Canonical: https://www.strataigize.com/insights/rebuild-unreliable-mobile-attribution/
Description: Store, MMP and ad platform counts follow different rules. Reconcile them step by step to find which gaps need a tracking fix and which need a fairer comparison.
Published: 2026-11-03T00:00:00.000Z
Modified: 2026-11-03T00:00:00.000Z

[← Blog](https://www.strataigize.com/insights/)

# Mobile Attribution Doesn't Match? Find What Actually Broke

By [**Ian McGavin**](https://www.strataigize.com/about/team/ian/), Founder & CMO · Published November 3, 2026 · 9 min read · [Editorial standards](https://www.strataigize.com/trust/editorial-standards/)

Mobile attribution can disagree without broken tracking. App stores, MMPs and ad platforms count different events on different clocks, so their totals are expected to differ. Give each system one question to answer, then bridge store downloads to MMP installs to platform claims, explaining each step with that tool's documented rule. Whatever the bridge cannot explain is where to look for the defect. Rebuild revenue separately, because gross amounts, currency and subscription renewals break in other places, and keep iOS privacy postbacks as their own aggregate ledger.

In this article

1.  [Give each system one question to answer](https://www.strataigize.com/insights/rebuild-unreliable-mobile-attribution/#give-each-system-one-question-to-answer)
2.  [Build an install bridge before blaming the tracking code](https://www.strataigize.com/insights/rebuild-unreliable-mobile-attribution/#build-an-install-bridge-before-blaming-the-tracking-code)
3.  [Revenue breaks in different places](https://www.strataigize.com/insights/rebuild-unreliable-mobile-attribution/#revenue-breaks-in-different-places)
4.  [Keep the iOS privacy ledger separate](https://www.strataigize.com/insights/rebuild-unreliable-mobile-attribution/#keep-the-ios-privacy-ledger-separate)
5.  [The order to rebuild in](https://www.strataigize.com/insights/rebuild-unreliable-mobile-attribution/#the-order-to-rebuild-in)
6.  [When the numbers still disagree](https://www.strataigize.com/insights/rebuild-unreliable-mobile-attribution/#when-the-numbers-still-disagree)

When attribution counts disagree, first check whether the tools answer different questions. The App Store says one number, the mobile measurement partner (MMP) says a second and Meta says a third, and the team concludes that nothing can be trusted. Each of those numbers follows published counting rules. Line up those rules to separate expected differences from gaps that need investigation.

The documentation cited here was checked on November 3, 2026. Vendors change defaults, so confirm your own account settings before using any figure below.

## Give each system one question to answer

Before reconciling anything, write down what each source is allowed to decide. A useful split for most app teams:

| Source | The question it answers | What it cannot settle |
| --- | --- | --- |
| App Store Connect and Google Play Console | How many downloads happened, and how much money the store billed and expects to pay out | Which ad deserves credit |
| Your MMP (AppsFlyer, Adjust, Singular and others) | Which source gets credit under rules you configured | Whether the ad caused the install |
| Each ad platform | What that platform believes it influenced, for its own bidding | How its claims overlap with other platforms |

The split matters because the platforms are not trying to agree. [AppsFlyer’s Meta discrepancy guide](https://support.appsflyer.com/hc/en-us/articles/4410481130641) says Meta self-attributes installs “regardless of other media sources”, while AppsFlyer applies last-click attribution across all of them. If Meta and another network both touched the same user, both can claim the install in their own dashboards while the MMP credits one. Summing platform claims can therefore overshoot the MMP total, although the same guide documents gaps in the other direction, such as installs that AppsFlyer attributes through install referrers but does not report back to Meta.

Neither view measures causation. Attribution assigns credit under rules; proving that ads created extra installs needs an experiment, as our [guide to what an MMP measures](https://www.strataigize.com/insights/what-is-an-mmp-understanding-mobile-measurement-partners/) explains.

## Build an install bridge before blaming the tracking code

If you suspect the SDK first, test that suspicion with a bridge. The SDK is the measurement code from the MMP that is built into the app and reports installs and purchases. A bridge is a short table that walks from one count to the next and assigns each difference to a documented cause. Fill it in for one closed week, with every source set to the same date range.

**Store downloads to MMP installs.** These differences are documented by the vendors themselves:

-   **Install definition.** [AppsFlyer’s app store discrepancy guide](https://support.appsflyer.com/hc/en-us/articles/207040726-Resolve-AppsFlyer-App-stores-discrepancies) says it records an install only at first launch, while stores count the download. People who never open the app appear in the store and not in the MMP. AppsFlyer puts launches at “about 90%” of downloads and warns the share varies by country and category.
-   **Install date.** The same guide notes stores date the download, while the MMP dates the first launch. A download on Sunday night opened on Monday lands in different weeks.
-   **Time zone.** [Google Play Console](https://support.google.com/googleplay/android-developer/answer/139628?hl=en) states that installation data is based on Pacific Time. AppsFlyer’s default app time zone is UTC unless you change it, according to the same [app store discrepancy guide](https://support.appsflyer.com/hc/en-us/articles/207040726-Resolve-AppsFlyer-App-stores-discrepancies).
-   **Reinstalls.** AppsFlyer’s [re-attribution window](https://support.appsflyer.com/hc/en-us/articles/115002587066-Re-Attribution-Window) defaults to 90 days, inside which a reinstall is not a new install. Apple’s [App Store Connect metric definitions](https://developer.apple.com/help/app-store-connect-analytics/reference/metrics-definitions) report First Time Downloads and Redownloads separately, and Play Console’s “Install events” includes devices that had the app before. Compare first-time downloads with new installs, not totals with totals.
-   **SDK upgrades.** AppsFlyer notes that existing users who update into the first build containing its SDK can appear as organic installs for a few days.

**MMP installs to platform claims.** AppsFlyer’s Meta guide lists the main causes. It gives Meta’s default windows as 7-day click and 1-day view and recommends setting the MMP to match. Meta reports in Pacific Time by default, while AppsFlyer defaults to UTC. Meta also credits cross-device installs, which AppsFlyer does not, and can show a reinstall from a re-engagement campaign as a new install while AppsFlyer files it as a re-attribution. Installs that fail an MMP’s fraud or validation rules can still count in the platform’s own report. Google Ads adds a clock difference: its [primary conversion columns](https://support.google.com/google-ads/answer/6270625?hl=en) are dated by the time of the click, and separate “by conv. time” columns use the date of the conversion.

Here is the form to copy. Set the tolerance column before you pull the numbers, from what each documented cause could plausibly explain for your app. The tolerance is a screening threshold, not proof: a gap inside it is not worth chasing yet, and a gap outside it is where to start. Where you can measure a cause directly, such as the share of downloads never opened, replace the estimate with the measurement. A measured gap cannot set its own passing mark.

| Step | Count A | Count B | Documented causes for the gap | Tolerance set beforehand | Observed gap | Inside tolerance? |
| --- | --- | --- | --- | --- | --- | --- |
| Store first-time downloads to MMP new installs |  |  | Never launched, launch date, time zone, reinstall window |  |  |  |
| MMP installs credited to one network to that network’s claim |  |  | Windows, time zone, self-attribution, cross-device, re-engagement reinstalls, rejected installs |  |  |  |
| Revenue in the MMP to revenue the store reports |  |  | Gross or net, currency, time zone, renewals, refunds, duplicates |  |  |  |

An illustrative example, with invented values: a week shows 1,000 first-time downloads in App Store Connect and 850 new installs in the MMP. Before pulling the data, the team set a 16% tolerance for that row: 12% for apps never opened, a little above AppsFlyer’s rough 10% figure, plus 4% for downloads opened after the week closed. The 15% gap is inside it. Had the MMP shown 600 installs instead, the 40% gap would be well outside, and the bridge’s allowances would leave the extra 24 points uncovered. That residual is what to investigate first. Typical suspects are an SDK that starts late, a release without the SDK, or an app ID mismatch.

When the residual is large, trace one controlled install or purchase through the app, the MMP and each partner. Our [Adjust integration guide](https://www.strataigize.com/insights/integrating-adjust-for-campaign-optimization/) and [AppsFlyer integration guide](https://www.strataigize.com/insights/integrating-appsflyer-for-campaign-optimization-a-complete-guide/) match each observation to the check it calls for.

## Revenue breaks in different places

Install counts and revenue fail for different reasons, so give revenue its own bridge.

**Gross or net.** [AppsFlyer’s in-app event documentation](https://support.appsflyer.com/hc/en-us/articles/115005544169) says it displays revenue exactly as the SDK sends it, without automatically deducting store commission or VAT, unless the developer deducts them first or sends a separate net revenue field. The stores report on different bases. [App Store Connect](https://developer.apple.com/help/app-store-connect-analytics/reference/metrics-definitions) shows Sales, the amount billed to customers, and Proceeds, the price after taxes and Apple’s commission. [Google Play Console](https://support.google.com/googleplay/android-developer/answer/139628?hl=en) bases Revenue on estimated sales including tax, and dates financial data in UTC while dating installs in Pacific Time. Compare like with like: gross MMP revenue against Sales or Play Revenue, and net MMP revenue against Proceeds. Check tax too, since Play Revenue includes it, App Store Sales includes it only when it was part of the product price, and MMP revenue includes whatever your app sends. Comparing gross MMP revenue with Proceeds makes paid users look more valuable than they are.

**Currency.** The same page says a missing currency parameter defaults to USD. A purchase made in Canadian dollars or euros that arrives without its currency code is counted as the same number of US dollars.

**Renewals and refunds.** Apple reports subscription renewals and refunds to your server as [App Store Server Notifications](https://developer.apple.com/documentation/appstoreservernotifications/notificationtype), including DID\_RENEW for a renewal and REFUND for a refunded transaction, and Google Play sends [Real-time developer notifications](https://developer.android.com/google/play/billing/rtdn-reference). AppsFlyer’s [store revenue product](https://support.appsflyer.com/hc/en-us/articles/42138855425297) lists those notifications among its sources for subscription events that occur inside and outside the app. A setup that records revenue only from events the app itself sends can therefore miss renewals and refunds that happen outside the app. If attributed revenue stops growing after the first billing period while the store’s subscription revenue keeps rising, check this first.

**Duplicates.** AppsFlyer’s Meta guide warns that Meta does not de-duplicate in-app events reported by both the Meta SDK and an MMP, which can inflate Meta’s reported revenue. Send each event to each network through one path only.

## Keep the iOS privacy ledger separate

On iOS, privacy-preserving attribution arrives on its own schedule and in aggregate. A postback is a delayed report sent to the ad network, rather than a record you can link to an individual user. Under Apple’s [AdAttributionKit rules](https://developer.apple.com/documentation/adattributionkit/receiving-ad-attributions-and-postbacks), the minimum time between a conversion event and the ad network receiving a postback is 24 to 48 hours. [Postbacks cover up to three conversion windows](https://developer.apple.com/documentation/adattributionkit/receiving-postbacks-in-multiple-conversion-windows): days 0 to 2, 3 to 7 and 8 to 35 after first launch. A conversion value is a code the app uses to report activity, such as reaching a stage or making a purchase. Only the first postback can carry the fine-grained value, the more detailed version of that code. Apple uses data tiers to limit the detail it shares for privacy; in the lowest tier, only the first postback is sent.

Two consequences follow for a rebuild. First, iOS results arrive late and in stages. Apple adds a random delay of 24 to 48 hours to the first postback and 24 to 144 hours to the second and third, and the first window itself runs to day 2 after first launch. Later conversion values can keep arriving for roughly six weeks after first launch, and Apple gives the device up to 60 days after an install to send its first conversion value update. Decide in advance how long you will wait before treating an iOS week as complete, and record that cutoff beside the bridge. Second, Apple limits what each postback contains to protect crowd anonymity, so treat these postbacks as an aggregate count. Report them beside your user-level install data rather than trying to match them to individual installs. Modeled results add another layer: AppsFlyer notes that when Meta’s Aggregated Event Measurement is enabled, Meta may model conversions differently in Ads Manager than in what it shares with the MMP.

## The order to rebuild in

1.  **Freeze definitions.** Write one page naming the install event, the revenue event, gross or net, the reporting currency, the time zone and every attribution window. Change settings in the tools to match it, and record the date of each change.
2.  **Fill the install bridge** for one closed week, using tolerances set beforehand.
3.  **Fill the revenue bridge** against the store’s own reports, including renewals and refunds.
4.  **Trace one controlled event** only for rows the bridge cannot explain. Stop when that row is explained or the defect is fixed; if neither happens after a full traced test, hold that report out of budget decisions and record the unresolved row.
5.  **Re-run the bridge** on the next closed week. Confirm the fix itself with the traced event from step 4, which should now arrive where it failed before. Then check that the row passes the screen against the tolerance written down before the fix, not a new one chosen afterwards.

Credit and cause stay separate in the client reporting we work from as well. In the Crush Crush growth review, players attributed to paid campaigns are reported separately from the whole cohort, which also counts organic and unattributed players. We present the paid figure as an attribution measure, not causal lift, and never present the whole-cohort return as advertising return on its own.

## When the numbers still disagree

Stop reconciling once every row of the bridge is inside its tolerance. The screen does not prove every count is right, and a later week can still break, but it means no row currently points to a defect, and the decision can go to the source you assigned to that question in the first step. Moving a budget on a platform’s self-reported number while the MMP disagrees within tolerance is a choice about which rules to trust, and it should be written down as one.

Author

**Ian McGavin**

Founder of Strataigize, connecting business strategy, growth marketing and applied AI. His expertise includes paid media, measurement and AI-search visibility.

### Growing an app? We do this all day.

One client added 242,279 installs in 16 weeks. Another's ASO overhaul lifted downloads more than 900%. Store listing, paid UA, and retention, run as one loop.

[See mobile app marketing →](https://www.strataigize.com/services/mobile-app-marketing/)

[Add us as a preferred source on Google](https://www.google.com/preferences/source?q=strataigize.com)

A free Google setting to see more of our relevant articles in your own search experience. You can change it any time.

## Related reading

[All Mobile App Marketing articles →](https://www.strataigize.com/insights/topics/mobile/)

[20 Mobile App Marketing Statistics for 2026 20 mobile app marketing statistics with dates and limits: store spending, acquisition, retention and subscription conversion from primary reports.](https://www.strataigize.com/insights/20-mobile-app-marketing-statistics-2026/) [Adjust vs AppsFlyer: Pricing and a Practical MMP Comparison Compare Adjust and AppsFlyer pricing, data access and iOS measurement. Use a matched quote and a migration test to choose the right MMP.](https://www.strataigize.com/insights/adjust-vs-appsflyer/) [App Intelligence Tools in 2026: Coverage and Costs Compare app intelligence tools by data coverage, current pricing and research task. Understand estimates, product consolidation and store-data limits.](https://www.strataigize.com/insights/app-intelligence-tools-guide/)