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)

Install record date

Facebook records new installs on the Click/View Time.

AppsFlyer records new installs on installation time (the very first launch of the app)

Multi-channel source
attribution

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.

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:

Facebook_Discrepancies.png

 Example

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.

 Example

  • 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

Installations discrepancies

Events that are performed by users that are attributed on one platform, but not on the other, are also under discrepancy by default.

Minimize the installation discrepancies according to this article to lower in-app events discrepancies as well.

Self-attribution

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

In 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 life time definition The users life time on Facebook is up to 7 days, meaning FB doesn't show events if they take place more than 7 days after the ad click.
Facebook users life time on AppsFlyer is up to 180 days.
When assessing the value of users from Facebook campaigns from more than 7 days ago. Use AppsFlyer's data to get the 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 (see capture below).
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.

fb-ads-in-app-events-postback_en-us.png

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.

 Note

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.

 Example

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.

 Example

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:

 

 

Was this article helpful?