Facebook Ads discrepancies

At a glance: Learn about the differences in attribution models between Facebook Ads and AppsFlyer.

Facebook Ads discrepancies with AppsFlyer

As any two major players in the mobile user acquisition eco-system, AppsFlyer and Facebook differ in their attribution models. This may cause discrepancies to occur between Facebook and AppsFlyer dashboards.

While we work closely with Facebook to minimize these discrepancies, advertisers should be aware of the following causes for them.

Detect a discrepancy between AppsFlyer and Facebook

Compare events listed in Facebook Event Manager to those in AppsFlyer reports. If the number of events varies significantly, there may be a discrepancy.

Differences in attribution models

Cause Facebook AppsFlyer

Click attribution lookback window

7 days (Note that there are some specific cases where the default is different).

1-30 days. Make sure to set to 7 days with Facebook.

View-through attribution lookback window

1 day (Note that there are some specific cases where the default is different).

1 day by default, but can be configured to be 1-48 hours (keep this default value)

Multi-channel source

Facebook self-attributes installs regardless of other media sources.

AppsFlyer uses last-click attribution (more information about AppsFlyer attribution available here)

Cross-device attribution

Facebook attributes its users that click and install on different devices, for example, iOS/Android/desktop.

AppsFlyer attributes single devices, which perform both the engagement and the install

Different time zones

Facebook Ads default reporting time zone is PST. Make sure to change it in Facebook Ads Manager to match the app time zone defined in the app settings in AppsFlyer.

AppsFlyer's default app time zone is UTC+0. You can change the time zone set for the app in the app settings page to match the time zone defined in Facebook Ads Manager.

Google install referrer

When an install without an advertiser ID was attributed to Facebook Ads using the Google Play install referrer, AppsFlyer doesn't report it back to Facebook Ads. This will cause a discrepancy since it'll display in AppsFlyer and not in Facebook Ads.  

Deeplink re-engagement attribution

A deeplinked re-engagement is not reported back to Facebook Ads. This will cause a discrepancy since it'll display in AppsFlyer and not in Facebook Ads.

Click-through and view-through attribution

AppsFlyer supports both click-through and view-through attribution. To minimize discrepancies between Facebook Ads and AppsFlyer, make sure that both the Click-Through and View-Through Lookback windows are consistent with the default ones defined by Facebook Ads.

Facebook Ads' default click-through lookback window is defined to 7 days. Although there are some specific cases where the default is different, it is recommended to set the click-through lookback window in AppsFlyer to 7 days to cover all Facebook Ads' default options. 

To compare the click-through and view-through attribution windows on Facebook with those on AppsFlyer, visit Facebook. We recommend configuring the attribution windows on AppsFlyer according to Facebook values as they are shown in the following screenshot:



Suppose that the Facebook click lookback window is configured on AppsFlyer to 1 day for your app com.greatapp, while on Facebook it has the default value of 7 days. Users that click on Greatapp's ad on Facebook, but launch the app for the first time after 2-7 days are attributed as organic users on AppsFlyer, while Facebook self-reports these users.

Restricted media discrepancies

Until October 28, 2021, attribution data of users brought by view-through attribution (VTA) was restricted and is not available to advertisers.
Starting October 29, 2021, the restrictions apply to users brought by both view- and click-through attribution. Aggregated reporting was not affected by this.

Since Facebook Ads doesn’t send user-level data, AppsFlyer might not attribute conversion-assisting impressions and clicks to Facebook Ads.


  • A user sees or clicks an ad in Facebook for AwesomeApp. Then, later, they see and click on a GreatAdNetwork ad for AwesomeApp and install it.
  • Facebook Ads claims the conversion since it occurred within their lookback window.
  • AppsFlyer attributes the conversion to GreatAdNetwork as they had the last engagement before install.
  • AppsFlyer won’t consider Facebook Ads as a conversion-assisting network since Facebook Ads raw data is restricted.

However, for click-through attribution, if the ad directs users to Google Play Store, attribution fields are available to advertisers in the Google Install Referrer. The fields provided via the referrer populate AppsFlyer raw data reports available to you and enable AppsFlyer to attribute users who don't have an advertising ID (LAT-enabled).

In-app events differences

