How long does it take to start attributing your Facebook mobile app ads with AppsFlyer?
If you already have AppsFlyer's SDK integrated in your app, and already have defined your app on Facebook, the answer is less than a minute!
You don't need to implement Facebook Login or integrate your app with Facebook's SDK for mobile attribution. Just follow the step-by-step setup instructions below.
Facebook App ID
But first, if you still haven't defined your app on Facebook, follow these instructions to create the Facebook app ID:
- Visit Facebook's App Dashboard
- Click Create New App under Apps
- Complete the name for your app, and also a unique namespace
The same Facebook app ID can be used for both your Android and iOS apps.
Basic Facebook attribution setup
To start attributing Facebook campaigns with AppsFlyer, follow these steps:
- When you define your mobile app on Facebook you get its Facebook App ID.
Copy your Facebook App ID and head to your app's dashboard on AppsFlyer.
- Click on Integrated Partners link on the left bar.
- Search for Facebook and click on its logo to open the Facebook setup page.
- On the Integration tab activate the partner, then click inside the Facebook App ID box and paste.
- Configuring install attribution:
- Set the Install click-through lookback window.
Select the lookback window units (hours or days) and set the slider to the desired value. The default lookback window is 28 days, to align with Facebook's default. - To enable view-through attribution, activate Install view-through lookback window.
Select the lookback window units (hours or days) and set the slider to the desired value.
We recommend setting the view-through lookback window to 1 day, to match with Facebook.
- Set the Install click-through lookback window.
- Configuring Reinstall attribution:
This lets you attribute users, who reinstall your app during their re-attribution window.
To enable Reinstall attribution, toggle it on.
You don't need to enable view-through attribution or configure lookback windows for reinstall attribution, as it takes its configuration from the install attribution settings (see step 5).
- Configuring Re-engagement attribution:
See here. - Press Save & Close.
Congratulations! You have completed basic attribution for Facebook mobile campaigns with AppsFlyer!
(Still not seeing Facebook results on AppsFlyer? Click here)
Caution
Ensure that the app collects either IDFA or GAID. Failing to do so results in Facebook installs being attributed as organic. For further information refer to the SDK Integrations Guides for either iOS or Android.
Advanced Facebook attribution setup
With basic attribution already set up for Facebook, it's time for some quick advanced attribution setup.
User-level data
By default Facebook does not release raw user-level data.
On the Integration tab (or here) click to accept Facebook's Terms of Service. This allows AppsFlyer to collect and enable you access to your Facebook users' raw data.
Note
Facebook introduced enhanced data privacy measures to protect the people using their services.
As of April 22nd, 2020, Facebook will no longer provide advertisers with view-through attribution data at the device level. Therefore, view-through conversions and their following in-app events, which are attributed to Facebook:
- Would display under the “restricted” media source
- Would have empty attribution fields in user-level sources such as raw data reports, Push API messages, Pull API reports, etc.
In-app events mapping
Limitations regarding event names:
- Length limitation of event names: 2-40 characters
- The following characters are not allowed:
- Colon (:)
- Period (.)
- Non-Latin (English) character sets: As of January 12, 2020 Facebook rejects Chinese characters. AppsFlyer has not tested other character sets and you should use these only after verifying with Facebook if they support these character sets in postbacks.
- Event names are case-sensitive. To avoid discrepancies, make sure you use
the correct case in the event names for all media sources and app versions.
- Toggle In-App Event Postbacks to ON
Note
When enabling the Facebook in-app events mapping for an app for the first time, all the af_XXX events from the SDK are automatically mapped to Facebook's predefined event list. This automatic mapping saves you time and decreases mapping mistakes significantly.
- The Sending Option for all SDK defined events is Events attributed to any partner or organic, i.e., your entire user base is available to be reported to Facebook.
- Click Add Event to add an SDK Event to the list
- Fill in the following parameters:
| Parameter Name | Description |
|---|---|
| SDK Event Name | The name of the event, as received by AppsFlyer either from the SDK integrated in your app, or from server to server events. Tip - don't see the event you want in the list? Make sure to activate the event on a device with a non-organic installation and recheck. |
| Partner Event Identifier | Select the most suitable predefined Facebook event tag for your event. You can also send Facebook CUSTOM events. |
| Send Revenue | When unchecked - AppsFlyer sends all the parameters of the rich in-app event to the partner, except for the revenue parameter, which is contained in the af_revenue parameter. When checked - AppsFlyer sends all the parameters including the revenue value (if exists in the event). |
For more information about mapping in-app events with Facebook go here.
Retargeting attribution
AppsFlyer's retargeting attribution for Facebook lets advertisers attribute an existing user's engagement with a Facebook ad, and measure the quality of the user, post engagement, using the AppsFlyer reports.
It should be used ONLY if you are actively running campaigns targeted at your own users in Facebook.
- Enable re-targeting in app settings page.
- Turn on Re-engagement attribution in Facebook configuration in AppsFlyer.
- Set the Re-engagement click-through lookback window.
The re-engagement lookback window is the period of time, starting from ad click, during which the app must be launched for the click to be recorded as a re-engagement.
Select a lookback window in hours or days and set the slider to the desired value. - Set the Re-engagement window.
This is the period when the user's in-app events are attributed to the retargeting media source, as primary source.
You can set the value in days (1-90), hours (up to 23), or even lifetime. The default is 30 days.
Cost, clicks and impressions data
Enabling the Facebook Cost feature gets you the cost data for your Facebook campaigns, adsets, ads and channel levels. It also gets you the aggregated clicks and impressions data for them.
- Make sure you are logged into the Facebook user account, which is enabled to handle the account's campaigns on Facebook. The user signing-in must have permissions to run all the campaigns in Facebook Business Manager
- Go to the Cost tab
- Toggle ON the Get Cost, Clicks and Impressions Data button
- Click the Facebook Login button
- When prompted, allow AppsFlyer to access your Facebook campaign data
To delete a connected Facebook account:
- In the actions column, hover over an account, click Delete connection.
Notes
- If you are already logged into Facebook, when you click the Facebook Login button, the Facebook window immediately opens and closes. This is the regular behavior.
- If you have several users with permissions to Facebook, the best practice is to perform the Facebook login for all of them, to avoid getting partial data.
Cost data sync status
The cost tab shows the status of your cost integration and the last time AppsFlyer managed to pull matching cost data.
Facebook allows you to sync several accounts for pulling cost data. For each synced account, AppsFlyer shows the status of cost integration and the last time AppsFlyer managed to pull matching cost data.
The table below lists that status messages, and what to do if you see them in the Cost tab.
| Status Message | Description | What to Do |
|---|---|---|
|
Active |
Partner API is responding and returning data. |
Nothing |
|
Active
With sync message: Cost Data was never successfully pulled |
One of the following is possible:
|
|
|
No Matching Data
|
AppsFlyer queries this app's active campaigns with the Partner API, but the partner API isn't returning any data for these campaigns. |
This might happen if you change the campaign ID while it is still running. If you rely on cost data, do not change the IDs of campaigns while they are still active and running. Also, make sure you enter the API credentials for the correct app, and that the network passes the correct campaign IDs on the attribution link. |
|
Partner API is not responding |
The ad network cost data API is either down or experiencing issues. |
Wait for the network API to become responsive. |
|
Invalid Credentials |
AppsFlyer is unable to pull cost data as the connection is no longer valid. This can happen if your Facebook password changes or if the AppsFlyer permission is revoked. |
Re-login to Facebook in the Cost tab. |
Last successful data pull
The cost tab shows the last time cost data has been pulled yet. If cost data has never been pulled, the sync message shows Cost Data was never successfully pulled.
Examples
Examples
Scenario 1: Stopped campaigns
AppsFlyer pulls cost for several campaigns that you run with ad network A. You look in the cost tab and you see the message Last successful sync 2 hours ago. The same day you stop running campaigns with ad network A. Two weeks later, you look in the cost tab of ad network A. You then see the message Last successful sync 14 days ago.
Scenario 2: Ad network API issues
AppsFlyer pulls cost for several campaigns that you run with ad network B. You look in the cost tab and you see the message Last successful sync 2 hours ago. Ad network B then experiences issues with their API. It takes them a few hours to fix it. When you look in the cost tab you see the message Last successful sync 8 hours ago.
For more information about enriching your Facebook information with cost, clicks and impressions data, click here.
Ad revenue recording
If your app uses Facebook Audience Network Ad Revenue for ad monetization, you can record your revenues from Facebook on AppsFlyer. This, with or without in-app purchase revenue data, gives you a complete picture of your user revenues.
To start recording Facebook Audience Network Ad Revenue:
- On the Ad Revenue tab set Get Ad Revenue Data to ON
- Set the Event Source, which is the event representing your ad revenue model in the best possible way. For example, if your revenue is based on impressions, it is recommended to send AppsFlyer an ad viewed event. The best event can be configured for each monetization platform separately. However, it is also possible to use the
af_app_openedevent. In this case, ad revenue is attributed for every app open performed by the user. - The Ad Revenue Event is displayed. It is a read-only field presenting the new ad revenue event called [source event]_monetized (e.g. Ad_Watched_Monetized as displayed above). The ad revenue event is presented in the dashboard as an additional event.
- Click Facebook Ad Revenue to enable collection of Facebook Audience Network Ad Revenue on Facebook. Login with your Facebook credentials to authorize Facebook Audience Network Ad Revenue.
- Enter the Audience Network App ID. Get this from Facebook Audience Network (FAN).
- Go to the FAN monetization manager dashboard.
- Find the property, then select the Ad Space.
- Below the Placements table, find the Placement ID column on the right.
- Copy the ID to the Audience Network App ID field in AppsFlyer
- Click Save ad revenue.
Facebook in-app events mapping
Advertisers can easily map their in-app events, SDK or S2S, to Facebook's predefined events. Advertisers can also send to Facebook postbacks about every app launch or every known app uninstall.
This enables advertisers to utilize Facebook’s advanced optimization capabilities, as well as build Custom and Lookalike Audience segments.
Predefined events mapping
Facebook offers a wide range of events that are already predefined and can be mapped to.
Find here the list of rich in-app events, that can be sent to Facebook with additional parameters providing extra information about the quality of events.
Below is the list of other predefined Facebook events that don't have additional parameters:
| Facebook event identifier |
Description |
Recommended AppsFlyer SDK name |
|---|---|---|
| Donate |
The donation of funds to your organization or cause. |
af_donate |
| Schedule |
The booking of an appointment to visit one of your locations. |
af_schedule |
| SubmitApplication |
The submission of an application for a product, service or program you offer, such as a credit card, educational program or job. |
af_submit_application |
| FindLocation |
When a person finds one of your locations via web or app, with an intention to visit. For example, searching for a product and finding it at one of your local stores. |
af_find_location |
| Contact |
A telephone or SMS, email, chat or other type of contact between a customer and your business. |
af_contact |
| CustomizeProduct |
The customization of products through a configuration tool or other application your business owns. |
af_customize_product |
Custom in-app events mapping
AppsFlyer allows you to map any custom in-app event to send to Facebook, by using the CUSTOM Facebook Event Identifier option.
The event name and the event value (including the event parameters) configured in the SDK are forwarded to Facebook, as is.
You can see the full custom events names on Facebook Analytics. On Facebook Ads Manager they are aggregated and displayed as "Custom events".
Caution
Events mapped to “CUSTOM” can't be used for the following functions in Facebook:
- App event optimization
- Value-based optimization
- Dynamic Product Ads
To enable using these functions in Facebook, based on your events data, we recommend mapping to Facebook's predefined events.
Automatic parameter mapping with the custom event
Through AppsFlyer's deep integration with Facebook, many of AppsFlyer’s standard SDK event parameters are automatically mapped to Facebook's predefined parameters. For example, the af_revenue parameter is converted to the _valueToSum parameter in Facebook, which allows you to send a revenue per event that can be measured and optimized towards on Facebook.
Note
Automatic parameter mapping can differ between CUSTOM and predefined events.
For predefined events, af_price is mapped to _valueToSum in some cases (for example, fb_mobile_add_to_cart). In other cases, af_revenue is mapped to _valueToSum (for example, in fb_mobile_purchase).
For events mapped to CUSTOM, af_price is always mapped to fb_price, and af_revenue to _valueToSum.
The following table details all the AppsFlyer event parameters, which when mapped through the CUSTOM event to Facebook, are automatically mapped to Facebook's parameters.
| AppsFlyer Parameter | Facebook Parameter |
|---|---|
| af_city | fb_city |
| af_class | fb_travel_class |
| af_content_id | fb_content_id |
| af_content_list | fb_content_id |
| af_content_type | fb_content_type |
| af_country | fb_country |
| af_currency | fb_currency |
| af_date_a | fb_checkin_date |
| af_date_b | fb_checkout_date |
| af_departing_arrival_date | fb_departing_arrival_date |
| af_departing_departure_date | fb_departing_departure_date |
| af_description | fb_description |
| af_destination_a | fb_origin_airport |
| af_destination_b | fb_destination_airport |
| af_destination_list | fb_destination_ids |
| af_hotel_score | fb_hotel_score |
| af_level | fb_level |
| af_max_rating_value | fb_max_rating_value |
| af_num_adults | fb_num_adults |
| af_num_children | fb_num_children |
| af_num_infants | fb_num_infants |
| af_order_id | fb_order_id |
| af_payment_info_available | fb_payment_info_available |
| af_preferred_neighborhoods | fb_preferred_neighborhoods |
| af_preferred_num_stops | fb_preferred_num_stops |
| af_preferred_price_range | fb_preferred_price_range |
| af_preferred_star_ratings | fb_preferred_star_ratings |
| af_price | fb_price |
| af_quantity | fb_num_items |
| af_region | fb_region |
| af_registration_method | fb_registration_method |
| af_returning_arrival_date | fb_returning_arrival_date |
| af_returning_departure_date | fb_returning_departure_date |
| af_revenue | _valueToSum |
| af_search_string | fb_search_string |
| af_success | fb_success |
| af_suggested_destinations | fb_suggested_destinations |
| af_suggested_hotels | fb_suggested_hotels |
| af_travel_end | fb_travel_end |
| af_travel_start | fb_travel_start |
| af_user_score | fb_user_score |
Event and parameter limitations
There are several limitations Facebook imposes on the sent events data:
- An event can have up to 25 parameters.
- Event names and parameter names must be between 2 and 40 characters and must consist of only alphanumeric characters, underscores, hyphens or spaces.
- Non-Latin (English characters should not be used. Using non-Latin letters results in inconsistent results.
- The length of each parameter value can be no more than 100 characters.
- Event names on AppsFlyer can be named the same as Facebook event names (i.e. fb_price), however, these should not be sent as CUSTOM events to Facebook. To keep on the safe side refrain from naming events the same as Facebook event names.
- To perform in-app events postback mapping with Facebook, it requires getting events data from ALL sources, including organic.
Important!
With the exception of the above parameters, AppsFlyer sends the CUSTOM events data as is to Facebook. It is the responsibility of the app owner to verify the events data is on par with Facebook's requirements.
If the event value contains parameters that are not mapped to valid Facebook parameters (see the table above), these parameters are not sent to Facebook.
AppsFlyer SDK vs. Facebook SDK
Your app may already have the Facebook SDK integrated in it, before the AppsFlyer SDK. Even if not, you may wonder whether you really need Facebook SDK in addition to AppsFlyer SDK. And if you do, can the two co-exist without duplicate reporting?
Who needs Facebook's SDK?
Generally, for user acquisition purposes, if you have AppsFlyer's SDK in your app, you don't need Facebook's SDK in it too. AppsFlyer's SDK takes care of all mobile user acquisition attribution purposes of your Facebook users, including engagements, installs, sessions, and post-install events.
However, if your app uses any of the following, it still requires Facebook SDK in addition to AppsFlyer:
- Deep linking data
To perform deep linking from Facebook, you don't need the Facebook SDK. However, if you need the Facebook deep linking data inside the app, you can only get it from the Facebook SDK. - Deferred deep linking and Dynamic Product Ads campaigns
You can perform deferred deep linking from Facebook, by using campaign or ad names from the conversion data, without having the Facebook SDK integrated into your app. However, this method has 2 downsides:- The deep linking data (af_dp) is not present and needs to be inferred from the campaign or ad names.
- For Dynamic Product Ads campaigns, AppsFlyer doesn't get the matching product data from Facebook.
- Other Facebook features
You may need Facebook SDK for reasons unrelated to attribution such as authentication, ad monetization, social sharing, user invites, etc.
Using Facebook SDK for deferred deep linking
To support deferred deep linking from Facebook:
- Prerequisites
* Minimum AppsFlyer SDK versions:
- Android AppsFlyer SDK 4.10.3
- iOS AppsFlyer SDK 4.10.4
* Complete Facebook integration set up.
* Have Facebook SDK integrated into the app (On Android, if developers integrate specific components of Facebook SDK, make sure AppLinks module is added). - To collect Facebook deferred deep linking data automatically from Facebook SDK to AppsFlyer SDK use:
AppsFlyerLib.getInstance().enableFacebookDeferredApplinks(true);AppsFlyerTracker.shared().enableFacebookDeferredApplinks(with: AppLinkUtility.self)[[AppsFlyerTracker sharedTracker] enableFacebookDeferredApplinksWithClass:FBSDKAppLinkUtility.class]; - Get af_dp in onConversionDataSuccess callback.
- Redirect user programmatically using the af_dp value.
Avoiding duplicates with Facebook SDK
Facebook requires AppsFlyer to report about installs and in-app events from ALL users, including organic users. If you have both SDKs in your app, install and in-app events are reported to Facebook SDK, and then via postbacks to Facebook servers through AppsFlyer. How can you avoid this duplicate reporting?
- Installs
Facebook de-duplicates app installs. If both Facebook SDK and AppsFlyer report on a new user installing a mobile app, Facebook knows to count this install only once. - In-app events
Facebook does not de-duplicate in-app events, which are reported from both its SDK methods as well as from another source, i.e. AppsFlyer. This means that, unless taken care of, Facebook may report double revenue and other events, falsely.
Use either of these possible methods to avoid duplicate in-app event reporting in Facebook:
- Don't configure events in the Facebook SDK
- Disable the Facebook in-app events mapping from AppsFlyer
Facebook channels
With Facebook you can see data broken down not only by campaigns, ad sets and ads, but also by Facebook channels (called Placements on Facebook).
- Facebook channel - users from the Facebook app
- Instagram - users from the Instagram app
- Messenger - users from the Facebook Messenger app
- AudienceNetwork - users from other apps that belong to or are affiliated with Facebook
Use this data to compare the quality of users that you get from the different channels of Facebook.
Facebook and agencies
Agencies and FMPs can run and attribute Facebook campaigns on behalf of advertisers on AppsFlyer, or even alongside the advertisers' own Facebook campaigns. In order for the agency campaigns to be attributed to the agency, the campaign name MUST begin with the agency's name.
For more details about agencies and Facebook install attribution please go here.
In addition, agencies can't alter Facebook lookback windows and retargeting control. Rather, they need to ask the advertiser to perform these changes if they're needed.
Besides, agencies cannot modify any in-app event postbacks sent to Facebook. The reason for that is Facebook's requirement to receive information about all installs, including those that are not attributed to it (and therefore may not be brought by the agency).
The image below shows all settings that need to be configured by the advertiser for the agency to be able to manage its Facebook campaigns:
Attribution for Facebook for out-of-store Android apps
Facebook doesn't allow creating mobile apps install campaigns for Android apps that are in out-of-store markets, e.g. Baidu.
However, you can advertise and record installs for out-of-store apps on Facebook following these instructions:
- The developer has to prepare a separate APK for each out-of-store market you use to advertise your app on. More details here.
- Create a Traffic or Conversions campaign on Facebook, with mobile attribution enabled, which sends leads to a landing page.
- The landing page should include a Download App button, which directly links to the out-of-store market where the APK exists.
- The lead clicks on the button and is redirected to the out-of-store market. After completing the installation AppsFlyer attributes the user to Facebook, via its MMP API.
Note
The same solution applies to apps in Google Play and the App store, which require a landing page prior to the redirection to the market.
For specific instructions on attribution for apps in Amazon on Facebook click here.
Facebook spend
AppsFlyer gets spend (including clicks and impressions) data from Facebook campaigns, if one or more installs occurred during the previous 7 days.
If a Facebook campaign engages with multiple platforms (Android, iOS, desktop, etc) the cost in the Dashboard is platform-specific and is calculated by Facebook.
Getting Facebook cost including clicks and impressions.
Facebook cost FAQs
I can't see old Facebook cost data in the AppsFlyer dashboard
Upon performing the first Facebook admin login described above AppsFlyer receives Facebook's cost data up to 7 days retroactively for existing campaigns. Cost data from beforehand isn't available.
This cost, clicks and impressions data is collected for all campaigns, which had at least 1 conversion during the last 7 days prior to the initial admin login.
Cost data was fine for a few months, but it stopped displaying
Facebook may reset this permission to get the cost data every few months. If you notice the cost data stopped appearing on the dashboard please repeat the Facebook admin login steps again.
If the Facebook admin user changes their Facebook password the login steps must be repeated as well.
I clicked on my Facebook ad 5 minutes ago. Why don't I see the click in AppsFlyer?
AppsFlyer gets aggregated clicks, impressions and cost data from Facebook periodically every few hours. Therefore, it may take a few hours before these actions are displayed on AppsFlyer's dashboard.
Are there raw clicks data from Facebook?
As AppsFlyer gets only aggregated click and impression data from Facebook, the entire set of raw clicks and impressions are not available. The only raw clicks and impressions available in raw reports are those that resulted in installs.
Are there limitations of Facebook cost data by geo?
If you filter by Geo on AppsFlyer's dashboard, you can see the summary and breakdown of the Facebook cost data.
This data is available only for "Mobile App Install Campaigns" on Facebook.
In addition, the cost by Geo data is only available for single platform campaigns. This means campaigns that have an Android targeted ad set, and an iOS targeted ad set, cannot have Geo specific cost data. To get the full cost data, dedicate a campaign to each platform.
What are the limitations of Facebook cost data in Master API?
Facebook doesn’t support grouping of cost data by Geo and Channel simultaneously in Master API reports.
To create a report with complete cost data, group it by only one of these dimensions.
The total cost doesn't match
There are differences between Facebook and AppsFlyer attribution models. These differences may lead to discrepancies with Facebook cost data:
- Facebook cross-device attribution: this might sometimes cause issues where a campaign for one platform (iOS/Android) shows an install with its cost for another platform.
- Facebook non-mobile campaigns: in these campaigns, like Facebook's link click campaigns, desktop users may eventually install mobile apps. For these cross-device campaigns, AppsFlyer does not show cost. However, if the link click was performed by the same device that installed the app, cost data is received.
For example, a Facebook user clicks on an ad leading to the advertiser's landing page on a desktop computer. A week later the same Facebook user installs the advertiser's iOS app on an iPhone device. While the install is attributed and displayed on AppsFlyer's dashboard, the cost of this cross-platform install is not. - Campaigns with 0 results in the last 7 days - AppsFlyer syncs the cost only for campaigns that had installs/conversions in the past 7 days. If Facebook cost was just set, campaigns which were inactive for more than 7 days beforehand will not show cost.
Although the total cost is identical, the eCPI AppsFlyer calculates is different from the cost calculated by Facebook. why?
The Cost Per Install is calculated by dividing the total cost with the number of installs. Since AppsFlyer counts installs differently from Facebook the eCPI will usually differ between the two.
Why is there cost data for only some of the campaigns?
Even if there are several Facebook users with permissions to run campaigns in the Facebook Business Manager, only one of them is required to perform the Facebook login described above.
However, if this user does not have access in Facebook to some of the running campaigns, the result is campaigns that are displayed on AppsFlyer's dashboard, but lack the cost, clicks and impression data.
Is Facebook cost data displayed for retargeting campaigns?
Facebook cost data is only displayed in the Overview dashboard for user acquisition campaigns, and not for retargeting campaigns in the Retargeting dashboard.
Why does the Facebook cost configuration window close before login
If you are signed in to Facebook on the same browser that you are performing the configuration, the window automatically connects to Facebook using those credentials and if access has already been granted to AppsFlyer's app, then there is nothing to do and the window closes.
What's the problem with Facebook cost for apps in the Amazon app store?
In contrast with AppsFlyer's data, Facebook doesn't tell apart cost data of Android apps and Amazon apps (which are Android based).
Therefore, the cost data of Amazon users may be attributed to campaigns targeting other Android users instead of the original Amazon campaigns.
Can I halt the Facebook cost sync?
What should you do if you want to switch the Facebook ad account, but have already linked the Facebook cost via AppsFlyer with your old ad account?
The solution is to disconnect the ad account via Facebook. No action should be taken on AppsFlyer.
- On Facebook navigate to Settings >> Business Integration.
- On the Active tab, remove the AppsFlyer integration.
- Navigate to AppsFlyer dashboard and connect the cost with the new ad account.
Facebook cost examples
An advertiser runs campaigns using Facebook Ads. In AppsFlyer the advertiser sees the following:
The cost information is provided by Facebook to AppsFlyer. The number of installs is calculated by AppsFlyer using AppsFlyer attribution rules. As a result, the eCPI calculated by Facebook and AppsFlyer usually differs.
Facebook 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's dashboards.
While we work closely with Facebook to minimize these discrepancies, advertisers should be aware of the following causes for them.
Differences in attribution models
| Cause | AppsFlyer | |
|---|---|---|
|
Click attribution lookback window |
1-30 days. Make sure to set to 28 days with Facebook. |
|
|
View-through attribution lookback window |
1 day |
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 |
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, e.g. 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 the Facebook and AppsFlyer platforms, ensure both the Click-Through and View-Through Lookback windows are the same.
To compare the click-through and view-through attribution windows on Facebook with those on AppsFlyer, visit Facebook. We recommend to configure the attribution windows on AppsFlyer according to Facebook's values as they are shown in the following screenshot:
Example
Suppose that Facebook's click lookback window is configured on AppsFlyer to 7 days for your app com.greatapp, while on Facebook it has the default value of 28 days. Users that click on greatapp's ad on Facebook, but launch the app for the first time after 8-28 days are attributed as organic users on AppsFlyer, while Facebook self-reports these users.
In-app events differences
The differences between platforms may also be present with post-install events (e.g. 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. |
| Different life time definition | The users life time on Facebook is up to 28 days, meaning FB doesn't show events if they take place more than 28 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 1 month 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, e.g. 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.
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.
Facebook integration troubleshooting
If you have completed the basic integration and still not seeing results from Facebook on AppsFlyer's dashboard, first verify that you have new installs from Facebook since the integration.
If so, please consult the main reasons below for solving this issue:
No IDFA collection
As stated in the SDK Integration Guide - iOS, you must add the AdSupport.framework to your project for IDFA collection to take place. Although in most cases attribution still works with finger-printing, IDFA collection is mandatory for working with Facebook. Check the Installation Raw Data report to see if the IDFA column is indeed empty or not.
Android installs work on Facebook even without GAID collection, but it is highly recommended to have it implemented too.
Wrong Facebook App ID
On the Facebook dashboard verify the app ID is correct and matches the value in the app store.
Note - in the past there was a URL for app ID validation, but it has been deprecated by Facebook.
App status on Facebook
The app must be defined on Facebook as Live rather than In development for attribution to work.
Wrong type of Facebook campaign
Facebook app install
Correct set-up - attribution works.
Incorrect set-up - attribution fails.
Facebook FAQs
I don't see Facebook campaign clicks in AppsFlyer's dashboard
By default Facebook sends only the conversion and engagement data. However, you can easily also start getting clicks, impressions and cost data for your Facebook campaigns.
Can I stop cost data sync?
To stop cost data sync with Facebook, remove AppsFlyer from your Business Integration in your Facebook account.
Can AppsFlyer show the campaign level and ad groups?
Is Facebook data shown in real-time?
When can I see a new campaign's data on AppsFlyer?
To see data from new ads, ad sets and campaigns on Facebook they must generate at least one install.
For example, a new ad has generated 100 clicks with no installs, and is not shown on AppsFlyer's dashboard and data. Another ad only has 1 click and 1 install, but is displayed on AppsFlyer.
How can I get more installs from Facebook?
How? Read here.
Do you make Facebook raw data available to agencies?
I don't see Facebook raw data in the installation and in-app events reports
By default, Facebook does not allow distribution of user-level data. Advertisers who want to get this raw data via AppsFlyer can sign Facebook’s Data Usage Terms for Advanced Mobile App Measurement.
Once an advertiser agrees to Facebook’s Data Usage Terms, the data doesn't appear immediately. After the advertiser agrees to Facebook's Data Usage Terms, at least one install from Facebook must take place for the data to appear on AppsFlyer. Anybody with access to the Facebook ad account can do the following:
- Go to Facebook's setup window on AppsFlyer
- Click on Terms of service
- Continue on Facebook and agree to the terms of service
OR go directly to Facebook here.
Once agreed, and at least once install takes place after accepting Facebook's Facebook's Data Usage Terms, historical Facebook raw data appears in AppsFlyer.
Are there specific columns for Facebook in AppsFlyer's performance reports?
Yes. The performance reports have static column structures in any combination of selected media source, which present information down to the campaign level.
However, when you download performance reports ONLY for Facebook Ads, AppsFlyer adds 4 columns to them, which present information down to the single ad level! The added columns are Adset Name, Adset ID, Adgroup (i.e. single ad) Name and Adgroup ID.
Can I work with Facebook FMPs and measure performance with AppsFlyer?
For details about setting up attribution with FMPs, click here.
What should I do when I receive the following warning?
- Verify the App ID in Facebook and check if you have any geo or age restrictions on their Facebook App ID.
- If attribution is already working, this indicates that app is already publicly available in the Facebook Developer Portal and you can you can safely ignore this error message.
What happens with different lookback windows than on Facebook?
Configuring these windows to be shorter on AppsFlyer, decreases Facebook attribution on AppsFlyer. On the other hand, configuring them longer on AppsFlyer has no effect, as installs taking part after Facebook's windows end, do not get attributed to Facebook.
Therefore, to minimize discrepancies, the recommendation is to configure Facebook's lookback windows in AppsFlyer to 28 day clicks and 1 day views.
What are the Facebook API parameters?
| Conversion data | AppsFlyer raw data | |
|---|---|---|
| campaign | campaign | campaign_group_name |
| campaign_id | Campaign ID | campaign_group_id |
| adgroup | Ad | adgroup_name |
| adgroup_id | Ad ID | adgroup_id |
| adset | Adset | campaign_name |
| adset_id | Adset ID | campaign_id |
| ad_id | AD ID | ad_id |
| agency | Partner | N/A |
| is_fb | Media Source | is_fb |
| af_channel | Channel | publisher_platform |
How long do you keep Facebook’s user-level data?
Past aggregate data remains the same.
This is relevant for all Facebook channels (Facebook app, Instagram, Messenger, and AudienceNetwork).