Why AppsFlyer and Meta Ads Manager report different installs — attribution windows, view-through, dedup, SKAN modeling — and which number to optimize on.
Oct 19, 2026 - 7
The AppsFlyer Facebook discrepancy — Meta Ads Manager reporting more installs than AppsFlyer attributes to Meta — is normal, and most of it is by design. The two systems answer different questions. Meta counts every install it believes its ads influenced, within its own attribution setting, regardless of what other networks did. AppsFlyer picks one winner per install across all your networks and organic, under the lookback windows you configured, and dates it by install time rather than ad engagement time. A gap that's stable over time is a feature of the measurement. A gap that changes suddenly is a signal worth investigating.
In this guide: The causes · How big is normal? · iOS · Which number to use · When the gap changes · Analyze both
Meta counts installs within the attribution setting on your ad set: the number of days after a click or a view in which an install is credited to the ad. AppsFlyer applies its own lookback windows, configured per network in the integration. If Meta credits views and AppsFlyer's view-through window is shorter or switched off, every view-through install inside Meta's window and outside AppsFlyer's becomes discrepancy. AppsFlyer's own guidance is to set Meta's attribution to 7-day click and 1-day view so the two line up as closely as possible.
This is usually the biggest single cause. Meta is a self-attributing network: it reports the installs it believes it drove, using only what it saw. It doesn't know that the same user also clicked a Google ad an hour later. AppsFlyer sees every network's touchpoints and gives each install to exactly one source, typically the last eligible click. Installs that Meta claims and AppsFlyer credits to Google, TikTok or organic all show up as discrepancy. The more networks you run, the bigger this slice.
Ad networks typically report an install against the date of the ad engagement — the click or impression. AppsFlyer reports it on the date of the install. A user who clicks on Monday and installs on Wednesday lands on different days in each system. Over a month this mostly washes out. Day by day, and especially around weekends, campaign launches and month-end, it doesn't.
A returning user who reinstalls may count as a new install for Meta. AppsFlyer may treat it as a reattribution or a re-engagement, depending on your settings and the user's history. Apps with high churn and reinstall rates see more of this.
Meta reports in your ad account's time zone; AppsFlyer reports in the app's time zone. A few hours of offset moves installs across date boundaries. And yesterday's numbers in either system can still be filling in this morning.
The discrepancy isn't limited to installs. If an in-app event is reported to Meta both through the Meta SDK and through AppsFlyer, Meta doesn't deduplicate them, so purchases or registrations can be double-counted on Meta's side. Pick one path for each event.
There's no universal number, and anyone who gives you one is guessing about your account. The size depends on:
What matters is the ratio's stability. Measure Meta-reported installs ÷ AppsFlyer-attributed Meta installs per week, per OS, over the last two months. That's your baseline. A ratio that moves outside its usual range is the thing to investigate, not the ratio itself.
On iOS, user-level attribution needs App Tracking Transparency consent, so much of the measurement runs through Apple's privacy-preserving frameworks, SKAdNetwork and AdAttributionKit. Postbacks arrive delayed, aggregated and with coarse conversion values. Meta and AppsFlyer each receive and model this data in their own way: different decoding of conversion values, different modeling for non-consented users, different timing. Expect a larger and noisier iOS gap than Android. Also expect step changes when either side changes its modeling. Treat iOS cohort numbers as partly estimated, and compare iOS against its own history rather than against Android. See SKAN and AdAttributionKit for UA analysis.
Both, for different jobs:
A stable discrepancy is measurement. A sudden change in it usually means something changed in the plumbing, not in your users. Check, in this order:
Until you know which it is, don't reallocate budget on the change. A measurement shift can make a healthy campaign look broken overnight. Installs dropped suddenly covers the delivery-side version of this diagnosis.
The usual advice is "pick a source of truth." It's half right. You need one source of truth for each decision, and the decisions differ. In practice the useful view keeps both numbers side by side:
That's how PvX Delta is built. It reads Meta Ads and your MMP every night through their official, read-only APIs and keeps each source's definitions intact. When cohort metrics move in one synchronized step across every campaign on the same date while delivery is unchanged, it reports a likely measurement change rather than a performance problem. Delta doesn't reconcile the two numbers into one; nothing honest can. It audits both in one context. More on that in MMP data vs ad network data and auditing AppsFlyer and Meta Ads together.
Read Meta and AppsFlyer in one context, every night.
PvX Delta is free and read-only.
Oct 19, 2026 - 7 minutes
Oct 16, 2026 - 10 minutes
Oct 16, 2026 - 15 minutes
Some of the fastest growing businesses in the industry