The differences between platforms may also be present with post-install events (for example, in-app purchases), that are displayed on Facebook and on AppsFlyer. The following table describes the most common reasons for these differences and advised on how to minimize them:

Cause Description AppsFlyer's Tip


Facebook always attributes events to its own campaigns that drove them, while AppsFlyer attributes these events to the acquisition source.

Installs and events, which Facebook incorrectly self-attributes, are indicated as assists in AppsFlyer.
Combine raw data of Facebook attributed conversions with raw data where Facebook is the contributor.

Different lifetime definition A user's lifetime on Facebook is defined as up to 7 days, meaning Facebook doesn't show events if they occurred over 7 days after the ad click.
In AppsFlyer, a Facebook user's lifetime is defined as up to 180 days.
When assessing the value of users from Facebook campaigns that occurred after 7 days, use AppsFlyer's data to get a broader picture.
Unmapped events AppsFlyer gets SDK originated events, but they are not mapped to Facebook, and therefore aren't sent. Make sure to map with Facebook all the in-app events that signify users' quality.
Unsent Revenue AppsFlyer gets the revenue from the SDK originated events, but they are not sent to Facebook. Make sure the Send Revenue boxes of the in-app events are always checked, for example, the purchase event in the capture below.
Missing event values on Facebook AppsFlyer sends parameters and values to Facebook as part of the events mapping, if they have the correct structures. Build your SDK in-app events according to AppsFlyer's recommended structures to fully map the event values with Facebook.

Installs from re-engagement campaigns in my UA dashboard?

A re-engagement campaign can cause users to open an already installed app(re-engagement). Alternately, when AppsFlyer recognizes a previous install of the app existed on the same device, AppsFlyer may refer to that conversion as a re-attribution.

If, on a re-engagement campaign, Facebook targets new users or users that have installed the app for the first time after more than the set re-attribution window following the original installation, these users are recorded as new user acquisition installs on AppsFlyer, which belong to a re-engagement campaigns on Facebook.

On the other hand, installs that take place within the set re-attribution window following the original installation, are considered as re-attributions and appear on the retargeting page of AppsFlyer, while they may be appearing as new installs by Facebook.


While Facebook shows all installs of a retargeting campaign in the same place, on the AppsFlyer dashboard, installs are divided between the Overview page (new installs) and the Retargeting page (re-attribution and re-engagements).

Cross-device attribution

Facebook reports on cross-device attribution. This could sometimes cause issues where a campaign for one platform (iOS/Android) shows installs on another platform.


Linda clicks on a mobile ad of GreatApp on Facebook using her Android phone. Facebook records the click done by Linda under the original Android targeted campaign "Android Females". Linda decides to install GreatApp on her home iPad. Upon first launch, AppsFlyer asks Facebook for the origin of this iOS install, and Facebook answers with the campaign "Android Females".

Validation rules and Protect360

If you use AppsFlyer's Validation Rules, results may differ between AppsFlyer and Facebook when there are rejected installs that originally come from Facebook. In these cases Facebook self-reports installs to itself, while AppsFlyer rejects the same installs.

Similarly, if you use AppsFlyer's anti-fraud solution, Protect360, there may be installs since Facebook self-reports, while AppsFlyer rejects.


Jeff, the UA manager of GreatApp, creates a campaign called SPNA, which targets only Spanish speakers in North America. To verify this Jeff defines a validation rule, that accepts users from Canada and the US only.
When a Facebook user from Spain clicks and installs, Facebook self-reports the install, while AppsFlyer rejects the install that doesn't pass the validation rule.

SDK related discrepancies

There could be several occasions when advertisers implement both AppsFlyer and Facebook Ads SDKs. This might cause discrepancies both for installs and in-app events:

  • Installs: In cases when Facebook Ads SDK is initialized at the app launch, before the AppsFlyer SDK, the install is recorded only by Facebook Ads and not by AppsFlyer. Verify that the AppsFlyer SDK is initialized at app launch, before the Facebook Ads SDK.
  • In-app events: Facebook Ads does not de-duplicate in-app events which are reported from both SDKs. This means that Facebook Ads may report falsely report revenue and other events.
    Use either of the following methods to avoid duplicate in-app event reporting in Facebook Ads: