AppsFlyer FAQs

At a glance. This article is for ad-networks who use the Tune (was Hasoffers) platform to integrate with AppsFlyer NativeTrack solution.AppsFlyer sends attribution data to Tune for both install and in-app events.

To initiate the integration send AppsFlyer:

Your attribution link

Your postback (for installs and in-app events)

Creating the attribution link

The attribution link consists of the following AppsFlyer base attribution link and additional macros added by the ad-network.

See the following AppsFlyers base attribution link with a detailed explanation per macro:

AppsFlyer Base URL

Description

http://app.appsflyer.com

AppsFlyer endpoint

app_id

Application unique ID dynamic value changed per app promoted

pid=

Media source name concatenated with _int to identify integrated networks

c=

Campaign name

See below what the complete attribution link should look like after you have added additional Tune macros:

Note

In the link below af_sub5={offer_id} is added for reporting purposes within Tune.

http://app.appsflyer.com/com.appsflyer?pid=mediaName_int&clickid=

{transaction_id}&af_siteid={affiliate_id}&af_c_id={offer_id}&af_ad_id={offer_file_id}&idfa=

{ios_ifa}&advertiser_id={google_aid}&af_sub5={offer_id}

For the Tune list of macros click here.

Creating your install and in-app event postbacks

See below a step by step explanation on how to create your install and in-app event postbacks in the Tune platform:

Create or select an offer that uses the Postback w/Transaction ID protocol

In the details section of the offer page, click the link that is labeled "tracking"

Copy the postback URL that appears in the box labeled postback URL

Remove the offer_id parameter and value from the postback url to change the postback from a specific postback into a global postback

For more information, click here.

Global Install Postback:

http://NETWORK_ID.go2cloud.org/aff_lsr?offer_id={af_c_id}&transaction_id={clickid}

NETWORK_ID is the network ID (domain) name provided by Tune

Global In-App Event Postback:

http://NETWORK_ID.go2cloud.org/aff_goal?a=lsr&goal_id={goal_id}&transaction_id={clickid}

NETWORK_ID is the network ID (domain) name provided by Tune.

goal_id= Set as Event Tag in the AppsFlyer dashboard for each app by the advertiser - this is the actual in-app event name from the application.

For details of Dynamic Event Mapping for In-App Events, click here.

Finalizing your registration

If you currently have an integration with AppsFlyer contact us at [email protected]

If you do not currently have an integration with AppsFlyer, complete the ad Partners Registration application here.

Introduction

AppsFlyer supports impression recording and view-through attribution for a large number of different ad networks.

Impressions Recording

Mobile users viewing ads for a minimum amount of time, regardless of any following clicks or installs

View-Through Attribution

Ad impressions that result in app installs, without the users clicking on the ads

Ad networks may send ad impressions recording data either in aggregated format, or via an AppsFlyer's API, similar to clicks API, which enables user-level data.

Only impressions that are reported with user-level data, may be attributed as view-through installs. Also, only when these impressions become installs, they may be recorded on the raw data reports.

Viewing the impressions data

The impressions data is presented in the dashboard's overview page. It is also available in the various performance reports in the Export Data page.

Impressions widget

The impressions displayed are the total number of impressions occurring and reported via all the selected media sources during the selected time period.

Impressions in the aggregated performance report

The table shows the impressions count per each media source, campaign, country etc. for the selected date range. For networks not supporting impressions recording (e.g. Google AdWords), the "N/A" value is displayed in this column.

Impressions vs. clicks

Are all clicks also counted as impressions (where impressions data is available)?

Generally, the answer is yes. After all, for any user to click on an ad, the user must see it first.

However, in some cases there may be a click without a preceding impression. Ad networks define impressions by a minimum exposure time to ads, e.g., Facebook sends an impression when users watch an ad for at least one second. In cases where a user is exposed to an ad for less than the minimum time for impression recording, but clicks the ad very quickly, there is a newly counted click but not a new impression.

Building impression links

When a user performs an ad impression the ad network can fill in the user specifics in a URL and send it to AppsFlyer in real time. This attributes an impression to the network in real-time, and also an install, if it follows.

The URL can contain any valid parameter from AppsFlyer's attribution links, but it has some specific requirements:

The base URL is http://impression.appsflyer.com. Both HTTP and HTTPS protocols are supported

Use a GET request

Device ID, either IDFA ("idfa=") or GAID ("advertising_id="), on the impression link is mandatory

If GAID isn't available for some reason include Android ID ("android_id=") on the link. If that isn't available use IMEI ("imei=)

The Device ID values can be hashed for better security using SHA1. The parameter name should begin with "sha1_" and be followed by the parameter name and the hashed value, i.e. sha1_idfa, sha1_advertising_id, sha1_android_id and sha1_imei

Example

http://impression.appsflyer.com/{app-id}?c={campaign name}&pid={media source}

&af_viewthrough_lookback=1d&af_prt={agency_name}&af_siteid={site id value}

&af_sub1={free value}&idfa={idfa value}

It is very important to send the impression data as early as possible to AppsFlyer so that the data can be attributed correctly.

Ad networks that want to support view-through should contact their dedicated Partner Development Manager or contact [email protected].

Custom impression links

Advertisers can also utilize attribution impression links, with their own custom media, e.g. website banners.

When advertisers create custom attribution links, they get full impression links, which can be fired every time their users engage with their owned ads. By doing so, advertisers can measure the impressions to clicks conversion rates of their owned media, and find the most engaging spots to use.

View-through attribution overview

View-through attribution allows you to measure installs coming from ad impressions, where the user has not clicked on the ad. Therefore, all view-through installs are also first counted as impressions.

When a new install occurs, if there is no relevant click, AppsFlyer looks for a possible matching impression. If a match is found then view-through attribution takes place.

However, if both clicks and impressions exist within the attribution lookback window, the last click always prevails and gets the attribution. The impressions preceding the last click, are then recorded as assisting the attribution.

View-Through attribution supports Device ID Matching only (no fingerprinting or referrer matching ).

Viewing the view-through data

The count of view-through installs is presented in the dashboard's overview page, as part of the Aggregated Performance Report table.

The view-through installs count should always be lower than the number of impressions, as it is a contained group within the impressions group.

However, there may be sources with view-through installs although the impressions data is not available (N/A). This only happens for SRNs, that don't have impression data collection enabled or supported, that do reply with the correct attribution touch type, click or view.

Raw data view-through installs

In the raw data installs and in-app events reports, when under the attributed_touch_type column you see the impression value, it is a view-through attributed install.

View-through attribution lookback window

You can set the view-through lookback window per each ad network, that supports view-through attribution, on its partner configuration page.

The view-through lookback window is the maximum amount of time, that can pass from an ad impression and until the first app launch, in which the user gets attributed to the ad serving network.

The recommended and the default view-through attribution lookback window is 24 hours. The possible view-through lookback windows are 1 to 48 hours (1h 48h) or 1 to 7 days (1d 7d).

For Ad Networks using impression attribution links:

A specific parameter appears on the attribution link af_viewthrough_lookback

If the af_viewthrough_lookback parameter does not appear in the attribution link, the default lookback window is 24h.

Enabling view-through attribution

View-through attribution is enabled by default. If AppsFlyer receives a valid impression attribution link (with IDFA/GAID), this impression participates in the attribution flow unless the view-through attribution is disabled in the partner setup page.

Note

Since view-through attribution is enabled by default, it is important that advertisers contractually agree with the network in advance whether or not they view-through attribution should be enabled.

Disabling view-through attribution

It's possible to disable view-through attribution per media source. If impressions are received and the view-through attribution is disabled, the user can still see the impressions in the dashboard, but the attribution process ignores these impressions.

To disable view-through attribution:

Open the relevant media source configuration

Deselect the view-through attribution check-box

Click Save & Close

Warning

With SRNs, disabling view-through attribution on AppsFlyer doesn't do the same on the networks side. Keep the view-through setup on AppsFlyer and the networks aligned to avoid discrepancies.

The following media sources support impression data and view-through attribution:

Company Name

Logo

12 Digit Marketing

360 Int

Aarki

Accordant Media (and Accordant Media 2)

Ad4Screen

Ad4Screen Partner

Adara

AdColony

Addict Mobile

Adello Group

Adelphic Mobile

Adform

Adikteev

Adition Technologies

Adobe Ad Cloud

Adpacker

AdSpecter

AdTheorent

Adtiming

Adxcel

AffectV

Affle

Aja

Amazon

AmoAd

amobee

AOL

Appgrowth

Applifier (Unity Ads)

AppLovin

Appnext

AppNexus

AppOnboard

Appreciate

Appromoters

Appsflowerprime

Aura Ironsource

Avow

Baidu Native Ads

Beeswax

Beintoo

Bidease

BidMotion

Bigabid

Bignox

BlackDragon

BoldScreen Media

Bright Storm

Bucksense

Bytemod

CA Reward

Caping

Captify Technologies

Cashslide

Chartboost

Cheetah Mobile

ClearPier

Connected Interactive

Conversant Media

Cross Networks

Crosschannel

Crossinstall

Curatemobileltd

CyberAgent (Dynalyst)

CyberAgent Inc

Datalift

Datamind

Dataxu

Deepintent

Deeprithm

Digilant

Display.io

DoFunApps

DoubleClick

Downstream

Drawbridge

Dstillery

Duapps

EPOM

ESPN

Everyads

Eyeview

Facebook

FastG8

Fiksu

Five

FlashTalking

Fractionalmedia

Freakout

Fyber

Gameberry

GetIntent

Glispa

Globalwide Media

Glossom

Google

Groundhog

Gruuv Interactive

Headway Digital

heyzap

HockeyCurve

Hotstar

Hubscale

HyperGrowth HQ

i-mobile

igaworkstradingworks

Iconpeak

Imgur

inmobile

Inflecto

Inmobi

ironSource

Jampp

Jana Mobile

Janesi

Jump Ramp Games

King

Klixer

Leadbolt

Lifestreet Media

Liftoff

LoopMe

Maio

Manage.com

Marin Software

Match Media Group

MB YNOT Media

MDSP Inc

MediaMath

Mediasmart

Meitu Monetization

Mezzomedia

Mintegral

Mobco

Mobilitr

Mobisummer

Moblin

MobPartner

Mobpressions

Mobvista

Mobway

Mobwonder

Mobyoung

Moloco Ads

MotionLead

Motive Interactive

Mozoo

NativeX

Neicon

Nend

Verizon Media (Oath: Ad Platforms / Yahoo Gemini)

OnetwoAD

Optimize

Pandora

Pepperjam

Persona.ly

Phunware

Picnic

Pinsight

Postr Media

Qihoo of Beijing

Radiumone

Reddit

RevMob

RevX

Rocket10

Rocketfuel

Sigmob Technology

Simplaex

Sirok (Dot Games)

Sitescout

Sizmek

Skillup Video

Smadex

Smart.bid

SMX E Ventures

Snapchat

Solosystem

Soundcloud

Sourceknowledge

SpotAd

StartApp

StartApp CPA

svgmedia

Tabmo

Taiwan Mobile

Tapjoy

Tappx

Tapsense

Taptica

the Trade Desk

Tokyo FM Broadcasting Co.

Twitter

Tyroo

UC Huichuan

United

Unity Ads

Unlockd

Unruly

Upday for Samsung

Upravel

Ve Global

VidoPlus

VivaVideo

Vungle

Weatherbug

Widespace

Winclap

Woobi

Xiaomi

YelloHammer

YieldMo

YouAppi

Zplay

Zplay Cross Promote

Zucks Ad Network

Bytedance Ads - China Traffic, an AppsFlyer integrated partner, is an Internet technology company operating several machine learning-enabled content platforms.

Note

If you want to promote your Android Apps with Bytedance Ads - China Traffic, you are required to send your IMEI to AppsFlyer SDK according to the instructions in the AppsFlyer SDK Integration - Android. Google Play service is blocked in China, IMEI is the most popular Android Device ID for ad attribution.

In addition to click-based mobile attribution, Bytedance Ads - China Traffic also offers view-through attribution, which you can record with AppsFlyer.

To configure your campaigns with Bytedance Ads - China Traffic, follow the steps below.

Setting up Bytedance Ads - China traffic

Go to the dashboard of your app and click on Integrated Partners on the left bar.

ad network permissions

Enter "Bytedance" in the search field and click on the logo next to Bytedance Ads - China Trafficto open Bytedance's configuration window.

Tip

The General Settings step in the Integration tab is mandatory for all partners

All the rest of the steps are either descriptive or optional

Integration tab

The Integration Tab is divided into different sections as described below.

Activate partners

On the first visit here, you will need to toggle ON the Activate Partner button to enable setup of the integration tab's parameters. The toggle MUST be ON for as long as you work with the partner. For more details about partner activation please click here.

General Settings

Enable View-Through attribution

Toggle this to ON if you want to attribute view-through installs from Bytedance. The view-through lookback slider is available on the attribution link tab (described below).

Default postbacks

AppsFlyer can send automatic postbacks to Bytedance following user installs and re-engagements. Use this section to define the source of the users that allow sending these postbacks.

In-app events settings

In this section you can map your AppsFlyer events with Bytedance via postbacks.

Toggle In-App Event Postbacks to ON

Select the Sending Option for all SDK defined events. - Only events attributed to this partner for events coming only from users attributed to this partner - Events attributed to any partner or organic to have your entire user base available to be reported to the partner

Click Add Event to add an SDK Event to the list

Complete 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. Bytedance accepts only 3 types of events:

registration

purchase

first day retention:a user opens theapp the day after the install date (this event can happen only once)

Tip - If you 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

The unique name or ID of each event as defined on Bytedance's side. Use the following values:

Bytedance event identifier

Event type

0

Install (First launch)

1

Register

2

Purchase

3

Form

4

Consultation

5

Successful consultation

6

Day 1 retention

19

Successful user acquisition

20

In-app order

21

In-app visit

22

In-app add to cart

23

In-app purchase

25

Key action

29

In-app detail page unique view

35

Submit form

If you are not sure which event type you should use, get in touch with your assigned point of contact at Bytedance.

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 it exists in the event).

Attribution link tab

In this tab, you can create the attribution links you want to send to Bytedance for attributing Bytedance's campaigns, ad sets or even single ads. Note that AppsFlyer DOES NOT save your generated partner's attribution links.

This tab is divided into different sections:

Attribution link parameters

In this section, select which parameters you want to add to the attribution link.

Adding parameters to the attribution link here enables you to later perform thorough drill-down analyses. Parameters that are already defined on the attribution link can be edited by adding them and their new values here.

Campaign - add it to compare different campaigns running with Bytedance. Attribution link parameter: c

Adset - set ad set names to compare different ad sets within specific Bytedance campaigns. Attribution link parameter: af_adset

Ad Name - set ad set names to compare different creatives within specific ad sets within specific campaigns Bytedance. Attribution link parameter: af_ad

Site ID and Sub Site ID - set Site ID parameter to attribute installs to specific publishers. If many publishers exist, we advise on limiting the number of used site IDs and using the sub site ID parameter, to avoid exceeding the site ID limitations. Attribution link parameters: af_siteid and af_sub_siteid

Subscriber Parameters - use any of the 5 subscriber parameters to insert useful values. Note that these parameters get parsed and appear in the raw data report, which makes them very handy for performing data aggregation or filtering. Attribution link parameters: af_sub1, af_sub2, af_sub3, af_sub4, af_sub5

Add any other parameter to the attribution link simply by typing it in a new parameter box. For more information about AppsFlyer's Attribution Link Structure and Parameters.

Click-through attribution

This slider allows you to set the maximum time from click to install. Only installs (first launches) that take place within the lookback window may be attributed to Bytedance.

Attribution link parameter: af_click_lookback

More details about the click lookback window here.

Click attribution link

This is the attribution link that contains all the setup information you have set for it. Send it to Bytedance to be activated when leads click on a corresponding ad.

Once you have generated the attribution link, complete the campaign setup process on Bytedance's site.

1. Create Conversion Rule in Bytedance Ads

Login to Bytedance Ads ( https://ad.toutiao.com/ ) <> Tool Box > Click Conversion

Click to create a new conversion.

Select the Conversion Source: App Install

To define the conversion name, go to App Download Link (iTunes page/ Android App download page) >> Enter AppsFlyer Attribution Link.

Click Submit.

2. Process the Install Test

Click Start Test

Enter userid.

Click Next Step.

If you receive the below notification, change a test device and repeat last step.

When you see the page shown below, go to Open App >> Find the testing ad in the news feed >> Click the Ad >> Download and open the App

When you finish the steps above, you are directed to the next page automatically.

Wait for the progress bar to be 100% completed and click Next Step.

You have now created the successful conversion.

Click Confirm to complete the test.

3. Create an Ad Campaign with the Newly Created Conversion

Go to New Ad >> Set Budget and Bid select the conversion you created for this app.

4. Send In-App events to Bytedance

Enter Bytedance (Toutiao) Configuration >> In-App Events tab, select register and(or) purchase event to postback, and save your setting.

Register-------- populate 1

Purchase--------populate 2

On the Bytedance Ads dashboard, you can choose register or purchase event as the conversion type:

View-through attribution lookback window

This slider allows you to set the maximum time from impression to install. Only installs (first launches) that take place within this lookback window, following an ad impression, are attributed to Bytedance, providing there was no other relevant ad click.

You can customize this value to 1-23 hours or 1-7 days.

Attribution link parameter: af_viewthrough_lookback

More details about the view-through attribution here.

Impressions attribution link

The impression attribution link contains similar attribution data to the click recording link (besides the different lookback window). Send it to Bytedance to be activated when a corresponding ad is watched, usually for 1 second or more.

Cost tab

Data Enrichment is not supported for this partner.

Ad revenue tab

Ad Revenue data is not supported by this partner.

Permissions tab

In this tab, you can select the permissions to grant Bytedance, whether the partner acts as an ad network, agency or even both. Note that even if attribution is disabled for Bytedance, the permissions tab is active and you can grant control to Bytedance.

Use these toggles to give the ad network permissions to handle its own configuration for your app:

Ad network permissions

Allow to configure integration - permit the partner to setup the integration tab (except in-app event postbacks)

Allow to configure in-app event postbacks - permit the partner to setup in-app event postbacks mapping to itself on the integration tab

Allow access to your retention report - only to the partner's own retention data

Allow access to your aggregate loyal user data- only to the partner's own loyal user data

Allow access to your aggregate in-app events data-only to the partner's own in-app events data

Allow access to your aggregate revenue data - only to the revenue data attributed to the partner

Allow access to your Protect360 dashboard - only to the partner's own Protect360 data, and providing the feature is enabled for the advertiser

Learn more about granting .

Introduction

OneLink, a unique AppsFlyer attribution link, that enables advertisers to utilize three primary features with a single click:

Device Detection and Redirection: OneLink detects the device type (Android, iOS, desktop, etc.) when clicked and redirect the user to a matching destination.

Deep Linking: Where the advertised mobile app is already installed, OneLink supports app launch after the click and/or serves the user with personalized content such as sending the user to a specific activity/page in the app).

Deferred Deep Linking: Where the advertised mobile app is not installed, OneLink can serve the user with personalized content such as sending the user to a specific activity/page in the app, on first launch of the app after install.

Advertisers usually deploy OneLink with their owned media, such as email and SMS campaigns, website banners and landing pages, viral posts on social media, and QR codes on physical posters. OneLink can also be used with integrated partners.

This guide covers OneLink basic setup, which enables device detection and redirection.

Once this basic setup is complete you can continue to the step-by-step Deep Linking Guide.

Example

AwesomeCom has released a new app for Android and iOS. Jill, the mobile marketer, decides to launch an SMS campaign using AwesomeCom's users mobile phone numbers database. The short message contains a call to action and a single OneLink URL. All Android users clicking the link are redirected to the app's page on Google Play. All iOS users clicking the same link are redirected to the app's page on iTunes. The campaign manages to convert 23.5% of AwesomeCom's registered users to mobile users using OneLink!

Device detection and redirection flow

When you are using an engaged device and click on OneLink the following steps occur:

You are redirected to AppsFlyer's servers

There, your click URL and its parameters are saved for later, for attribution and deep linking purposes, should you choose to install the app

Immediately afterwards, based on the user agent of the device, the device type is detected

You are then redirected to the designated destination according to OneLink's template (see below), which fits your device type

There are two stages required for OneLink's set up to achieve these steps:

Configuring OneLink template

Creating custom links from OneLink's template

Note

OneLink also supports the following platforms:

Android - Android based Smart TVs

Apple - Apple TV (tvOS)

Amazon Fire TV - for Amazon Fire TV use the Custom Android APK URL option

Windows - All Universal Windows Platforms including Xbox

OneLink template configuration

The OneLink template is where all the different destinations per device types are defined.

Once the basic OneLink setup is complete, you can create many custom links with different parameters, that lead to the same destinations stated in the OneLink template (except if overridden ).

You cannot delete a OneLink template. If you want to delete a OneLink template, contact your customer success manager or email us to [email protected].

Each mobile app under an AppsFlyer account can be defined in multiple OneLink templates. For details on assigning an app to more than one OneLink template go here.

Important!

Although it is possible to define a mobile app in multiple OneLink templates, in most cases there is no need for it. Generally, an app should only be set up ONCE in the OneLink template. Use this setup to create many custom attribution links that have different attributes, but lead to the same destinations.

OneLink list page

The OneLinks list window is at account level, meaning it is common between all apps and contains all the OneLink templates of the account.

1. From the dashboard of any of your apps, under the Engagement & Deep Linking section, click OneLink Configuration to open the OneLinks list window

OneLink is properly set up

Each generated OneLink has its own unique OneLink ID (provided the OneLink sub domain is defined): http://myapp.onelink.me/onelinkid. Each OneLink also has its own custom name.

2. For a new OneLink template click .

3. To work on an existing OneLink template click the respective OneLink name.

Note

It is not possible to delete OneLink templates once they are set. This is because any existing attribution links based on deleted OneLink templates stop working and may redirect users to a 404 page (page not found).

Instead, you can simply edit existing OneLink templates.

After selecting an existing OneLink template, or adding a new one, the OneLink configuration page opens.

OneLink configuration page

From here you can set the destinations for iOS, Android and Windows phone devices. In addition, there are some more advanced destinations you can set. The following explains each of these options.

OneLink template name

Set the OneLink name here, preferably for the participating apps in the template. This is optional, but if you don't set the name, the default name "Untitled OneLink" is generated for the template.

You can change the OneLink name at any time.

iOS apps

Using the dropdown menu, select the iOS app you want the user to be redirected to in the App Store.

Advanced options

Custom Landing Page To redirect iOS users to a destination different from the App Store, populate a destination URL in the Custom iOS Landing Page URL field.To set OneLink deep linking options for iOS toggle the Enable Universal Links for deep linking button to On.

App ID PrefixApplication-identifier key in your app's entitlements

iOS Test AppsIf you are using a test app to develop your iOS app, you can test it using OneLink. Complete the App ID prefix (same as 2) and the iOS App Bundle ID, as defined on XCode.

Note

Both values are found on developers.apple.com in the Identifiers >> App IDs section. Just click the corresponding registered App ID as shown below.

iPad If you have a separate iPad app version, select it in the iPad dropdown menu, to redirect iPad users to it.

Android apps

Using the dropdown menu, select the Android app that you want the user to be redirected to in Google Play.

Custom Android APK URL

Insert here the link for your Android app, if it is out of Google Play, Android users are redirected to this link.

Enable App Links for deep linking"App Links" is an advanced method for performing deep linking on Android devices from Android OS version 6.0 and above. For more details go here.

Windows Phone app

Select the Windows Phone app that you want the user to be redirected to in the Windows Phone store, and add its URL in the Custom Windows Phone URL box.

Additional configuration

Note

The Deep Linking (iOS9/Android 6 and above) sub-domain field must not contain a '.' For example, MyApp is valid but com.MyApp is not valid.

Kindle Fire: Populate an Amazon Store ASIN or an alternative URL for Kindle Fire users.

Website URL: Populate any destination URL for desktop users. If no URL is defined, the user is redirected to the app's page in Apple's App Store.

Note

The first two additional configuration parameters are covered in the Deep Linking Guide.

Creating custom links from the OneLink template

Now your OneLink template is ready, you can create parameter-rich attribution links using it. These attribution links can differ by values such as the media source and campaign names (e.g. emails, website, banners etc.), but the basic OneLink redirections are common for all links (except if you override them ).

You can create OneLink attribution links manually using the custom attribution links setup window. For details click here.

Alternately, if you want to automatically create OneLink attribution links or by bulk, you can do this using the OneLink REST API.

You cannot delete a OneLink template. If you want to delete a OneLink template, contact your customer success manager or email us to [email protected].

Testing OneLink's redirections

To test your newly-configured OneLink template follow these instructions:

1. Create a Multi-platform 'test' custom attribution link

2. Select the OneLink configuration the attribution link is intended for

3. Fill in the media source and campaign names. You can create different links for any type of tests you run. However, AppsFlyer recommends using the test media source name for all of them

Tip

Always prefer using test media source (&pid=test) when you test anything with AppsFlyer, to see all test results under the test media source. Add the test type under the campaign name parameter (&c={test type}, e.g. &c=redirections) to distinguish between different test types with the campaign name parameter.

4. Generate the attribution link and use either the long or short URL for testing

Example:

https://go.onelink.me/{AUTO_GENERATED}?pid=test&c=redirections

5. For every OS version configured in the OneLink configuration page:

Send the test URL - To the respective whitelisted device using email, QR code etc.

Click on the test URL - Verify the device is redirected to the configured destination (Google Play, iTunes, web page etc.)

Install the mobile app - On the device and launch it

Check results - On the dashboard's overview page look for a new click and install under 'test' media source and the campaign name you put in the URL (e.g. redirections)

Warning

Completing the above tests successfully means your app is ready for performing OneLink redirections only. For deep linking tests click here.

Overriding OneLink's template destinations

Although OneLink's template-configured redirections are common for all attribution links that use it, you can override them with custom parameters. Placing the following destination parameters on the attribution link sends clicking users to the values stated in the link instead of the template's configured values.

Destination parameters

Destination Parameter Name

Description

AppsFlyer's Tip

af_ios_url

Redirect iOS users to a different URL than the app's page on iTunes

Use this for landing page redirections, or as fallback in case deep linking fails. Note -Mac desktop users, with Safari 13.0.0 and above, are redirected according the af_ios_url, and not according to af_web_dp.

af_android_url

Redirect Android users to a different URL than the app's page on Google Play

Use this for landing page redirections, or as fallback in case deep linking fails.

af_r

Redirect users to the specified URL on all operating systems and platforms

Use this for landing page redirections.

af_web_dp

Redirect desktop users to a different web page than configured in the OneLink template

Use this to keep attribution data of desktop users on other platforms (e.g. Google Analytics or Omniture).

af_dp

The path for an internal activity in the app that users are deep linked into

Use this for deep linking and retargeting.

af_ios_fallback

Supply fallback URL for users of iOS 10.3 and above

Use this to improve the broken flow for iOS 10.3 users.

af_param_forwarding

When set to false, none of the parameters that are on the OneLink pass to the redirected page

Use this for a cleaner looking URL in the redirected page, or if OneLink parameters might cause issues due to query parameter handling on the redirected page.

Warning

Do not use any of the following characters as part of the destination parameter values (not even URL-encoded). Using them blocks OneLink's redirection or deep linking actions. The characters are: []<>;(){}'`"

Example

Android users that click the following example link are redirected to google.com rather than the preconfigured android app page on Google Play. Clicking iOS users are redirected to apple.com:

https://go.onelink.me/{AUTO_GENERATED}pid=test&c=redirections&

af_android_url=http%3A%2F%2Fwww.google.com&

af_ios_url=http%3A%2F%2Fwww.apple.com

OneLink & social apps

Advertisers may want to use OneLink with "viral" posts on social apps, as potential users that are exposed to such posts cannot be targeted in advance according to their devices.

Unfortunately, limitations set mainly by Apple's Universal Links, in conjunction with restrictions of some of the social apps, complicate the use of OneLink for deep linking, or even sometimes for basic device recognition, redirection and attribution.

The following table summarizes what you can do with OneLink in todays popular social apps:

Social App

Android Redirection

Android Deep Linking

iOS Redirection

iOS Deep Linking

Facebook

Y

*Conditionally

Y

*Conditionally

Facebook Messenger

Y

*Conditionally

Y

*Conditionally

Snapchat

Y

*Conditionally

Y

*Conditionally

Instagram

Y

Y

Y

N

Y

Y

Y

N

Reddit

N

N

N

N

Slack

Y

*Conditionally

Y

*Conditionally

Twitter

Y

*Conditionally

Y

*Conditionally

WeChat

Y (See WeChat FAQ)

N

N

N

Whatsapp

Y

Y

Y

Y

*Conditionally - if URI scheme is used instead of App or Universal link, or if you set a landing page.

The landing page workaround for social apps

To avoid the aforementioned OneLink limitations, and still enable device redirection on social apps' posts, we recommend using the social app landing page.

Alternatively, you can create your own landing page. The flow is as follows:

Create a landing page with a "Download app" button, with OneLink behind it

Post the link to the landing page on the social app

A User clicks on the landing page link inside the post on the social app

The user is redirected to a landing page

Landing page contains a "Download app" button, with OneLink behind it. User clicks the button

The regular OneLink flow follows including deep linking and attribution using fingerprinting

Note

The conversion rates for landing pages may be a bit lower than the original sources, due to the second click required from the users.

To learn more about attributing mobile users coming from Facebook to landing pages go here.

For performing deep linking from social media posts with OneLink go to the deep linking guide.

Using OneLink with integrated networks

OneLink is mainly used with owned media, and not with ad networks.

It is rare for ad networks to require OneLink since they usually advertise on apps. This enables them to know the user's platform, device ID etc., so their app and platform-specific attribution links suffice.

However, sometimes ad networks don't know their users' platform in advance, for example when they run email or SMS campaigns themselves.

Important!

OneLink with integrated networks requires you to use the long version of OneLink.

OneLink setup with integrated networks

Go to Integrated Partners on your Android app's dashboard and select the relevant ad network.

Copy the app's attribution link from the setup window and save it to an external document.

For your iOS app, repeat steps 1+2.

Now build the attribution link:

Make sure

Create a basic OneLink URL in the Custom Attribution Link window and save it to an external document. When you create the basic OneLink URL, use "test" as the media source name:

After you click Generate Link, you see the following screen:

Copy the long link.

In the long link, Replace the "test" media source with the exact PID of the integrated partner to the link https://greatapp.onelink.me/U8ru?pid=network_int&c=MyCampaign

Add ALL parameters from BOTH attribution links If the attribution link of the iOS and Android app are identical, simply copy the parameters from either one of the links. Otherwise, make sure you have all the parameters from both links.

If all the integrated network parameters are added correctly, once OneLink is clicked and redirected to the right platform, the required parameters are sent to the network within a postback after the user installs.

Example

https://greatapp.onelink.me/3287867539?pid=network_int&c=email&

idfa{$IDFA}&gaid={$GAID}&clickid=$SITEID&

af_sub1=[pixel_code]&af_sub2=[creative]

The network uses either the IDFA or GAID parameters according to the client's device platform and disregards the other parameter.

FAQs

Is there any limitation on posting OneLink on web pages?

Yes, using target="_blank" in the HTML href tag does not result in redirecting to Google Play.If OneLink URL has is placed inside an html a tag withtarget="_blank"attribute, it opens a blank page in Chrome on Android. This affects OneLink functionality. Make sure that the a tag doesn't include the target attribute.

Are there any limitations on posting OneLink on Instagram?

Yes, there are several Instagram limitations:

Due to the way Instagram renders the text of a page post, links do not become clickable when entered into a post caption.

Instagram profile descriptions do not support clickable links.

Linking from profile website links is possible, however it directs to the App Store all the time since Universal Links are not supported in Instagram (iOS only).

What is AppsFlyer's solution for Android OneLink redirections on WeChat?

WeChat overrides Android deep links redirecting users to a web page. From this web page the user must then click the options button and choose to open the page in browser. As a result, users encounter a broken user experience increasing the chance for them to drop off in the conversion funnel.

To overcome this, OneLink can recognize clicks in WeChat and loads a dedicated landing page instructing the user to click the options button and then to click Open in Browser. This opens the redirect URL defined in the OneLink configuration.

If the users WeChat language is registered as Chinese, OneLink generates a localized version of the landing page:

Introduction

The purpose of this article is to explain how to integrate AppsFlyer withGoogle Marketing Platform.

Google Marketing Platform (DoubleClick) is made up of CM (Double Click Campaign Manager) and DV360 (DoubleClick Bid Manager).

What is CM?

CM stands for Campaign Manager. This is a Google 3rd-party ad server service. It enables mobile marketers to plan, execute and measure their display campaigns through DoubleClick.

What is DV360?

DV360 stands for Display and Video 360. This is a Google-owned demand-side-platform (DSP) providing trading desks, agencies, and advertisers with greater transparency and performance in global display media buying across ad exchanges.

How does it work?

Google Marketing Platform allows you to create something called Floodlights/Conversions. Floodlight is just another name for conversion. You create a floodlight for either install or post-install events (such as subscription or purchase) in order to integrate Google Marketing Platform and AppsFlyer for conversion measurement.

Google Marketing Platform integration scenarios

See the following table for integration scenarios with Google Marketing Platforms.

Integration

Integration type

Requirements

DV360

Integrating DV360 with AppsFlyer

Retrieve Floodlight values from DV per conversion.

Integrate Google Marketing Platform in AppsFlyer.

CM + DV

Buying DV360 traffic through CM

Retrieve Floodlight values from DV per conversion.

Integrate Google Marketing Platform in AppsFlyer.

CM + another media source which is not DV360

Buying traffic from media sources and funneling this traffic to CM.

Retrieve Floodlight values from DV per conversion.

Integrate Google Marketing Platform in AppsFlyer.

Retrieve CM measurement link.

Retrieve AppsFlyer measurement link - could be a integrated media source link or a custom link.

Append AppsFlyer link to CM link.

Give the combined link to the media source.

Setting up Google Marketing Platform inAppsFlyer

Note

The information in this sectionis relevant for both CM + media source and DV360 campaigns.

Activating Google Marketing Platform

Before you begin setting upGoogle Marketing Platform, activate it in the Integration tab.

Retrieving floodlight parameters

Before you can setup DoubleClick, you need to create an install (first_open) floodlight and retrieve its parameters. See here for more information. The parameters you should end up with are:

cat -The activity tag string, which Floodlight servers use to identify the activity group to which the activity belongs.

src -The Advertiser ID that is the source of the Floodlight activity. This is the src= parameter in the floodlight tag you export from the Pixel setup screen, not the DBM advertiser ID.

type - The group tag string, which identifies the activity group with which the Floodlight activity is associated.

Token - see instructions for retrieving the token:

CM

DV360

These parameters are required for the integration with Appsflyer.

Note

Floodlight parameters are unique per app. You should have two sets of floodlight parameters, one for each app.

Integrating with DoubleClick

Go to the dashboard of your app and click on Integrated Partners on the left menu.

details here

Enter "DoubleClick" in the search field and click on its logo to open DoubleClick's configuration window.

DoubleClick's configuration window includes 3 active tabs: Integration, Ad Revenue, and Permissions. Click on the items below to read about the tabs setup.

In addition to click-based mobile attribution, DoubleClick offers view-through and retargeting attributions, which you can record with AppsFlyer.

For a detailed description of the Partner Configuration Window Header, click here.

Integration tab

Setting floodlight parameters

In the integration tab, set the floodlight parameters in their respective fields.

Retargeting campaigns

To measure running retargeting campaigns on DoubleClick:

Toggle DoubleClick Retargeting to ON. If you do not have any active DoubleClick retargeting campaigns, it is recommended to toggle this button OFF.

Create a new Floodlight for retargeting campaigns (for example, app_opens). Then in AppsFlyer dashboard enter the cat, src, token and typeparameters specific to your retargeting campaigns.

Note

The token parameter is the same token parameter that you get when you enable third-party mobile in-app conversion.

Set the time period following the re-engagement, where the user's in-app events are attributed to the retargeting media source. You can set the value in days (1-90), hours (up to 23), or even lifetime.

Note

Agency accounts can configure Retargeting independently and have a separate Re-Engagement Window. For example, an advertiser can use a 30-day window for their own retargeting campaigns, while an agency that runs other campaigns for the same app, can set up a 45-day re-engagement window.

Click-through attribution

This slider allows you to set the maximum time from click to install. Only installs (first launches) that take place within the lookback window may be attributed to DoubleClick.

DoubleClick's default click-through lookback window is 30 days. To minimize discrepancies, we recommend aligning with DoubleClick's time period value.

More details about the click lookback window here.

View-through attribution

This slider allows you to set the maximum time from impression to install. Only installs (first launches) that take place within this lookback window, following an ad impression, are attributed to the partner, providing there was no other relevant ad click.

Toggle this to ON if you want to attribute view-through installs from DoubleClick. You can customize this value to 1-23 hours or 1-7 days.

DoubleClick's default view-through lookback window is 7 days. To minimize discrepancies, we recommend aligning with DoubleClick's time period value.

In-app events settings

First, create a floodlight for a specific activity such as a purchase or subscription. Then, retrieve the floodlight parameters.

Toggle In-App Event Postbacks to ON

Select the Sending Option for all SDK defined events - Only events attributed to this partner for events coming only from users attributed to DoubleClick - Events attributed to any partner or organic to have your entire user base available to be reported to DoubleClick

Click Add Event to add an SDK Event to the list

Select the SDK Event Name

Under Partner Event Identifier, configure the event using the floodlight parameters: The format should be set as below: token=123XXX456XXX&type=XXXXXXXX&cat=XXXXX123456&src=58XXX35

Note

Floodlight parameters are unique per event. For each in-app event that you configure in the postback, you need to provide unique floodlight parameters.

Floodlight parameters are unique per app.

The parameter details should be completed based on what you entered in the cat, src and token and type fields above.

The following two additional parameters are automatically transferred to DoubleClick: Order_ID and af_revenue.

AppsFlyer only supports sending additional floodlight parameters (u parameters) up to U26. The u parameters are pre-mapped and fixed on AppsFlyer's end so take the following into consideration:

Since they are pre-mapped, no additional custom U parameters can be configured.

Follow this mapping when to configure custom floodlight parameters in DoubleClick.

If AppsFlyer cannot send a specific u parameter, AppsFlyer doesn't send it. For example, if the carrier data is missing, AppsFlyer doesn't send u5.

Since they are pre-mapped, no additional custom U parameters can be configured.

Parameter mapping

For every in-app event AppsFlyer sends the following floodlights:

Description

Example

u1=

af device id

1540995037437-2811776739500410055

u2=

customer user id

eaf8a5f2.1836.4686

u3=

Android: Advertising id

iOS: idfa

9d9d03ab-f211-4e17-994e-d0afdf23ac01

u4=

wifi

true

u5=

carrier

Jio%204G

u6=

country code

IN

u7=

Region

HR

u8=

city

Gurgaon

u9=

device type

motorola::Moto G (4)

u10=

os version

7

u11=

sdk version

v4.8.18

u12=

app version

3.31.1

u13=

install timestamp

1540995041

u14=

click time

1546441586

u15=

impression time

1546441586

u16=

campaign name*

Appinstall_campaign

u17=

campaign id

12345ABC

u18=

adset name*

Appinstall_adset

u19=

adset id

12345ABC

u20=

ad name*

Appinstall_ad

u21=

ad id

12345ABC

u22=

site id

site_id_123456

u23=

event time

2019-01-04 12:56:35.707

u24=

event name

af_purchase

u25=

event value

{"af_price":459,"af_content_id":"77147","af_revenue":4.59,"af_currency":"EUR"}

u26=

currency

EUR

*In such cases AppsFlyer does not receive the name in the response from Google Marketing Platform (see the important note below) so it populates the field with the corresponding ID (i.e. Adset name becomes adset ID).

Important!

When AppsFlyer queries Google Marketing Platform, Google Marketing Platform returns only four parameters in the response. See them below and how they are mapped to AppsFlyer parameters that appear in the dashboard and raw data reports.

Site ID = (af_siteid)

Placement ID = (af_c_id)

Ad ID = (af_adset_id)

Creative ID = (af_ad_id)

Attribution link tab

the attribution link tab is not functional for DoubleClick, because it is an SRN and therefore doesn't use external attribution links for attribution.

However, attribution links do play a role in the integration with DoubleClick:

Attribution links for CM + media source

To run campaigns with CM and media source, two attribution link are required:

A CM measurement link.

The AppsFlyer attribution link for a specific media source (integrated partner or custom media source).

See setting attribution links for CM.

Attribution links for DV360 (DBM)

It is possible to use AppsFlyer's attribution links with DV360 for impressions and click recording only. These links are NOT used for attribution, and any additional information contained within them is not parsed or used for any purpose.

If you want to be able to measure the number of clicks from DVM360 on AppsFlyer, you should add an AppsFlyer attribution URL on your DVM360 dashboard. When doing so, make sure the campaign name in the attribution URL is identical with the campaign name on DoubleClick so that AppsFlyer can retrieve and append the click data on the correct campaigns.

Important!

Using Attribution Links for DoubleClick DV360 (DBM) is not mandatory.

If you want to count clicks in AppsFlyer, use this link:

https://app.appsflyer.com/ADD-APP-ID?pid=doubleclick_int&af_siteid=${UNIVERSAL_SITE_ID}

&af_ad_id=${CREATIVE_ID}&c=${CAMPAIGN_ID}&af_c_id=${CAMPAIGN_ID}

If you want to count impressions in AppsFlyer use this link:

https://impression.appsflyer.com/ADD-APP-ID?pid=doubleclick_int&af_siteid=%24{UNIVERSAL_SITE_ID}

&af_ad_id=${CREATIVE_ID}&c=${CAMPAIGN_ID}&af_c_id=${CAMPAIGN_ID}

Cost tab

Cost data is not available for DoubleClick.

Ad revenue tab

Follow these instructions to setup Ad Revenue:

In the DoubleClick integration window go to the Ad Revenue tab.

Select the in-app event which will be used for ad revenue recording

If you are using DoubleClick for mediation and want to measure the ad revenue of the mediated monetization platforms through the DoubleClick integration - select Include Mediation Revenue.

Important!

If you report all revenues through the DFPs mediation platform,don'tintegrate the other mediated networks ad revenue recording as well in the Integrated Partners screen. This will cause duplicate revenue reporting.

Sign In with Google to authenticate the Ad Revenue Integration.

Permissions tab

In this tab, you can select the permissions to grant DoubleClick. Note that even if attribution is disabled for DoubleClick, the permissions tab is active and you can grant control to DoubleClick.

Ad network permissions

Use these toggles to give the ad network permissions to handle its own configuration for your app:

Allow to configure integration - permit the partner to setup the integration tab (except in-app event postbacks)

Allow to configure in-app event postbacks - permit the partner to setup in-app event postbacks mapping to itself on the integration tab

Allow access to your retention report - only to the partner's own retention data

Allow access to your aggregate loyal user data- only to the partner's own loyal user data

Allow access to your aggregate in-app events data-only to the partner's own in-app events data

Allow access to your aggregate revenue data - only to the revenue data attributed to the partner

Allow access to your Protect360 dashboard - only to the partner's own Protect360 data, and providing the feature is enabled for the advertiser

Learn more about granting ad network permissions.

Important!

Make sure to follow the Integration Guide before continuing with the instructions in this section.

If you are managing a DV360 campaign through CM, ignore the instructions in this section. Switch back to the integration tab and follow the instructions there.

Setting an attribution link for DoubleClick campaign manager

To run and measure campaigns in CM, you need an AppsFlyer attribution link.

First, create an attribution Link. the attribution link should contain the real media source that you use and not DoubleClick. For example, if you are running through Rocketfuel, use pid=rocketfuel_int and not pid=doubleclick_int.

the attribution link should look something like this:

https://app.appsflyer.com/com.example?pid=rocketfuel_int&c=campaign_name

Then, append the AppsFlyer attribution link to the DoubleClick tracking URL:

https://ad.doubleclick.net/ddm/trackclk/N736113.127733/B202683.204586115;

dc_trk_aid=404426918;dc_trk_cid=92566356;dc_lat=;dc_rdid=?

https://app.appsflyer.com/com.example?pid=rocketfuel_int&c=campaign_name

Notes

You must make sure you have a placeholder for the Device ID - the parameter dc_rdid.

For Retargeting campaigns make sure your network link contains &is_retargeting=true. For more details. click here.

Using the attribution link

Once you have the attribution link give it to the media source. When an install occurs, AppsFlyer attributes the install to the media source. AppsFlyer then lets DCM know about the install using the floodlight parameters that you use when configuring the integration.

The end result is an install that is attributed to the media source, and an install that is registered in DCM.

CM token parameter

A fourth parameter called token is also required. A token is an advertiser-specific alphanumeric string that must be passed along with each server request to DoubleClick Digital Marketing (DDM.) To retrieve this token, you mustenable third-party mobile in-app conversion recording at the advertiser (Floodlight configuration) level:

Go to the Floodlight configuration tab

In the Server to server section, enable In-app attribution recording

Click New Token to generate a token, then enter a name (i.e. App Install - AppsFlyer).

Click Save.

CM (DCM) generates values for the new token.

Use this token when integrating Google Marketing Platform with AppsFlyer.

Important!

Make sure to follow the Integration Guide before continuing with the instructions in this section.

DoubleClick bid manager (DV360)

The system operates as an SRN. Therefore, it doesn't make use of attribution links as DCM does. To measure installs and other conversions,AppsFlyer uses the DoubleClick S2S API.

However, you can useAppsFlyer attribution links in DV360 (DBM) campaigns to measure clicks and impressions. See using attribution links with DV360.

Conversion measurement with DV360

To measure conversions with DV360, you need to create floodlights for each type of conversion:

Install

Retargeting

In-App Events

When you configure floodlights, DV360 gives you the parameters required to integrate with AppsFlyer.

DV360 token parameter

There is a fourth parameter, called token, that is also required. To retrieve this parameter you must enable third-party mobile in-app conversion recording at the advertiser(Floodlight configuration) level:

Go to Resources >> Floodlight for a campaign

Under the Basic Details tab, navigate to the Integrations >> Third-Party App Attribution section and enable in-app attribution recording

Click New token to generate a token, then enter a name

Click Save

Bid Manager generates values for the new tokens.

Agency configuration

As part of AppsFlyer's advanced integration with Google, AppsFlyer supports multiple calls to Google DoubleClick. This enables Agencies to promote the same app on behalf of an advertiser using their own DoubleClick integration parameters.

Adding a new agency configuration for Google DoubleClick

To configure DoubleClick under the agency's account please login to the client's app from the agency's account and follow the setup guide.

For CM (DCM): For AppsFlyer to attribute an install to an agency, AppsFlyer must know the name of the agency. The name of the agency should be passed to AppsFlyer with the af_prt parameter found in the attribution link or via the referrer as part of the URL.

For DV360 (DBM): The Agency must configure their own Floodlights (src, cat, type, token). For the agency to do so, the advertiser must activate DV360 in their own account. The advertiser should only activate the integration. They don't need to configure any floodlight parameters.

Support for retargeting and reengagement

To enable support for retargeting and reengagement, the advertiser needs to enable retargeting it when they activate the DoubleClick in their account. The advertiser only needs to enable retargeting. They don't need to configure any floodlight parameters.

In-app event mapping

Agencies can have their own in-app event mapping with DoubleClick, even if the advertiser client also has its own mapping. More .

How many agencies can work on DoubleClick per app?

AppsFlyer supports up to ten different configurations per app including the advertiser's own configuration (i.e. the advertiser's configuration and nine additional agency configurations).

Once the maximum number of configurations is reached, an existing configuration must be deleted before adding a new configuration.

Agency configuration vs. advertiser configuration

Agencies and Advertisers can both promote the same apps using DoubleClick.

If you choose to run campaigns separately from the agency please take the following into consideration:

Distinct floodlight parameters

Floodlight parameters should not be shared between agencies and advertisers. If the advertiser and agency configure the integration with DoubleClick using the sameFloodlight parameters, the advertiser cannot view any data in their dashboard.

It is crucial that each party use different Floodlight parameters.

Discrepancy reasons

See the following to learn about discrepancies and how you minimize them.

Differences in attribution models

Cause

Description

AppsFlyer's tip

View-through attribution window

View-through in DV360/CM attribution window is 14 days, while AppsFlyer's default window is 1-day.

Set the view-through window in AppsFlyer to match the view-through set in DV360/CM set-up window.

Incorrect floodlight parameters

Working with incorrect floodlight parameters could cause issues with attribution.

Make sure that the floodlight parameters are always correct when you set the integration with DV360/CM.

Multi-channel source attribution

In AppsFlyer, the last media source that a click comes from gets attributed.

A click can come from DV360/CM, followed by a click from another media source. In such cases, DoubleClick self-reports an install, but in AppsFlyer, the install goes to the other media source.

In such cases, AppsFlyer's attribution decision is the one you should follow.

Overview

AppsFlyer's Web SDK is a lightweight Javascript tag that allows you to attribute and record web-based events. You can record and measure web activities such as conversions, events, sessions, and revenue-related items.

The Web SDK also complements AppsFlyer's mobile SDK. If you integrate the mobile SDK, AppsFlyer seamlessly maps users activity in both mobile and web-based platforms.

The Web SDK is compatible with all modernbrowsers and operating systems.

Topics in this article

Integrating the SDK

Recording events

Identifying users

Real-world examples

Integrating the web SDK

This part is for web developers and explains how to integrate the Web SDK. Once integrated, the Web SDK can record sessions and user actions on the website.

Prerequisites

Before you can integrate the Web SDK, you must obtain your web dev key. The webdev key is generated when you create a brand bundle. The web dev key is not the same as the mobile dev key. They are two different dev keys. Don't use the mobile dev key in the web SDK.

Make sure you can add scripts to the head tag on your website.

If you are using Google Tag Manager, make sure that Google Tag Manager is integrated into the website.

Best practices

We recommend that you install the SDK on all pages of your website. This makes sure that all sessions and events are recorded.

Make sure to paste the code so it loads as early as possible in the page scope. You can achieve that by pasting the code near the top of the head tag.

If you are integrating the SDK using Google Tag Manager, make sure that the SDK loads only once per page load. Also, set the SDK to load a soon as the page loads using GTM prioritization.

There are two ways to install the SDK:

Native Install Tag Manager Install

Javascript code snippet

Replace the WEB_DEV_KEY placeholder in the script with your web dev key.

Paste this code snippet in the head tag on your website. Make sure to paste it near the top of the head tag.

<!-- AppsFlyer web SDK -->

<script>

!function(t,e,n,s,a,c,i,o,p){t.AppsFlyerSdkObject=a,t.AF=t.AF||function(){

(t.AF.q=t.AF.q||[]).push([Date.now()].concat(Array.prototype.slice.call(arguments)))},

t.AF.id=t.AF.id||i,t.AF.plugins={},o=e.createElement(n),p=e.getElementsByTagName(n)[0],o.async=1,

o.src="https://websdk.appsflyer.com?"+(c.length>0?"st="+c.split(",").sort().join(",")+"&":"")+(i.length>0?"af_id="+i:""),

p.parentNode.insertBefore(o,p)}(window,document,"script",0,"AF","pba","WEB_DEV_KEY")

</script>

Follow the instructions below to activate attribution.You can decide whether to install the SDK in all pages or in specific pages.

First, make sure to add the Google Tag Manager to your website

Create a new tag for the AppsFlyer web SDK, select the Custom HTML tag type.

Give the tag a meaningful name, paste the AppsFlyer SDK snippet in the textarea and save (make sureto change the WEB_DEV_KEY placeholder token to your specific web dev key).

<!-- AppsFlyer web SDK -->

<script>

!function(t,e,n,s,a,c,i,o,p){t.AppsFlyerSdkObject=a,t.AF=t.AF||function(){

(t.AF.q=t.AF.q||[]).push([Date.now()].concat(Array.prototype.slice.call(arguments)))},

t.AF.id=t.AF.id||i,t.AF.plugins={},o=e.createElement(n),p=e.getElementsByTagName(n)[0],o.async=1,

o.src="https://websdk.appsflyer.com?"+(c.length>0?"st="+c.split(",").sort().join(",")+"&":"")+(i.length>0?"af_id="+i:""),

p.parentNode.insertBefore(o,p)}(window,document,"script",0,"AF","pba","WEB_DEV_KEY")

</script>

On tag save, select to add a trigger.

Define the tag firing trigger. We recommend to set it to All Pages but you can choose to configure any subset of your website pages.

All Pages

Specific Pages

To install AppsFlyer Web SDK on specific pages, you first need to set a trigger for these pages.

In Google Tag Manager dashboard, click on Triggers and then New

Give the trigger a meaningful name and click on the pen icon in the upper left-hand side

Choose Page View

Select Some Page Views and configure the page properties

Click Save

Set the new trigger to the AppsFlyer Web SDK tag

The image below shows a configuration that loads the Web SDK for any page view. This is the recommended way, but you can set the tag to only be served fora specific subset of pages, directory or subdomain

Checking that the SDK is working

Once the SDK is integrated into your website, do the following to make sure that it is loaded:

Go to your website and.

Open the browser developer tools.

Switch to the network tab.

Refresh the page.

If the SDK is installed correctly, you should see the AppsFlyer on page load with response code 200.

Make sure that the SDK loads only once. Multiple SDK loading can cause the SDK to stop functioning.

Recording conversions and events

AppsFlyer Web SDK lets you record 2 types of events: conversion events and standard events.

By default, all events are defined as standard events. If you want to mark events as conversions events, you can do so from PBA settings. For more information see here.

Retrieving events data

You can view events data in two places

In the People-Based Analytics table - only conversion events appear there

In raw data reports - both conversion and standard events appear there

Conversion events

Conversion events provide insights into your marketing & business efforts. Such events can be purchases, downloads, signups, and subscriptions. The Web SDK attributes conversion events to those media sources that drive users to your websites.

This way you can record, measure and highlight media sources through which you acquire high-quality users.

Conversion events also allow you to record revenue and calculate ROI. You can compare the budget of ads for specific media sources against the revenue generated from the users that come from these media sources.

Standard events

Standard events help you validate user journey and funnels that lead to conversions. They can also help you measure user activity and highlight media sources that bring engaged users. Recording user activity can also help you mark users for reengagement campaigns.

Recording events

You can record events when certain conditions are met such as when a landing page loads or when users interact with website elements. See real-world examples of recording events.

Available event parameters

Parameter Name

Type

Description

Required

eventType

String

The event type. Can be one of two:

EVENT - to send a user action or event

IDENTIFY - to set customer user ID to the user

Yes

eventCategory

String

Event type grouping e.g. "conversion"

No

eventName

String

The name of the event e.g. "purchase", "subscription"

Only ifeventType is EVENT

eventLabel

String

Flexible client data labeling, useful for passing product id, A/B testing etc. This data is available in the raw data reports.

The event label parameter accepts strings and not objects. It is not like the event value parameter in the mobile SDK which accepts a map of key-value pairs.

Use this parameter for labeling purposes rather than sending rich in-app events.

No

eventRevenue

Float

Revenue assigned to a conversion event

No

eventRevenueCurrency

String

Revenue currency, 3 character ISO 4217 currency code

If no currency is specified, it defaults to USD

eventCost

Float

Cost assigned to a conversion event

No

customUserId

String

Mapping the user ID of your customers in your own systems, to the user ID that the SDK sets for the user

To be used when eventType isIDENTIFY

Only when sending an IDENTIFY event

Recording event example

// purchase event of shoes with associated revenue

AF('pba', 'event', {eventType: 'EVENT', eventName: 'purchase', eventLabel: 'shoes', eventRevenue: 12});

Recording event scenarios

The events that you send depend on the nature of your web app. An eCom web app requires a certain set of events different than that of an online news outlet. See the scenarios below to get a sense of what sort of events you should and send and when.

Online store

Suppose you are managing an online store. Some events that you want to record can be:

Search - standard event

Add to cart -standard event

Remove from cart -standard event

Purchase -conversion event

News outlet

Suppose you are managing a new outlet. Some events that you want to record can be:

Signup - conversion event

Purchase subscription - conversion event

Checking that events are sent

This part is intended for web developers. It explains how to check that events are sent to AppsFlyer.

Open your website.

Open thebrowser developer tools.

How to open the developer tools in Chrome

How to open the developer tools in Safari

Switch to the network tab.

Trigger the event.

Filter by message and look for a network request that starts with destination wa.appsflyer.com - see screenshot below.

Make sure that the status code is 200.

Make sure that the Request Payload aligns with the parameters in the event.

5. Identifying users

The Web SDK lets you identify users so that you can attribute events and conversions to specific users. If you set the same user ID for a mobile and web user, then you have a holistic view of this user's activity across both platforms.

Set user ID

Use the IDENTIFY event to set a unique user ID. The ID can be a unique string of characters or an email. Fire the below javascript call as soon as you identify your user.

Important: the value for customer user ID must be a string. If your customer user ID is a number e.g. 663274, pass it as a string to the API call.

Identify user example

// Associate all current user web events to distinct id 663274

AF('pba', 'event', {eventType: 'IDENTIFY', customUserId:'663274'})

This tab shows real-world examples of recording events and identifying users.

These are just examples that demonstrate how to record events. The code provided in these examples is for reference only. Do not use this code as-is. If you are not sure how to use this code, consult your web developer. Both examples assume that the Web SDK is already loaded by the page by the time the event is sent.

Recording events

Below you can find examples that show how to record events. There are two examples:

How to record events when a landing page loads

How to record events when users interact with your website.

Native Event RecordingTag Manager Event Recording

Recording events when a landing page loads

You have a subscription page for newsletters and you want to record subscriptions. You can set up a thank you page and redirect users to it after they subscribe.

<html>

<head>

<!-- Assume that the server returns a response with details about the newly subscribed user -->

<!-- Alternatively, you can extract data from localstorage or cookies,

in case data was set in either of them during the subscription process

-->

<script>window.onload = function(){

AF('pba', 'event', {eventType: 'EVENT', eventCategory: 'conversion',eventName: 'subscription', eventLabel: 'newsletters'});

}

</script>

</head>

<body>

<h1>Thank You for Subscribing to Our Newsletter</h1>

</body>

</html>

The code above shows a basic HTML page. The web page needs to load the Web SDK in order for you to send events.

Once the page loads after the user is redirected to it, the window loading method callsThe AFAPI method to send the subscription event to AppsFlyer.

Recording events when users interact with the website

You have an eCommerce website and you want to record checkout events. Once the user clicks on the checkout button, the Web SDK sends an event to AppsFlyer.

<html>

<head>

<!-- Assume that data about proudcts in the shopping cart

is stored in localstorage -->

<script>

window.onload = function () {

document.getElementById('checkout').addEventListener('click', function () {

AF('pba', 'event', {eventType: 'EVENT',eventCategory: 'conversion', eventName: 'checkout'});

});

}

</script>

</head>

<body>

<h1>Shopping Cart</h1>

<h2>Shirt</h2>

<p>

<ul>

<li>Color: Blue</li>

<li>Quantity: 2</li>

<li>Price: $20</li>

</ul>

</p>

<h2>Pants</h2>

<p>

<ul>

<li>Color: Black</li>

<li>Quantity: 3</li>

<li>Price: $15</li>

</ul>

</p>

<button id='checkout'>Checkout</button>

</body>

</html>

The code above shows a basic HTML page.The web page needs to load the Web SDK in order for you to send events.

Once the page loads, it binds a click listener to the Checkout button. When the user clicks theCheckout button, the callback function fetches data from localstorage. It then calls the AFAPI method and passes data to it. The AFAPI method sends the event to AppsFlyer.

Recording events when a landing page loads

You have a subscription page for newsletters and you want to record successful subscriptions. For this purpose, you can set up a thank you page to which users are redirected after successfully subscribing.

Setup a thank you page

<html>

<head>

<script>

// Google Tag Manager loads the Web SDK

<script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':

new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],

j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=

'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);

})(window,document,'script','dataLayer','GTM-XXXX');

</script>

<script>

// Assume that the server returns a response with details about the newly subscribed user

function getResponseFromServer() {

return JSON.stringify({ action: 'subscribe', category: 'site actions', label: userEmail })

}

//Alternatively, you can extract data from localstorage or cookies,

//in case data was set in either of them during the subscription process

localStorage.setItem('data', JSON.stringify({ action: 'subscribe', category: 'site actions', label: '[email protected]' }));

</script>

</head>

<body>

<h1>Thank You for Subscribing to Our Newsletter</h1>

</body>

</html>

The code above loads Google Tag Manager which in turn loads the Web SDK. Two other actions take place in the script. One is a function that gets a response from the server with user details. The other sets data to local storage. Google Tag Manager has access to both function and localStorage. You can call the function and access localstorage using Google Tag Manager.

Add a new tag for attributing subscriptions after the thank you page loads

Give the tag a distinct name and select the Custom HTML tag type option

Put the following code in the Custom HTML.

<script>

AF('pba', 'event', {eventType: 'EVENT', eventCategory: 'conversion', eventName: 'subscription');

</script>

Expand the Advanced Settings control and then the Tag Sequencing control below the textarea and make sure it is set up to fire the conversion after the tag was executed

Set a trigger for the conversion tag to indicate when the conversion tag should be fired (in the below example it is fired on Thank you page load)

Recording events when users interact with the website

You have an eCommerce website and you want to record checkout events. Once the user clicks on the checkout button, the Web SDK sends an event to AppsFlyer.

Setup a checkout page

<html>

<head>

<script>

// Google Tag Manager loads the Web SDK

<script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':

new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],

j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=

'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);

})(window,document,'script','dataLayer','GTM-XXXX');

</script>

</head>

<body>

<h1>Shopping Cart</h1>

<h2>Shirt</h2>

<p>

<ul>

<li>Color: Blue</li>

<li>Quantity: 2</li>

<li>Price: $20</li>

</ul>

</p>

<h2>Pants</h2>

<p>

<ul>

<li>Color: Black</li>

<li>Quantity: 3</li>

<li>Price: $15</li>

</ul>

</p>

<button id='checkout'>Checkout</button>

</body>

</html>

The code above loads the Web SDK using Google Tag Manager. The rest is simply HTML that mimics a shopping cart page. Notice the Checkout button that has the ID checkout. It is required when setting Google Tag Manager to handle a click on that button.

In Google Tag Manager, click on Variables, click on Configure and check Click Element in the list of Built-In Variables

Create a new variable, give it a meaningful name and choose type of All Elements

In the trigger configuration, choose Some Clicks, choose Click Element that matches CSS Selector of #checkout

Create a new tag for the checkout action, choose type Custom HTML and set the trigger to the checkout trigger

<script>

AF('pba', 'event', {eventType: 'EVENT', eventCategory: 'conversion', eventName: 'checkout');

</script>

Important!

Make sure the web SDK functions tag is loaded before the event is fired

Avoid sending any special characters in event values e.g. currency signs in revenue value

Value strings should be shorter than 50 characters

Setting customer user ID

Example: Setting the user ID after signup

The following example demonstrates how to set user ID. The code provided in these examples is for reference only. Do not use this code as-is. If you are not sure how to use this code, consult your web developer. The example assumes that the Web SDK is already loaded by the page by the time the event is sent.

Consider the following scenario:

A user signs up to your website.

You gather the user details and send it to your server.

Your server creates a new user and generates a unique ID for that user.

In the thank you page after signup, you query the server for the new user ID.

You use the response from the server to set the user ID using the Web SDK identify method.

Important!

Both examples assume that the Web SDK is already loaded by the page by the time the event is sent. There is no need to load the SDK again.

Native Google Tag Manager

Set up a signup page

<html>

<head>

<!-- The Web SDK script has to load first -->

<script>

!function(t,e,n,s,a,c,i,o,p){t.AppsFlyerSdkObject=a,t.AF=t.AF||function(){

(t.AF.q=t.AF.q||[]).push([Date.now()].concat(Array.prototype.slice.call(arguments)))},

t.AF.id=t.AF.id||i,t.AF.plugins={},o=e.createElement(n),p=e.getElementsByTagName(n)[0],o.async=1,

o.src="https://websdk.appsflyer.com?"+(c.length>0?"st="+c.split(",").sort().join(",")+"&":"")+(i.length>0?"af_id="+i:""),

p.parentNode.insertBefore(o,p)}(window,document,"script",0,"AF","pba","WEB_DEV_KEY")

</script>

<script>

};

// this function stores the user email to be sent to the server after the user reaches the thank you page

// the response from the server is a unique user ID that we use in the IDENTIFY event type

function storeUserEmail (){

var userEmail = document.getElementById('email').value;

localStorage.setItem('user_email', userEmail);

}

</script>

</head>

<body>

<h1>Sign Up</h1>

<form onsubmit="storeUserEmail()" action="/signup" method="post">

<div><label>Name</label>

<input type="text" name="name" id="name"></div>

<br />

<div> <label>Email</label>

<input type="email" name="email" id="email"></div>

<br />

<input type="submit" id="submit">

</form>

</body>

</html>

The code above is a simple signup form. When the form is submitted, the email is stored in localStorage. When the user reaches the thank you page, the user email is sent to the server to get the unique user ID for that email.

Set up a thank you page for users who sign up:

<html>

<head>

<script>

!function(t,e,n,s,a,c,i,o,p){t.AppsFlyerSdkObject=a,t.AF=t.AF||function(){

(t.AF.q=t.AF.q||[]).push([Date.now()].concat(Array.prototype.slice.call(arguments)))},

t.AF.id=t.AF.id||i,t.AF.plugins={},o=e.createElement(n),p=e.getElementsByTagName(n)[0],o.async=1,

o.src="https://websdk.appsflyer.com?"+(c.length>0?"st="+c.split(",").sort().join(",")+"&":"")+(i.length>0?"af_id="+i:""),

p.parentNode.insertBefore(o,p)}(window,document,"script",0,"AF","pba","WEB_DEV_KEY")

</script>

<script>

// using the fetch api to send the user email to the server

// and get the unique user id in return

window.onload = function () {

var userEmail = localStorage.getItem('user_email');

fetch('users/' + userEmail).then(function (res) {

res.text().then(function (id) {

console.log(id);

AF('pba', 'event', { eventType: 'IDENTIFY', customUserId: id});

});

});

} </script>

</head>

<body>

<h1>Thank You for Signing Up!</h1>

</body>

</html>

The code above makes use of the fetch API. It sends the server the email that the user puts in the signup form. Assuming that the server creates a user with a unique ID upon signup, sending the email to the server is for the purpose of receiving a unique user ID. The server responds with a unique ID and this unique ID is the value that is passed with the IDENTIFY event type.

Set up a signup page

<html>

<head>

<script> // Google Tag Manager loads the Web SDK

(function (w, d, s, l, i) {

w[l] = w[l] || []; w[l].push({

'gtm.start':

new Date().getTime(), event: 'gtm.js'

}); var f = d.getElementsByTagName(s)[0],

j = d.createElement(s), dl = l != 'dataLayer' ? '&l=' + l : ''; j.async = true; j.src =

'https://www.googletagmanager.com/gtm.js?id=' + i + dl; f.parentNode.insertBefore(j, f);

})(window, document, 'script', 'dataLayer', 'GTM-5VJ6C7R');

// this function stores the user email to be sent to the server after the user reaches the thank you page

// the response from the server is a unique user ID that we use in the IDENTIFY event type

function storeUserEmail (){

var userEmail = document.getElementById('email').value;

localStorage.setItem('user_email', userEmail);

}

</script>

</head>

<body>

<h1>Sign Up</h1>

<form onsubmit="storeUserEmail()" action="/signup" method="post">

<div><label>Name</label>

<input type="text" name="name" id="name"></div>

<br />

<div> <label>Email</label>

<input type="email" name="email" id="email"></div>

<br />

<input type="submit" id="submit">

</form>

</body>

</html>

The code above is a simple signup form. When the form is submitted, the email is stored in localStorage. When the user reaches the thank you page, the user email is sent to the server to get the unique user ID for that email.

Setup a thank you page for users who sign up

<html>

<head>

<script> // Google Tag Manager loads the Web SDK

(function (w, d, s, l, i) {

w[l] = w[l] || []; w[l].push({

'gtm.start':

new Date().getTime(), event: 'gtm.js'

}); var f = d.getElementsByTagName(s)[0],

j = d.createElement(s), dl = l != 'dataLayer' ? '&l=' + l : ''; j.async = true; j.src =

'https://www.googletagmanager.com/gtm.js?id=' + i + dl; f.parentNode.insertBefore(j, f);

})(window, document, 'script', 'dataLayer', 'GTM-5VJ6C7R');

</script>

</head>

<body>

<h1>Thank You for Signing Up!</h1>

</body>

</html>

The code above is simply the thank you page. This page has a Google Tag Manager trigger that sends the server the email that the user puts in the signup form. Assuming that the server creates a user with a unique ID upon signup, sending the email to the server is for the purpose of receiving a unique user ID. The server responds with a unique ID and this unique ID is the value that is passed with the IDENTIFY event type. See below for instructions on how to create the tag and trigger.

Add a new tag for attributing subscriptions after the thank you page loads

Give the tag a distinct name and select the Custom HTML tag type option

Put the following code in the Custom HTML.

<script>

var userEmail = localStorage.getItem('user_email');

fetch('users/' + userEmail).then(function (res) {

res.text().then(function (id) {

AF('pba', 'event', {eventType: 'IDENTIFY', customUserId: id});

});

});

</script>

Expand the Advanced Settings control and then the Tag Sequencing control below the textarea and make sure it is set up to fire the conversion after the tag was executed

Set a trigger for the conversion tag to indicate when the conversion tag should be fired (in the below example it is fired on Thank you page load)

Notes

If the user ID is not set, the distinct id currently in the persistent store (cookie or localStorage) is used.

The IDENTIFY event can be sent at any stage in the user flow (e.g. after user login). AppsFlyer uses the most recent IDENTIFY event to update the current observed user for past or future touchpoints and events.

We recommend using the user ID field from your database. This comes in handy in case a user changes their name, email address or any other distinct identification that they can change

Sending the user identification is completely optional and AppsFlyer enables you to hash it to make sure your user privacy is kept.

Introduction

Google Ads is an online advertising platform developed by Google. AppsFlyer enables you to attribute the various Google Ads campaign types.

Using Google Ads

The Google Ads UI only allows you to configure an App Campaign, for iOS and Android devices.

To attribute users from other platforms, e.g. Windows Phone users, to Google Ads you need to use a landing page solution.

To configure other specific campaign types besides App Campaign, contact your Google representative.

Configuring Google Ads attribution for advertisers

To start attributing Google Ads campaigns with AppsFlyer, follow these steps:

Note

As a prerequisite for the integration with Google Ads, the app must collect IDFA / GAID. For further information, refer to the SDK Integrations Guides for either Android or iOS.

Watch

Read

Step 1: create the Google Ads link ID (mandatory)

(Google Ads admin only)

Go to your Google Ads dashboard and click on the Tools icon on the upper right corner

Select Linked accounts under Setup

In the Third-party app analytics box click on DETAILS

Click the + button

From the App analytics providers list select AppsFlyer

Select your mobile app's platform, iOS or Android, and select the relevant app under look up your app

Click on CREATE LINK ID

Copy the new Link ID, which now uniquely identifies your mobile app on Google Ads

Remember - you MUST repeat these steps to create the unique LINK ID for each of your mobile apps

Step 2: set up Google Ads on AppsFlyer (mandatory)

(Any member in AppsFlyer's account)

Head to your app's dashboard on AppsFlyer and click Integrated Partners

Select Google Ads

here

Activate the partner and paste the copied Link ID.

Configuring Install attribution:

Set theInstall click-through lookback window. Select the lookback window units (hours or days) and set the slider to the desired value. We recommend setting the lookback window to 30 daysto match with Google Ads.

Enable Install view-through attribution.

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 Google Ads.

Reinstall attribution:

To enable reinstall attribution, switch it on.

No need to enable view-through attribution or configure lookback windows for reinstall attribution, as the values are taken from install attribution settings.

Configuring Re-engagement attribution:

Enable retargeting in app settings.

EnableRe-engagement click-through attribution.

Set the Re-engagement click-through lookback window, which is theperiod 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.

EnableRe-engagement view-through attribution.Important - to activateRe-engagement view-through attribution with Google Ads you must also contact Google Ads directly, on top of the setup in AppsFlyer.

Set the Re-engagement view-through lookback window, which is theperiod of time, starting from ad impression, during which the app must be launched for the impression 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, following either a click or an impression. You can set the value in days (1-90), hours (up to 23), or even lifetime. The default is 30 days.

Go to the Cost tab

Toggle ON the Get Cost, Clicks and Impressions Data button.

Click on the Connect Google Adsbutton and log into your Google account to get all your Google Ads campaign costs on AppsFlyer.

Click Save.

Click here to learn how to see cost data sync status.

Note

To record clicks and impressions you must configure cost, as described above.

To learn about Google ads cost, click here.

Important!

The next step (step 3) is optional. You don't have to map your in-app events.

However, step 4 is MANDATORY! Even if you decide to skip step 3, you still have to go through step 4.

Step 3: map your in-app events (recommended)

(Any member attached to the AppsFlyer's account)

Go to the Integration tab and scroll down to the In-App Events section

Set the Link ID again here, if required

Note

When enabling the Google Ads in-app events mapping for an app for the first time, all the af_XXX events from the SDK are automatically mapped to Google's pre-defined event list. This automatic mapping saves you time and decreases mapping mistakes significantly.

Toggle In-App Event Postbacks to ON

Select the Sending Option for all SDK defined events - Only events attributed to this partner for events coming only from users attributed to Google Ads - Events attributed to any partner or organic to have your entire user base available to be reported to Google Ads (recommended for future Google Ads remarketing purposes)

Click Add Event to add an SDK Event to the list

Complete 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 (Google)Event Identifier

The unique name or ID of each event as defined on the partner's side. There are several options here: Text field - get the corresponding event ID from the partner. Drop down box - select the most suitable pre-defined event for your event.

Some integrations have the CUSTOM value, which enables sending your SDK event as is to the partner. However, as is doesn't mean that the event value is sent as is as well. The event value must contain standard AF parameters. If you send an event whose value contains Non-AF parameters, these parameters are not sent to Google.

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).

Tip

We recommend mapping AF app opened with session start for future retargeting purposes.

Click Save

Important!

For Google Ads to register your new conversions, you MUST launch your app and perform your mapped in-app events at least once. Afterwards, it may take up to 6 hours until they are added to the queue. Once they are added, you can import them or the new conversions change status from No recent conversion to recording conversion".

Step 4: measure your app conversions (mandatory)

(Google Ads admin only)

Head back to your Google Ads account and click on the Tools icon

Under the section labeled Measurement - click on Conversions

Click the Plus button

Select Appfrom the list of conversion types

Select Third-party app analytics, and click on Continue

Check the box next to first_open of ALL your apps, and for each event youd like to import

Click Import and Continue, and then click Done

You can now see your third-party conversion event in the Conversion actions table. Click on the name of the event to see more details If an event does not appear in the list or if it has been removed from the Google Ads Conversion import list, click Status and select All to show all events, so that you can re-import the event:

Congratulations! You are now measuring Google Ads mobile campaigns with AppsFlyer!

Note

Please ensure your "include in conversions" setup is aligned with your campaign goals in Google Ads. For more information, consult with your Google representative or refer to the Google documentation here.

Tip

The Google Ads API integration automatically includes the Google Ads remarketing feature. By completing this integration and sending events to Google Ads you are able to create remarketing audience lists in Google Ads without any additional integrations.

Granting permissions to Google Ads team members

You can grant Google Ads permissions to access certain data in your account. You can do this in the Google Ads configuration page under the Permission tab for each one of your apps.

To be able to get these permissions and access your app, your Google Ads representative should be a team member of Google Ads partner account on Appsflyer.

Because of Googles privacy requirements, Google can add new team members to its AppsFlyer partner account only when its explicitly requested by an advertiser.

In order to grant a Google Ads team member access to your app, do the following:

Fill out and submit this form to request your account manager to be added to Googles partner account on AppsFlyer.

Wait for the confirmation from Google Ads that your GA account manager has been added.

Go to Configuration > Integrated partners > Google Ads > Permissions and add your account manager email to the list of team members.

Activate the permissions you wish to grant your Google Ads account manager.

Read more about providing permissions to Ad networks.

Enabling Google Ads attribution for agencies

AppsFlyer supports agency configurations with Google Ads. It is essential that the advertiser and the agency have separate Google Ads accounts to enable AppsFlyer to correctly attribute the data. For details, click here.

Running with multiple Google Ads accounts

AppsFlyer supports working with multiple Google Ads accounts for the same app. This is performed through sharing the Link ID in Google Ads and importing the events into each Google Ads account.

For further details on how to share your Google Ads Link ID, click here.

iOS App Campaigns

Google is going to update its iOS app campaign search inventory logic. As a result, AppsFlyer will not show installs for AC iOS search inventory campaigns. Google, however, will show conversions for all AC iOS search inventory results. Clients who opt-out of this Google update will still see installs for AC iOS search inventory campaigns in AppsFlyer. For more information, click here.

Google Ads parameter mapping

The table below is the parameter mapping between Google Ads and AppsFlyer.

Note

Advertisers cannot add personalized parameters to any Google Ads campaigns.

Campaign type: app campaigns

Set out below in the table is the parameter mapping received from Google.

Network Type

Search

Display

Video

Channel (af_channel)

UAC_Search

UAC_Display

UAC_Video

Campaign (c)

Yes

Yes

Yes

Campaign ID (af_c_id)

Yes

Yes

Yes

Adset (af_adset)

N/A

N/A

N/A

Adset ID (af_adset_id)

N/A

N/A

N/A

Ad (_ad)

N/A

N/A

N/A

Ad ID (af_ad_id)

N/A

N/A

N/A

Ad Type (af_ad_type)

Yes*

Yes*

Yes*

Site ID (af_siteid)

GoogleSearch/ Search Partners

N/A

YouTubeVideos/ YouTubeSearch/ VideoPartners

Keywords

N/A

N/A

N/A

*For more information on what ad types are available in Google's response see here.

Important!

Google is an SRN (Self Reporting Network). For more information about how the attribution flow works for these networks, click here.

AppsFlyer can present any campaign information that is provided by Google. The campaign type (Search, Video, Display) and associated information is determined by Google. For more information, click here.

Click Blocking - For Android, AppsFlyer blocks clicks from pid googleadwords_int, meaning they are counted in the system, but ignored for attribution.

Google Ads retargeting campaigns

With AppsFlyer, you can measure the results of Google Ads App Campaigns for Engagement. In AppsFlyer, such campaigns are called Retargeting campaigns.

Retargeting campaigns target users who have installed your app in the past.

Retargeting engagements by users, who still have your app installed, are called Re-engagements. These usually result in deep linking users.

Retargeting engagements by users, who don't have your app installed, are called Re-installs or Re-attributions.

Currently AppsFlyer doesn't pull cost, clicks, and impressions for Google Ads retargeting campaigns.

For more information, see Google Ads for engagement support documentation.

Setting up Google Ads app campaigns for engagement

Before you begin, ask your Google Ads account manager to whitelist your Google Ads account for Engagement.

To measure Google Ads App Campaigns for Engagement, follow these three steps:

Enabling retargeting in app settings

To enable retargeting campaigns of any media source, you need to enable it on the app level. If this is the first retargeting campaign for your app, do the following:

Go to your apps dashboard

On the left-hand menu, click App Settings

Scroll all the way down

Toggle on Enable Re-Targeting Campaign Measurement

Enabling Google Ads retargeting in AppsFlyer

Follow item #5 in the instructions for setting up Google Ads in AppsFlyer.

Importing session start conversions in Google Ads

To record conversions for re-engagement campaigns, you need to import the event session_start in Google Ads.

This event appears in Google Ads if at least one user launches the app after you enable retargeting in AppsFlyer for Google Ads. Just to be sure, launch the app yourself after you enable retargeting.

To learn how to import conversions in Google Ads, see here.

Setting up deep linking for app campaigns for engagement

Google App Campaigns for Engagement require you to use deep links for re-engagement campaigns. Third party deep linking solutions cannot be used due to a domain mismatch. This includes AppsFlyers OneLink. Use your own internally-developed App Links, Universal Links or custom URI schemas.

There is no need to add any additional parameters to the deep link (is_retargeting=true and pid=adwords are not required).

Deep linking and customizing user experience

Google App Campaigns for Engagement involve deep linking. When performing deep linking with AppsFlyer using OneLink, an SDK method called onappopenattribution provides you with data related to the re-engagement campaign. However, this data is not available when deep linking takes place through Google App Campaigns for Engagement. Click here to learn more.

Dynamic remarketing and shopping campaigns

Dynamic remarketing for apps and shopping campaigns are supported in AppsFlyer. For AppsFlyer, they are just like any other re-engagement campaign.

To learn about Dynamic remarketing for apps, click here. To learn about Shopping campaigns, click here. To learn more about Google Ads for Engagement click here.

Google Ads cost data sync status

The cost tab in the integration shows the status of your cost integration and the last time AppsFlyer managed to pull matching cost data.AppsFlyer pulls cost only for campaignsthat had at least one install or click in the last 7 days. In addition, AppsFlyer doesn't pull cost for re-engagement campaigns.

Google Ads 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 describes five different status messages, and what to do if you see them in the cost tab.

Status

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:

You just set up the integration and AppsFlyer have yet to pull data.

There is no data in AppsFlyer about installs coming from the ad network.

Wait for AppsFlyer to pull data.

Start running campaigns with the ad network.

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 entered the API credentials for the correct app, and that the network is passing 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

Cost API credentials are incorrect. AppsFlyer in unable to pull cost data.

Make sure that the cost API key is correct.

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 showsCost Data was never successfully pulled.

Examples

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 messageLast 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 messageLast successful sync 14 days ago.

Stopping Google cost sync

To stop cost sync with Google:

In Google, Go to Google account permissions

Click Remove, next to AppsFlyer Google Cost

Google Ads costs, clicks and impressions

AppsFlyer supports getting cost, click and impression data from Google Ads. This integration allows you to view and measure your ad spend on Google Ads, and then calculate eCPI and ROI of your Google Ads campaigns.

MCC Accounts are also supported.

To view Google Ads cost, click and impression data within the AppsFlyer dashboard, connect via your Google Ads configuration page. Once the connection is complete, AppsFlyer begins to query your Google Ads cost amounts, clicks, and impressions for all of your existing campaigns.

Click here to see details of setting up cost in Google Ads.

After the setup, data should come through within a few hours. AppsFlyer receives cost data seven days retroactively from the first time you log in to the system.

Clicks and impressions

Enabling cost also collects clicks and impressions data. The Data in AppsFlyer is shown up to Campaign level.

Note

Tip

Users can confirm they are logged in with the correct Google Ads account by checking the email address, which appears on the top right corner of the Google Ads dashboard.

If the Google Ads account is a sub-account of an MCC account, then the top right ID is the MCC's, and the sub-account's ID is on the top left corner.

If it is not the correct account, sign out of the account and sign in again using the email address for a different Google account.

Cost, clicks, and impressions by Geo

Cost by Geo allows you to view cost data based on geographical location. This option is supported for campaigns with installs after August 27, 2018.

To view Cost by Geo:

In the Filter By field, select Google Ads as the media source.

In the Group By field, select Group by Geo in the filters.

Cost, clicks and impressions by Geo are collected according to the campaigns' targeting. Campaigns with worldwide or proximity targeting show their cost, clicks, and impressions grouped under Geo "N/A".

A campaign with specific targeting, e.g. US, can still drive installs from other countries, e.g. Canada. All cost clicks and impressions are tied to the campaign's targeting. Installs coming from GEOs other than the campaign's targeting show cost, clicks and impressions as N/A.

Warning

Having enabled Google Ads cost, do not change the name of any live Google Ads campaign, as this could cause serious discrepancies or missing cost data.

Why can't I see my cost data?

Client logged-in with the wrong account email

When logging in, it is important to verify the right Google account is used.

If you login using the wrong Google account, no cost is pulled or displayed. In such a situation, you must remove the app from Google apps permissions and login with the correct account. To do so, follow these steps:

Click on the following URL: https://myaccount.google.com/permissions

Remove AppsFlyer Cost on Google and login again.

Spaces and special characters

Using spaces or special characters in iOS Search or Android Landing Page campaigns may cause issues with matching cost data to click data and leading to missing cost reporting.

Where is my Geo based clicks data?

In some cases, AppsFlyer receives partial Geo clicks data from Google. When this occurs AppsFlyer completes the missing clicks information from other Google sources, which lack the Geo data. Therefore, when grouping by Geo, the total number of clicks from Google's campaigns, may not match with the same number with another grouping dimension.

Recording ad revenue with Google Ads

If you are acting as a publisher with Google ads you may want to attribute your ads revenue to find the media sources that earn you the most money on ad clicks. Through the Google Ads setup window you can do that as follows:

Click the Ad Revenue tab on the Google Ads setup window

Toggle the Get Ad Revenue Data button to ON

Press the API Authentication button to authenticate the Google Ads account

Event Source - choose the event representing your ad revenue model in the best possible way. The Ad Revenue Event value is automatically created upon your selection.

Note

Google sends to AppsFlyer only ad revenue that is generated via the Google Ads Network. Ad revenue from mediation partners such as ironSource or Unity may be displayed on Google's dashboard. However, Google doesn't send this ad revenue to AppsFlyer. You can configure these partners in AppsFlyer's dashboard to send ad revenue data directly to AppsFlyer.

FAQs

Why am I not seeing clicks from Google Ads?

Aggregate clicks and impressions data from Google Ads is collected once you have authenticated cost, clicks and impressions collection in the Cost tab.

Clicks and impressions data from Google Ads was made available during August 2018, first for Android apps and later on for iOS apps. Therefore, when analyzing clicks data from 2018 and before, Google Ads clicks data may be missing or incomplete.

Why am I not seeing first_open conversions on Google Ads

If you are not seeing first_open conversions on Google Ads as shown in the screenshot below:

it means that you need to import conversions in Google Ads. Follow the instruction on importing conversions.

Why can't I see in-app events on Google Ads?

Are you seeing this screen on Google Ads after mapping your preferred in-app events on AppsFlyer's dashboard ( configuration step 3 )?

If so, then you need to perform these events on a mobile device AFTER the mapping takes place. It may take up to 6 hours afterwards for the events to show up on Google Ads' dashboard.

Can I stop Google cost sync?

To stop cost sync with Google:

Go to your Google account permissions

Click on Remove next to AppsFlyer Google Cost

Do I need to create and then import session_start?

This depends on the type of campaign you are running. If you are running a re-engagement campaign then it is recommended to create and import session_start to measure engagements.

For a user acquisition campaign, this is not mandatory.

Does AppsFlyer display campaign level data?

Yes! You can also view channel level data in the AppsFlyer main dashboard.

Do I need to configure anything to create audience lists in Google Ads based on AppsFlyer data?

No. In the Google API, this information is already set and is based on your In-App Event configuration.

I'm running an apps campaign, why can't I see data or conversion events in the AppsFlyer or Google Ads dashboard?

It is very likely that you have not yet imported events. For details about how to import events, click here.

What do I do if there are multiple accounts?

There is no problem using multiple accounts with Google Ads with AppsFlyer. AppsFlyer only works with one Link ID. Therefore, only one Link ID must be generated in Google Ads and this can be shared between multiple accounts. For more information, click here.

What happens with link IDs created at mcc level vs. account level

Link IDs at MCC or account level are supported by AppsFlyer. We recommend working closely with your Google Ads representative to ensure your account is structured correctly. For more information, click here.

What is parallel tracking?

Google Ads' Parallel tracking enables your landing page to load faster, reducing the issue of lost visits. As a result, conversions are increased and ad performance is improved. With Parallel Tracking, users are sent to the final URL, directly from your ad, before sending them to the attribution links, while click measurement takes place in the background.

For a full explanation of Parallel Tracking, click here.

Additional information

Attribution Link Mismatch - Sometimes Google displays a notification that there is a mismatch between the attribution link and the final URL. This has no impact on measurement and attribution on the AppsFlyer side. To avoid this notification, when using the basic tracking template, you can add an additional URL parameter called af_r and use the value of the final app store URL. In the screenshot above, the landing page URL is

https://play.google.com/store/apps/details?id=com.XXXXXX.XXXX&hl=en

To the AppsFlyer URL template, add the following URL to the af_r parameter with the landing page URL above:

https://app.appsflyer.com/com.XXXXX.XXXXX?af_c_id={campaignid}&af_siteid={placement}&af_adset={adgroupid}&af_adset_id={adgroupid}&af_ad={creative}&af_ad_id={creative}&pid=ga_parallel_test&af_click_lookback=7d&c={campaignid}&url={lpurl}&network={network}&af_keywords={keyword}&af_r=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.XXXX.XXXXX%26hl%3Den

In most cases, Google does not enable third party attribution links, which includes regular attribution links and AppsFlyer's OneLink.

How do you configure a campaign with Android or iOS configuration

Important!

AppsFlyer supports all app campaigns enabled by Google Ads.

Google is an SRN (Self Reporting Network). For more information about how the attribution flow works for these networks, click here.

AppsFlyer can present any campaign information that is provided by Google. The campaign type (Search, Video, Display and Re-engagement) and associated information is determined by Google. It is recommended to configure App campaigns. For guidance on other campaign types, you should contact your Google representative. For details of these campaigns, click here.

Android configuration for Google Ads

To support Android attribution, make sure that your app supports GAID (Google Advertising ID) collection, and that it is passed to AppsFlyer through our SDK.

Creating conversion recording (installs)

For details of how to create conversion recording, click here.

Google Ads - Android Configuration - Sending In-App Events

If you want to further measure the success of your Mobile App Install campaigns in Google, you can send in-app events to your Google Ads account from your AppsFlyer account.

Create a conversion (in-app events)

For details of how to measure your app conversions, click here.

iOS configuration for Google Ads

Google Ads - iOS configuration: app campaigns

App campaigns allow you to promote your iOS app across Google Search, YouTube and Display in a single place of configuration.

Generally, Google Ads itself can't self-attribute iOS installs from search campaigns as the clicks come from mobile web sources, preventing Google from pulling the IDFA from the devices, and from performing ID matching.

In contrast, iOS searchonApp Campaigns can be attributed by Google Ads, for ads that are served on the Google Search App.

creating conversion recording (installs)

For details of how to create conversion recording, click here.

Google Ads - iOS configuration - sending in-app events

If you want to further measure the success of your Mobile App Install campaigns in Google, you can send in-app events to your Google Ads account from your AppsFlyer account.

Creating a conversion (in-app events)

For details of how to measure your app conversions, click here.

For how long do you keep Google Ads user-level data?

Google Ads requires attribution providers to delete its user-level data 6 months after the install. This means that the events performed by these users 6 months after they install the app are counted as organic.

Past aggregate data remains the same.

This is relevant for all Google Ads channels.

Discrepancies

Sometimes there are discrepancies between the Google Ads dashboard and the AppsFlyer dashboard.

While we work closely with Google Ads to minimize these discrepancies, advertisers should be aware of the following reasons:

Both iOS and Android

Cause

Google Ads

AppsFlyer

Multi-Channel Source Attribution

Google Ads does not hold this data.

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

Install Record Time

Google Ads attributes the conversion to the Click time.

AppsFlyer attributes the conversion to the launch time (app open).

Reports Time

Google Ads dashboard might have up to 72 hours delay

AppsFlyers reports are in real time.

Time Zones

Varies - based on location

Varies - based on location.

Attribution Window

30 Days

From Google integration it's set for 30 Days default (can be modified).

Assisted Installs

Google Ads, as an SRN, attributes all installs following engagements with Google Ads, within their attribution window.

AppsFlyer attributes the last click only, and treats engagements before it as assists.

Re-installs

Google Ads doesn't show this data

AppsFlyer attributes and displays re-installs (AKA re-attributions) as part of its retargeting data.

In-App Events

Google Ads attributes the in-app event to the Click time.

In the AppsFlyer dashboard in-app events are attributed according to the install time. In Raw Data Reports, AppsFlyer attributes in-app events according to the time of the event.

Validation Rules

Google receives all information from AppsFlyer regardless of validation rules.

AppsFlyer might deduct a number of installs based on their validation rules.

Cause: iOS App Campaign Search Inventory

Google Ads includes inventory for iOS AC search results in both mobile web and Googles search app.

Google Ads doesnt respond to attribution partner queries about iOS AC search conversions in mobile web. As a result, these installs are not attributed to Google Ads in AppsFlyer.

Cost - Google Ads campaign channels

Google reports cost for all channels of a given campaign - YouTube, display, and search.

AppsFlyer gets cost data from Google for all channels of a campaign, but only attributes conversions from YouTube and display channels in iOS AC. As a result, the overall CPI in AppsFlyer is higher.

Notes

While Google Ads 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-engagements).

To avoid duplicate postbacks, for retargeted Google Ads users AppsFlyer sends the af_app_opened event, which indicates an app session, only once.

When comparing data from Google Ads dashboard and AppsFlyer, make sure that the data in Google Ads dashboard is data that is imported from 3rd party analytics (AppsFlyer). Data imported from Firebase or Google Play is structued differently and is not fully comparable with AppsFlyer data. To learn how to import data from AppsFlyer to Google Ads dashboard, click .

To compare install events (first_open in Google Ads), make sure that you drill down to install events in the conversion report in Google Ads. Google Ads might show all conversions (could be installs, purchases, subscriptions) which is why it is important to select only those install events out of all conversion events.

Introduction

ironSource, one of AppsFlyer's integrated partners, builds monetization, engagement, analytics and discovery tools for app developers, device manufacturers, mobile carriers and advertisers.

In addition to click-based mobile attribution, ironSource also offers cost, ad revenue, retargeting and view-through attribution, which you can record with AppsFlyer.

To configure your campaigns with ironSource, follow the steps below.

Setting up ironSource

Go to the dashboard of your app and click on Integrated Partners on the left bar.

agency permissions

Enter "ironSource" in the search field and click on its logo to open ironSource's configuration window.

ironSource's configuration window includes 5 tabs: Integration, Attribution link, Cost, Ad Revenue, and Permissions. Click on the items below to read about the tabs setup.

For a detailed description of the Partner Configuration Window Header, click here.

Tip

The General Settings step in the Integration tab is mandatory for all partners

All the rest of the steps are either descriptive or optional

Integration tab

Activate partners

On the first visit here, you will need to toggle ON the Activate Partner button to enable setup of the integration tab's parameters. The toggle MUST be ON for as long as you work with the partner. For more details about partner activation please click here.

Note

As an ALL-Installs network, ironSource prefers to receive postbacks for all new installs of your app from ANY source, including organic. It is recommended to select Events attributed to any partner to send all install postbacks to ironSource.

General settings

Partner ID

ironSource connects with AppsFlyer via a unique advertiser ID (6-digit number) and a password. If you don't already have the advertiser ID and password, you must obtain it from ironSource to continue with the integration.

Enable View-Through attribution

Toggle this to ON if you want to attribute view-through installs from ironSource. The view-through lookback slider is available on the attribution link tab (described below).

Default postbacks

AppsFlyer can send automatic postbacks to ironSource following user installs and re-engagements. Use this section to define the source of the users that allow sending these postbacks.

Select Only events attributed to this partner for events coming only from users attributed to ironSource. Select Events attributed to any partner or organic to have your entire user base available to be reported to ironSource.

In-app events settings

In this section you can map your AppsFlyer events with ironSource via postbacks.

Enter the advertiserid and password again.

Toggle In-App Event Postbacks to ON.

Select the Sending Option for all SDK defined events. - Only events attributed to this partner for events coming only from users attributed to this partner - Events attributed to any partner or organic to have your entire user base available to be reported to the partner

Click Add Event to add an SDK Event to the list.

Complete 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 - If you 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

The unique name or ID of each event as defined on ironSource's side. Obtain the corresponding Event ID from ironSource and set in the text field.

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 it exists in the event).

Attribution link tab

In this tab, you can create the attribution links you want to send to ironSource for attributing ironSource's campaigns, ad sets or even single ads. Note that AppsFlyer DOES NOT save your generated partner's attribution links.

This tab is divided into different sections:

Attribution link parameters

In this section, select which parameters you want to add to the attribution link.

Adding parameters to the attribution link here enables you to later perform thorough drill-down analyses. Parameters that are already defined on the attribution link can be edited by adding them and their new values here.

Campaign - add it to compare different campaigns running with ironSource. Attribution link parameter: c

Adset - set ad set names to compare different ad sets within specific ironSource campaigns. Attribution link parameter: af_adset

Ad Name - set ad set names to compare different creatives within specific ad sets within specific campaigns ironSource. Attribution link parameter: af_ad

Site ID and Sub Site ID - set Site ID parameter to attribute installs to specific publishers. If many publishers exist, we advise on limiting the number of used site IDs and using the sub site ID parameter, to avoid exceeding the site ID limitations. Attribution link parameters: af_siteid and af_sub_siteid

Subscriber Parameters - use any of the 5 subscriber parameters to insert useful values. Note that these parameters get parsed and appear in the raw data report, which makes them very handy for performing data aggregation or filtering. Attribution link parameters: af_sub1, af_sub2, af_sub3, af_sub4, af_sub5

Add any other parameter to the attribution link simply by typing it in a new parameter box. For more information about AppsFlyer's Attribution Link Structure and Parameters.

Retargeting settings

When enabled, AppsFlyer recognizes a link as a retargeting attribution link, rather than a user acquisition link, by adding the &is_retargeting=true to the click recording link. Note that retargeting is currently only supported for click-through and not view-through attribution. Attribution link parameter: is_retargeting.

The following setup below is displayed when retargeting is enabled.

1. Standard Link vs. OneLink

Select standard attribution link option if:

You don't need to deep link with the URL or

Plan to use only URI schemes for deep linking

select Use OneLink for:

Using a single link for both Android and iOS apps or

Deep linking using Universal or app links

Note that selecting OneLink changes the click recording link from app specific to a OneLink URL.

2. Deep Link URL

Use this field if the link is meant to deep link users to any specific activity within your app. Attribution link parameter: af_dp You can find more information about AppsFlyer's deep linking solution in this guide.

3. Re-engagement Window

Set the time period following the re-engagement, where the user's in-app events are attributed to the retargeting media source. You can set the value in days (1-90), hours (up to 23), or even lifetime.

Attribution link parameter: af_reengagement_window

Click-through attribution

This slider allows you to set the maximum time from click to install. Only installs (first launches) that take place within the lookback window may be attributed to ironSource.

Attribution link parameter: af_click_lookback

More details about the click lookback window here.

Click attribution link

This is the attribution link that contains all the setup information you have set for it. Send it to ironSource to be activated when leads click on a corresponding ad.

View-through attribution lookback window

This slider allows you to set the maximum time from impression to install. Only installs (first launches) that take place within this lookback window, following an ad impression, are attributed to ironSource, providing there was no other relevant ad click.

You can customize this value to 1-23 hours or 1-7 days.

Attribution link parameter: af_viewthrough_lookback

More details about the view-through attribution here.

Impressions attribution link

The impression attribution link contains similar attribution data to the click recording link (besides the different lookback window). Send it to ironSource to be activated when a corresponding ad is watched, usually for 1 second or more.

Cost tab

ironSource automatically sends CPI cost data on the attribution link for all installs.

For the full list of partners supporting cost data go here.

Ad revenue tab

This section is relevant only if you are acting as a publisher, displaying ads of the partner to your users. As such, you would certainly like to measure the engagement of your users acquired from different sources, to find the most profitable sources for you.

ironSource offers aggregate and user-level ad revenue granularity. Select only one type of integration.

Set the Get Ad Revenue Data toggle to display the partner's required setup for revenue data. Follow the specific instructions on the partner's ad revenue section. For example, in the capture below the partner requires a simple login to its system.

To learn more about ad revenue attribution.

To enable User-Level revenue attribution:

If enabled, disable ad revenue integration with AppsFlyer integrated partners that mediate through ironSource. Note:If you do not disable these integrations ad revenue can be duplicated in the Platform.

In AppsFlyer, go to Configuration> Integrated partners.

Select ironSource.

Go to the Ad Revenue tab.

Select User Level integration.

Complete the fields:

Refresh Token.

Secret key.

App ID.

Click Save Ad Revenue User-level ad revenue collection is now active.

To enable Aggregate attribution:

In AppsFlyer, go to Configuration> Integrated partners.

Select iRonSource.

Go to the Ad Revenue tab.

Select Aggregate Integration.

Complete the fields:

Secret Key

User Name

App ID

Event Source

Click Save Ad Revenue The integration is active.

Permissions tab

In this tab, you can select the permissions to grant ironSource, whether the partner acts as an ad network, agency or even both. Note that even if attribution is disabled for ironSource, the permissions tab is active and you can grant control to ironSource.

Use these toggles to give the ad network permissions to handle its own configuration for your app:

Ad network permissions

Allow to configure integration - permit the partner to setup the integration tab (except in-app event postbacks)

Allow to configure in-app event postbacks - permit the partner to setup in-app event postbacks mapping to itself on the integration tab

Allow access to your retention report - only to the partner's own retention data

Allow access to your aggregate loyal user data- only to the partner's own loyal user data

Allow access to your aggregate in-app events data-only to the partner's own in-app events data

Allow access to your aggregate revenue data - only to the revenue data attributed to the partner

Allow access to your Protect360 dashboard - only to the partner's own Protect360 data, and providing the feature is enabled for the advertiser

Learn more about granting ad network permissions.

Agency permissions

Use these toggles to give the agency permissions to handle its own configuration for your app:

Main toggle - Set to On to reveal the agency permissions options

Allow access to your retention report - only to the agency's own retention data

Allow access to aggregate organic data

Allow to configure in-app event postbacks - permit the agency to setup in-app event postbacks mapping to itself on the integration tab

Learn more about granting .

At a glance: By attributing ad revenue, app owners gain the complete view of user LTV and campaign ROI.

Vungle

Ad revenue attribution

Ad revenue is generated by displaying ads on rewarded videos, offer walls, interstitials, and banners in an app. To display ads, ad monetization network SDKs are integrated into the app. Having done so you are able to serve ads to your app users and generate ad revenue.

Ad revenue combined with in-app and subscription revenue completes the app user LTV picture. By matching user LTV with media spend the campaign ROI is determined and is available in the Dashboard.

Ad revenue is reported using the integration between AppsFlyer and the monetization network. The revenue is attributed to the media source that brought the user. Ad revenue can be broken down by user geo and monetization network.

The data freshness of ad revenue in the Dashboard is: Daily40

Ad revenue attribution supports different granularity methods.

Aggregate granularity :The network reports the total revenue per day broken down by geo.Appsflyer derives the effective revenue per action (eRPA) bydividing the revenue with the number of instances of a trigger event. The trigger events are app open or in-app events defined in the app itself.

User-level granularity :(best practice): The network reports the revenue per day at the user level. This enables attributing the revenue to the original UA source. Not all monetization networks support this method.

Ad revenue attribution workflows

To implement ad revenue attribution, follow one of the granularity method workflows in the following table.

Ad revenue attribution workflows

Step

Aggregate granularity

User-level granularity

1

Assess if you want to implement in-app events or use the app open event.

Are you are partnering with ad revenue mediation platforms? If so, read this.

Not Applicable

2

In the app implement:

Ad monetization networks' SDK.

AppsFlyer in-app events.

In the app implement:

Ad monetization network's SDK in the app

3

Connect to the add monetization network partner in AppsFlyer

Connect to a user-level ad monetization network:

ironSource

4

Generate and attribute ad revenue

Generate and attribute ad revenue

Implementation

Aggregate granularity using app open or in-app events

Aggregate granularity implementation:

The network reports by integration the total revenue per day broken down by geo.

Appsflyer derives the effective revenue per action (eRPA) bydividing the ad revenue with the number of instances of a trigger event.

For each instance of the trigger event, AppsFlyer creates a _monetized event, that includes the eRPA. For example,ad_matched_monetized.

Using eRPA revenue is attributed to media sources.

You can use one of the following event types:

Unique monetization in-app eventrequires modifications to the app.

af_app_open_event which is available by default,

Don't report ad revenue in in-app events. Doing so causes ad revenue to be duplicated in the Dashboard because AppsFlyer gets the revenue data from the monetization network by integration.

Aggregate ad revenue using events

Event method

How implemented

Considerations

Unique monetization in-app event

An in-app event is set at the time of ad display

This provides a distinct count of user actions which enables superior eRPA calculations

This can be further refined by having a different in-app event for each monetization network doing so enables you to break the revenue down by monetization network See the table that follows for a full discussion.

Requires the developer to modify the app

Revenue can be broken down by monetization network in the Dashboard

af_app_open event

The af_app_open event is sent by the Appsflyer SDK by default

It is triggered by each user session

No app modification required

Quick to implement

eRPA values are significantly distorted unless you show only one app per session

No breakdown of revenue by monetization network

The event pertains to all users who launch the app and you have no indication of the user's willingness to watch ads

Comparison of in-app event methods

Method

Pros

Cons

Considerations

Use the same event for all networks. For example,ad_watched. This automatically generates the ad_watched_monetized event containing the monetization details

Simplest to implement

No quality information, like the number of clicks and ad revenue per network

Best suited if the main goal is to find source/campaigns that get users with the greatest tendency to click on ads.

It is not suited to comparing the performance of monetization networks.

(best practice) Each network is allocated a unique event for ad watching. Example:ad_watch_admob,

ad_watch_vungle.

Full visibility and ability to compare the monetizing networks in the dashboard in addition to the raw data.

Ad revenue isn't accumulated under a single event. The number of events is equivalent to the number of networks

Enables comparison of monetizing networks in the dashboard. Ad revenue is separated by network using

User-level granularity with Ad revenue API

This method is the best practice. It provides the greatest level of granularity and enables attributing ad revenue and does not require any modifications to the app. The benefit of using user-level granularity is that ad revenue is accurately attributed to the UA source. Note: User-level data used for ad revenue attribution is not available as raw data or postbacks.

User-level granularity (best practice)

Method

How implemented

Considerations

User-level data using Ad revenue API

Configure the integrated partner parameters in the Dashboard. Note: There is no need to implement in-app events.

Data displays in the dashboard with the af_ad_revenue event

This method is available with the following monetization partners:

ironSource

Connecting to ad revenue integrated partners

Before you begin:

Prepare the app

Request that the ad revenue integrated partner provide you API credentials.

To enable ad revenue integration with the ad revenue network:

In Appsflyer, go to Configuration > Integrated Partners. The Integrated Partner window opens.

Select a partner. Tip: SelectActive andAd revenue to display your existing partners who have Ad revenue capabilities.

Select the integrated partner. The integrated partner's configuration window opens.

Go toAd Revenue tab, enable Get Ad Revenue Data.The API credentials fields are displayed.

Some partners offer User-level and Aggregate granularity. Select one.

Complete the API credentials as provided by the integrated partner.

Select the app trigger in-app event that represents the ad monetization trigger. This event is usually sent for each ad impression. For example, ad watched or video watches.

Click Save Integration.

Implementing ad revenue mediation platforms

App owners may contract with one or more ad monetization networks, either directly or via ad revenue mediation platforms Examples: IronSource, Admob, DoubleClick (DFP).

If you implement a mediation platform's SDK in the app, this may cause duplicate reporting of revenue. To avoid duplication use the flow chart that follows to identify the appropriate way to integrate monetizing networks and mediation platforms.

AppsFlyer requires these platforms to integrate with it to perform ad monetization recording. You can check if the ad monetization platform you use is integrated with AppsFlyer in the Supporting Networks tab.

Admob and Applovin can act as mediation platforms but in AppsFlyer they only report ad revenue generated via Admob or Applovin respectively.

Viewing ad revenue data

Ad revenue shows the quality of users from different sources over time. As users continue launching the app and engaging with ads, their LTV continues to increase.

Ad revenue attribution information is available in:

Overview dashboard in theAggregated Performance Report table. (LTV)

Events dashboard (activity date). Use this report to see the value of revenue generated by date.

Cohorts (LTV)

Activity reports (activity date)

Downloadable aggregate data reports (LTV)

Overview dashboard - aggregated performance report

In the Overview dashboard:

Values including revenue are LTV See LTV vs. activity data.

The Revenue column includes all revenue including ad revenue and in-app purchases

Drill-down into the advertising hierarchy (media source, campaign, ad set, geo) to view the monetized events in the report.

Events dashboard

In the Activity dashboard:

Values including revenue are activity date based. See LTV vs. activity data.

TheAverage Actions per User, indicates the tendency of users to engage with the ads presented in the app.

Limitations

Daily40 data freshness: Ad revenue includes revenue accumulated during the previous day. AppsFlyer pulls the revenue the day following the actual revenue event. This means that ad revenue typically displays in the date following the actual ad display date. This means thatthe original trigger event (example, ad_watched) is displayed, its parallel ad revenue event (example, ad_watched_monetized) is displayed on the day following the event.

Ad revenue events are not available in the following:

Raw Data reports

In-app event postbacks

Push API

Retargeting dashboard

Agencies are not able to access ad monetization platform configuration

Additional limitations for user-level granularity:

The af_ad_revenue event is not available for cohorts in Pivot and Master API.

The event is available in Cohort analytics.

Examples

Three users install an app on December 31, 2017. They are attributed as follows:

User A: Network A

User B: Network B

User C: Organic

The app is integrated with five different monetization platforms. Each platform uses a unique in-app event using the AppsFlyer SDK as follows:

Facebook Audience Network: fb_ad_view

Chartboost: chartboost_ad_view

Admob: admob_ad_view

Applovin: applovin_ad_view

IronSource: is_ad_view

After the install for a period of four days, the users are shown ads, as follows:

User

UA network

fb_ad_view

chartboost_ad_view

admob_ad_view

applovin_ad_view

is_ad_view

Total

A

Network A

2017-12-31

2018-01-01

$1

2018-01-02

$1

2018-01-02

$1

2018-04-01

$1

$4

B

Network B

2017-12-31

2018-01-02

$1

2018-01-04

$1

$2

C

Organic

2017-12-31

2018-01-01

$1

2018-01-02

$1

$2

If we look at the data we can summarize the revenue collected per day and the generated in-app events. This gives the eventual revenue per event which is then distributed to each user:

User LTV

User

2018-01-01

2018-01-02

2018-01-03

2018-01-04

Total LTV

A

$1

$1

$1

$1

$4

B

$1

$1

$2

C

$1

$1

$2

Total

$2

$3

$1

$2

$8

Understanding the Reports:

As mentioned, ad revenue is tied to the user LTV. As a result, the time period you select in the Dashboard represents the cohort of installs for which the revenue is aggregated up until the current time and day. Lets examine the report from two different date selection and understand the reporting.

Aggregate Report - Date Selected: 2018-12-31, current day 2018-01-05

Network

LTV Revenue

Organic

$2

Network A

$4

Network B

$2

Network C

$2

In this case the cohort is the install date and the current day is 2018-01-05. All the revenue generated is tied back to the acquiring source and represented under the users LTV.

FAQ

How can I get the total ad revenue from each platform?

Ad revenue attribution is linked and displays in relation to the user acquisition source.

This provides the LTV view of your ROI and KPIs.

To view the total revenuefrom each monetization platform use a different in-app event for each network and use the following procedure:

In the Overview dashboard, go to the aggregated performance report table.

Select up to four monetizedevents representing the platforms you want to query.

Download the report by, clickExport CSV.

Sum up the Revenue column of the requested platform's monetized event

Note that this total ad revenue is LTV data, i.e. it's the entire revenue generated by a monetizing network for your app from users, who installed during the specified date range.

Is there ad revenue data in the activity page?

Yes!

The Activity page reports on the combined revenue from in-app purchases and ad revenue. Note:Ad revenue data is sent to AppsFlyer on a daily basis, the day following the event. This means that in the Activity dashboard ad revenue data is assigned to the following day.

Example

On Monday midnight AppsFlyer gets a total ad revenue of $1000 for Monday for your gaming app - "Example App". While the AppsFlyer LTV data on the overview page shows the $1000 recorded for Monday, the activity page shows it for Tuesday (while its Monday data shows Sunday's ad revenue).

Do I need to activate the partner in the Integration tab?

If you engage with the partner for ad monetization (ad revenue) only: don't enableActivate Partnerin the integration tab.

Enable onlyGet Ad Revenue data in the Ad Revenue tab.

List of Ad revenue integrated partners

Partner

Logo

Credential parameters required

Data granularity

AdColony

API Key

App ID

Aggregate level with geo

AppLovin

Report Key

App Package Name

Aggregate level with geo

Bytedance Ads - China traffic

Secure key

App ID

Account ID

Aggregate level with geo

Chartboost

User ID

User Signature

App ID

Aggregate level with geo

Google Marketing Platform -DV360/CM (DoubleClick)

Login to Google Marketing Platform -DV360/CM

Aggregate level with geo

Facebook

Login to Facebook

Aggregate level with geo

Google Ads

API Authentication by OAuth

Aggregate level with geo

IronSource

Secret Key

User Name

App ID

Aggregate level with geo

User-level

Mintegral

App ID

Secret Key

API Key

Aggregate level with geo

TikTok Ads

Aggregate level with geo

Twitter (MoPub)

API Key

Inventory Report ID

APP ID

Aggregate level with geo

Unity Ads

API Key

App ID

Aggregate level with geo

Voodoo Ads

Bundle ID

Access token

Aggregate level with geo

API Key

App ID

Aggregate level with geo

Liftoff, an AppsFlyer integrated partner, is one of the top contributors of traffic for bloggers and brands.Liftoff offers click-based and view-through mobile attribution, as well as click-based and view-through retargeting which you can record with AppsFlyer.

After accepting Liftoff's terms, accept Liftoff Mobile Measurement Terms & Conditions

To configure your campaigns with Liftoff, follow the steps below.

Setting up Liftoff

In AppsFlyer, go to Configuration > Integrated Partners.

Search for liftoff. agency permissions

Click Liftoff. The Liftoff configuration window opens.

The configuration window consists of the following tabs:

(mandatory)Integration

Attribution link

Cost

Permissions. Click on the items below to read about the tabs setup.

For a detailed description of the Partner Configuration Window Header.

Integration tab

Activate partners

On the first visit here, EnableActivate Partnerto enable setup of the integration tab parameters. For more details about partner activation please click here.

Note

As an ALL-Installs network, Liftoff prefers to receive postbacks for all new installs of your app from ANY source, including organic. It is recommended to select Events attributed to any partner to send all install postbacks to Liftoff.

General settings

Enable View-Through attribution

Toggle this to ON if you want to attribute view-through installs from Liftoff. The view-through lookback slider is available on the attribution link tab (described below).

Default postbacks

AppsFlyer can send automatic postbacks to Liftoff following user installs and re-engagements. Use this section to define the source of the users that allow sending these postbacks.

Select Only events attributed to this partner for events coming only from users attributed to Liftoff. Select Events attributed to any partner or organic to have your entire user base available to be reported to Liftoff.

In-app events settings

In this section you can map your AppsFlyer events with Liftoff via postbacks.

Toggle In-App Event Postbacks to ON

Select the Sending Option for all SDK defined events. - Only events attributed to this partner for events coming only from users attributed to this partner - Events attributed to any partner or organic to have your entire user base available to be reported to the partner

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 - If you 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

The unique name or ID of each event as defined on Liftoff's side. Obtain the corresponding Event ID from Liftoff and set in the text field.

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 it exists in the event).

Attribution link tab

In this tab, you can create the attribution links you want to send to Liftoff for attributing Liftoff's campaigns, ad sets or even single ads. Note that AppsFlyer DOES NOT save your generated partner's attribution links.

This tab is divided into different sections:

Attribution link parameters

In this section, select which parameters you want to add to the attribution link.

Adding parameters to the attribution link here enables you to later perform thorough drill-down analyses. Parameters that are already defined on the attribution link can be edited by adding them and their new values here.

Campaign - add it to compare different campaigns running with Liftoff. Attribution link parameter: c

Adset - set ad set names to compare different ad sets within specific Liftoff campaigns. Attribution link parameter: af_adset

Ad Name - set ad set names to compare different creatives within specific ad sets within specific campaigns Liftoff. Attribution link parameter: af_ad

Site ID and Sub Site ID - set Site ID parameter to attribute installs to specific publishers. If many publishers exist, we advise on limiting the number of used site IDs and using the sub site ID parameter, to avoid exceeding the site ID limitations. Attribution link parameters: af_siteid and af_sub_siteid

Subscriber Parameters - use any of the 5 subscriber parameters to insert useful values. Note that these parameters get parsed and appear in the raw data report, which makes them very handy for performing data aggregation or filtering. Attribution link parameters: af_sub1, af_sub2, af_sub3, af_sub4, af_sub5

Add any other parameter to the attribution link simply by typing it in a new parameter box. For more information about AppsFlyer's Attribution Link Structure and Parameters.

Retargeting settings

When enabled, AppsFlyer recognizes a link as a retargeting attribution link, rather than a user acquisition link, by adding the &is_retargeting=true to a click recording link or an impression recording link. Attribution link parameter: is_retargeting.

The following setup below is displayed when retargeting is enabled.

1. Standard Link vs. OneLink

Select standard attribution link option if:

You don't need to deep link with the URL or

Plan to use only URI schemes for deep linking

select Use OneLink for:

Using a single link for both Android and iOS apps or

Deep linking using Universal or app links

Note that selecting OneLink changes the click recording link from app specific to a OneLink URL.

2. Deep Link URL

Use this field if the link is meant to deep link users to any specific activity within your app. Attribution link parameter: af_dp You can find more information about AppsFlyer's Deep Linking solution in this guide.

3. Re-engagement Window

Set the time period following the re-engagement, where the user's in-app events are attributed to the retargeting media source. You can set the value in days (1-90), hours (up to 23), or even lifetime.

Attribution link parameter: af_reengagement_window

Click-through attribution

This slider allows you to set the maximum time from click to install. Only installs (first launches) that take place within the lookback window may be attributed to Liftoff.

Attribution link parameter: af_click_lookback

More details about the click lookback window here.

Click attribution link

This is the attribution link that contains all the setup information you have set for it. Send it to Liftoff to be activated when leads click on a corresponding ad.

View-through attribution lookback window

This slider allows you to set the maximum time from impression to install. Only installs (first launches) that take place within this lookback window, following an ad impression, are attributed to Liftoff, providing there was no other relevant ad click.

You can customize this value to 1-23 hours or 1-7 days.

Attribution link parameter: af_viewthrough_lookback

More details about the view-through attribution here.

Impressions attribution link

The impression attribution link contains similar attribution data to the click recording link (besides the different lookback window). Send it to Liftoff to be activated when a corresponding ad is watched, usually for 1 second or more.

Cost tab

AppsFlyer can get cost (ad spend) details directly from Liftoff. Liftoff provides data with the following dimensions:Media Source, campaign, geo, and ad.

Before you begin ensure that you haveLiftoff reporting API credentials, to get Liftoff cost data. To get the credentials, contact your Liftoff CSM.

To enable getting cost details from Liftoff:

In the Cost tab, enable Get Cost Data.

Complete the API credentials provided by Liftoff. Note: The credentials differ to those of your Liftoff dashboard credentials.

Test the connection, click Test Connection.

Ensure that the Cost API Status indicator is Active.

Ad revenue tab

Ad Revenue data is not supported by this partner.

Permissions tab

In this tab, you can select the permissions to grant Liftoff. Note that even if attribution is disabled for Liftoff, the permissions tab is active and you can grant control to Liftoff.

Use these toggles to give the ad network permissions to handle its own configuration for your app:

Ad network permissions

Allow to configure integration - permit the partner to setup the integration tab (except in-app event postbacks)

Allow to configure in-app event postbacks - permit the partner to setup in-app event postbacks mapping to itself on the integration tab

Allow access to your retention report

Allow access to your Protect360 dashboard - only to the partner's own Protect360 data, and providing the feature is enabled for the advertiser

Learn more about granting ad network permissions.

Agency permissions

Use these toggles to give the agency permissions to handle its own configuration for your app:

Main toggle - Set to On to reveal the agency permissions options

Allow to configure in-app event postbacks - permit the agency to setup in-app event postbacks mapping to itself on the integration tab

Allow access to aggregate organic data

Allow access to your retention report - only to the agency's own retention data

Learn more about granting .

What's changing: Granularity of ad revenue attribution data provided by ironSource to AppsFlyer by integration API

Where is it changing: Aggregate LTV data

Publication date: December 10, 2019

Who is impacted: App owners who implement ironSource ad revenue mediation in AppsFlyer

For more information about Ad revenue attribution

Before the change

ironSource reports ad revenue to AppsFlyer using aggregate granularity. This means that revenue is reported per day broken down by geo.Appsflyer derives the effective revenue per action (eRPA) bydividing the revenue with the number of instances of a trigger event. Using this the revenue is attributed to the UA source. This method is less precise than user-level granularity

After the change

The AppsFlyer integration with ironSource supportsuser-level granularityand aggregate granularity. App owners can choose either granularity.

User-level granularity;IronSource reports the revenue per day at the user level. This enables superior precision when attributing the ad revenue to the original UA source. This means that app owners are better able to assess user LTV and campaign ROI.

This change does not provide user-level data in raw data reports and postbacks

What you need to do to prepare for the change

The best practice is to implement user-level granularity. Aggregate granularity remains unchanged.

Migrating from aggregate granularity to user-level granularity:

Before you begin:

Disable ad revenue integration with AppsFlyer integrated partners that mediate through ironSource.

Caution

If you do not disable the integrations ad revenue displays in duplicate in the Dashboard.

To migrate from aggregate granularity to user-level granularity:

In AppsFlyer, go toConfiguration>Integrated partners.

Select ironSource.

Go to theAd Revenuetab.

SelectUser Level integration.

Complete the fields:

Refresh Token.

Secret key.

App ID.

ClickSave Ad RevenueUser-level ad revenue collection is now active.

What's New See in AppsFlyer.

At a glance: Using pull APIs you can get CSV files of reports by using URL links that contain the query parameters. Pull API reports contain either aggregated or raw data.

CSV reports can be delivered using Pull APIs and also by Download, Email, and Data locker *

The method you use depends on the report size and frequency you use the same report. In general, for reports, you need ad-hoc use the download/email method.

Pull API is for use by advertisers and agencies.

See also:

About choosing between API and Data locker

The benefits of using Push API and Pull API together

You can create the API link manually as described in this document or ready prepared in AppsFlyer. To get the prepared API: GotoIntegration > API access. (Note: When the admin user in AppsFlyer changes so does the API key)

If you use the manual creation method for the creating of the API link then ensure that:

Parameters are in lowercase as they are case-sensitive.

You don't specify the same field twice in the same URL. Doing so results in an empty file being downloaded.

Notes:

Changing the AppsFlyer account admin: Pull API links require an API key which is generated when the AppsFlyer account is first created. If the account admin changes then the API also changes. This means, for example, that if you have pull API URLs contained in scripts, and the account owner changes you need to update the pull API URL with the new API key.

Parameters are in lowercase as they are case-sensitive.

Don't specify the same field twice in the same URL. Doing so results in an empty file being downloaded.

* An AppsFlyer premium feature

API parameters (required)

api_token

Is the user's external API Authorization Key: "{Account owner API Key should be used}"

from

The date range meaning differs according to report type as follows: Aggregate: LTV, Raw data: Activity, Retargeting: Activity. Start date in the format of "yyyy-mm-dd" or "yyyy-mm-dd hh:mm". For example: 2010-01-01 or 2010-01-01%2000%3A15 - (The hours parameter is for raw reports only).

to

End date. Same format as from

API filtering parameters (optional)

Filter by media source

Filtering the reports to list only a specific media source is available by adding both the category and media source parameters to the request URL:

category

To get Facebook data set category=facebook on the URL. To get Twitter data set category=twitter on the URL. For any other specific media source set category=standard

media_source

Supply the name of a single media source (media_source=[SOURCE_NAME]) as it appears on AppsFlyer dashboard.

Examples

1: Google Adwords Filtered Report

https://hq.appsflyer.com/export/com.greatapp/installs_report/v5?api_token=xxxx

&from=2018-04-09&to=2018-05-09&category=standard&media_source=googleadwords_int

2: Facebook Filtered Report

https://hq.appsflyer.com/export/com.greatapp/installs_report/v5?api_token=xxxx

&from=2018-04-09&to=2018-05-09&category=facebook&media_source=facebook

Filter by event name

Filter the raw in-app events report data to include only a specific event, by using the event_name parameter. To filter multiple events use a comma separated list of events.

For example: event_name=af_purchase,ftd

For retargeting exports

Use reattr=true to get results attributed to retargeting campaigns.

Additional fields

Through Pull API you can add some fields, that complete the picture for raw data installs and in-app events in some cases.

To add new fields add "&additional_fields=" to the API link, followed by the comma-separated list of additional fields. See the Pull API examples below.

The result is a CSV report with added columns, that contain information when relevant.

Field name

Relevant for

rejected_reason rejected_reason_value

Validation Rules

blocked_reason blocked_reason_value blocked_sub_reason blocked_reason_rule

Protect360 (Anti-Fraud solution)

install_app_store

Out-of-store Android markets

custom_data

Retrieving custom data

gp_referrer

Google Play field - click here for more info.

gp_click_time

Google Play field - click here for more info.

gp_install_begin

Google Play field - click here for more info.

keyword_match_type

The keyword match type returns by search networks APIs or attribution links shall be mapped to the raw report.

Note: Google AdWords and Apple Search Ads are the only networks that return this parameter for search campaigns.

network_account_id

Media Source Account ID

gp_broadcast_referrer

Google Play Broadcast Referrer

amazon_aid

Amazon Fire ID

Time zone and currency

timezone (optional)

You can get the Pull API raw data in ANY valid time zone:

Add &timezone=[Joda-Time] in the Pull API link to receive the report in the preferred timezone (see note below)

Add &timezone=[Numerical value] in the Pull API link to receive the report in the specified numerical timezone. For example: for time zone UTC+10:00 add on the link &timezone=%2B10:00 Using numeric value for timezone is only possible when pulling raw data reports. It doesn't work with aggregate reports like performance reports.

Otherwise the data is received in the default UTC time zone.

Notes

1. Joda-Time time zone format takes into account daylight saving time.

2. The Joda-Time value MUST be identical to the possible values in the app settings page. For example, if you wish to get data in France's time zone, check the time zone list in the app settings page, which is "Europe/Paris" for France. The timezone value in the Pull API URL should be &timezone=Europe%2fParis. Pulling data in the selected time zone is only available from the date when the time zone setting was made. Any data prior to the date of the change, is shown as default GMT.

currency (optional)

Is used to receive the Revenue and Cost data in your selected currency, rather than in USD, which is the default option. This is set by the account admin.

To receive the data in your preferred currency, please add the following to your request link: &currency=preferred

is used to receive Revenue and Cost data in your selected currency.

Note

Generally, the Pull API URLs do not need to be encoded. However, if using parameters that have non-URL compatible values, you will need to URL encode them. For example, using hours and time zone parameters.

API policy and usage limitations

AppsFlyer API Policy ensures high quality of service to the users of pull API by limiting the total number of daily requests and preventing abuse of the service.

See details about the API policy for aggregated data via Pull API and for raw data via Pull API.

The maximum number of records per report is 200K. If you get a report that has 200K rows then you have some results that were left out.

Tip

If your daily results exceed 200K rows you can split your files according to the date AND the time of day, using the "yyyy-mm-dd hh:mm" date/time format in thefromandtoparameters on the Pull API URL. For example - an app owner has up to 300K new daily installs from all sources. The app owner decides to split the daily Pull API calls to 2 calls every 12 hours. The first URL call includes from=yyyy-mm-dd 00:00&to= yyyy-mm-dd 11:59 and the second from=yyyy-mm-dd 12:00&to= yyyy-mm-dd 23:59 (before encoding)

Note

By default, the Pull API Performance Report shows Facebook data at campaign level only. Add "&category=facebook" to enable the report to present Facebook information at both the Ad Set and Ad level. This is relevant for Facebook only.

API security

All Pull API links use secure encrypted http s connections.

Pull API link examples

You can get the exact API code including the API token in AppsFlyer. Go to Integration > API Access.

Report Category

Report Type

Link Example

Raw data reports

Installs report

https://hq.appsflyer.com/export/{App ID here}/installs_report/v5?api_token=<API TOKEN HERE>&from=yyyy-mm-dd&to=yyyy-mm-dd

Retargeting conversions report

https://hq.appsflyer.com/export/id578915438/installs_report/v5?api_token=<API TOKEN HERE>&from=yyyy-mm-dd&to=yyyy-mm-dd&additional_fields=install_app_store,contributor1_match_type,contributor2_match_type,contributor3_match_type,match_type,device_category,gp_referrer,gp_click_time,gp_install_begin,amazon_aid,keyword_match_type&reattr=true

In-app events report

See: Filter by event name

https://hq.appsflyer.com/export/{App ID here}/in_app_events_report/v5?api_token=<API TOKEN HERE>&from=yyyy-mm-dd&to=yyyy-mm-dd

Retargeting in-app events report

See: Filter by event name

https://hq.appsflyer.com/export/id578915438/in_app_events_report/v5?api_token=<API TOKEN HERE>&from=yyyy-mm-dd&to=yyyy-mm-dd&additional_fields=install_app_store,contributor1_match_type,contributor2_match_type,contributor3_match_type,match_type,device_category,gp_referrer,gp_click_time,gp_install_begin,amazon_aid,keyword_match_type&reattr=true

Uninstalls report

https://hq.appsflyer.com/export/{App ID here}/uninstall_events_report/v5?api_token=<API TOKEN HERE>&from=yyyy-mm-dd&to=yyyy-mm-dd

Organic installations report

https://hq.appsflyer.com/export/{App ID here}/organic_installs_report/v5?api_token=<API TOKEN HERE>&from=yyyy-mm-dd&to=yyyy-mm-dd

Organic in-app events report

See: Filter by event name

https://hq.appsflyer.com/export/{App ID here}/organic_in_app_events_report/v5?api_token=<API TOKEN HERE>&from=yyyy-mm-dd&to=yyyy-mm-dd

Validation rules reports

Invalid installs report

https://hq.appsflyer.com/export/{App ID here}/invalid_installs_report/v5?api_token=<API TOKEN HERE>&from=yyyy-mm-dd&to=yyyy-mm-dd&additional_fields=rejected_reason,rejected_reason_value

Invalid in-app events report

See: Filter by event name

https://hq.appsflyer.com/export/{App ID here}/invalid_in_app_events_report/v5?api_token=<API TOKEN HERE>&from=yyyy-mm-dd&to=yyyy-mm-dd&additional_fields=rejected_reason,rejected_reason_value

Protect360

Post-attribution raw data fraud

https://hq.appsflyer.com/export/{App ID here}/detection/v5?api_token=<APITOKEN HERE>&from=yyyy-mm-dd&to=yyyy-mm-dd&additional_fields=install_app_store,match_type,contributor1_match_type,contributor2_match_type,contributor3_match_type,device_category,gp_referrer,gp_click_time,gp_install_begin,fraud_reason,fraud_sub_reason,fraud_reasons,install_time_tz,detection_date&detect-from=yyyy-mm-dd&detect-to=yyyy-mm-dd

Note regarding date parameters: From/to: is the install date range limited to one calendar month. detect-from/detect-to: is the date of the detction and is limited to the seventh day of the calendar month following the installation.

API version V5

Unchanged:

The existing API (v4) is still available for use

The version does not apply any change to the file format or headers

Aggregated (performance) reports provide details of the effectiveness of advertising campaigns. These reports may be either LTV or activity based so check the report specification.

API parameters (required)

api_token

Is the user's external API Authorization Key: "{Account owner API Key should be used}". The API token is displayed ONLY to the account owner

API filtering parameters (optional)

Filter by media source

Filtering the reports to list only a specific media source is available by adding both the category and media source parameters to the request URL:

category

To get Facebook data set category=facebook on the URL. For any other specific media source set category=standard

media_source

Supply the name of a single media source (media_source=[SOURCE_NAME]) as it appears on AppsFlyer dashboard.

Examples

1: Google Adwords Filtered Report

https://hq.appsflyer.com/export/com.greatapp/partners_report/v5?api_token=xxxx

&from=2018-04-09&to=2018-05-09&category=standard&media_source=googleadwords_int

2: Facebook Filtered Report

https://hq.appsflyer.com/export/com.greatapp/partners_report/v5?api_token=xxxx

&from=2018-04-09&to=2018-05-09&category=facebook&media_source=facebook

For retargeting exports

Use reattr=true to get results attributed to retargeting campaigns.

Important!

The date range and media source filters might affect which event columns appear in the report.

If you consume the data and push it into your BI systems, make sure to account for possible differences in the event columns that appear in the report.

Time zone and currency

timezone (optional)

You can get the aggregated data via Pull API in either UTC or the app's preferred time zone, which is set in the App Settings page:

1. Add &timezone=[selected Joda-Time] in the Pull API link to receive the report in the app's preferred timezone (see note below)

2. Otherwise the data is received in the default UTC time zone.

Notes

1. Joda-Time time zone format takes into account daylight saving time.

2. The Joda-Time value MUST be identical to the value set in the app settings page. For example, if the selected time zone in the app settings is "Europe/Paris", the timezone value in the Pull API URL should be &timezone=Europe%2fParis

encrypted https

currency (optional)

Is used to receive the Revenue and Cost data in your selected currency, rather than in USD, which is the default option. This is set by the account admin.

currency=preferred

is used to receive Revenue and Cost data in your selected currency.

Note

Generally, the Pull API URLs do not need to be encoded. However, if using parameters that have non-URL compatible values, you will need to URL encode them. For example, using hours and time zone parameters.

API policy

AppsFlyer API Policy ensures high quality of service to the users of pull API by limiting the total number of daily requests and preventing abuse of the service.

The maximum number of records per report is 200K. If you get a report that has 200K rows then you have some results that were left out.

Tip

If your daily results exceed 200K rows you can split your files according to the date AND the time of day, using the "yyyy-mm-dd hh:mm" date/time format in the from and to parameters on the Pull API URL. For example - an app owner has up to 300K new daily installs from all sources. The app owner decides to split the daily Pull API calls to 2 calls every 12 hours. The first URL call includes from=yyyy-mm-dd 00:00&to= yyyy-mm-dd 11:59 and the second from=yyyy-mm-dd 12:00&to= yyyy-mm-dd 23:59 (before encoding)

Note

By default, the Pull API Performance Report show Facebook data at campaign level only. Add "&category=facebook" to enable the report to include Facebook information at both the Ad Set and Ad level. This is relevant for Facebook only.

API security

All Pull API links use secure encrypted https connections.

For more details go here.

Pull API link examples

Report category

Report name

Link example

Performance reports

Partners (media source)

(LTV)

https://hq.appsflyer.com/export/{App ID here}/partners_report/v5?api_token=<API TOKEN HERE>&from=yyyy-mm-dd&to=yyyy-mm-dd

Partners by date (LTV)

https://hq.appsflyer.com/export/{App ID here}/partners_by_date_report/v5?api_token=<API TOKEN HERE>&from=yyyy-mm-dd&to=yyyy-mm-dd

Daily

(LTV)

https://hq.appsflyer.com/export/{App ID here}/daily_report/v5?api_token=<API TOKEN HERE>&from=yyyy-mm-dd&to=yyyy-mm-dd

Geo (LTV)

https://hq.appsflyer.com/export/{App ID here}/geo_report/v5?api_token=<API TOKEN HERE>&from=yyyy-mm-dd&to=yyyy-mm-dd

Geo by date (LTV)

https://hq.appsflyer.com/export/{App ID here}/geo_by_date_report/v5?api_token=<API TOKEN HERE>&from=yyyy-mm-dd&to=yyyy-mm-dd

Retargeting Reports

Partners (Activity)

https://hq.appsflyer.com/export/{App ID here}/partners_report/v5?api_token=<API TOKEN HERE>&from=yyyy-mm-dd&to=yyyy-mm-dd&reattr=true

Partners by date

(Activity)

https://hq.appsflyer.com/export/{App ID here}/partners_by_date_report/v5?api_token=<API TOKEN HERE>&from=yyyy-mm-dd&to=yyyy-mm-dd&reattr=true

Daily

(Activity)

https://hq.appsflyer.com/export/{App ID here}/daily_report/v5?api_token=<API TOKEN HERE>&from=yyyy-mm-dd&to=yyyy-mm-dd&reattr=true

Geo

(Activity)

https://hq.appsflyer.com/export/{App ID here}/geo_report/v5?api_token=<API TOKEN HERE>&from=yyyy-mm-dd&to=yyyy-mm-dd&reattr=true

Geo By Date

(Activity)

https://hq.appsflyer.com/export/{App ID here}/geo_by_date_report/v5?api_token=<API TOKEN HERE>&from=yyyy-mm-dd&to=yyyy-mm-dd&reattr=true

API version (v5)

Changes:

In Version (v5) performance reports that contain multiple partners, group Facebook data by campaign only. Performance reports that contain Facebook data only (by specifying &category=facebook) group data by campaign and ad group.

Export data page for aggregated reports uses the API version (v5)

Unchanged:

The existing API (v4) is still available for use

The version does not apply any change to the file format or headers

Note

To use V4 Performance Reports, change v5 to v4.

For example, the v5 (in red) should be changed to v4.

https:// hq.appsflyer.com/export/i {app_ id}/geo_report/v5?api_token={ api_token}&from={from_date}& to={to_date}

Protect360 aggregated data as it appears in the advanced detection table in the dashboard.

API parameters (required)

api_token

Is the user's external API Authorization Key: "{Account owner API Key should be used}"

from

Report start date in the format of "yyyy-mm-dd" or "yyyy-mm-dd hh:mm". For example: 2010-01-01 or 2010-01-01%2000%3A15 - (The hours parameter is for raw reports only).

to

Report end date. Same format as from

KPIs (required)

Protect360 parameters are the same in Pull API and Master API.

For the list of available KPIs and their descriptions, go here.

API filtering parameters (optional)

Filter by media source

Filtering the reports to list only a specific media source is available by adding: pid=media source name.

Time zone and currency

timezone (optional)

You can get the Protect360 aggregated data via Pull API in either UTC or the app's preferred time zone, which is set in the App Settings page:

1. Add &timezone=preferred in the Pull API link to receive the report in the app's preferred timezone

2. Otherwise the data is received in the default UTC time zone.

currency (optional)

Is used to receive the Revenue and Cost data in your selected currency, rather than in USD, which is the default option. This is set by the account admin.

currency=preferred

is used to receive Revenue and Cost data in your selected currency.

Note

Generally, the Pull API URLs do not need to be encoded. However, if using parameters that have non-URL compatible values, you will need to URL encode them. For example, using hours and time zone parameters.

API security

All Pull API links use secure connections.

Pull API link examples

Note: To see all the available pull API links: In Appsflyer, go to, Integration > Api access.

Report Category

Report Type

Link

P360 - Aggregated Advanced Detection Reports

Partners Report

https://hq1.appsflyer.com/master/p360/reports/v4?api_token=<API Token>&app_id=<APP_ID>&from=yyyy-mm-dd&to=yyyy-mm-dd&groupings=pid,af_siteid&kpis=protect360_total_installs,install_fraud_new_devices_installs,install_fraud_new_devices_installs_rate,install_fraud_new_devices_loyal_user_rate,install_fraud_lat_devices_installs,install_fraud_lat_devices_install_rate,install_fraud_lat_devices_loyal_user_rate,install_fraud_suspicious_devices_installs,install_fraud_suspicious_devices_install_rate,install_fraud_suspicious_devices_loyal_user_rate,install_fraud_clean_device_installs,install_fraud_clean_device_install_rate,install_fraud_clean_device_loyal_user_rate,clicks,cr,click_flood_under_5_min_rate,click_flood_from_5_to_60_min_rate,click_flood_over_60_min_rate,contribution_rate,install_hijacking_up_to_10_sec_rate,install_hijacking_10_to_30_sec_rate,install_hijacking_over_30_sec_rate

Partners Daily Reports

https://hq1.appsflyer.com/master/p360/reports/v4?api_token=<API-TOKEN>&app_id=<APP_ID>&from=yyyy-mm-dd&to=yyyy-mm-dd&groupings=pid,af_siteid,install_time&kpis=protect360_total_installs,install_fraud_new_devices_installs,install_fraud_new_devices_installs_rate,install_fraud_new_devices_loyal_user_rate,install_fraud_lat_devices_installs,install_fraud_lat_devices_install_rate,install_fraud_lat_devices_loyal_user_rate,install_fraud_suspicious_devices_installs,install_fraud_suspicious_devices_install_rate,install_fraud_suspicious_devices_loyal_user_rate,install_fraud_clean_device_installs,install_fraud_clean_device_install_rate,install_fraud_clean_device_loyal_user_rate,clicks,cr,click_flood_under_5_min_rate,click_flood_from_5_to_60_min_rate,click_flood_over_60_min_rate,contribution_rate,install_hijacking_up_to_10_sec_rate,install_hijacking_10_to_30_sec_rate,install_hijacking_over_30_sec_rate

Geo Report

https://hq1.appsflyer.com/master/p360/reports/v4?api_token=<API-Token>&app_id=<APP_ID>&from=yyyy-mm-dd&to=yyyy-mm-dd&groupings=geo&kpis=protect360_total_installs,install_fraud_new_devices_installs,install_fraud_new_devices_installs_rate,install_fraud_new_devices_loyal_user_rate,install_fraud_lat_devices_installs,install_fraud_lat_devices_install_rate,install_fraud_lat_devices_loyal_user_rate,install_fraud_suspicious_devices_installs,install_fraud_suspicious_devices_install_rate,install_fraud_suspicious_devices_loyal_user_rate,install_fraud_clean_device_installs,install_fraud_clean_device_install_rate,install_fraud_clean_device_loyal_user_rate,clicks,cr,click_flood_under_5_min_rate,click_flood_from_5_to_60_min_rate,click_flood_over_60_min_rate,contribution_rate,install_hijacking_up_to_10_sec_rate,install_hijacking_10_to_30_sec_rate,install_hijacking_over_30_sec_rate

Geo Daily Report

https://hq1.appsflyer.com/master/p360/reports/v4?api_token=<API-TOKEN>&app_id=<APP_ID>&from=yyyy-mm-dd&to=yyyy-mm-dd&groupings=geo,install_time&kpis=protect360_total_installs,install_fraud_new_devices_installs,install_fraud_new_devices_installs_rate,install_fraud_new_devices_loyal_user_rate,install_fraud_lat_devices_installs,install_fraud_lat_devices_install_rate,install_fraud_lat_devices_loyal_user_rate,install_fraud_suspicious_devices_installs,install_fraud_suspicious_devices_install_rate,install_fraud_suspicious_devices_loyal_user_rate,install_fraud_clean_device_installs,install_fraud_clean_device_install_rate,install_fraud_clean_device_loyal_user_rate,clicks,cr,click_flood_under_5_min_rate,click_flood_from_5_to_60_min_rate,click_flood_over_60_min_rate,contribution_rate,install_hijacking_up_to_10_sec_rate,install_hijacking_10_to_30_sec_rate,install_hijacking_over_30_sec_rate

Partners Campaign Report

https://hq1.appsflyer.com/master/p360/reports/v4?api_token=<API_TOKEN>&app_id=<APP_ID>&from=yyyy-mm-dd&to=yyyy-mm-dd&groupings=pid,af_siteid,c&kpis=protect360_total_installs,install_fraud_new_devices_installs,install_fraud_new_devices_installs_rate,install_fraud_new_devices_loyal_user_rate,install_fraud_lat_devices_installs,install_fraud_lat_devices_install_rate,install_fraud_lat_devices_loyal_user_rate,install_fraud_suspicious_devices_installs,install_fraud_suspicious_devices_install_rate,install_fraud_suspicious_devices_loyal_user_rate,install_fraud_clean_device_installs,install_fraud_clean_device_install_rate,install_fraud_clean_device_loyal_user_rate,clicks,cr,click_flood_under_5_min_rate,click_flood_from_5_to_60_min_rate,click_flood_over_60_min_rate,contribution_rate,install_hijacking_up_to_10_sec_rate,install_hijacking_10_to_30_sec_rate,install_hijacking_over_30_sec_rate

API version (v5)

Changes:

In Version (v5) performance reports that contain multiple partners, group Facebook data by campaign only. Performance reports that contain Facebook data only (by specifying &category=facebook) group data by campaign and ad group.

Export data page for aggregated reports uses the API version (v5)

Unchanged:

The existing API (v4) is still available for use

The version does not apply any change to the file format or headers

Note

To use V4 Performance Reports, change v5 to v4.

For example, the v5 (in red) should be changed to v4.

https://hq.appsflyer.com/export/i{app_ id}/geo_report/v5?api_token={ api_token}&from={from_date}& to={to_date}

Scripts to retrieve data from Pull API

Often times it is more convenient to setup automated scripts to retrieve data periodically.

Below you can find scripts to retrieve data from pull API. The sample scripts pull data from the install report. Edit the scripts to fit your requirements in terms of what report and what data you wish to retrieve.

JavaNode JSPythonC#PHP

import okhttp3.*;

import java.io.BufferedWriter;

import java.io.FileWriter;

import java.util.concurrent.TimeUnit;

public class PullApi {

public static void main(String[] args){

String appID = "<APP_ID>";

String reportType = "<REPORT_TYPE>";

String apiToken = "<API_TOKEN>";

String from = "<FROM_DATE>";

String to = "<TO_DATE>";

String requestUrl = "https://hq.appsflyer.com/export/" + appID + "/" + reportType + "/v5?api_token=" + apiToken + "&from=" + from + "&to=" + to;

OkHttpClient client = new OkHttpClient.Builder()

.connectTimeout(30, TimeUnit.SECONDS)

.readTimeout(30, TimeUnit.SECONDS)

.build();

Request request = new Request.Builder()

.url(requestUrl)

.addHeader("Accept", "text/csv")

.build();

try {

Response response = client.newCall(request).execute();

if(response.code() != 200) {

if(response.code() == 404) {

System.out.println("There is a problem with the request URL. Please make sure it is correct");

}

else {

assert response.body() != null;

System.out.println("There was a problem retrieving the data: " + response.body().string());

}

} else {

assert response.body() != null;

String data = response.body().string();

BufferedWriter writer;

writer = new BufferedWriter(new FileWriter(appID + "-" + reportType + "-" + from + "-to-" + to + ".csv"));

writer.write("");

writer.write(data);

writer.close();

}

System.exit(0);

} catch (Exception e) {

e.printStackTrace();

System.exit(1);

}

}

}

request = require('request');

const fs = require('fs');

const appID = '<APP_ID>';

const reportType = '<REPORT_TYPE>';

const apiToken = '<API_TOKEN>';

const from = '<FROM_DATA>';

const to = '<T0_DATE>';

const requestUrl = `https://hq.appsflyer.com/export/${appID}/${reportType}/v5?api_token=${apiToken}&from=${from}&to=${to}`;

request(requestUrl, (error, response, body) => {

if (error) {

console.log('There was a problem retrieving data:', error);

}

else if (response.statusCode != 200) {

if (response.statusCode === 404) {

console.log('There is a problem with the request URL. Make sure that it is correct');

} else {

console.log('There was a problem retrieving data:', response.body);

}

} else {

fs.writeFile(`${appID}-${reportType}-${from}-to-${to}.csv`, response.body, (err) => {

if (err) {

console.log('There was a problem writing to file: ', err);

} else {

console.log('File was saved');

}

});

}

});

import requests

app_id = '<APP_ID>'

report_type = '<REPORT_TYPE>'

params = {

'api_token': '<API_TOKEN>',

'from': 'FROM_DATE',

'to': 'TO_DATE'

}

request_url = 'https://hq.appsflyer.com/export/{}/{}/v5'.format(app_id, report_type)

res = requests.request('GET', request_url, params=params)

if res.status_code != 200:

if res.status_code == 404:

print('There is a problem with the request URL. Make sure that it is correct')

else:

print('There was a problem retrieving data: ', res.text)

else:

f = open('{}-{}-{}-to-{}.csv'.format(app_id, report_type, params['from'], params['to']), 'w', newline='', encoding="utf-8")

f.write(res.text)

f.close()

using System;

using RestSharp;

using System.Text;

using System.Net;

using System.IO;

namespace Pull_API

{

class PullAPi

{

static void Main(string[] args)

{

var appID = "<APP_ID>";

var reportType = "<REPORT_TYPE>";

var apiToken = "<API_TOKEN>";

var from = "<FROM_DATE>";

var to = "<TO_DATE>";

var requestUrl = "https://hq.appsflyer.com/export/" + appID + "/" + reportType + "/v5?api_token=" + apiToken + "&from=" + from + "&to=" + to;

var client = new RestClient(requestUrl);

var request = new RestRequest(Method.GET);

request.AddHeader("Accept", "text/csv; charset=UTF-8");

IRestResponse response = client.Execute(request);

HttpStatusCode statusCode = response.StatusCode;

int numericStatusCode = (int)statusCode;

if(numericStatusCode != 200){

if(numericStatusCode == 404){

Console.WriteLine("There is a problem with the request URL. Make sure that it is correct.");

} else {

Console.WriteLine("There was a problem retrieving data: " + response.Content);

}

} else {

System.IO.File.WriteAllText(@"" + appID + "-" + reportType + "-" + from + "-to-" + to + ".csv", response.Content);

Console.WriteLine("Data retrieved succesfully");

}

}

}

}

<?

$appID = '<APP_ID>';

$reportType = '<REPORT_TYPE>';

$apiToken = '<API_TOKEN>';

$from = '<FROM_DATE>';

$to = '<TO_DATE>';

$query = http_build_query([

'api_token' => $apiToken,

'from' => $from,

'to' => $to

]);

$requestUrl = 'https://hq.appsflyer.com/export/' . $appID . '/' . $reportType . '/v5?'.$query;

$report = $appID . '-' . $report . '-' . $from . '-to-' . $to;

$curl = curl_init($requestUrl);

curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);

curl_setopt($curl, CURLOPT_ENCODING, "");

curl_setopt($curl, CURLOPT_NOSIGNAL, true);

curl_setopt($curl, CURLOPT_FOLLOWLOCATION, true);

curl_setopt($curl, CURLOPT_MAXREDIRS, 10);

curl_setopt($curl, CURLOPT_FAILONERROR, true);

curl_setopt($curl, CURLOPT_TIMEOUT, 100);

curl_setopt($curl, CURLOPT_CUSTOMREQUEST, "GET");

curl_setopt($curl, CURLOPT_HTTPHEADER, array(

"cache-control: no-cache",

"Accept: text/csv; charset=UTF-8"

));

$response = curl_exec($curl);

$info = curl_getinfo($curl);

$err = curl_error($curl);

curl_close($curl);

var_dump($response);

if ($err) {

echo $info['http_code'];

echo "cURL Error #: " . $err . '. ';

if ($info['http_code'] == 404) {

echo 'There is a problem with the request URL. Make sure that it is correct';

}

if ($info['http_code'] == 401) {

echo 'There was a problem retrieving data: authentication failed.';

}

echo PHP_EOL;

} else {

$fp = fopen($report, 'w+');

fwrite($fp, $response);

fclose($fp);

echo $response;

}

?>

API errors and troubleshooting

This section discusses common API erros and how to handle them.

An empty CSV file is downloaded

If the pull requests generates an empty CSV file, it means that a certain field appears on the URL more than once.

The supplied API token is invalid

Error message

The supplied API token is invalid

Error code

401

Description

The server could not authenticate the request. The API token is either missing or invalid.

How to solve

Make sure that the URL contains the correct API token. The API token is passed in the api_token parameter.

API querying date range is limited to past 3 months

Error message

The server could not comply with the request since it is either malformed or otherwise incorrect.

API querying date range is limited to past 3 months

Error code

400

Description

This error messages is returned when you try to query data that spans over a 3-month range.

How to solve

Make sure to limit the date range to 3 months or less using the to and from parameters.

Description of downloadable reports available as CSV files

The reports described here are available for export as CSV files by download, email, API and Data locker.

Report types

Reports are either aggregate (aka performance) orraw data. Aggregate reports are calculated using either the:

Activity date: means the date the event took place.

Lifetime value (LTV) : means users who installed the app during the report date range. It includes the events related to these users on any date after the install date. To clarify, the report includes events that occur after the last date in the report date range.

The earliest date that a report can contain is:

Aggregate:The date of the first app install recorded in AppsFlyer

Raw data:up to 90 days before today. For example, if today is December 29, then the earliest date is October 1.

Conversion type: Reports contain at least one of the following conversion (acquisition) types:

Organic

Non-organic

Data freshness: Reports are near-real-time with a typical delay of up to 15 minutes.

Descriptions of the reports

The descriptions that follow, are structured, according to the Reports > Export data page in AppsFlyer.

Performance reports

This section contains:

The list of aggregate reports

Examples of the reports

List of fields contained in each report

UA Aggregate data reports

Report name

Grouped by

LTV/ Activity

Organic

Non -organic

Pull API name

Partners (media sources)

Agency, media source, campaign

LTV

Yes

Yes

partners_report

Partners by date

Date, agency, media source, campaign

LTV

Yes

Yes

partners_by_date_report

Activity by date

Date, agency, media source, campaign

LTV

Yes

Yes

daily_report

Geo

Country, agency, media source, campaign

LTV

Yes

Yes

geo_report

Geo by date

Date, country, agency, media source, campaign

LTV

Yes

Yes

geo_by_date_report

Note: If Facebook is themedia sourceselected then additional fields are included in the report: Adgroup ID, Adgroup name, Adset ID, Adset Name

Example of aggregate reports in CSV files.

Note about date fields in CSV files: Date fields in the CSV files have the format yyyy-mm-dd. When you open a CSV file in Excel, date fields are formatted using your computer's date and time settings. Be sure to select the appropriate date display in Excel.

Examples of aggregate reports

Partners (media source) LTV aggregate report

Partners by date LTV aggregate report

Daily activity LTV aggregate report

Geo LTV aggregate report

Geo by date LTV aggregate report

Fields in the aggregate reports

Report name

Field

Description

Partner (media source)

Partner by date

Daily

Geo

Geo by date

Country

Installation country

Yes

Yes

Date

Attribution date

Yes

Yes

Yes

Agency/PMD (af_prt)

Agency/partner Name

Yes

Yes

Yes

Yes

Yes

Media Source (pid)

Media source that generates the install (pid=media source)

Yes

Yes

Yes

Yes

Yes

Campaign

Campaign name

(c= campaign name)

Yes

Yes

Yes

Yes

Yes

Campaign ID

Facebook campaign ID

FB only

FB only

FB only

FB only

FB only

Adgroup ID

Facebook ad group ID

FB only

FB only

FB only

FB only

FB only

Adgroup Name

Facebook ad group

FB only

FB only

FB only

FB only

FB only

Adset ID

Facebook adset ID

FB only

FB only

FB only

FB only

FB only

Adset Name

Facebook adset name

FB only

FB only

FB only

FB only

FB only

ARPU

Average revenue per user

Yes

Yes

Yes

Yes

Average eCPI

The average eCPI

Yes

Clicks

Number of clicks

Yes

Yes

Yes

Yes

Yes

Conversion Rate

Number of installs/number of clicks

Yes

Yes

Yes

Yes

Yes

CTR

Click-through Rate

Yes

Yes

{your event name}(Unique users)

Number of unique users who performed the event

Yes

Yes

Yes

Yes

{your event name} (Event counter)

Event counter

Yes

Yes

Yes

Yes

{your event name} (Sales in USD)

Event sales in USD

Yes

Yes

Yes

Yes

Impressions

Number of impressions

Yes

Yes

Installs

Number of installs

Yes

Yes

Yes

Yes

Yes

Loyal Users

(default) User who opens the app more than 3 times

Yes

Yes

Yes

Yes

Yes

Loyal Users/Installs

Percentage of loyal users from non-organic installs

Yes

Yes

ROI

Return on investment

Yes

Yes

Sessions

Number of app opens

Yes

Yes

Yes

Yes

Yes

Total Cost

Total cost

Yes

Yes

Total revenue

Total revenue generated from the media source and campaign

Yes

Yes

Yes

Yes

Note:Fields shown as FB only are included in reports where Facebook is the selectedmedia source

Raw data reports

Raw data reports are part of AppsFlyer's premium features.

Raw data reports, contain records of activities of a certain type, like non-organic installations. The reports have the following characteristics:

The date range relates to the activity (actual) date the event took place

The fields in the report are detailed in the raw data specification

Data is available for the preceding 90 days

A single download file can span a date range of up to 60 days and not more than200K rows

For reports that contain a large amount of data, download them using Data locker (an AppsFlyer premium feature)

When the report contains a large number of rows, it may take several minutes to prepare the report

Raw data activity reports

Report name

Organic

Non -organic

Additional information

Pull API name

Installations*

N/A

Yes

See using installs raw data Example report

installs_report

Installations*

Yes

N/A

See Installs (organic)

organic_installs_report

In-app events*

N/A

Yes

See using in-app raw data

in_app_events_report

In-app events*

Yes

N/A

See using in-app raw data

Retargeting in-app events*

N/A

Yes

See using in-app raw data

in_app_events_report

&reattr=true

Retargeting conversions*

N/A

Yes

See using in-app raw data

installs_repor

t&reattr=true

Uninstalls*

N/A

Yes

See uninstalls (non-organic)

uninstall_events_report

*An AppsFlyer premium report

Installations (organic) raw data report

Use this report to:

Analyze the organic install, event, device and user characteristics

Build an organic install event audience for retargeting

Notes:

Install date is based on the first launch date

Once an event occurs, it may take up to 8 hours until it is visible in the raw data report

See using installation raw data.

Uninstalls (non-organic) raw data report

Use this report to:

Analyze the uninstall event, device and user characteristics

Build an uninstall event audience for retargeting

Notes:

The uninstall event time appears in the "Event time" field. It does not represent the exact time of the uninstall event. Rather it holds the time of the periodic query to the store's cloud, upon which AppsFlyer discovered the app has been uninstalled. Therefore, the actual time of the uninstall may be up to 24 hours prior to the raw data event time. For more information, click here.

Currently, the following fields are empty: SDK Version, App Version, WIFI, Operator, Carrier, Customer User ID, IDFV, Device Type, App Name, and Bundle ID.

To ensure accurate data in the report, make sure uninstall measurement is correctly implemented in when integrating the SDK. See Uninstall Measurement.

Postback raw data reports

Postback reports contain the raw data non-organic postbacks sent to the attributed media source. The reports contain the raw data fields and additional fields as detailed in this section.

Reports are for information purposes and are not required for integration with the ad networks.

Using postback reports you can look upspecific data sent to an ad network. This information can be used, for example, as part of a dispute investigation between you, the advertiser, and an ad network.

The following installs are not included in postback reports:

Organic users even in cases where the ad network received a postback about organic installs

Installations in CPA campaigns with disabled Install postbacks

Postback raw data reports

Report name

Organic

Non -organic

Events sent to the attributed media source

Pull API name

Installation*

N/A

Yes

Non-organic installation postbacks

N/A

In-app events*

N/A

Yes

Non-organic in-app event postbacks

N/A

Conversion*

N/A

Yes

Non-organic re-engagement and reattribution conversions

N/A

In-app events conversions*

N/A

Yes

Non-organic in-app events generated from retargeting conversions

N/A

*An AppsFlyer premium report

Additional fields in postback reports

Field

Description

Postback URL

Some values, like revenue, may not appear in the appropriate field, but you can still see this data in thePostback URL

Postback method

Postback HTTP response code

200: Confirms that the postback was received by the ad network.

Postback error message

Retargeting

Retargeting conversion reports contain details of re-engagements and re-attributions. Some of the retargeting fields have different meanings than the parallel user acquisition names. See retargeting attribution guide.

Retargeting reports

Report name

Grouped by

Aggregate/ raw data

Organic

Non -organic

Pull API name

Partners (media sources)

Agency, media source, campaign

Aggregate

Yes

Yes

N/A

Partners by date

Date, agency, media source, campaign

Aggregate

Yes

Yes

N/A

Activity by date

Date, agency, media source, campaign

Aggregate

Yes

Yes

N/A

Geo

Country, agency, media source, campaign

Aggregate

Yes

Yes

N/A

Geo by date

Date, country, agency, media source, campaign

Aggregate

Yes

Yes

N/A

Conversions

N/A

Raw data

Yes

Yes

N/A

In-app events

N/A

Raw data

Yes

Yes

N/A

Blocked fraud Protect360

Blocked fraud reports provide details of events blocked by Protect360. Both aggregate and raw data reports are provided.

Field specification is the same as aggregated reports

Field specification is the same as raw data reports

Protect360 is an AppsFlyer premium feature

Events blocked by Protect360

Report name

Aggregate /Raw data

Description

LTV / Activity

Pull API name

Delivery by Email/ Download

Partners (media sources)*

Aggregate

LTV

Pull API

N/A

Partners by date*

Aggregate

LTV

Pull API

N/A

Geo*

Aggregate

LTV

Pull API

N/A

Geo by date*

Aggregate

LTV

Pull API

N/A

Partner's campaign report*

Aggregate

LTV

Pull API

N/A

Installations*

Raw data

Blocked installs with the block reason

Activity

blocked_ installs_ report

Yes

In-app events*

Raw data

Organic and non-organic in-app events performed by blocked users

Activity

blocked_in_app_ events _report

Yes

Clicks*

Raw data

Non-organic clicks performed by blocked users

Activity

blocked_clicks_ report

Yes

Installation postback*

Raw data

Postback to the media source of blocked installs

Activity

N/A

Yes

Post-attribution fraud

Raw data

Fraudulent installs

Activity

Pull API

N/A

* AppsFlyer premium report

Limitation:The blocking reason Botsdisplays even in cases where the reason should be app version or missing customer user id.

Validation Rules targeting blocked installs raw data

Targeting Validation Rules reports contain the list of rejected installations and their associated in-app events. The reports contain the fields found in raw data and have the following additional fields:

Reject reason value: Ruleset ID that caused the reject

Reject reason: Rule that caused the reject

Validation Rules targeting reports

Report name

Description

Organic

Non -organic

Pull API name

Invalid installations*

List of invalid installs

Yes

Yes

invalid_installs_

report

Invalid in-app events*

List of in-app events generated by invalid installs

Yes

Yes

invalid_in_app_

events_report

Invalid installations postbacks*

List of invalid install postbacks sent to the attributed media source

Yes

Yes

N/A

At a glance:Attribution related fraud is a significant challenge in the app industry. This fraud drains marketing budgets, pollutes marketing performance data, and can turn successful campaigns into losing ones. Protect360 provides real-time fraud protection and detection.

page

What is Protect360?

Protect360 is a fraud protection solution to prevent attribution related fraud. It consists of dynamic tools able to detect fraud and block fraudulent attribution.

By using AppsFlyer scale, machine learning, and behavioral analysis,Protect360 provides coverage against known and new forms of click/install fraud including bots and behavioral anomalies.

Protect360 guards marketers from fraud attempts at the device, publisher, and media source levels.

The following layers of protection are provided:

Real-time fraud blocking

Post-attribution

Real-time fraud blocking

The first layer of anti-fraud protection is to block the attribution of fraudulent media sources in real-time. Note: Protect360 never blocks the app install. Only fraudulent attribution events are blocked.

For details on what happens with blocked events, go here.

Post-attribution fraud

The second layer of anti-fraud protectionrelates to fraudulent events, which can only be detected after the install and real-time attribution occur.

After Protect360 identifies installs as fraudulent in retrospect, they can't be erased, but need to be treated as real fraud and not charged for.

Once a source, like an ad network, site ID, or country is identified as fraudulent:

Future clicks: from the source are blocked.

Past installs: from the start of the current calendar month until the present, are labeled as post-attribution fraud, but not erased from the data.

Past installs: from before the start of the current month, are not changed.

Examples for post-attribution fraud:

Seemingly regular installs followed by fraudulent signals within in-app events

New form of fraudfound

Installs which turn out to be fraudulent only after anomaly detection algorithms collect enough statistical data about the installs of any publisher

How to use Protect360?

In the remaining tabs of this article we explain how Protect360 works, how to use the Protect360 dashboard, and how to benefit from raw data. Use the following guidelines in implementing Protect360:

At the start of each month contact the account manager in each ad network where fraud occurred.

Notify them of the number of fraudulent installs: blocked and post-attribution.

Share the fraud raw data with the network forreconciliation and optimization of their traffic.

The table below describes where the data for both protection layers is found in AppsFlyer:

Aggregate

Raw Data

Real-time fraud Blocking

Protect360 dashboard

Export Data page

Post-attribution fraud

Protect360 dashboard

Protect360 dashboard

The Anomalies insight page offers information about media sources that have installs with abnormal CTIT values, when compared with other trusted sources. Visit the page to investigate these anomalies. Cross-reference the suspected installs with your raw installs data and look for suspicious signs such as weird app version numbers, old OS versions, distinctive locations etc.

Use Validation rules to block installs with short CTIT values. Protect360 automatically blocksinstalls with very low CTIT values.

Tip

How affected by fraud is your vertical? Explore our App install fraud benchmarks guide covering a wide range of parameters.

Protect360 dashboard

The Protect360 dashboard displays aggregate fraud data. Initially this is at the account level. It displays the fraud inflicted, split into categories, blocked in real-time and post attribution.

The Protect360 dashboard provides you with insights about fraudulent traffic in the account. You can drill down to further examine the fraud events by using the filtering and grouping options. Additionally, it allows you to detect anomalies, which may indicate the occurrence of additional fraud.

Protect360 dashboard view

Getting there

In Appsflyer, go to Dashboard > Protect360.

Who can access?

Advertisers:Team members

Ad Networks:

Protect360 dashboard access requires advertiser permission.

Blocked fraud raw data reports with media source data are always available to ad networks.

Agencies: Protect360 access requires advertiser permission. Once granted agencies can view the Protect360 dashboard and download post attribution raw data.

Filters and groupings

Filter and groupings window

The following filtering and grouping options are available:

Basic filters:

App name

Media source

Geo

Date range

Expanded filters - click on the blue arrow, to the right of the date picker:

Agencies

Campaigns

Channels

Minimum cohort size

Grouping options - choose different dimensions to group the fraud data by to get the specific insights you need:

Application:compare the total amount of fraud per each of your apps.

Media Source(default): compare the handled fraud from each of the media sources used by your apps

Media Source + Campaign:compare the handled fraud from all your campaigns across all media sources used by your apps

Media Source + Site ID: compare the handled fraud from all publishers (site IDs) across all media sources used by your apps

Media Source + Site ID + Campaign:compare the handled fraud from all publishers (site IDs) across all media sources used by your apps, associated with the relevant campaign names

Geo: compare the handled fraud from all countries

Data freshness

The Protect360 dashboard data is updated Daily. The lag from end of day until the updated data displays is 15 hours. The most recent update time, displays below the date range filter.

App-specific time zone is used in the dashboard provided all apps are set to the same time zone.

Fraud trend over time chart

The fraud trend over time chart displays the number of fraudulent events per day, broken down between blocked installs and post attribution events.

Identified fraud KPIs

TheIdentified FraudKPIs enable you to see:

Estimated savings

Number of fraudulent installs,

Number of fraudulent (in-app) events

For each KPI you can see a percentage value. This value shows how the presented KPI is in relation to the parallel date range that before it. For example, the last 7 days show 19% increase in estimated savings, meaning the previous week before the last 7 days had 19% less fraudulent installs.

Estimated savings widget

The widget breaks down the monetary amounts ofidentified fraud in the account. It shows the value of blocked fraud the value of post-attribution fraud, to be settled by you with the ad networks. Thepost-attribution amount for any select filtering may update over the course of a month, so make sure to use it at the beginning of each month, for the previous month.

TheEstimated Savings widget shows you an approximation of this amount based on the following formula:Estimated Savings = number of blocked installs X app's average eCPI

For more details on how this amount is calculated read this FAQ.

Total identified fraud widget

This widget breaks down the amount of blocked fraud installs from all various fraud blocking reasons. It also displays the amount of installs identified as fraudulent at post-attribution phase.

Blocked in-app events widget

This widget shows the amount of in-app events, which were blocked by AppsFlyer. The events may have been blocked due to belonging to blocked installs, or due to being marked as suspicious post-attribution events.

Anomaly insights widget

Click the Explore anomaliesbutton to open the anomalies chart page described in the following.

Identified fraud breakdown table

The Identified Fraud Breakdown table displays an abundance of information about fraud blocks, post-attribution marking of installs and more indications of fraud per media source.

Table left side

The table below explains about the columns in the left half of theIdentified fraud breakdown table:

Table Column

Description

Groupings

By default the table and dashboard are grouped by Media Source. More supported groupings include Campaign, Site ID, GEO, Channel, agency and their combinations.

Installs

High level breakdown ofblocked and post-attribution fraudulent installs.

Total

Total installs = regular installs + blocked installs. Regular installs per media source can be seen in the UA Overview page. Post-attribution blocked installs are part of the total installs.

Blocked

Total number of blocked installs of the source. By default the table is sorted in descending order by this KPI.

Blocked %

Blocked installs / total number of installs

Post-attribution

Total number of installs of the source marked as fraud post-attribution

Post-attribution %

Post-attribution installs / total number of installs

Hijacked installs block breakdown

Breakdown of blocked and post-attribution fraudulent last clicks aimed to steal attribution of real app installs

Blocked install hijacking

Total number of blocked install hijacking of the source

Post-attributioninstall hijacking

Total number of install hijacking marked as fraud in post-attribution

Blocked CTIT anomalies

Total number of installs blocked due to Click Time to Install anomalies

Post-attributionCTIT anomalies

Total number of CTIT anomalies marked as fraud in post-attribution

Blocked click flooding

Total number of installs blocked due to click flooding (fraud attempts tosend large numbers of clicks hoping to deliver the last clicks prior to random installs)

Post-attribution click flooding

Total number of click flooding installs marked as fraud in post-attribution

Blocked faked installs breakdown

Breakdown of blocked and post-attribution fraudulent fake installs, usually performed programmatically

Blocked site ID blacklist

Total number of installs blocked due to the SiteID appearing on Protect360 blacklist

Post-attribution site ID blacklist

Total number of installs marked as fraud due to the SiteID appearing on Protect360 blacklistpost-attribution

Blocked bots

Number of blocked installation attempts made by automatic bots

Post-attribution bots

Number of installs marked as fraud due to identified automatic bots activitiespost-attribution

Blocked behavioral anomalies

Total number of installs blocked due to behavioral anomalies, i.e.abnormal session and in app event performance of users

Post-attribution behavioral anomalies

Total number of installs marked as fraud due to behavioral anomaliespost-attribution

Blocked install validation

Total number of installs blocked due to negative store validation

Table right side

The table below explains about the columns in the right half of theIdentified fraud breakdown table:

Table Column

Description

Clicks

Legit and blocked clicks from the source

Total

Total number of clicks from the source

Blocked

Total number of blocked clicks from the source

%

Blocked clicks / total number of clicks

In-App Events

Legit and blocked in-app events from the source

Total

Total number of in-app events from the source

Blocked

Total number of blocked in-app events from the source

Percentage

Blocked in-app events / total number of events

Blocked Installs Breakdown - Install Hijacking

Total number of installs blocked due to install hijacking based on the Google Play Server-Side API discrepancies

Device farm indicators - new devices

Indicators of fraudulent device farm activity, using Device ID Reset fraud

Installs

Number of installs from the source, which have a new device ID unrecognized by AppsFlyer

Installs %

New devices installs / total number of installs

Loyal user %

General KPI indicating whether the users from the source are real or fake

Device farm indicators - LAT devices

Indicators of fraudulent device farm activity, using Limited Ad Tracking fraud

Installs

Number of installs from the source, which are set for Limited Ad Tracking

Installs %

LAT devices installs / total number of installs

Loyal user %

General KPI indicating whether the users from the source are real or fake

Click flooding indicators

User quality KPIs

Conversion rate

Low percentage compared with the general app's conversion rate indicates click flooding fraud

Assists %

High percentage compared with other media sources (in the Assists widget in the overview page) indicates click flooding fraud

Click flooding indicators - CTIT

Indications of click flooding fraud, based on abnormally high Click to Install Time

Over 60 minutes

Normally ~30% of first app launches occur more than 60 minutes after download

Over 5 hours

Normally ~20% of first app launches occur more than 5 hours after download

More table options

Click Export CSV button to download the table to your desktop in CSV format

Click thewheel cog icon to:

Change the order of table columns

Add or remove the columns described above

Add or remove any of your app's recently blocked in-app events to the table. For each added in-app event the relevant following columns are displayed:

Table Column

Description

Events Counter (Total)

Number of the specific event's blocked occurrences

Unique Users

Number of unique users getting the specific eventblocked

Note that uncommon rates of either of these KPIs does not necessarily indicate fraud, as many events get blocked due to fraudulent post-attribution installs.

The amount of events shown is activity and not LTV based, i.e. it's the exact number of event blocks during the specified date range.

Anomaly insights

The Anomaly insights page lets you detect media sources, which have suspicious Click to Install Time (CTIT) values, when compared with other media sources. This powerful KPI is on the media source level, which enables you to get compensated by the source and consider whether to continue working with it or not.

The following actions are enabled in the page. The numbers refer to the preceding screenshot:

Select apps to watch in the page.

Select which countries contribute to the data in the page.

Select the date range of the data in the page.

Turn Exclude post-attribution fraud on to see only blocked fraud, or turn it off to see the full fraud insights.

Select the media source baseline to compare with. The default App Baseline takes into consideration various sourcestrusted by AppsFlyer, which contribute to your traffic.

Select the time resolution shown in the graph: seconds, minutes, hours or days.

Customize the validation rules to exclude installs with illogical CTIT. Note: the validation rules feature must be enabled for your account to perform this.

To see more details, hover over the distinctly colored parts in the graph, which indicate detected CTIT anomalies.

Click to see a visual comparison of CTIT throughout different media sources.

Click the Protect 360 link to go back to the Identified Fraud page.

The CTIT anomalies breakdowntable, at the page bottom, displays all the media sources which have CTIT anomalies. Use it to see data about the number and percentage of installs with abnormal CTIT values. With this table you can also export to CSV, add or remove columns or set their order.

Data limitations

The described tables are limited to maximum 1000 entries. If you query for a larger data set, some media sources might be excluded from it.

To overcome this limitation, we recommend the following:

Query for a smaller dataset - smaller date range, specific apps and specific media sources

Export Protect 360 raw data reports

Export Protect 360 Aggregated Advanced Detection Reports through Pull API

Fraud issues & solutions

Customers using Protect360 are provided with automatic and comprehensive anti-fraud protection both on the single device level and on the general service level. The table below describes some of the common fraud issues and how Protect360 handles them.

Fraud Issue

Issue Description

AppsFlyer's Solution

Device ID reset fraud

Device ID is constantly reset by the fraudster on the same device(s), to display a large amount of installs.

AppsFlyers unparalleled database of mobile devices is the biggest of its kind in the world encompassing over 98% of all smartphones on the planet. This database allows us to identify abnormal rates of new devices and consequently blacklist any source delivering them.

Install hijacking

Fraudsters plant malware on mobile devices that alerts when a download of an app takes place. Instantly a click is sent to AppsFlyer claiming credit for the install.

AppsFlyer blocks attributed clicks with a very quick CTIT ( Click To Install Time ) and based on Google Play Server-Side API.

Click hijacking

Malware identifies an install tracking link click and instantly sends another click that credits them if it is attributed.

AppsFlyer blocks attributed clicks occurring very fast after other clicks for the same app on the same device.

Click flooding

Mobile fraud where large numbers of fraudulent clicks are sent, with the purpose of delivering the last-click prior to installs.

AppsFlyer blocks attributed clicks from site IDs with a low conversion rate and long CTIT.

Behavioral anomalies

Mobile fraud where the fraudster generates an inconsistent and abnormal post-install activity.

AppsFlyers unique scale allows us to track and understand behavioral engagement patterns on multiple levels - such as by app, region, media source and publisher. Non-human behavioral patterns are identified in near real-time, and blocked at the source.

IP blacklists

Fraudsters usually operate from click farms, which may be identified by their IP addresses for long periods of time.

AppsFlyer blacklists IP addresses suspected of fraud on a daily basis based on up to date data received from 3rd party global provider Digital Element.

Note - IP Blacklists protection is automatically enabled for ALL AppsFlyer clients.

SDK authentication

Fraudsters send fake SDK messages to simulate valuable user actions.

AppsFlyer uses a proprietary hashing protocol to encrypt internal messages between our SDKs and our web services, preventing fraudsters from mimicking the messages.

Note - SDK authentication protection is automatically enabled for ALL AppsFlyer clients.

Store validations

Fraudsters send fake SDK messages to simulate installs or in app purchases so they can claim high CPA fees. For more information, click here.

AppsFlyer enables install validation on iTunes and in-app purchase validation for both iTunes and Google Play, of any install or in-app purchase that has taken place to prevent attribution of fraudulent activities.

Note that AppsFlyer withholds the exact time values cited above to protect our clients.

More blocking reasons are explained in the raw data tab.

What does fraud blocking actually do?

When AppsFlyer identifies fraudthe attributionevent associated with the fraud is blocked. This eliminates the fraudsters' gains and motivation. Note: The app install still takes place and is not blocked. This means the app user can use the app and generate revenue for the advertiser.

The following lists the type of fraudulent attribution events which are blocked:

Fraudulent fake installs, like bots,are blocked and don't show in the dashboard and raw data reports. This includes non-organic and organic installs.

Hijacked installs, likeclick flooding, are attributed to the legitimate media source. This means that fraudulent clicks are deleted and the installs attributed to the last valid engagement of the user prior to the fraudulent click (or organic).

Install postbacks are recorded in the blocked installs raw data report. They are sent to media sources that support postbacks with blocking reasons for internal optimization.

In-app eventsoriginating from fraudulent installs, or that are considered as fraudulent on their own, are blocked from showing in the dashboard and raw data report. This includes both non-organic and organic events.

In-app event postbacks are not sent to media sources.

Blocked fraud clicks, installs, and in-app events are found in Protect360 fraud raw data reports.

Protect360 raw data reports

Raw data reports contain user-level details of the events blocked by Protect360. The reports include details of clicks, installs, and post-install events.

These reports are used by advertisers to reconcile ad network accounts and for optimization. They alsoenable an analysis of fraud issues.

Protect360 has raw data reports for blocked fraud and post-attribution fraud.

Blocked fraud reports

To download blocked fraud reports, in the Protect360 dashboard, go toRaw data reports>Blocked. Download the reports.

You can also download the blocked fraud reports from the Export Data page.

The following reports are available in the Blocked Fraud Reports section in the Export Data page:

Installations

Blocked installs (organic and non-organic)

In-App Events

Blocked in-app events (organic and non-organic)

Clicks

Blocked clicks

Installation Postbacks

Raw data of blocked installation postbacks sent to the attributed media source.

Post-attribution fraud reports

The post-attribution raw data fraud reports, described here, have the same structure as the blocked fraud reports. This enables you to merge the two kinds of report.

The current month (by install date) post-attribution report continues to be updated until the seventh day of the following month (detection date).

Example

Example A: During December (install date) 15 installs are attributed to example_media. On January 3 (detection date), Protect360 identifiesexample_media as a fraudster. As a result, the 15 installs attributed to example_mediaare listed as fraudulent in the post-attribution fraud report for further action by the app owner.

Example B:During December, 15 installs are attributed to example_media. On January 9, Protect360 identifiesexample_mediaas a fraudster. In this case, no action is taken by Protect360 because the fraudster was identified after the month close on January 7.

Post-attribution raw data fraud reports are available as follows:

Dashboard user interface: limited to one media source during one calendar month.

Pull API: contains all media sources. (Limitation: Available app owners only)

To add or download a post-attribution report:

In the Protect360 dashboard, clickRaw data reports> select Post-attribution.

Select the media source and the calendar month.

Click Generate report.

Report generation may take several minutes, depending on the volume of traffic from the media source. You can click Done and return later on to download the report when it is available.

Protect360 report structure

Protect360 reports have the same general structure as their parallel user acquisition reports. You can readabout the fields available in the reports here.

Protect360 reports have the following additional fields that relate to blocking as follows:

Blocked reason

Blocked sub-reason

Blocked reason value

Blocked Reason Rule

Click level blocked reasons

At the click level, clicks are blocked, and the attribution process ignores them.

Blocked reason

Description

ip_blacklist

Based on a dynamically created list ( details )

install_store_validation

The discrepancy between Google Referrer values of the install

invalid_fingerprint

S2S clicks only: invalid parameters sent by the source (for Fingerprinting matching)

Install level blocked reasons

At the install level, clicks are blocked, and the last valid contributor is attributed.

Bots traffic, is completely blocked.

Install hijacking can only occur on Android.

Blocked reason

Blocked sub-reason

Description

ctit_anomalies

Click-time to install too short as determined by Protect360

ctit_anomalies

validation_rules

* Click-time to install too short as defined by the advertiser

install_hijacking

referrer_hijack

Fraudsters pushing additional non-legitimate referrers

install_hijacking

CTCT_anomalies

Multiple clicks too close to each other

install_hijacking

click_after_install_begins

Click injected after "install begins" by anothter google API

Bots

---

Fake traffic by bots

Bots

custom_validations

* Advertiser custom validation rule defined with the CSM.

Bots

validation_rules

* Advertiser defined rule in the user interface

* Rules defined by the advertiser. Other rules are part of Protect360 suite of rules.

Site ID level blocking reasons

At the site ID level, fraudulent site ID traffic is completely blocked.

Blocked reason

Blocked sub-reason

Description

behavioral_anomalies

---

Low post-install in-app event activity ratio, in comparison with the app's benchmarks

site_blacklist

high_fraud_rate

Sites with high rates of fraud traffic, with installs fraud characteristics only (but not hijacking)

site_blacklist

high_emulator_rate

Sites with high rate of installs originated in emulators

site_blacklist

multiple_fraud_signals

Sites with high rate of installs with various suspicious KPIs

Pull API

You can pull aggregate Protect360 data from AppsFlyer's servers directly into your back office. To learn about it go here.

FAQs

How is the Estimated savings widget calculated?

For networks that support sharing cost data you get an accurate estimation of the savings.

For networks that don't support that AppsFlyer uses the average eCPI coming from the entire group of verified installs from all sources that have cost data. In case your app still has no source with cost data you are prompted to enter an estimated eCPI manually when you enter the dashboard.

Media sources granted access to the Protect360 from the advertiser are unable to see any estimated savings data.

What's new in Protect360 V2 compared with V1?

There are 3 main changes in the P360 V2.0: Post-Attribution fraud - wherever we present blocked installs, we also show Post-Attribution fraud installs. Post-Attribution is also available as a raw data report.

Anomaly Insights - A new section called Anomaly Insights was added, in which advertisers can analyze anomalies via visualization tools. Its replacing the 2 charts on the old Advanced Detection tab.

Centralization of all the fraud data - the advanced detection tab was removed and instead we present all the information in 1 tab.

Why isn't the post-attribution raw data available in the Export Data page?

Post-attribution reports are on the account level per media source, In order to make the reconciliation process easier. The Export Data page is on the single app level, and still contains the Blocked fraud data on the app level, for backwards compatibility.

Does post-attribution data update retroactively?

No, the install data on the overview page and all other reports outside Protect360 dashboard, do not update retroactively. Currently, also in-app events related to Post-attribution fraud continue to be attributed to the original fraudulent install.

Selecting specific networks in Anomaly insights

Question: I looked at the CTIT anomalies and selected AF_Baseline as benchmark. It showed me one network's anomalies (first screenshot below). Then I selected the same network as benchmark, expecting to see no anomalies, but now there are other ones (second screenshot). How come?

Answer: This outcome is actually what you should expect. When the trusted baseline is used, the network shows abnormal rate of CTIT in the 24-39 seconds range. These installs are "subtracted" from the normal distribution, which means that regular traffic should have some "abnormal" spikes compared with the problematic traffic of the specific network.

Benchmarks and tips

Detecting new devices fraud

Fraudsters may mask their devices by frequently resetting the main IDs of their devices, i.e.IDFA for iOS and GAID for Android. Fortunately, AppsFlyer identifies over 98% ofmobile devices globally. Therefore, a high percentage of unknown new devices is a strong indication of fraud by click farms, unless intentionally targeting new devices.

Detecting new devices:

In Protect360 go to theIdentified fraud breakdown table.

Scroll right to the Device farm indicators - new devices columns.

Click on the Installs % column name to sort the table in descending order of new device ratio.

New device fraud benchmarks:

Suspect sources with 100+ installs, which have over 60% new devices ratio.

Sources with relatively more installs, are also suspicious with lower new device ratio, e.g. source with 1000 installs is suspicious as fraud with 40% ratio.

For borderline sources, compare the loyal users ratio with the general loyal users ratio, found in the Aggregated performance report table in the dashboard's overview page. A relative low percentage is a strong indication of fraud.

Note

Campaigns of pre-installed apps usually have extremely high rates of new devices, as these may be among the very first apps that users launch when activating their new devices. Therefore, for pre-installed apps, new device fraud is unlikely, even with high new devices rates.

Detecting LAT fraud

LAT (Limited Ad Tracking) users select to opt out of exposing their device ID, IDFA or GAID, to advertisers. Approximately 15% of iOS users and 10% of Android users take this choice.

Similarly to the new device ranking, LAT users may be legitimate users. However, a high percentage of them could indicate fraudulent activity.

Detecting LAT:

In Protect360 go to theIdentified fraud breakdown table.

Scroll right to the Device farm indicators - LAT devices columns.

Click on the Installs % column name to sort the table in descending order of LAT device ratio.

LAT devices fraud benchmarks:

Suspect sources with 100+ installs, which have over 60% new devices ratio.

Sources with relatively more installs, are also suspicious with lower new device ratio, e.g. source with 1000 installs is suspicious as fraud with 40% ratio.

For borderline sources, compare the loyal users ratio with the general loyal users ratio, found in the Aggregated performance report table in the dashboard's overview page. A relative low percentage is a strong indication of fraud.

Detecting click flooding fraud

Using Click Flood, fraudsters send millions of clicks with real device IDs, hoping to register as the last click for real users. Sources with this type of fraud have very low conversion rates, but high quality users, since these are real users.

Detecting click flood:

In Protect360 go to theIdentified fraud breakdown table.

Scroll right to the Click flooding indicatorscolumns.

Click on the Conversion ratecolumn name to sort the table in ascending order of conversion rate.

Click flooding fraud benchmarks:

Normal Conversion Rates are between 0.5% to 35%. Suspect sources whose conversion rate are abnormally low, or that have 25% or less of the average conversion rate of the app.You can find this KPI in the Aggregated performance report table in the dashboard's overview page.

For borderline sources, compare the Assists % with the average assists ratio. You can see the normal assists ratio in the assists widget, in the dashboard's overview page. Sources whose assists ratio is50% higher than the average assists ratio of the app are considered suspicious. Note that the more sources are used by an app, the higher are its Contribution rates.

Detecting click flooding with CTIT indicators

Another indication of click flooding, is even distribution of CTIT. Usually, around 70% of normal installs take place within 1 hour from the ad engagement. With click flooding, there's no connection between the fake engagement and the actual install. This leads to much more than 30% of fraud installs, which have longer than 1 hour CTIT.

Detecting click flood CTIT indications:

In Protect360 go to theIdentified fraud breakdown table.

Scroll right to the Click flooding indicators- CTIT columns.

Click flooding CTIT benchmarks:

Normally,Over 60 minutes values should be around 30%. Suspect sources who have more than 50% with this metric.

Normally,Over 5 hours values should be around 20%. Suspect sources who have more than 40% with this metric.

Use the Anomaly insights to investigate sources with suspicious CTIT.

Advanced anti-fraud tips

Number of Installs

Filtering by the number of installs per checked source is important for detecting the biggest fraud sources. Additionally, lower number of installs may not be mathematically significant.

Tip

Sources with less than 30 installs, or even 50, are not significant enough to draw conclusions from. Expand the date range or other search criteria to get more significant results.

Change Loyal User Definition

The default definition for Loyal users is 3 or more launches of the app. It is an important KPI for user engagement, but unfortunately many fraudsters know it and use it to fake high rates of loyal users, thus avoiding suspicion. Avoid being conned by creating and selecting a better, more elaborate loyal user definition.

Tip

Analyze your app's user quality KPIs such as register, tutorial completion, purchase, multiple sessions etc. Within the app's code send a new loyal user in app event if a user performs ALL the list of KPIs.

After the first non-organic loyal user event is sent, go to App Settings and select it to indicate loyal users for your app. Expect general loyal user rates to slightly drop and then drastically drop for fraudulent sources.

What's changing: New report: Protect360Post-attribution raw data

Where is it changing: Pull API

Publication date: December 11, 2019

Who is impacted: Advertisers who implement Protect360. Agencies and ad networks do not have access.

Before the change

Not applicable.

After the change

Protect360 post-attribution raw data events report is available using Pull API.

It contains post-attribution fraud events identified by Protect360

Until now, this report was made available in the Dashboard and not by Pull API

The Pull API version includes all media sources in the same report

Post attribution raw data report Pull API call

<https://hq.appsflyer.com/export/{app_id}/detection/v5?api_token={api_token}&from={from}&to={to}&additional_fields=install_app_store,match_type,contributor1_match_type,contributor2_match_type,contributor3_match_type,device_category,gp_referrer,gp_click_time,gp_install_begin,fraud_reason,fraud_sub_reason,fraud_reasons,install_time_tz,detection_date&detect-from={detect-from}&detect-to={detect-to}

Protect360 post attribution fraud raw data API parameters

Parameter

Description

Format

Mandatory

app_id

App id as it appears in AppsFlyer

String

Yes

api_token

Retrieve the key from the Dashboard. Go to Integration > API AccessOnly the account admin can retrieve the API token.

String

Yes

from

Start of the install date range

YYYY-MM-DD

Yes

to

End of the install date range

YYYY-MM-DD

Yes

detect-from

Start of the fraud detect date range

YYYY-MM-DD

Yes

detect-to

End of the fraud detect date range

YYYY-MM-DD

Yes

Date limitations:

The install date from/to is limited to calendar months or partial calendar months. This means that the value of MM in both the from and to fields must be the same.

The detect-from/detect-to date range is limited as follows:

detect-from: equal or later than the from date.

detect-to: no later than the seventh day (DD=07) of the month following the from date. Meaning if the from month is January then the detect-to date can't be later than February 7 (YYYY-02-07).

The reason for the date limitation is due to the manner in which Protect360 manages post-attribution fraud.

What's New See in AppsFlyer.

At a glance: View campaign ad spend (cost) information

Ad spend (cost) information is recorded using various cost models like CPI, CPA, CPC, and CPM. The model used, depends on how the partner reports the spend. AppsFlyer accepts spend reporting by click, Cost API, and by Ad Spend Ingestion (CSV file upload).

Spend information, with additional campaign and LTV performance metrics, is available in the dashboards and performance reports.The reports include ROI, clicks, impressions, campaign ROI, and average effective cost per installation (eCPI) over time.

The Data freshness rate of spend information is as follows:

Click: Real-time

Cost API: Six times a day on average once every four hours

Ad Spend Ingestion: Several minutes after ingestion

Don't change campaign names

Don't change the names of active campaigns

Starting November 18, 2019, Facebook Ads campaign names may be changed according to this announcement. Note: This change will be rolled out to additional ad networks in the future.

Avoid using macros with attribution link parameters that define the campaign

Viewing ad spend in the Overview dashboard

In the Overview dashboard,Aggregated Performance Report contains: cost, clicks, impressions, ROI, and average eCPI data This report and others are available for download.

API

Ad spend FAQ and operations

Costs without installs

Why do I see cost data with no installs?This occurs when ad spend is provided at the campaign level, but the performance information (clicks and installs) is provided at the adset or lower level in the advertising hierarchy.

Example: Cost with no installs

An advertiser runs a campaign. The advertising hierarchy is as follows:

Media source:media_eg

Campaign:campaign_eg

Adsets:adest1,adset2

The following information relating to the media source is displayed

Hierarchy: All Media Sources > media_eg

Campaign

Cost

Installs

campaign_eg

$100

100

campaign_yy

$200

1000

campaign_zz

$300

2000

Drilling down into campaign_eg, the adset level is shown.

Hierarchy: All Media Sources > media_eg > campaign_eg

Adset

Cost

Installs

None

$100

adset_1

N/A

30

adset_2

N/A

70

In this case, the ad spend of campaign_eg is $100 and is provided at the campaign level. When drilling down to the adset level, which in this case is the component level, the cost can not be broken down by adset.

To overcome this, AppsFlyer carries downthe ad spend from the campaign level and displays it in a separate row. In this case, the adset is shown asnoneand the installs field left blank

Stop Ad Spend API

To stop the API Ad Spend:Go to Integrated Partners, select the partner, go to the Cost tab, disable Get Cost Data.

Cost reporting methods

The type and cost model supported of spend information depends on the method used.

Cost Reporting Method

Cost models supported

Data granularity

Where is data available

Clicks (attribution link)

CPI

User-level

Dashboard and Performance reports

Raw data reports

API integration with partners

All

Levels above user level

Dashboard and Performance reports

Ad Spend Ingestion (file upload)

All

Campaign

Dashboard and Performance reports

Changing campaign names

Changing the names of active campaigns, ad sets, and ads may cause duplication or missing cost data. Pay attention to the following cases:

Ad Spend API/SRN networks:avoid changing the names of campaigns, ad sets and ads on these networks. Starting November 18,, 2019 changing campaign names in Facebook is permitted subject to the product change notification referenced here

Click networks:avoid using macroswith the attribution link parameters of campaigns, ad sets, and ads, if the results can be dynamic. Example: c={campaign} is the correct usage, as it returns the same campaign name. In contrast, c={campaign}_{creative_size}returns different results and records as separate campaigns in AppsFlyer.

Cost currency conversion

If the cost currency provided by the ad network differs from that of the currency configured in the app, the cost is converted to the app-defined currency as follows:

AppsFlyer gets the rates from openexchangerates.org

Exchange rates are updated hourly

Currency conversions are performed using the last know rate

Ad networks providing ad spend information

The table below lists ad networks that provide cost information to AppsFlyer.

Ad networks providing ad spend information

Media source name

Logo

Cost reporting method

Dimensions Supported

Aarki

API

Media source, campaign, and Geo

AdAction

Click

Dimensions on the attribution link

Adattraction

Click

Dimensions on the attribution link

Adcolony

API

Media source, campaign, and Geo

Click

Dimensions on the attribution link

Adcrimson

Click

Dimensions on the attribution link

Adcrops

Click

Dimensions on the attribution link

AdDeals

Click

Dimensions on the attribution link

AddictiveAds

Click

Dimensions on the attribution link

Adison

Click

Dimensions on the attribution link

Adjoe

Click

Dimensions on the attribution link

Adlix

Click

Dimensions on the attribution link

Adperio

Encrypted Click

Dimensions on the attribution link

Adpick

Encrypted Click

Dimensions on the attribution link

AdTiming

Encrypted Click

Dimensions on the attribution link

AdTrial

Click

Dimensions on the attribution link

Adxperience

Click

Dimensions on the attribution link

Affilinet

Click

Dimensions on the attribution link

Altrooz

Click

Dimensions on the attribution link

AML

Click

Dimensions on the attribution link

AOL Platforms

Click

Dimensions on the attribution link

Appa

Click

Dimensions on the attribution link

Appadvice

Click

Dimensions on the attribution link

AppBrain

Click

Dimensions on the attribution link

Appcoachs

Click

Dimensions on the attribution link

Appflood

Click

Dimensions on the attribution link

Appflood Affiliate Network

Click

Dimensions on the attribution link

Click

Dimensions on the attribution link

APPKIN

Click

Dimensions on the attribution link

Apple Search Ads

API

Campaign, adset level, and Geo.

Keyword cost without Geo.

AppLike

Click

Dimensions on the attribution link

AppLovin

API

Media source, campaign, and Geo

AppNext

Click

Dimensions on the attribution link

APPSILON

Click

Dimensions on the attribution link

AppThis

Click

Dimensions on the attribution link

APUS

Click

Dimensions on the attribution link

ASB

Click

Dimensions on the attribution link

Aura by ironSource

Click

Dimensions on the attribution link

Bebi Media

Click

Dimensions on the attribution link

Beintoo

Click

Dimensions on the attribution link

Bidmotion

Click

Dimensions on the attribution link

Blind Ferret

Click

Dimensions on the attribution link

Click

Dimensions on the attribution link

Bubbleye

Click

Dimensions on the attribution link

Camera360

Click

Dimensions on the attribution link

Chartboost

Click

Dimensions on the attribution link

CheBuoni

Click

Dimensions on the attribution link

Cheetah Mobile

Encrypted Click

Dimensions on the attribution link

Click2perform

Click

Dimensions on the attribution link

ClickDealer

Click

Dimensions on the attribution link

CommuteStream

Click

Dimensions on the attribution link

Creative Clicks

Click

Dimensions on the attribution link

Crobo

Click

Dimensions on the attribution link

Cross Install

Click

Dimensions on the attribution link

Curate

Click

Dimensions on the attribution link

DGM

Click

Dimensions on the attribution link

Digilant

Click

Dimensions on the attribution link

Directagents

Click

Dimensions on the attribution link

DirectFocus

Click

Dimensions on the attribution link

Drawbridge

Click

Dimensions on the attribution link

Digital Sunray

Click

Dimensions on the attribution link

Digital Turbine

Click

Dimensions on the attribution link

Discovry

Click

Dimensions on the attribution link

Display.io

Click

Dimensions on the attribution link

Encrypted Click

Dimensions on the attribution link

Click

Dimensions on the attribution link

Edge360

Click

Dimensions on the attribution link

Everyads

Click

Dimensions on the attribution link

Exciteco

Click

Dimensions on the attribution link

Facebook

API

Media source, campaign, geo, ad Set, ad, and Channel.

Fizzylabs

Click

Dimensions on the attribution link

Fyber

Click

Dimensions on the attribution link

Gamespipe

Click

Dimensions on the attribution link

Glispa Media CPI

Encrypted Click

Dimensions on the attribution link

Encrypted Click

Dimensions on the attribution link

Google

API

Media source, campaign, and geo.

Groundhog

Click

Dimensions on the attribution link

HangMyAds

Click

Dimensions on the attribution link

HAWK

Click

Dimensions on the attribution link

Headway Digital (MoBrain)

Click

Dimensions on the attribution link

Heyzap

Click

Dimensions on the attribution link

Hopemobi

Click

Dimensions on the attribution link

Iconpeak

Click

Dimensions on the attribution link

Immersv

Click

Dimensions on the attribution link

Implus Technology

Click

Dimensions on the attribution link

Inflecto

Encrypted Click

Dimensions on the attribution link

Infleux

Click

Dimensions on the attribution link

Inmobi

API

Media source, campaign, and geo.

Inneractive

Click

Dimensions on the attribution link

Intango

Click

Dimensions on the attribution link

ironSource

Encrypted Click

Dimensions on the attribution link

IRONTRAFFIC

Click

Dimensions on the attribution link

Jampp

Click

Dimensions on the attribution link

JetFuel

Click

Dimensions on the attribution link

Jump Ramp Games

Click

Dimensions on the attribution link

KickAssOffers

Click

Dimensions on the attribution link

KissMyAds

Click

Dimensions on the attribution link

Kixer

Click

Dimensions on the attribution link

Lemmonet

Encrypted Click

Dimensions on the attribution link

LifeStreet

Click

Dimensions on the attribution link

Liftoff

API

Media Source, campaign, ad, and geo

LoopMe

Click

Dimensions on the attribution link

Lunplay

Click

Dimensions on the attribution link

Lyto

Click

Dimensions on the attribution link

Madeviral

Click

Dimensions on the attribution link

Criteo DSP (Manage)

Click

Dimensions on the attribution link

MARKETIT

Click

Dimensions on the attribution link

Matchmade

Click

Dimensions on the attribution link

MdotM

Click

Dimensions on the attribution link

Minimob

Click

Dimensions on the attribution link

Mintegral

Encrypted Click

Dimensions on the attribution link

MOA

Click

Dimensions on the attribution link

Mobair

Click

Dimensions on the attribution link

Mobcastle

Click

Dimensions on the attribution link

Mobiblade

Click

Dimensions on the attribution link

Mobikaka

Click

Dimensions on the attribution link

Mobilda

Encrypted Click

Dimensions on the attribution link

Mobile10

Click

Dimensions on the attribution link

MobilePlay

Click

Dimensions on the attribution link

MobiteMedia

Click

Dimensions on the attribution link

Mobonus

Click

Dimensions on the attribution link

MobPartner

Encrypted Click

Dimensions on the attribution link

Mobsuccess

Click

Dimensions on the attribution link

Mobupps

Click

Dimensions on the attribution link

Mobvista

Encrypted Click

Dimensions on the attribution link

Moloco

Click

Dimensions on the attribution link

Moinstall

Click

Dimensions on the attribution link

Motive

Click

Dimensions on the attribution link

Msales

Click

Dimensions on the attribution link

myTarget

API

Media source, campaign, and geo

Naranya

Click

Dimensions on the attribution link

NativeX

Encrypted Click

Dimensions on the attribution link

Netlion

Click

Dimensions on the attribution link

Click

Dimensions on the attribution link

Octro

Click

Dimensions on the attribution link

OfferToro

Click

Dimensions on the attribution link

OnSeo

Click

Dimensions on the attribution link

Outmarketing

Click

Dimensions on the attribution link

Performance Revenues

Encrypted Click

Dimensions on the attribution link

Pinterest

API

Media source, campaign, ad set, Ad (promoted pin)

Playhaven

Click

Dimensions on the attribution link

PMANetwork

Click

Dimensions on the attribution link

Pocket Media

Click

Dimensions on the attribution link

Promolta

Click

Dimensions on the attribution link

Pubmint

Click

Dimensions on the attribution link

Purple Friends

Click

Dimensions on the attribution link

Pusic

Click

Dimensions on the attribution link

rAPId:ads

Click

Dimensions on the attribution link

ReevAds

Click

Dimensions on the attribution link

RevMob

Click

Dimensions on the attribution link

Rocket10

Click

Dimensions on the attribution link

Rootmedia

Click

Dimensions on the attribution link

Click

Dimensions on the attribution link

Seads

Click

Dimensions on the attribution link

SeccoSquared

Click

Dimensions on the attribution link

SDM

Click

Dimensions on the attribution link

Snap

API

Media source, campaign, ad set, and ad.

Skrilo

Click

Dimensions on the attribution link

Startapp

Encrypted Click

Dimensions on the attribution link

Supersonic

Click

Dimensions on the attribution link

Surikate

Click

Dimensions on the attribution link

Tapjoy

API

Media source, campaign, and Geo.

Click

Dimensions on the attribution link

Tapcash

Click

Dimensions on the attribution link

TapCommerce

Click

Dimensions on the attribution link

Tapmyads

Click

Dimensions on the attribution link

Tapsense

Encrypted Click

Dimensions on the attribution link

Taptica

Click

Dimensions on the attribution link

Time One

Encrypted

Dimensions on the attribution link

Tyroo

Click

Dimensions on the attribution link

Unity Ads

Click

Dimensions on the attribution link

Verizon Media (Oath Ad Platforms)

API

Media source, campaign, ad set, ad, and geo

Vungle

Click

Dimensions on the attribution link

Wagawin

Click

Dimensions on the attribution link

Wisebirds

Click

Dimensions on the attribution link

yeahmobi

Encrypted Click

Dimensions on the attribution link

Yieldmo

Click

Dimensions on the attribution link

Webpals

Click

Dimensions on the attribution link

ZPLAY Ads

Click

Dimensions on the attribution link

Ad networks providing ad spend information by API

Ad netorks providing ad spend information by API

Media source name

Logo

Cost reporting method

Dimensions Supported

Aarki

API

Media source, campaign, and Geo

Adcolony

API

Media source, campaign, and Geo

Apple Search Ads

API

Campaign, adset level, and Geo.

Keyword cost without Geo.

AppLovin

API

Media source, campaign, and Geo

Facebook

API

Media source, campaign, geo, ad Set, ad, and Channel.

Google

API

Media source, campaign, and geo.

Liftoff

API

Media Source, campaign, ad, and geo

myTarget

API

Media source, campaign, and geo

Pinterest

API

Media source, campaign, ad set, Ad (promoted pin)

Snap

API

Media source, campaign, ad set, and ad.

Tapjoy

API

Media source, campaign, and Geo.

Verizon Media (Oath Ad Platforms)

Media source, campaign, ad set, ad, and geo

Introduction

push API

Allowing your existing users to invite their friends and contacts as new users to your app can be a key growth factor for your app. AppsFlyer allows you to attribute and record new installs originating from user invites within your app.

Note

User Invite Attribution is available on AppsFlyer's SDK versions 4.8.0 and above and Unity SDK version 4.17.0.

Why is attributing user invites so useful?

Obtain information about the best-referring users

Users that refer their friends to your app are high value engaged users, which you may want to preserve, retarget or incentivize.

Use the referring user information to personalize the first time experience for the new user

Instead of a general welcome message, you could have a personalized message, which engages the new user much more. For example: "Welcome, John! Join your friend Marsha in an epic battle after you finish the tutorial".

Know the cost and ROI of user invites for better results

Are user invites free of charge? Not really. They use up your app's advertising "real estate", which could alternately get you real ads revenue.

Do user invites get you positive ROI, compared with the alternative? In some cases they do, and in others, they don't.

You can use AppsFlyer's cost parameters to assign cost to user invite installs, based on the alternatives.

Example

A banner gains you $5 RPM with ads views (here's a great way to measure it ). On average, with a 2% conversion rate of views to invites, and with a 10% conversion rate of invites to installs, you get 2 new users from every 1K views. Therefore, using the same banner space to promote invites costs 5$/2=$2.5 per install. Add af_cost_value=2.5 value to reflect this cost on the dashboard.

Combined with your revenue reporting in-app events you are able to see which user invites campaigns give you the best or worst results, and which invite channels are best for your purposes.

How does attributing user invites work?

Installs attributed to an invite link appear on the dashboard under the media source af_app_invites.

The channels used to send the invites through (mail, SMS, Facebook etc.) appear under the Channel grouping under the media source af_app_invites.

Selecting af_app_invites media source, and grouping by Channel, displays clicks and installs from user invites that went through Gmail and Facebook

The developer's guide

Importing libs

On Android make sure to import the following libs:

import com.appsflyer.share.ShareInviteHelper;

import com.appsflyer.share.LinkGenerator;

Setting OneLink

Invite attribution uses OneLink to redirect the invited user to the relevant app store. OneLink also allows you to use deferred deep linking. Deferred deep linking opens a specific activity when the user launches the app. It also sets customized content to keep the user in the context of installing after an invite.

Make sure to configure OneLink correctly for your app:

Configure OneLink redirections

Follow the guide on how to set up deferred deep linking - setting up deferred deep linking gives the data that you need to programmatically send users to specific activities, or reward both the inviter and invitee.

Optional - Configure OneLink deep linking - you don't have to configure OneLink deep linking but it could be helpful in certain scenarios. For example:

You set up a campaign where users invite their friends to install the app. Both get credit points to use in the app. If the invitee installs the app, the inviter gets 50 credit points and the invitee gets 100 credit points. If the invitee already has the app installed, the inviter gets 25 credit points and the invitee gets 50 credit points. To distinguish between the two cases use deferred deep linking for the first and deep linking for the second.

Once the OneLink is fully configured, take the relevant OneLink ID.

Before calling startTracking in your app, set the OneLink which is invoked according to the OneLink ID (1bBC in this example):

Note

Make sure the correct OneLink ID is used. Otherwise, the created attribution link is broken.

Android iOS Unity

AppsFlyerLib.getInstance().setAppInviteOneLink("1bBC");

Objective C Swift

[AppsFlyerTracker sharedTracker].appInviteOneLinkID = @"1bBC";

AppsFlyerTracker.shared()?.appInviteOneLinkID = "1bBC";

AppsFlyer.setAppInviteOneLinkID("1bBC");

Important

To generate a shortened OneLink with the User Invite feature you must set a sub-domain for your OneLink in the OneLink Configurations page, under Additional Configurations. If you do not set a unique sub-domain for your OneLink, a "long" OneLink is generated with all added parameters visible on the link.

Generating the link

The LinkGenerator class builds the invite URL according to various setter methods which allow passing on additional information on the click. This information is available through getConversionData when the new user accepts the invite and installs the app. In addition, campaign and channel parameters are visible in the AppsFlyer Dashboard.

Android iOS Objective-C iOS Swift Unity

LinkGenerator linkGenerator = ShareInviteHelper.generateInviteUrl(MainActivity.this);

linkGenerator.setChannel("Gmail");

linkGenerator.addParameter("af_cost_value","2.5");

linkGenerator.addParameter("af_cost_currency","USD");

CreateOneLinkHttpTask.ResponseListener listener = new CreateOneLinkHttpTask.ResponseListener() {

@Override

public void onResponse(String s) {

Log.d("Invite Link", s);

// write logic to let user share the invite link

}

@Override

public void onResponseError(String s) {

// handle response error

}

};

linkGenerator.generateLink(MainActivity.this, listener);

Note

onResponse and onResponseError are callback methods for generating OneLink URLs. They are part of the CreateOneLinkHttpTask.ResponseListener interface and need to be implemented. They are used to generate invite links that you can put in various views in the application.

[AppsFlyerShareInviteHelper generateInviteUrlWithLinkGenerator:^AppsFlyerLinkGenerator * _Nonnull(AppsFlyerLinkGenerator * _Nonnull generator) {

[generator setChannel:@"channel_name"];

[generator setReferrerName:@"referrer_name"];

[generator addParameterValue:@"2.5" forKey: @"af_cost_value"];

return generator;

} completionHandler:^(NSURL * _Nullable url) {

NSLog(@"%@", url);

// write logic to let the user share the invite link

}];

AppsFlyerShareInviteHelper.generateInviteUrl(linkGenerator:

{(_ generator: AppsFlyerLinkGenerator) -> AppsFlyerLinkGenerator in

generator.setChannel("channel_name")

generator.setReferrerName("referrer_name")

generator.addParameterValue("2.5", forKey: "af_cost_value")

return generator },

completionHandler: {(_ url: URL?) -> Void in // write logic to let the user share the invite link })

Android:

Dictionary<string,string> inviteDicionary = new Dictionary<string,string>();

inviteDicionary.Add("channel","channel_name");

inviteDicionary.Add("referrerName","referrer_name");

AppsFlyer.generateUserInviteLink(inviteDicionary, "customCallbackObject", "onFailedMethodName", "onFailedMethodName");

iOS:

Dictionary<string,string> inviteDicionary = new Dictionary<string,string>();

inviteDicionary.Add("channel","channel_name");

inviteDicionary.Add("referrerName","referrer_name");

AppsFlyer.generateUserInviteLink(inviteDicionary, null, null, null);

// Any value can be set instead of null, but the iOS callback will always

//return to the AppsFlyerTrackerCallbacks object -> onInviteLinkGenerated callback method.

All link generator setters

Android iOS

API Name

Description

Usage

setChannel(String channel)

The channel through which the invite was sent (e.g. Facebook/Gmail/etc.)

Recommended

setCampaign(String campaign)

A campaign name

Optional

setReferrerName(String referrerName)

The name of the referring user

Optional

setReferrerImageURL(String referrerImageURL)

The URL to referrer user avatar

Optional

setReferrerCustomerId(String referrerCustomerID)

Set the customer_user_id of referrer user

Optional

addParameter(String key, String value)

A single key value custom parameter

Optional

addParameters(Map<String, String> parameters)

Multiple key value custom parameters

Optional

API Name

Description

Usage

setChannel :(NSString *) channel

The channel through which the invite was sent (e.g. Facebook/Gmail/etc.)

Recommended

setCampaign :(NSString *) campaign

A campaign name

Optional

setReferrerName :(NSString *) referrerName

The name of the referring user

Optional

setReferrerImageURL:(NSString *) referrerImageURL;

The URL to referrer user avatar

Optional

setReferrerUID :(NSString *) referrerUID

Internal systems customer user ID

Optional

addParameterValue :(NSString *) value forKey:(NSString*)key

A single key value custom parameter

Optional

addParameters :(NSDictionary*) parameters

Multiple key value custom parameters

Optional

Recording the sender's invites

It is recommended to generate an in-app event after the invite is sent to record the invites from the senders' perspective. This enables you to find the users that tend most to invite friends, and the media sources that get you these users.

You can send a regular in-app event or use trackInvite method instead. trackInviteis a ready-made in-app event encapsulated in an API for easier use.

Android iOS

ShareInviteHelper.trackInvite(context, channel, additionalParametersForTheEvent_optional);

NSDictionary *optional_params = @{@"key": @"value"};

[AppsFlyerShareInviteHelper trackInvite:@"your_channel" parameters:optional_params];

Retrieving attribution data after invited user install

All the parameters passed in the link generator are available by calling getConversionData. This allows you to retrieve the relevant parameters (such as referrer name and avatar url) and personalize the first time experience for the new user. This is an example of the attribution data returned by getConversionData:

{

"attribute": "is_first_launch" = "true"

"attribute": "click_time" = "2019-04-04 08:33:05.668"

"attribute": "af_referrer_customer_id" = "CUSTOMER_USER_ID"

"attribute": "shortlink" = "12a3b456"

"attribute": "af_referrer_uid" = "1234567890123-4567890123456789012"

"attribute": "af_siteid" = "com.company.app"

"attribute": "install_time" = "2019-04-04 08:33:45.286"

"attribute": "cost_cents_USD" = "0"

"attribute": "campaign" = "None"

"attribute": "af_click_lookback" = "7d"

"attribute": "orig_cost" = "0.0"

"attribute": "af_status" = "Non-organic"

"attribute": "iscache" = "true"

"attribute": "media_source" = "af_app_invites"

}

More information about using conversion data: iOS and Android.

Using user invite links for reengagment

You can use user invite links for reengagment. However, you need to make sure that the invited user has the app installed. If a user who doesn't have the app gets a user invite links and installs the app, a click appears in the retargeting dashboard but the install appears in the overview dashboard.

To use user invite links for reengagment, add the parameter is_retargeting add set it to true using the addParameter method:

Android iOS Unity

AppsFlyerLib.getInstance().addParameter("is_retargeting", "true");

Objective C Swift

[generator addParameterValue: @"true" forKey: @"is_retargeting"];

generator.addParameterValue("true" forKey: "is_retargeting")

inviteDictionary.Add("is_retagerting", "true");

Rewarding on user invite

You can reward users who invite their friends to install your app. By rewarding, you encourage users to invite their friends. This is a great way to expand your user base and boost your revenue.

When to reward

You can reward users when their friends install your app after being invited. You can also reward users when their friends perform some in-app event like a purchase in your app.

Reward users on install

When an invited user installs the app, the ID of the referring user is found in the conversion data in the SDK :

af_referrer_uid - is the AppsFlyer ID of the user who sends the invite

af_referrer_customer_id - is the customer user ID of the user who sends the invite. Only appears in the conversion data if you set customer user ID for this user.

Use referrer ID to reward on install

Jenny invites Nivi to install your app.

When Nivi launches the app, the app fetches Jenny's referrer ID

The app sends the referrer ID to your backend

In your backend, add Jenny's referrer ID to a list of users to be rewarded

When Jenny launches her app, check if her referrer ID is inthe list of users to be rewarded

If it is, reward her

Reward users on in-app event

If you want to generate revenue through user invites, rather then just acquire users, you can reward on in-app events. In this case, you only reward referring users when the invited user performs an in-app event like a purchase or subscription.

The process of rewarding on in-app event

Jenny invites Nivi to install your app.

Set af_sub1 on The Invite Link

When Jenny invites Nivi, generate an invite link

In the invite link, put a parameter af_sub1=<JENNY_USER_ID>

Nivi installs the app and makes a purchase. When he makes a purchase, an in-app event is sent to AppsFlyer. This in-app event hassub1=<JENNY_USER_ID>associated with it.

Use af_sub1 to Update The List of Users to Be Rewarded

Pull in-app event data using pull API or get in-app event data from

In the data, look for events that haveaf_app_invites as the media source

Such events have af_sub1 associated with them that contains the referrer ID

Store referrer IDs in the list of users to be rewarded

Reward Jenny

When Jenny launches her app, check if her referrer ID is inthe list of users to be rewarded

If it is, reward her

Custom dashboard views

Below are the available views of the Custom Dashboard that show user invite information:

Introduction

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:

Watch

Read

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.

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.

Watch

Read

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.

In-app events mapping

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 theperiod 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.

For more information about AppsFlyer's retargeting attribution, click here.

For information about deep linking users from SRNs, such as Facebook's, click here.

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

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 describes five different 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:

You just set up the integration and AppsFlyer have yet to pull data.

There is no data in AppsFlyer about installs coming from the ad network.

Wait for AppsFlyer to pull data.

Start running campaigns with the ad network.

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 showsCost 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 messageLast 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 messageLast 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 messageLast 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 messageLast 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 Revenuetab 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_opened event. 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.

Click Save & Close.

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 Facebooks 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 AppsFlyers 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 andpredefined 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, infb_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.

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 SDKintegrated 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'sSDK in your app, you don't need Facebook'sSDKin it too.AppsFlyer'sSDKtakes 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 for Dynamic Product Ads campaigns In most cases you can perform deferred deep linking from Facebook, by using campaign or ad names from the conversion data, without using Facebook SDK. ForDynamic Product Adscampaigns, however, AppsFlyer doesn't get the matching product data from Facebook. Therefore, in order to deep link according to the specific product in these campaigns, you need Facebook SDK.

Other Facebook features You may need Facebook SDK for reasons unrelated to attribution such as authentication, ad monetization, social sharing, user invites etc.

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 "Link click" campaign on Facebook, which sends leads to a landing page.

The landing page includes a "Download App" button, which has a custom attribution link behind it. The link MUST include the landing page redirection parameter, af_r.

The lead clicks on the button and is redirected to the out-of-store market. After completing the installation the lead becomes an attributed user.

Note

Since it's not possible to extract the lead's device ID from the landing page on mobile web, AppsFlyer uses fingerprinting as the attribution method.

For specific instructions on attribution for apps in Amazon on Facebook click here.

Facebook spend (cost)

AppsFlyer gets spend data from Facebook for campaigns, having one or more installs during the previous seven days.

Getting Facebook costs, including clicks and impressions, is easy to setup but frequently questions about this arise.

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 30 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 30 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 doesnt 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: inthese 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 usingFacebook Ads. In AppsFlyer the advertiser sees the following:

The cost information is provided by Facebook to AppsFlyer. The number ofinstallsis 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

Facebook

AppsFlyer

Click Attribution Lookback Window

28 days

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 SourceAttribution

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 displays the data according to the local time zone of the logged in user.

AppsFlyer displays the data according to the time zone set for the app in the app settings dashboard page, regardless of the user's location.

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 morethan 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

The Facebook App ID set on Facebook may have a wrong value. 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

Make sure the Facebook campaign is Mobile app install adsor Mobile App Engagement. For other campaign objectives (e.g. Link Click for landing pages), to measure mobile installs, the advertiser must check the App Event recordingoption when defining the Facebook campaign.

Facebook app install

When setting up the Facebook app install campaign you can select the app from a dropdown list or paste the full store URL to the app. While both work for you on Facebook the second method fails AppsFlyer's attribution.

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?

Yes. In fact, AppsFlyer shows you also the single ad level, so you have 3 levels of drill down with Facebook Ads, campaigns >> ad groups >> ads.

Is Facebook data shown in real-time?

Yes, all installs and subsequent in-app events are shown in real time. However, the clicks, impressions and cost data AppsFlyer gets in an aggregated form from Facebook arrives periodically every few hours.

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?

If you have activated retargeting for Facebook you can get up to 100% more installs in your user acquisition campaigns, for free! How? Read here.

Do you make Facebook raw data available to agencies?

No. We are not allowed to provide Facebook raw data to agencies, this is because agencies are regarded as third parties in terms of Facebook's terms of services.

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 Facebooks Data Usage Terms for Advanced Mobile App Measurement.

Once an advertiser agrees to Facebooks Data Usage Terms, the data doesn't appear immediately. After theadvertiser 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?

Yes. AppsFlyer is integrated with dozens of Facebook Mobile Partners. These partners can be setup for attributing in the Integrated Partners page in the dashboard.

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?

28 day click and 1 day view are the maximum and default lookback windows for 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?

In some AppsFlyer APIs Facebook's parameters have different names than displayed on the dashboard, for backwards compatibility reasons. Consult the table below:

Conversion data

AppsFlyer raw data

Facebook

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 Facebooks user-level data?

Facebook requires attribution providers to delete its user-level data 6 months after the install. This means that the events performed by these users 6 months after they install the app are counted as organic. Past aggregate data remains the same. This is relevant for all Facebook channels (Facebook app, Instagram, Messenger, and AudienceNetwork).

At a glance: Ad networks report ad spend by sending CSV files by email or file uploading.

In Appsflyer, ad spend is reported on the click, by Cost API and by Ad Spend Ingestion. Ad Spend Ingestion is available to ad networks and advertisers.This quick start guide for ad networks provides an overview and a step-by-step workflow on how to use ad spend ingestion. For the detailed article see Ad Spend Ingestion.

Ad Spend Ingestion for ad networks

Ad networks report ad spend by preparing CSV files that contain details of the spend. Files are submitted by email or by using the Ad Spend Ingestion user interface.

The advertiser (app owner) needs to grant the ad network permission to submit and manage ingestions in the AppsFlyer platform. This is a simple and brief process.Note: Permission is granted for each app individually.

The CSV columns (fields) are as follows:

Date of spend

App ID (multiple apps allowed per file if they all belong to the same owner)

Media source (one per file allowed)

Campaign name

Spend amount

Geo (optional)

Currency

Upload workflows for ad networks

We recommend that initially, ad networks use the file upload workflow.

Workflow for ad networks: File upload in the user interface

Step

Description

Link

1

Request that the advertiser grant you spend ingestion permission

Grant spend ingestion permission

2

Prepare the CSV file

CSV file format and schema

3

Upload and ingest the file in the user interface

Uploading ad spend files

4

On completion of the ingestion, use the interface to monitor the ingestion:

Status

Percentage of matched rows

Ad spend ingestion actions

Additional procedures

Overwrite previous ingestion

Overwrite

Revert (cancel)

Revert

Workflow for ad networks: Upload file by email

Step

Description

Link

1

Request that the advertiser grant you spend ingestion permission

Grant spend ingestion permission

2

Get an ad spend token

Get an Ad Spend token

3

Prepare the CSV file

CSV file format and schema

4

Send the file by email

Email

5

Wait for an email status report from AppsFlyer detailing if the ingest was successful or if any issues were found.

6

Use the interface to monitor the ingestion:

Status

Percentage of matched rows

Ad spend ingestion actions

Additional procedures

Overwrite previous ingestion

Overwrite

Revert (cancel)

Revert

At a glance:Ad SpendIngestion provides advertisers with 100% coverage of their spend reporting needs. Advertisers and ad networks can record the ad spend (cost) from media sources that don't report spend by API or click.

Quick start guidefor ad networks

Full Ad Spend data

Use Ad Spend Ingestion to record ad spend (cost) from media sources that don't report the spend by click or API. Doing so enables you to have a complete picture of your ad spend and ROI in the Dashboard.

Ad spend can be recorded at the campaign level. This is done by using CSV files. The files are uploaded to the Dashboard and ingested. The updated aggregate ad spend displays in the Dashboard and aggregate data several minutes thereafter.

Advertisers and ad networks can send and manage spend files. Agency support is on the roadmap.

Previously ingested ad spend data can be overwritten if required.

Example use cases:

Record the spend incurred originating from networks that do not send spend data by API or attribution link

Offline channels, like radio campaigns and billboards

Influencers

To manage Ad Spend Ingestion go toIntegration> Ad Spend Ingestion.Note: The Ad Spend Ingestion page is an account level page. This means you manage ingestions for all apps in the account using the same page.

Preparing, uploading and ingesting ad spend files

Use one of the following workflows to prepare, upload, and ingest your ad spend files.

We recommend that initially, you use the file uploadmethod. This is because error messages due to file format and content issues display immediately making it simpler for you to resolve issues.

Upload workflows

Workflow: Upload file in the user interface

Step

Description

Link

1

Step for ad networks only:Before anad network can send files, the advertiser needs to grant the ad networks permission

Grant spend ingestion permission

2

Prepare the CSV file

CSV file format and schema

3

Upload and ingest the file in the user interface

Uploading ad spend files

4

On completion of the ingestion, use the interface to monitor the ingestion:

Status

Percentage of matched rows

Ad spend ingestion actions

Additional procedure: Overwrite previous ingestion

Overwrite previously ingested spend

Workflow: Upload file by email

Step

Description

Link

1

Prerequisite step for ad networks:Before an ad network can send files, the advertiser needs to grant them permission.

Grant spend ingestion permission

2

Prerequisite: Get an ad spend token

Get an Ad Spend token

3

Prepare the CSV file

CSV file format and schema

4

Send the file by email

Email

5

Wait for an email status report from AppsFlyer detailing if the ingest was successful or if any issues were found.

6

Use the interface to monitor the ingestion:

Status

Percentage of matched rows

Ad spend ingestion actions

Additional procedure: Overwrite previous ingestion

Overwrite previously ingested spend

Procedures

CSV file format and schema

The ad spend CSV file format, schema, and validation rules are detailed here. If you use Excel to create the file, you must see Excel formatting instructions.

Note

Don't use Excel to either view or verifythat CSV file is formatted correctly. Instead, use an editor

Content rules and schema of ad spend CSV files

File structure and content rules

Item

Requirement

Media source

One media source per file

Multiple apps for the same media source are permitted

Limitations:

Don't send spend data from a media source that has an existing Cost API integration with AppsFlyer. Ingestion is not allowed from these sources. This includes Facebook Ads, Apple Search Ads, and Snapchat.

Don't send ad spend where the CPI is reported on the click attribution link. Doing so will result in duplicate spend reporting. (We expect this limitation to be temporary)

App owner

One advertiser (app owner) per file permitted. This means that multiple apps from the same advertiser are permitted.

Filename extension

CSV Example: abc123.csv

File structure

Format: Files have a CSV format meaning that each column is separated by a comma

Header row: The first row is a header row that matches the schema

Data rows:Contain the mandatory columns.Note: Ensure that there are no trailing blanks in your data. For example, [USD ] (a blank follows theDshould be changed to [USD].

Blank rows: Not permitted

Ad Spend CSV schema

Column name

(case sensitive)

Format/remark

Example

Mandatory

date

The date the spend was incurred

Format: YYYY-MM-DD

Future dates not permitted

Note: Are you using Excel to prepare the file? Read this.

2019-05-30

Yes

app-id

App ID as it appears in the Dashboard.

Multiple apps are allowed in a single file

All apps need to belong to the same advertiser

com.app.name

id12356789

Yes

media-source

Media source as it appears in the Dashboard.

Only one media source per file permitted.

network_x_int

Yes

campaign

Campaign name. If the campaign name appears in the ad network, it should match (case sensitive) to the name as it appears in the ad network.

campaign_a

Yes

spend

Monetary spend

5 digits allowed after the decimal point

The value 0 (zero) is permitted

Note:

The format "2,874.12" is not permitted.

Are you using Excel to prepare the file? Read this.

2874.12345

Yes

geo

Two-letter country code compliant with ISO 3166Note: Ensure that you send 2 characters with no blanks.

US, GB, CN, AU

Optional

currency

Three-letter currency code compliant with ISO 4217.Note: Ensure that you send 3 characters with no leading or trailing blanks.

One currency code per app in the file allowed. Different apps can have different currency codes.

USD, GBP, EUR, JPY

Optional. Will default to USD if left empty.

Getting an Ad Spend token

The Ad Spend token is used to verify that the email sender is authorized to submit the ad spend file. Advertiser and ad networks tokens are different.

Caution

Advertisers do not share your token with ad networks.

The ad networks has their own unique token.

Advertiser token:

The same token is valid for all apps in the account

Any team member can retrieve the Ad Spend token

Ad network token:

The same token is used for all advertisers.

In addition, the advertiser needs to grant the ad network permission to submit ingestion files.

To retrieve the ad spend token:

Go to Integration > Ad Spend Ingestion.

In the upper right-hand of the page, click View Ad Spend token. The Ad Spend token is displayed.

Copy and save the Ad Spend token.

Granting an ad network spend ingestion permission

To grant the ad network Ad Spend Ingestion permission:

The advertiser needs to go to Configuration> Integrated Partners.The Integrated Partner page displays.

Select the integrated partner.

Go to the Permissions tab.

EnableAd Network Permissions if it is not already so.

(optional) Add team members.

Enable Allow spend ingestion.

Sending ad spend files by email

Email prerequisites:

Advertisers: Ad Spend tokenis required.

Ad networks:

Ad spend token is required.

The advertiser needs to grant the partner (ad network) ad spend ingestion permission

To send the ad spend file by email:

Complete the email address fields:

To: [email protected].

CC: Users who should get a copy of the automatic feedback

Subject: Paste theAd Spend token in the subject field.

Attachment: CSV file with the data.

Send the email.

On completion of processing, a status email is sent that summarizes the upload and detailing issues or errors found during processing. The email is sent to all parties on the submission email and to the advertiser admin. Where errors are identified you should take corrective measures.

You can view the status of files submitted in the Ad Spend Ingestion page

Uploading ad spend files

To upload the ad spend file:

In the Dashboard, go to Integration> Ad Spend Ingestion.The Ad Spend Ingestion page displays.

Click + Ingest Ad spend fileThe Ingest Ad spend window opens.

Drag the CSV file to the Ingest Ad spend filewindow. The Processing file message displays.

If an error message displays during upload: rectify the error and repeat the relevant steps.

The Ad spend ingestion: file summarywindow opens. example CSV file

Do one of the following:

Abort the upload, click Cancel ingestion.

Complete the ingestion process, click Ingest file. The message, All set! displays.

Click Ingest another file or Done.

Managing Ad Spend Ingestions

On the Ad Spend Ingestion page, you can perform the following actions.

Monitor the status of ingested files: To identify ingestion files that require your attention as the data may not have been ingested or was ingested partially. You may need to resubmit these files.

Monitor unmatched rows:Thematched rowsindicator displays the percentage of matched rows. If unmatched rows are unexpected, you should examine the data, by downloading the unmatched reportto identify the root cause.

Download copies of CSV files submitted

Revert (cancel) the ingestion

Permission to view uploaded files and unmatched reports:

All team members can access the Ad Spend Ingestion page

Access to detailed information is restricted to team members who have app permission.

If a file contains the data of multiple apps, the team member requires access to all the apps referenced in the file.

Ad Spend Ingestion actions

To view the ingestion status at the file level:

Go to, Integration >Ad Spend Ingestion.The Ad Spend Ingestion page displays, the list of uploaded files displays.

If you have app permissions to all the apps contained in the file, use the Action command to:

Download CSV file: This a copy of the CSV file that was uploaded.

Download unmatched report for all apps in the file.

To view the ingestion status at the app-level:

Select the file. The app-level page displays. The list of apps in the ad spend file displays.

Perform file-level or app-level actions as described here.

File-level: If you have app permissions to all the apps contained in the file, you can use the controls in the upper-right right side of the page to:

Revert (cancel)the Ad Spend Ingestion for all apps in the file.

Downloada copy of the CSV file that was submitted.

App-level:If you have app permission for a specific app you can do so by using the Action command:

Download app data.

Download unmatched reportfor the app

Revert (cancel) the Ad Spend Ingestion for the selected app.

Status indicators

Status

Remarks

Applied

Action completed successfully

Reverted

Action completed successfully

Error processing data

AppsFlyer system problem. Wait 10 minutes and try again. If it fails again contact AppsFlyer support.

No permissions

The token is not approved for this app.

Advertisers: check to that that app id is correct.

Partner: confirm with the advertiser that they have enabled allow spend ingestionin the integrated partners permission tab.

Validation error

Row matching and the unmatched report

Row matching is the process where the ingestion mechanism matches the spend rows reported by ingestion with campaign performance rows already recorded in the Dashboard. This is done using the media source, campaign, date fields as a key.Note: Irrespective of the matching status the spend is recorded.

Example: Matched and unmatched rows

Date

Media source

Campaign

Impressions

Clicks

Cost

Matching status

2019-01-01

example

abc

5000

100

$1000

is-matching = TRUE Performance information found

2019-01-02

example

abc

is-matching = FALSE No performance information on 2019-01-02

2019-01-02

example

influencer

$2500

is-matching = FALSE No performance information on 2019-01-02

The percentage of matched rows displays in the ingest page.

If unmatched rows are unexpected, download the unmatched report to investigate the cause. If necessary cancel the ingestion by reverting it.

The Unmatched report contains a column, is-matched which can have a value of TRUE (matched) or FALSE (unmatched) rows.

Ad Spend Ingestion page displaying the percentage of matched rows

Overwrite (correct) previously ingested spend

Previously ingested spend can be overwritten by using CSV files that contain data with the identical key of data previously ingested.

The key is formed from the date, media source, and campaign fields. If the keys match, data ingested last overwrites data previously ingested.

The following examples illustrate ad spend overwrite.

Example: Ad spend overwrite

+ indicates the mandatory fields

Example A

Spend1.csv ingested on Monday

Date+

App ID+

Media Source+

Campaign+

Spend

2019-06-01

com.my.app

network_x

campaign_a

100

Spend2.csv ingested on Tuesday

Date+

App ID+

Media Source+

Campaign+

Spend

2019-06-01

com.my.app

network_x

campaign_a

200

The spend data from spend1.csv was overwritten by the spend data in spend2.csv. This is because spend2.csv was ingested last and the mandatory field which for the key are the same.

Example B

Spend3.csv ingested on Monday

Date+

App ID+

Media Source+

Campaign+

Spend

Geo

2019-05-01

com.my.app

network_x

campaign_a

100

US

2019-05-01

com.my.app

network_x

campaign_a

200

CN

Spend4.csv ingested on Tuesday

Date+

App ID+

Media Source+

Campaign+

Spend

2019-05-01

com.my.app

network_x

campaign_a

50

The spend data from spend3.csv was overwritten by the spend data in spend4.csv. This is because spend4.csv was ingested last and the mandatory fields which form the key are the same. Note: Both spend3.csv rows are overwritten.

Troubleshooting

Using Excel to format date and spend fields of CSV files

When using Excel to create a CSV file, the date and spend columns need to be formatted correctly before you save the file as a CSV file. Use the procedures here to format the date and spend fields correctly.

After saving the CSV file, verify that the content is formatted correctly. Note: Don't use Excel to do the verification, rather use an editor.

Formatting date cells in Excel

To format date cells in Excel with the format YYYY-MM-DD:

Select the cells to be formatted.

Right-click, select Format cells. The format cells window opens.

Select Custom.

In the Type field, enter YYYY-MM-DD

Click OK.The date is formatted.

Formatting Spend cells in Excel

Excel usually formats value cells with a comma to separate the thousands as shown in the figure. This format is not suitable for ingestion.

You can correct this by formatting the cells in Excel.

To format the Spend amounts without a 1000 separator:

Select the cells to be formatted.

Right-click, select Format cells. The format cells window opens.

Select Number.

ClearUse 1000 separator (,).

(Optional) Set the number of Decimal places. The default is 2. The maximum permitted is 5.

ClickOK. The cells are formatted correctly.

Visual inspection of the CSV file without Excel

To examine the content of the CSV file use an editor to view the file.

Windows: Notepad, Notepad++

macOS: TextEdit

The following contains a screenshot of the displayed in an editor.

Editor view

Using an editor examine the CSV file. Pay special attention to the following:

Blank spaces: Ensure that there are no leading or trailing blank spaces before or after the commas that separate the fields. In Excel, use the @trim command to remove blank spaces.

Date:Ensure that the date field has the format YYYY-MM-DD.

Spend: Ensure that there is no comma in the spend field.

At a glance: Convert desktop users to mobile app users using SMS vendors and OneLink.

here

Introduction

If your brand has both a web app and a mobile app, desktop web users might decide at some point that they want to install the mobile app.

To help them do so and for better user experience, you can text them a direct link to the app. This is the quickest way to help them install the app.

This way, they don't have to open the app store on their mobile, find your app and install it. When you save users the time and effort, they are more likely to convert and install your mobile app.

Note

for mobile web users, you can just feature a OneLink in the mobile version of the website.

Requirements

To text desktop users a link to your mobile app you need the following:

An SMS provider account like Twillio, AWS SNS or bandwidth.com.

A backend environment where you can handle the logic for texting links to users.

A multi-platform custom link such as OneLink.

Setting up

The following section is a high-level overview of the requirements discussed earlier.

SMS provider account to text a link to the app

Create an account with an SMS provider. You can send links to your mobile app to a large number of users at any given time.

You can use the following SMS providers:

Twillio

bandwidth

AWS SNS

Braze

Airship

Swrve

Mixpanel

Each of the providers listed supports a variety of programming languages and provides comprehensive API for various use cases.

A backend environment to communicate with the SMS provider

SMS providers require authentication tokens to use their services. In addition, user phone numbers are sensitive data. Due to these aspects, the best thing to do is to handle everything from your backend.

A multi-platform custom link

A multi-platform custom link redirects the user to the correct app store or destination according to the device they have. This way you can send the same link to any user no matter what device they have.

Texting the app to users

This section describes the flow of texting users a link to the app. It also explains how to follow up on the number of users that install the app from the link.

Create a multi-platform OneLink

Create a multi-platform OneLink to put in the SMS. When you create the link, you have the option to define the media source and campaign. We suggest that you set the media source and campaign as follows:

media source: website

campaign: text-me-the-app

When sending OneLink in SMS, it's best to use the short link version of the OneLink. See here to learn more.

To learn how to create the link, see here.

Set up an SMS topic in your SMS provider account

In this step, you create an SMS topic or message that contains the OneLink to the app. This SMS is sent when users fill out and submit a form with their phone number. When users submit the form, your backend receives the request and communicates with the SMS provider API to send the link.

Set up a web form to collect phone numbers

In your website, at pages of your choice, set up a call-to-action to prompt users to install your app. The call-to-action should open a web form through which users can submit their phone numbers.

Apply logic in your backend

On submitting the form, the website should send a request to your backend. The backend receives the phone number and sends a request to the SMS provider to text a link to the app to the user's phone.

Refer to your SMS provider API and documentation to learn how to create the logic in your backend.

How Attribution works when sending a link to the app

There's no way to include the advertising ID when texting desktop users a link to the app. Therefore, AppsFlyer resorts to attribution using fingerprinting.

AppsFlyer limits the lookback window for fingerprinting clicks to maintain accuracy. The limits are:

iOS - up to 24 ours

Android (Google Play) - up to one hour

Android (out-of-store) - up to 24 hours

Encourage your users to install as close as possible to the click so that AppsFlyer can accurately attribute the install to the texted link. You can do so by offering coupons, discounts, or game credits.

People-based attribution

There are more ways, other than texting a link to the app, in which users convert from web to app. It's not always clear where these users come from and what media sources and campaigns contribute to their conversion.

To get more insights into how many web users convert to mobile apps users, and what media sources and campaigns are involved in the process, use People-based attribution.

People-based attribution (PBA) puts together data from both web and mobile app campaigns. The consolidated data helps you analyze user journeys across platforms and user transition from web to mobile apps.

To learn more, see .

The main sources of mobile user traffic which AppsFlyer records are:

Integrated Partners

Facebook, Adwords, Snapchat, Twitter, etc.

Owned Media

Email and SMS campaigns, web site banners and landing pages, viral posts on social media, Push notifications or even QR codes on print, in-Store and out of home media.

Owned media is a great source of abundant (and mostly free) traffic. It's important to record and attribute it properly, to get more installs and better engagements from your new users.

To attribute owned media it's necessary to create and manageCustom Attribution Links.

In Link Management you manager custom attribution links.

1. Getting there

1.1 Log into Appsflyer.

1.2 Go toEngagement & Deep Linking >Link Management.

1.3 You can also access it by clicking Integrated Partners on the left bar, and then clicking Custom Attribution Link at the top right corner of the page

2. First time

If this is the first time you (and your team) have entered the link management screen, the following page is displayed:

Click on Add Custom Attribution Link to create your first attribution link.

3. Custom link management page

If you already have defined one or more links beforehand, you are now in the link management page.

Here you can see the details of all defined custom links, including their names, media sources, relevant app or apps, the attribution links and the last date of modification.

3.1 Editing your existing links

Click on an existing link's name to view or modify its previous setup.

Once you're finished click on

3.2 Actions Button

There are several actions you can perform per link by clicking on its Actions button:

3.2.1 View Link Details shows the saved link's short and long URLs:

Note you can only view, but not modify, the links on this page.

Hover over the button next to the short or long URLs to copy them. You can also download the QR code image for each of the links.We strongly recommend using the short link URL - here's why.

3.2.2 Show History provides an audit of the users that have created or modified the link, from the latest modification to the first creation.

3.2.3 Duplicate Link creates a new link with the exact same settings. If you have a common template for links and you want to easily create many links with some minor variations (e.g. links for influencers), this option is very useful. Note that you can't modify the app or OneLink selection on duplicated links.

3.2.4 The Delete option only removes the link from the Link Management table. Any existing links still redirect.

Short vs long URLs

Important!

Should you use short or long URLs? AppsFlyer recommendation is clear - short URLs are better, for several reasons:

Short URLs enable campaigns with limited text space, such as SMS campaigns.

Short URLs hide the parameters and business logic of your ads, that is otherwise exposed to the user.

Short URLs enable you to change the used parameters once on AppsFlyer's dashboard, and affect links on the fly. For example, having started an SMS campaign with several providers, you realize you didn't add the channel parameter with the name of the SMS provider. With short URLs you can simply add the parameter on the dashboard - all leads, even those who already received your message, are attributed to the new channel.

You can keep using the QR code of a short link, even if you update the link's parameters.

4. Creating custom attribution links

4.1 Click on (if you haven't already)

4.2 Select what type of link to create, single-platform (regular app-specific) or multi-platform (OneLink).

Important!

Single or Multi-platform - that is the question. The answer is - usually multi-platform. As the single-platform links are app-specific, you should use them only for tests, or when all your targeted audience has the same platform, e.g. all leads have Android devices. Otherwise, AppsFlyer recommends using multi-platform to benefit from OneLink's diagnostic, redirection and deep linking capabilities.

iOS Universal Links Another reason to use multi-platform OneLink configuration is iOS Universal Links. Single platform configuration doesn't support iOS Universal Links. In that case, you should use multi-platform OneLink configuration with only an iOS app.

4.3 General settings

4.3.1 Name the new link with an easily recognizable name. You can use letters, digits and spaces, but refrain from using other special characters. If the name you set is unique and valid the box displays:

Single-platformMulti-Platform

4.3.2 Select the app the attribution link is intended for

4.3.2 Select the OneLink configuration the attribution link is intended for

Note

For single-platform links, team members can only select apps that are associated with them. For multi-platform links, a team member can only select a OneLink template, when the member has access to one or more of its associated apps. Likewise, agencies can only select apps and OneLink templates, that are owned by them or that they're partners of.

4.3.3 Short URLThe link gets an automatic shorter URL, which is very useful with SMS campaigns etc. You can customize the last part in the short URL to make it a branded link. Note you can use only letters and digits here (a-z, A-Z, 0-9). If the URL you set is unique and valid the box displays

If you use Branded Links, you can choose your branded link from the drop down menu:

Warning

The short URL becomes usable and final only when you click, upon which the short URL cannot be changed anymore.

4.4 Attribution settings

4.4.1 Set the Media Source Name

Enter your owned media source name, or use one of the predefined ones according to common use cases such as posting a link in your Blog or Social Facebook page.

Enter your owned media source name manually in the box or click one of the tabs (e.g. Email). The media source value is represented in the attribution link, under the pid parameter.

Note

To properly differentiate between your custom attribution links and AppsFlyer integrated partners attribution links, do not use "Facebook", "Facebook Ads", "GoogleAdwords", "Twitter" or "Organic" as your custom media source name (case insensitive). Using these names for custom attribution links may affect your attribution data's integrity as installs from your owned media would get attributed to integrated partners.

Attribution link parameter: pid

Note

Integrated Partner reserved pid values (ending with _int), cannot be used as media source values in Custom Attribution Links. Use the Integrated Partners setup to create partner-related attribution links. For more details, click here.

If you need to use OneLink with integrated partners, here's how.

4.4.2 Set Optional Attribution Parameters

You can add further attribution parameters here to enable you to later perform thorough drill-down analyses.

Campaign - add it to compare different campaigns within the owned media source. Attribution link parameter: c

Adset - set ad set names to compare different ad sets within specific campaigns of the media source. Attribution link parameter: af_adset

Ad Name - set ad set names to compare different creatives within specific ad sets within specific campaigns of the owned media source. Attribution link parameter: af_ad

Channel - set Channel names if you have more than one distribution channel for your owned media, which you wish to compare. For example, if you split your SMS messages between 2 SMS service providers, specify on the Channel parameter which provider it is. Later you can compare conversion rates to decide on the better provider. Attribution link parameter: af_channel

Subscriber Parameters - use any of the 5 subscriber parameters to insert useful values. Note that these parameters get parsed and appear in the raw data report, which makes them very handy for performing data aggregation or filtering. Attribution link parameters: af_sub1, af_sub2, af_sub3, af_sub4, af_sub5

Custom Parameters - similar to the subscriber parameters, you can use fields with any values, and also any names. However, these are not parsed and made available on the raw data reports, only as part of the full original URL. Attribution link parameters - Custom

See more information about AppsFlyer's Attribution Link Structure and Parameters.

Important!

When you set parameters on the attribution link, make sure that you use consistent naming. Do not use upper and lower case names intermittently.

If you don't keep the same case in parameter names, it might cause issues with viewing data in the dashboard and raw data.

For example, if you set pid=MyMediaSource on one attribution link and pid=mymediasource on another, discrepancies in data might occur. The same goes for any other param that you set on the attribution link. If you choose a case, upper or lower, make sure you always use it.

4.4.3 Set Retargeting

Enable the Retargeting Campaign toggle button to use this link primarily for retargeting attribution, rather than for user acquisition.

Attribution link parameter: is_retargeting

4.5 Redirection settings

Single-platformMulti-Platform

4.5.1 Mobile Deep Link and Redirection

To deep link your existing users straight into some activity in your app, default or otherwise, enter the URI scheme that represents the activity in this box. To learn about deep linking with AppsFlyer go to the step by step deep linking guide.

Attribution link parameter: af_dp

4.5.2 Advanced Redirection

Single-platformMulti-Platform

To send your leads over to a landing page instead of directly to the app stores:

Select Landing Page

Paste the URL of the web page on the box

This is extremely useful when posting links to platforms where deep linking breaks, e.g. Facebook.

Attribution link parameter: af_r

You can send your leads to different landing pages, instead of the app stores, based on the platform they're using while engaging with your owned media.

1. Desktop users - Paste the URL of the landing page on the Web Deep Link URL box

2. iOS users - Select iOS Landing Page and paste the URL of the iOS landing page on the URL box to its right

3. Android users - Select Android Landing Page and paste the URL of the Android landing page on the URL box to its right

This is extremely useful when posting links to platforms where deep linking breaks, e.g. Facebook.

Attribution link parameters: af_web_dp, af_ios_url, af_android_url

Note

Multi platform links should already have values taken from the OneLink template configuration page. Fill in the above boxes only if you need new values that differ from the OneLink template.

Important!

If both deep linking and landing page redirection are set, AppsFlyer attempts deep linking first. If it fails (e.g. the app is not installed yet), the redirection to the landing page takes place.

Preventing parameter forwarding on redirections

af_r, af_ios_url, af_android_url, and af_web_dp carry over parameters from the attribution link or OneLink over to the redirected page. To prevent such parameters from being carried over the redirected page, add af_param_forwarding=false to the attribution link.

4.6 Social media apps landing page

In iOS, if thesocial media app doesn't support deep linking using Universal Links, this can be overcome by implementing a social media app landing page. Doing so enables theuse of OneLink with Universal Links to deep link users.

A social media app landing page can be used in the following:

Instagram

Facebook

Pinterest for iOS

Twitter

WeChat

User experience

When using a landing page, the user experience depends on whether the app is installed or not.

The user clicks on the custom link:

App installed: the user is deep linked into the app.

App not installed: the user is taken to the relevant app store.

Note

The social app landing page only supports OneLink short URL.

To set up a social app landing page:

Configure the landing page as described below.

To fully support deep linking on both IOS and Android, addaf_dp and af_force_deeplink=true to the attribution link.

Grab the generated short URL. Note that the Social media apps landing page does not work with long OneLink URLs.

Post the OneLink short URL on the social app.

Attribution is determined by attribution settings in step 4.4.

To configure the Social apps landing page:

Enable landing page

Image URL: Enter an image URL including the extension. Example, https://example.com/image.png. Use one of the following file types:

jpeg

jpg

png Note: webp format is not supported. The recommended ratio and dimensions for the image are:

Ratio - 1:1

Dimensions - 320px x 320px

Fill out the following fields and select a color for each.

Tag:The tag usually contains the campaign topic.

Title

Description

Call to action

(Optional)Disclaimer

4.7 Advanced settings

4.7.1 Customized Lookback Window

Enabling the Customized Lookback Window button allows you to set the maximum click to install time. Installs (first launches) that take place within the lookback window are attributed to the media source. Installs that take place afterwards, are attributed as Organic.

By default the window is set to 7 days, but you may wish to set it otherwise in different cases.

Example

A regular 7 day lookback window for Email campaigns is reasonable. However, if an email contains an attractive and memorable video, it makes sense to extend its lookback window to 14 days.

More details about the click lookback window here.

Attribution link parameter: af_click_lookback

4.7.2 Cost per Install

Enabling the Cost per Install button allows you to apply a specific CPI value for each install coming from the link.

Select the cost currency and then a numeric ONLY value (float - up to 4 digits after the decimal point) representing the CPI.

Example

An SMS campaign costs $20 per 1000 messages (CPM). From your experience these campaigns achieve a 5% conversion rate, i.e. the derived CPI is $1. Setting the cost per install to 1 USD enables you to easily see the eventual ROI of the SMS campaign.

More details about measuring cost and ROI here.

Attribution link parameters: af_cost_currency, af_cost_value

4.8 Finalize the linkset up by clicking

4.9 Grab the short or long link, in either text or QR code format

4.10 Test the link by sending the link to your device and clicking on it or by scanning the QR code - the result for either is the same: a click is recorded in the dashboard

Tip

Are you planning on testing custom links? Save time by scanning the QR code directly from your mobile testing device. Scanning the QR code is the same as clicking the link.

Limitations

Important!

It is very important that you pay attention to certain length limitations during the creation of the URLS:

Total URL length must not exceed 2000 characters

Link Name and Media Source: must not exceed 100 characters

The following characters are not allowed [<>;(){}`']

Shortlink ID must not exceed 50 characters

uninstall measurement SDK Version: 5.0.0 ( Release Notes )

1. Overview

AppsFlyer Android SDK provides app installation and event recording functionality as part of AppsFlyer's complete attribution solution. The SDK is market-proven, secure, lightweight, and simple to embed.

With the embedded SDK you can record installs, sessions and additional in-app events (e.g. in-app purchases, game levels, etc.) to evaluate user engagement levels and even ROI!

1.1 SDK integration - what you need to do

Tab

Purpose

After completing

SDK integration (Mandatory)

Adding and configuring the SDK

A new organic install in your app's dashboard.

A new non-organic install in your app's dashboard.

Core APIs (Highly Recommended)

Measure in-app events, revenue, perform deep linking, and gather conversion data

In-app events and revenue appear on your dashboard.

You are able to perform deep linking.

Additional APIs (Recommended)

Implementation and usage of optional APIs

We recommend checking this list, as some optional APIs may be vital for your business plan, e.g. uninstall measurement or referrals attribution.

You are able to measure uninstalls, referrals, and user engagement with push notifications.

API reference

Quick reference of the SDK APIs for developers

1.2 SDK compatibility with Android platforms

Android OS version 2.3 and above

Non-mobile Android-based platforms such as Smart TVs, including Amazon's Fire TV

Out-of store markets for Android apps, e.g. Amazon, Baidu

This tab explains how to implement and initialize the AppsFlyer SDK, and is written for app developers. After completing this tab, you will see two installs in your app's dashboard, one organic and one non-organic.

2. Adding the SDK to your app

2.1 Adding the SDK to your project

There are two ways to add the SDK to your app:

Using Gradle (recommended)

Manually adding the SDK

Adding the SDK Using Gradle Manually Adding the SDK

Add the code below to Module-level /app/build.gradle before dependencies:

repositories {

mavenCentral()

}

Add the latest version of AppsFlyer SDK as a dependency. You can find the latest version here.

dependencies {

//make sure to use the latest SDK version: https://mvnrepository.com/artifact/com.appsflyer/af-android-sdk

implementation 'com.appsflyer:af-android-sdk:5.0.0'

}

Sync the project to retrieve the dependencies - see the following screenshot:

Download the AF-Android-SDK.jar

Add it to the project

2.2 Adding Android install referrer

The Android Install Referrer improves attribution accuracy, protects from install fraud and more. It is supported from AppsFlyer Android SDK version 4.8.6.

Add the Install Referrer

Add the Android Install Referrer as a dependency. You can find the latest version here.

dependencies {

//make sure to use the latest SDK version: https://mvnrepository.com/artifact/com.appsflyer/af-android-sdk

implementation 'com.appsflyer:af-android-sdk:5.+'

implementation 'com.android.installreferrer:installreferrer:1.0'

}

Sync the project to retrieve the dependencies - see the following screenshot:

If you are using ProGuard and want to use Google's new referrer API, set the following ProGuard rule: -dontwarn com.android.installreferrer

If you are not using gradle:

Download the Install Referrer aar

Add it to the project

Add the following permission to the manifest: com.google.android.finsky.permission.BIND_GET_INSTALL_REFERRER_SERVICE

2.3 Setting required permissions

Adding permissions helps increase the rate of fingerprinting attribution. It also allows the SDK to send more data like Wifi and carrier network data. You can find this data in raw data reports and use it for analysis and optimization of campaigns.

Add Required Permissions

Add the following permissions to AndroidManifest.xml:

<uses-permission android:name="android.permission.INTERNET" />

<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />

<uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />

<!-- Optional : -->

<uses-permission android:name="android.permission.READ_PHONE_STATE" />

2.4 Setting BroadcastReceiver to get data from Google Play

The BroadcastReceiver gets information from Google Play that AppsFlyer uses for attribution. Using the BroadcastReceiver increases the attribution rate.

The following two options are available for implementing the install referrer BroadcastReceiver:

Single BroadcastReceiver Multiple BroadcastReceiver

If you do not have a receiver listening on the INSTALL_REFERRER, in AndroidManifest.xml, add the following receiver within the application tag:

<application>

<receiver android:name="com.appsflyer.SingleInstallBroadcastReceiver" android:exported="true">

<intent-filter>

<action android:name="com.android.vending.INSTALL_REFERRER" />

</intent-filter>

</receiver>

</application>

If you already have a receiver listening on the INSTALL_REFERRER, AppsFlyer provides a solution that broadcasts INSTALL_REFERRER to all other receivers automatically. In the AndroidManifest.xml, add the following receiver as the FIRST receiver for INSTALL_REFERRER, and ensure the receiver tag is within the application tag:

<application>

<receiver android:name="com.appsflyer.MultipleInstallBroadcastReceiver" android:exported="true">

<intent-filter>

<action android:name="com.android.vending.INSTALL_REFERRER" />

</intent-filter>

</receiver>

</application>

Tip

If you get the error "Unresolved class SingleInstallBroadcastReceiver" after adding the receiver to AndroidManifest.xml, make sure to build the app first.

3. Implementing and initializing the SDK

This section describes how to implement and initialize AppsFlyer Android SDK.

3.1 Retrieving your dev key

AppsFlyer uses the dev key to uniquely identify your account. The dev key is mandatory because it allows the SDK to securely send and retrieve data that belongs to your AppsFlyer account.

Important: it is crucial to use the correct dev key when initializing the SDK. Using the wrong dev key or an incorrect dev key impact all traffic sent from the SDK and cause attribution and reporting issues.

To retrieve your dev key:

Go to your app's dashboard.

In the dashboard, under Configuration click App Settings.

Copy your dev key.

3.2 Initializing the SDK

We recommend initializing the SDK inside the app's global application class. This allows the SDK to initialize in all scenarios, including deep linking.

The steps listed below take place inside the app's global application class.

Inside the app's global class, import the following libraries

import android.app.Application;

import com.appsflyer.AppsFlyerLib;

import com.appsflyer.AppsFlyerConversionListener;

import java.util.Map;

Inside the global class, assign your dev key to a variable, preferably named AF_DEV_KEY. Important: it is crucial to use the correct dev key when initializing the SDK. Using the wrong dev key or an incorrect dev key impact all traffic sent from the SDK and cause attribution and reporting issues.

Java Kotlin

public class AFApplication extends Application {

private static final String AF_DEV_KEY = "qrdZGj123456789";

//...

}

class AFApplication : Application() {

private val devKey = "qrdZGj123456789";

//...

}

Inside the global class, after the call to super.onCreate(), implement the AppsFlyerConversionListener. See code below in step 4.

Inside the global class, after the ConversionListener, initialize the SDK and call the startTracking method

Java Kotlin

public class AFApplication extends Application {

private static final String AF_DEV_KEY = "qrdZGj123456789";

@Override

public void onCreate() {

super.onCreate();

AppsFlyerConversionListener conversionListener = new AppsFlyerConversionListener() {

@Override

public void onConversionDataSuccess(Map<String, Object> conversionData) {

for (String attrName : conversionData.keySet()) {

Log.d("LOG_TAG", "attribute: " + attrName + " = " + conversionData.get(attrName));

}

}

@Override

public void onConversionDataFail(String errorMessage) {

Log.d("LOG_TAG", "error getting conversion data: " + errorMessage);

}

@Override

public void onAppOpenAttribution(Map<String, String> conversionData) {

for (String attrName : conversionData.keySet()) {

Log.d("LOG_TAG", "attribute: " + attrName + " = " + conversionData.get(attrName));

}

}

@Override

public void onAttributionFailure(String errorMessage) {

Log.d("LOG_TAG", "error onAttributionFailure : " + errorMessage);

}

};

AppsFlyerLib.getInstance().init(AF_DEV_KEY, conversionListener, getApplicationContext());

AppsFlyerLib.getInstance().startTracking(this);

}

}

class AFApplication : Application() {

private val devKey = "qrdZGj123456789";

override fun onCreate() {

super.onCreate()

val conversionDataListener = object : AppsFlyerConversionListener{

override fun onConversionDataSuccess(data: MutableMap<String, String>?) {

data?.let { cvData ->

cvData.map {

Log.i(LOG_TAG, "conversion_attribute: ${it.key} = ${it.value}")

}

}

}

override fun onConversionDataFail(error: String?) {

Log.e(LOG_TAG, "error onAttributionFailure : $error")

}

override fun onAppOpenAttribution(data: MutableMap<String, String>?) {

data?.map {

Log.d(LOG_TAG, "onAppOpen_attribute: ${it.key} = ${it.value}")

}

}

override fun onAttributionFailure(error: String?) {

Log.e(LOG_TAG, "error onAttributionFailure : $error")

}

}

AppsFlyerLib.getInstance().init(devKey, conversionDataListener, applicationContext)

AppsFlyerLib.getInstance().startTracking(this)

}

}

3.3 Registering the global application class

In the AndroidManifest.xml file, inside the application tag, add the following line:

android:name="APP.PACAKAGE.NAME.AFApplication"

APP.PACAKGE.NAME - replace this with the app's package name.

AFApplication - replace this with the name that you set for the app's global class.

This line in manifest.xml tells the application what the global application is. As mentioned above, doing so makes the AppsFlyer SDK globally accessible throughout the app.

4. Testing installs

Now you are ready to test the SDK integration by simulating organic and non-organic installs.

4.1 Whitelisting your test device

Before you start testing installs, whitelist the device you are going to test on.

4.2 Simulating an organic install

Organic installs are unattributed installs which are usually direct installs from app stores.

To simulate an organic install:

Make sure you have a mobile device connected to your computer.

In Android Studio, open the Logcat.

From Android Studio, install the app on the device or emulator.

Wait for the app to launch.

In the Logcat, look for your app's package name.

You should see the following:

The highlighted part in the screenshot indicates that the SDK reports an organic install. This data comes from the onConversionDataSuccess method in the AFApplication class. Getting conversion data is discussed later in this guide.

Note: Starting SDK V5, onConversionDataSuccess is the name of the method for getting conversion data. If you are using an SDK version lower than 5.0.0, the name of the method is onInstallConversionDataLoaded . We recommend that you upgrade to SDK 5.0.0. To learn more, click here.

An organic install should now appear on the Overview page of the application's dashboard.

If you don't see an install in the app's dashboard, see our SDK troubleshooting guide.

4.3 Simulating a non-organic install

A non-organic install is an attributed install that usually follows an ad engagement. You can simulate a non-organic install by using attribution links.

To simulate a non-organic install:

In the manifest, find out what is the package name of your app e.g. com.company.app.

In the URL below, replace <PACKAGE_NAME> with your app's package name:

https://app.appsflyer.com/<PACKAGE_NAME>?pid=sdk_test&c=sdk_test

The pid parameter represents the media source name. The c parameter represents the campaign name.

Send this URL to the device. You can do so for example by email or WhatsApp

On the device, click on the URL.

If the app is listed in the app store, you are redirected to the app store. Don't download and install the app from the app store. Proceed to step 5.

If the app is not listed in the app store and is still in development, the screen shows a message that the app is not available in the app store. Simply proceed to step 5.

In Android Studio, open the Logcat.

Connect the device to your computer using a USB cable.

From Android Studio, Install the app on the device.

In the Logcat, look for your app's package name.

You should see the following:

A non-organic install should now appear in the Overview page of the application's dashboard.

Known issues with integrating the SDK

See the following to learn more about possible issues when integrating the SDK and how to overcome them.

ProGuard warning

If you are using ProGuard and you encounter a warning regarding ourAFKeystoreWrapperclass, then add the following code to your ProGuard rules file:

-keep class com.appsflyer.** { *; }

Backup rules

If you addandroid:fullBackupContent="true"inside the <application> tag in the AndroidManifest.xml, you might get the error:

Manifest merger failed : Attribute application@fullBackupContent value=(true)

To fix this error, addtools:replace="android:fullBackupContent"in the <application> tag in the AndroidManifest.xml file.

If you have your own backup rules specified, please merge them with AppsFlyer rules manually by adding the following rule:

<full-backup-content>

...//your custom rules

<exclude domain="sharedpref" path="appsflyer-data"/>

</full-backup-content>

This tab explains how to record in-app events and revenue, and how to set up deep linking.

Recording in-app events and revenue allows you to measure the quality of your users. Deep linking allows you to provide users with better user experience.

This tab contains instructions for developers, but input from the marketer is essential because:

The marketer should decide which in-app events need recording to measure user quality.

The marketer has access to AppsFlyer dashboard, which is required for setting up OneLink for deep linking.

5. Recording in-app events

In-App events provide insight into what is happening in your app. We recommend to take the time and define the events you want to record. Recording in-app events helps you to measure KPIs such as ROI (Return on Investment) and LTV (Lifetime Value).

There are several ways to record in-app events. The most common way is sending events via the SDK, which we discuss in this article. To learn about other ways to record in-app events, see our in-app events overview guide.

If your app belongs to a certain vertical, e.g. travel, gaming, eCommerce, etc., you can use the full list of recommended in-app events per vertical.

5.1 In-app event names and parameters

The SDK has two in-app event related interfaces:

AFInAppEventType - constants for in-app event names.

AFInAppEventParameterName - constants for in-app event parameter names.

We strongly recommend using these two interfaces for the following reasons:

The standard naming allows AppsFlyer to automatically map events to SRNs such as Facebook, Google, Twitter, and Snapchat.

Backward compatibility - if AppsFlyer decides to change the name of any event or event parameter, your implementation is backward compatible.

To use these two interfaces, import them:

import com.appsflyer.AFInAppEventParameterName;

import com.appsflyer.AFInAppEventType;

Here is the list of recommended event names and structures.

5.2 Recording revenue

You can send revenue with any in-app event. Use the af_revenue (AFInAppEventParameterName.REVENUE) event parameter to include revenue in the in-app event. You can populate it with any numeric value, positive or negative.

af_revenue is the only event parameter that AppsFlyer counts as real revenue on the raw data and dashboard. For more details please click here.

When sending events with revenue, keep the following in mind:

If you set currency code (see example below), it should be a 3 character ISO 4217 code. (default is USD).

You can set the currency code for all events by calling the following method: AppsFlyer.setCurrencyCode("ZZZ") To learn about currency settings, display, and currency conversion, see our guide on revenue currency.

The revenue value should not contain comma separators, currency sign, or text. A revenue event should be similar to 1234.56, for example

Example: In-app event purchase event with revenue

Java Kotlin

Map<String, Object> eventValue = new HashMap<String, Object>();

eventValue.put(AFInAppEventParameterName.REVENUE,1234.56);

eventValue.put(AFInAppEventParameterName.CONTENT_TYPE,"Shirt");

eventValue.put(AFInAppEventParameterName.CONTENT_ID,"1234567");

eventValue.put(AFInAppEventParameterName.CURRENCY,"USD");

AppsFlyerLib.getInstance().trackEvent(getApplicationContext(), AFInAppEventType.PURCHASE, eventValue);

val eventValue = HashMap<String, Any>()

eventValue.put(AFInAppEventParameterName.REVENUE,1234.56)

eventValue.put(AFInAppEventParameterName.CONTENT_TYPE,"Shirt")

eventValue.put(AFInAppEventParameterName.CONTENT_ID,"1234567")

eventValue.put(AFInAppEventParameterName.CURRENCY,"USD")

AppsFlyerLib.getInstance().trackEvent(getApplicationContext(), AFInAppEventType.PURCHASE, eventValue)

The purchase event above has $1234.56 in revenue associated with it, appearing as revenue in the dashboard.

Recording Negative Revenue

There may be situations where you want to record negative revenue.

For example, a user receives a refund for shoes that they purchased from you.

Java Kotlin

Map<String, Object> eventValue = new HashMap<String, Object>();

eventValue.put(AFInAppEventParameterName.REVENUE,-200);

eventValue.put(AFInAppEventParameterName.CONTENT_TYPE,"shoes");

eventValue.put(AFInAppEventParameterName.CONTENT_ID,"4875");

eventValue.put(AFInAppEventParameterName.CURRENCY,"USD");

AppsFlyerLib.getInstance().trackEvent(getApplicationContext(), "cancel_purchase", eventValue);

val eventValue = HashMap<String, Any>()

eventValue.put(AFInAppEventParameterName.REVENUE, -200)

eventValue.put(AFInAppEventParameterName.CONTENT_TYPE, "category_a")

eventValue.put(AFInAppEventParameterName.CONTENT_ID, "1234567")

eventValue.put(AFInAppEventParameterName.CURRENCY, "USD")

AppsFlyerLib.getInstance().trackEvent(applicationContext, "cancel_purchase", eventValue)

Note

Notice the following in the code above:

The revenue value is preceded by a minus sign.

The event name has a unique value of "cancel_purchase" - to allow you to identify negative revenue events in the dashboard and raw data reports.

5.3 In-app purchase validation

AppsFlyers SDK provides server verification for in-app purchases. To validate a purchase, call the validateAndTrackInAppPurchase.

This call automatically generates an af_purchase in-app event, given that the purchase is validated.

public static void validateAndTrackInAppPurchase(Context context,

String publicKey, String signature, String purchaseData,

String price, String currency, HashMap<String, String> additionalParameters);

Method parameters

String publicKey public key from Google Developer Console.

String signature transaction signature (returned from Google API when the purchase is completed).

String purchaseData product purchased in JSON format (returned from Google API when the purchase is completed).

String revenue in-app event revenue to be reported to AppsFlyer.

String currency in-app event currency to be reported to AppsFlyer.

HashMap<String, String> additionalParameters additional parameters of the in-app event that appear in the event_value field in in-app event raw data.

Purchase validation success and failure callbacks

If you want to know if the attempt to validate the purchase is successful or not, implement registerValidatorListener in your application class. This listener has two callback blocks, one for Success and one for Failure (for any reason, including validation fail).

Java Kotlin

AppsFlyerLib.getInstance().registerValidatorListener(this,new

AppsFlyerInAppPurchaseValidatorListener() {

public void onValidateInApp() {

Log.d(TAG, "Purchase validated successfully");

}

public void onValidateInAppFailure(String error) {

Log.d(TAG, "onValidateInAppFailure called: " + error);

}

});

AppsFlyerLib.getInstance().registerValidatorListener(this, object : AppsFlyerInAppPurchaseValidatorListener {

override fun onValidateInApp() {

Log.d(LOG_TAG, "Purchase validated successfully")

}

override fun onValidateInAppFailure(error: String) {

Log.d(LOG_TAG, "onValidateInAppFailure called: $error")

}

})

Usage example of validating a purchase:

Java Kotlin

// Purchase object is returned by Google API in onPurchasesUpdated() callback

private void handlePurchase(Purchase purchase) {

Log.d(LOG_TAG, "Purchase successful!");

Map<String, String> additional_event_values = new HashMap<>();

additional_event_values.put("some_parameter", "some_value");

String revenue = "10";

String currency = "USD";

AppsFlyerLib.getInstance().validateAndTrackInAppPurchase(getApplicationContext(), PUBLIC_KEY, purchase.getSignature(), purchase.getOriginalJson(), revenue, currency, additional_event_values);

}

// Purchase object is returned by Google API in onPurchasesUpdated() callback

private fun handlePurchase(Purchase purchase) {

Log.d(LOG_TAG, "Purchase successful!");

val additional_event_values = HashMap<String, String>()

additional_event_values.put("some_parameter", "some_value");

val revenue = "10";

val currency = "USD";

AppsFlyerLib.getInstance().validateAndTrackInAppPurchase(this, PUBLIC_KEY, purchase.getSignature(), purchase.getOriginalJson(), revenue, currency, additional_event_values);

}

Validating in-app purchase automatically sends an in-app purchase event to AppsFlyer. See below a sample data that is passed in the event_value parameter:

{

"some_parameter":"some_value", // from additional_event_values

"af_currency":"USD", // from currency

"af_content_id":"test_id", // from purchase

"af_revenue":"10", // from revenue

"af_quantity":"1", // from purchase

"af_validated":true // flag that AF verified the purchase

}

Note

Calling validateAndTrackInAppPurchase automatically generates an af_purchase in-app event. Sending this event yourself creates double duplicate event reporting.

5.4 In-app events limitations

The name of an in-app event can be up to 45 characters long.

For pricing and revenue, use only digits and decimals, e.g. 5 or 5.2.

Pricing and revenue values can have up to 5 digits after the period, e.g. 5.12345.

AppsFlyer supports non-English characters with in-app events, or with any other SDK API, starting from Android SDK version 4.8.1.

5.5 Examples for recording in-app events

You can record in-app events by calling trackEvent with event name and value parameters. See In-App Events documentation for more details.

Below is a simple example of how to record a purchase event. For a comprehensive list of ready-made code snippets per vertical, see our guide for rich in-app events per verticals.

Example: In-app purchase event

Java Kotlin

Map<String,Object> eventValues = new HashMap<>();

eventValues.put(AFInAppEventParameterName.REVENUE, 1200);

eventValues.put(AFInAppEventParameterName.CURRENCY, "JPY");

eventValues.put(AFInAppEventParameterName.CONTENT_TYPE, "Shoes");

AppsFlyerLib.getInstance().trackEvent(this, AFInAppEventType.PURCHASE, eventValues);

val eventValues = HashMap<String, Any>();

eventValues.put(AFInAppEventParameterName.REVENUE, 1200)

eventValues.put(AFInAppEventParameterName.CURRENCY, "JPY")

eventValues.put(AFInAppEventParameterName.CONTENT_TYPE, "Shoes")

AppsFlyerLib.getInstance().trackEvent(this, AFInAppEventType.PURCHASE, eventValues)

5.6 Recording offline in-app events

If a user initiates an event when the internet connection is unavailable, Appsflyer is still able to record it. This is how it works:

SDK sends the events to AppsFlyer's servers and waits for a response.

If the SDK doesnt receive a 200 response, the event is stored in the cache.

Once the next 200 response is received, the stored event is re-sent to the server.

If there are multiple events in the cache, they are sent to the server one promptly after another.

Note

SDKs cache can store up to 40 events, which means that only the first 40 events that happen offline are saved. Everything that comes afterwards until the next 200 response, gets discarded.

The event time that appears in the raw data is the time the event is sent to AppsFlyer after the device goes online again. It is not the actual time that the event takes place.

6. Deep linking with OneLink

OneLink is AppsFlyer's solution for multi-platform attribution, redirection, and deep linking.

6.1 Device detection and redirection

OneLink detects the device type upon click and redirects the user to the matching destination, e.g. Google Play, iOS app store, out-of-store markets, or web pages.

The OneLink redirections guide discusses implementing multi-platform attribution links (no SDK coding required). It's also the basis for deep linking.

6.2 Deep linking

Deep linking allows you to send users to specific activities and serve them with customized content. This is especially useful when running retargeting campaigns.

To set up deep linking with OneLink, a marketer with access to AppsFlyer dashboard and a developer with access to the app must work together.

See our guide on setting up deep linking with OneLink.

6.3 Deferred deep linking

Deferred deep linking allows you to deep link new users and serve them with customized content after they install the app. This is unlike regular deep linking where the app needs to be already installed on the user's device.

To set up deferred deep linking with OneLink, the developer also needs access to the AppsFlyer dashboard.

The setup for deferred deep linking is the same as deep linking. The only difference is that you need to implement additional logic in the app in order to deep link the users and serve them with customized content after they install and launch the app.

See our guide on deferred deep linking to learn more.

6.4 Getting deep link data

The SDK provides you with the conversion or engagement data following every install or deep linking event. You can use this data to customize content and the app's behavior programmatically.

See our guide on deep linking data to learn more.

7. Get conversion data

You can access the user attribution data in real-time for every new install, directly from the SDK level.

By doing this you can serve users with personalized content or send them to specific activities within the app (see deferred deep linking in this article), which can greatly enhance their engagement with your app.

To obtain AppsFlyer's conversion data from the Android SDK, implement AppsFlyerConversionListener.

Java Kotlin

import android.app.Application;

import com.appsflyer.AppsFlyerLib;

import com.appsflyer.AppsFlyerConversionListener;

import java.util.Map;

import android.util.Log;

public class AFApplication extends Application {

private static final String AF_DEV_KEY = "qrdZGj123456789";

@Override

public void onCreate() {

super.onCreate();

AppsFlyerConversionListener conversionListener = new AppsFlyerConversionListener() {

@Override

public void onConversionDataSuccess(Map<String, String> conversionData) {

for (String attrName : conversionData.keySet()) {

Log.d("LOG_TAG", "attribute: " + attrName + " = " + conversionData.get(attrName));

}

}

@Override

public void onConversionDataFail(String errorMessage) {

Log.d("LOG_TAG", "error getting conversion data: " + errorMessage);

}

@Override

public void onAppOpenAttribution(Map<String, String> conversionData) {

for (String attrName : conversionData.keySet()) {

Log.d("LOG_TAG", "attribute: " + attrName + " = " + conversionData.get(attrName));

}

}

@Override

public void onAttributionFailure(String errorMessage) {

Log.d("LOG_TAG", "error onAttributionFailure : " + errorMessage);

}

};

AppsFlyerLib.getInstance().init(AF_DEV_KEY, conversionListener, getApplicationContext());

AppsFlyerLib.getInstance().startTracking(this);

}

}

import com.appsflyer.AppsFlyerConversionListener

import com.appsflyer.AppsFlyerLib

import com.appsflyer.AppsFlyerLibCore.LOG_TAG

class AFApplication : Application() {

private val devKey = "qrdZGj123456789";

override fun onCreate() {

super.onCreate()

val conversionDataListener = object : AppsFlyerConversionListener{

override fun onConversionDataSuccess(data: MutableMap<String, String>?) {

data?.let { cvData ->

cvData.map {

Log.i(LOG_TAG, "conversion_attribute: ${it.key} = ${it.value}")

}

}

}

override fun onConversionDataFail(error: String?) {

Log.e(LOG_TAG, "error onAttributionFailure : $error")

}

override fun onAppOpenAttribution(data: MutableMap<String, String>?) {

data?.map {

Log.d(LOG_TAG, "onAppOpen_attribute: ${it.key} = ${it.value}")

}

}

override fun onAttributionFailure(error: String?) {

Log.e(LOG_TAG, "error onAttributionFailure : $error")

}

}

AppsFlyerLib.getInstance().init(devKey, conversionDataListener, applicationContext)

AppsFlyerLib.getInstance().startTracking(this)

}

}

The two most important APIs in the AppsFlyerConversionListener interface are:

onInstallConversionData - provides conversion data for new installs. Note: Starting SDK V5,onConversionDataSuccess is the name of the method for getting conversion data. If you are using an SDK version lower than 5.0.0, the name of the method is onInstallConversionDataLoaded . We recommend that you upgrade to SDK 5.0.0. To learn more, click here.

onAppOpenAttribution - provides retargeting conversion data when an existing app is launched, either manually or through deep linking.

To learn more about conversion data, see our guide on conversion data scenarios.

8. Attribution

Out-of-store Android apps

With AppsFlyer, you can attribute installs for out-of-store Android apps. This allows you to promote your apps and reach larger audiences in markets where Google Play is not available

For more details on how to attribute installs for out-of-store apps, read here.

Pre-installed apps

In pre-install campaigns, app owners can ask device manufacturers to pre-install their apps on devices before they leave the factory.

With AppsFlyer, you can easily attribute installs of pre-installed apps. When users launch your app for the first time, AppsFlyer attributes the install to the manufacturer as a media source.

For details, click here.

Measure uninstalls

AppsFlyer allows you to measure the uninstalls rate of users coming from different sources. Uninstall measurement can help you to analyze and optimize your campaigns according to this significant KPI.

To learn how to setup uninstall measurement, read here.

Setting a tracking request listener

If you want to receive a confirmation that the tracking request was successfully received by the AppsFlyer servers, implement the AppsFlyerTrackingRequestListener listener.

The onTrackingRequestSuccess() callback method is invoked for every 200 response to an attribution request made by the SDK.

The onTrackingRequestFailure(String error) callback method is invoked for any other response and returns the response as the error string.

Implementation example

Java Kotlin

AppsFlyerLib.getInstance().startTracking(this.getApplication(),"devKey", myListener());

private AppsFlyerTrackingRequestListener myListener() {

return new AppsFlyerTrackingRequestListener() {

@Override public void onTrackingRequestSuccess() {

Log.d("Debug", "Got 200 response from server");

} @Override public void onTrackingRequestFailure(String error) {

Log.d("Debug", error);

}

};

}

AppsFlyerLib.getInstance().startTracking(this,"devKey", myListener())

private fun myListener() : AppsFlyerTrackingRequestListener{

return object : AppsFlyerTrackingRequestListener{

override fun onTrackingRequestSuccess() {

Log.d("Debug", "Got 200 response from server");

}

override fun onTrackingRequestFailure(error: String?) {

Log.d("Debug", error);

}

}

}

Setting additional custom data

The setAdditionalData API is required to integrate on the SDK level with several external partner platforms, including Segment, Adobe and Urban Airship. Use this API only if the integration article of the platform specifically states setAdditionalData API is needed.

setAdditionalData code example:

Java Kotlin

HashMap<String,Object> CustomDataMap = new HashMap<>();

CustomDataMap.put("custom_param_1","value_of_param_1");

AppsFlyerLib.getInstance().setAdditionalData(CustomDataMap);

val customDataMap = HashMap<String, Any>()

customDataMap.put("custom_param_1","value_of_param_1")

AppsFlyerLib.getInstance().setAdditionalData(customDataMap)

9. Sessions

Custom time between sessions

By default, at least 5 seconds must pass between two app launches to count as two separate sessions (more about counting sessions ).

Use the following API to set the minimum time between sessions:

AppsFlyerLib.setMinTimeBetweenSessions(int seconds);

Setting a high value to the custom time between launches may badly impact APIs relying on sessions data, such as deep linking.

Background sessions for utility apps

You can report new user sessions using this SDK method. For example, this may be handy for utility apps that run in the background.

Use this API in your activitys onCreate():

public void reportTrackSession(Context context);

Usage Example:

AppsFlyerLib.getInstance().reportTrackSession(context);

10. Owned media

Resolving wrapped deep link URLs

Some 3rd party services such as email service providers wrap links in emails with their own click recording domains. Some even allow you to set your own click recording domains. If OneLink is wrapped in such domains, it might limit its functionality.

To overcome this issue you can use the setResolveDeepLinkURLs API. Use this API to get the OneLink from click domains that launch the app. Make sure to call this API before SDK initialization.

For example, you have three click domains that redirect to your OneLink which is https://mysubdomain.onelink.me/abCD. Use this API to get the OneLink that your click domains redirect to. This API method receives a list of domains that the SDK resolves. Add the following code before SDK initialization.

AppsFlyerLib.getInstance().setResolveDeepLinkURLs("clickdomain.com", "myclickdomain.com", "anotherclickdomain.com");

The code above allows you to use your click domain while preserving OneLink functionality. The click domains are responsible for launching the app. The API, in turn, gets the OneLink from these click domains and then you can use the data from this OneLink to deep link and customize user content.

Recording push notifications

With AppsFlyer, you can record push notifications as part of retargeting campaigns.

To enable this feature, call the sendPushNotificationData method inside the onCreate method of every activity that is launched after clicking the notification:

AppsFlyerLib.getInstance().sendPushNotificationData(this);

For more information on push notification measurement, read here.

User invite attribution

Allowing your existing users to invite their friends and contacts as new users to your app, can be a key growth factor for your app. With AppsFlyer, you can attribute and record installs that originate from user invites within your app.

For details, see the User Invite Attribution article.

Cross promotion attribution

Cross promoting apps can be a major growth factor in driving additional installs for your apps. AppsFlyer enables you to attribute and record installs originating from a cross-promotion of one of your apps from within the current app the user has. For details, see the Cross Promotion Attribution article, here.

11. User identifiers

Get AppsFlyer ID

An AppsFlyer ID is created for every new install of an app. You can use AppsFlyer ID for various purposes:

Send server-to-server in-app events.

Match AppsFlyer ID with user records in your backend systems.

Map entries when merging data from pull and push API.

Use the following API to obtain AppsFlyer ID:

public String getAppsFlyerUID(Context context);

Usage example:

String appsFlyerId = AppsFlyerLib.getInstance().getAppsFlyerUID(this);

Set Customer User ID

Setting your own Customer User ID in the AppsFlyer SDK enables you to cross-reference your own unique ID with the AppsFlyer ID and other identifiers. The customer user ID is available in AppsFlyer raw data reports. You can also use it in postback APIs for cross-referencing with your internal IDs.

To set your Customer User ID:

public void setCustomerUserId(String id);

Usage example:

AppsFlyerLib.getInstance().setCustomerUserId("myId");

We recommend setting the Customer User ID early in the app's flow, as it is only associated with events reported after its setup:

If setCustomerUserId is called before calling startTracking, the Customer User ID appears in the raw data reports for installs and for events.

If it is set after, Customer User ID is only associated with events that are recorded after setting the Customer User ID.

Getting Customer User ID:

To avoid setting the Customer User ID value again beyond the first launch, and to reduce calls to your server to get the customer user ID, you can check if its value is empty or not by using:

AppsFlyerProperties.getInstance().getString(AppsFlyerProperties.APP_USER_ID)

For more information about the Customer User ID, click here.

Delay SDK init for customerUserID

You can delay the SDK Initialization until the customerUserID is set.

To indicate that the SDK should delay initialization for the Customer User ID call:

AppsFlyerLib.getInstance().waitForCustomerUserId(true);

immediately before the init() method. The rest of the SDK initialization should remain unchanged.

Once the customerUserID has been provided, call

AppsFlyerLib.getInstance().setCustomerIdAndTrack("customer_id", this);

to provide the SDK with the relevant Customer User ID and start the SDK.

The code should appear as follows:

Java Kotlin

public class AFApplication extends Application {

private static final String AF_DEV_KEY = "qrdZGj123456789";

@Override

public void onCreate() {

super.onCreate();

AppsFlyerConversionListener conversionDataListener =

new AppsFlyerConversionListener() {

...

};

AppsFlyerLib.getInstance().waitForCustomerUserId(true);

AppsFlyerLib.getInstance().init(AF_DEV_KEY, getConversionListener(), getApplicationContext());

AppsFlyerLib.getInstance().startTracking(this);

// Do your magic to get the customerUserID

// ...

// any AppsFlyer SDK code invoked here will be discarded

//Call the following API once the customerUserID is available:

AppsFlyerLib.getInstance().setCustomerIdAndTrack("customer_id", this);

}

}

class AFApplication: Application() {

private val afDevKey = ""

override fun onCreate() {

super.onCreate()

val conversionDataListener = object: AppsFlyerConversionListener {

...

}

AppsFlyerLib.getInstance().waitForCustomerUserId(true);

AppsFlyerLib.getInstance().init(afDevKey, conversionDataListener, this)

AppsFlyerLib.getInstance().startTracking(this)

// Do your magic to get the customerUserID

// ...

// any AppsFlyer SDK code invoked here will be discarded

// Call the following API once the customerUserID is available:

AppsFlyerLib.getInstance().setCustomerIdAndTrack("customer_id", this)

}

}

To learn more about delaying the SDK initialization until the Customer User ID is available, go here.

Warning

Use this API only in cases where it is appropriate for your business logic. Using this API increases the chance for discrepancies and might make the app more exposed to fraud.

Google Advertising ID

From SDK Version 4.8.0 AppsFlyer automatically collects the google_advertising_id.

The requirement to collect the Google Advertising ID is only relevant for SDK versions 4.7.X and below.

OAID, IMEI, and Android ID

At least one unique device identifier must be collected to enable attribution. The following identifiers are available: GAID, Android ID, IMEI, and OAID.

GAID - Google Advertising ID

Collected automatically from apps thatcontain Google Play Services. If GAID is availableIMEI and Android ID should NOT be collected by the app to avoid violation of the Google Play policy.

IMEI and Android ID

Disabled by default.Can be collected ONLY for apps that do NOT contain Google Play Services. Note: Starting with Android 10 (API level 29), released in late 2019, access to the IMEI parameter is restricted.

To send these IDs to AppsFlyer:

On app open collect the device IMEI and/or Android ID.

Call the following APIs BEFORE calling the startTracking method:

AppsFlyerLib.getInstance().setImeiData("IMEI_HERE");

AppsFlyerLib.getInstance().setAndroidIdData("ANDROID_ID_HERE");

OAID -Open Advertiser Identifier

Disabled by default.Currently, only HUAWEI devices support OAID collection. To collect OAID:

Implement HUAWEI Ads Kit in your app.

Use the following API BEFORE calling the startTracking method:

AppsFlyerLib.getInstance().setCollectOaid(true);

Or, if you already have the OAID, you can use

AppsFlyerLib.getInstance().setOaidData("OAID_HERE");

Opting out of device ID collection

Developers can opt-out of collecting IMEI, Android ID, and OAID by using the following APIs:

AppsFlyerLib.getInstance().setCollectIMEI(false);

AppsFlyerLib.getInstance().setCollectAndroidID(false);AppsFlyerLib.getInstance().setCollectOaid(false);

12. User privacy

Opt-out

In some extreme cases, you might want to shut down all SDK tracking due to legal and privacy compliance. This can be achieved with the isStopTracking API. Once this API is invoked, the SDK stops functioning and no longer communicates with AppsFlyer servers.

AppsFlyerLib.getInstance().stopTracking(true, context);

There are several different scenarios for user opt-out. We highly recommend following the exact instructions for the scenario, that is relevant for your app.

In any event, the SDK can be reactivated by calling the same API, by passing false.

Important

Do not call trackAppLaunch if isStopTracking is set to true

To start tracking again once stopTracking is set to false, use the following SDK API:

AppsFlyerLib.getInstance().trackAppLaunch(getApplicationContext(), AF_DEV_KEY);

Warning

Use the stopTracking API only in cases where you want to fully ignore this user from any and all tracking. Using this API SEVERELY impacts your attribution, data collection and deep linking mechanism.

Anonymize user data

AppsFlyer provides you with a method to anonymize specific user identifiers in AppsFlyer analytics. This method complies with the latest privacy requirements and with Facebook data and privacy policies. Its default value is NO, meaning anonymization isn't performed by default.

Use this API during the SDK Initialization to explicitly anonymize a user's install, events and sessions:

public void setDeviceTrackingDisabled(boolean isDisabled);

Usage example:

AppsFlyerLib.getInstance().setDeviceTrackingDisabled(true);

Tracking can be restarted by calling deviceTrackingDisabled set to false.

Warning

Anonymizing users SEVERELY impacts your attribution information. Use this option ONLY for regions which legally prevents you from collecting your users' information.

getAppsFlyerUID

Description

Get AppsFlyer ID. For more information see here.

Method signature

public String getAppsFlyerUID(Context context);

Usage example

String appsFlyerId = AppsFlyerLib.getInstance().getAppsFlyerUID(this);

onTrackingRequestFailure

Description

Callback method for AppsFlyerTrackingRequestListener. Called when the SDK fails to report app launch.

Method signature

public void onTrackingRequestFailure(String error);

Usage example

See setting a tracking request listener.

onTrackingRequestSuccess

Description

Callback method for AppsFlyerTrackingRequestListener. Called when the SDK successfully reports app launch.

Method signature

public void onTrackingRequestSuccess();

Usage example

See setting a tracking request listener.

reportTrackSession

Description

Report sessions if your app is a utility app that runs in the background.

Method signature

public void reportTrackSession(Context context);

Usage example

AppsFlyerLib.getInstance().reportTrackSession(this);

sendDeepLinkData

Description

This method is used in any activity that is deep-linked into.

This method makes sure that you get attribution data even if the user is deep linked into a specific activity.

For more information, see here.

Method signature

public void sendDeepLinkData(Activity activity);

Usage example

AppsFlyerLib.getInstance().sendDeepLinkData(this);

sendPushNotificationData

Description

Measure and get data from push notifications campaigns. For more information, see measuring push notifications.

Method signature

public void sendPushNotificationData(Activity activity);

Usage example

AppsFlyerLib.getInstance().sendPushNotificationData(this);

setAdditionalData

Description

Adding additional data to be sent to external partner platforms.

Method signature

public void setAdditionalData(HashMap<String, Object> customData);

Usage example

See setting additional data.

setAndroidIdData

Description

Send Android ID to AppsFlyer. See OAID, IMEI and Android ID.

Method signature

public void setAndroidIdData(String aAndroidID);

Usage example

AppsFlyerLib.getInstance().setImeiData("Android ID");

setAppInviteOneLink

Description

Set the OneLink template ID that is used to create custom attribution links for user invites.

Method signature

public void setAppInviteOneLink(String oneLinkId);

Usage example

See setting OneLink for user invite attribution.

setCollectAndroidID

Description

Indicate whether Android ID should be sent to AppsFlyer.

Method signature

public void setCollectAndroidID(boolean isCollect);

Usage example

See OAID, IMEI and Android ID.

setCollectIMEI

Description

Indicate whether IMEI should be sent to AppsFlyer.

Method signature

public void setCollectIMEI(boolean isCollect);

Usage example

See OAID, IMEI and Android ID.

setCustomerIdAndTrack

Description

Initiates the SDK once a Customer User ID is available. For more information, see delay SDK init for Customer User ID.

Method signature

public void setCustomerIdAndTrack(String id, @NonNull Context contex);

Usage example

AppsFlyerLib.getInstance().setCustomerIdAndTrack(customer_id", this);

setCustomerUserId

Description

Set the Customer User ID. For more information, see setting the Customer User ID.

Method signature

public void setCustomerUserId(String id)

Usage example

AppsFlyerLib.getInstance().setCustomerUserId("customer_id")

setDebugLog

Description

Enable debugging logs. See debugging for Android.

Method signature

public void setDebugLog(boolean shouldEnable);

Usage example

AppsFlyerLib.getInstance().setDebugLog(true);

setDeviceTrackingDisabled

Description

Anonymize a user's installs, events, and sessions. For more information, see anonymizing user data.

Method signature

public void setDeviceTrackingDisabled(boolean isDisabled);

Usage example

AppsFlyerLib.getInstance().setDeviceTrackingDisabled(true);

setLogLevel

Description

Set the AppsFlyer SDK log level.

Method signature

public void void setLogLevel(AFLogger.LogLevel logLevel)

Usage example

AppsFlyerLib.getInstance().setLogLevel(AFLogger.LogLevel.INFO);

setMinTimeBetweenSessions

Description

Set the minimum time between sessions. For more information, see custom time between sessions.

Method signature

public void setMinTimeBetweenSessions(int seconds);

Usage example

AppsFlyerLib.getInstance().setMinTimeBetweenSessions(10);

setOaidData

Description

Send OAID to AppsFlyer. See OAID, IMEI and Android ID.

Method signature

public void setOaidData(String oaid);

Usage example

AppsFlyerLib.getInstance().setOaidData("OAID");

setOutOfStore

Description

Specify the alternative app store that the app is downloaded from.

Method signature

public void setOutOfStore(String sourceName);

Usage example

AppsFlyerLib.getInstance().setOutOfStore("baidu");

setPreinstallAttribution

Description

Set the SDK to report pre-install when a pre-installed app launches.

Method signature

public void setPreinstallAttribution(String mediaSource, String campaign, String siteId)

Usage example

See pre-install campaigns for Android.

setResolveDeepLinkURLs

Description

Resolve OneLink from click domains. For more information, see resolving wrapped deep link URLs.

Method signature

public void setResolveDeepLinkURLs(String... urls);

Usage example

AppsFlyerLib.getInstance().setResolveDeepLinkURLs("example.com", "click.example.com");

startTracking

Description

Start the SDK on app launch. For more information, see initializing the SDK.

Method signature

public void startTracking(Application application);

Usage example

AppsFlyerLib.getInstance().startTracking(this);

stopTracking

Description

Shut down all SDK functionality. For more information, see user privacy - opt-out.

Method signature

public void stopTracking(boolean isTrackingStopped, Context context);

Usage example

AppsFlyerLib.getInstance().stopTracking(true, this);

trackAppLaunch

Description

Has two functions:

Send an immediate app launch event to AppsFlyer.

Restart SDK functionality if SDK functionality was shut down using stopTracking.

Method signature

public void trackAppLaunch(Context context, String devKey);

Usage example

AppsFlyerLib.getInstance().trackAppLaunch(this, AF_DEV_KEY);

trackEvent

Description

Send in-app events to AppsFlyer. For more information, see recording in-app events.

Method signature

public void trackEvent(Context context, String eventName, Map<String, Object> eventValues);

Usage example

AppsFlyerLib.getInstance().trackEvent(this, AFInAppEventType.PURCHASE, eventValues);

updateServerUninstallToken

Description

For developers who use Firebase for other purposes other than uninstall measurement. For more information, see .

Method signature

public void updateServerUninstallToken(Context context, String token)

Usage example

AppsFlyerlib.getInstance().updateServerUninstallToken(getApplicationContext(), TOKEN)

waitForCustomerUserId

Description

Delay SDK initilization until Customer User ID is set.

Method signature

public void waitForCustomerUserId(boolean wait);

Usage example

AppsFlyerLib.getInstance().waitForCustomerUserId(true);

A B C D E F G I J K L M N O P Q R S T U V W X Y Z

*The glossary terms in all languages are ordered according to the English alphabet.

A

Account Owner

aka Admin

Ad

A method of promoting brands, products or services on paid channels in different locations. In the context of mobile: banners, links or videos displayed on mobile sites or apps.

Ad Network

An organization that places your mobile ads across a variety of websites and apps.

Ad Network Integration

The setup of Ad Networks on AppsFlyer as Partners for the purpose of further recording and attribution. [Article]

Admin

aka Account Owner The principal team member of an AppsFlyer account, usually the person who initially creates the account and has admin permissions. [Article]

Advertiser

aka Marketer, App Owner The party that owns an app and advertises/markets the app across various platforms in order to increase the quantity and quality of its user base.

Adwords

Former name of Google Ads. [Article]

Affiliates

Publishers that promote advertisers' offers with the incentive of being paid, based on the users they refer. [Article]

Agency

A marketing agency that runs, attributes and measures app marketing campaigns across a variety of traffic vendors and direct publishers, on behalf of its clients (Advertisers /App Owners). [Article]

All-Installs Network

An ad network that accepts postbacks for every new app install, from any source, even if these installs are not attributed to this network.

All-Launches Network

An ad network that accepts postbacks for every new app launch, from any source, even if these launches are not attributed to this network.

Android App Links

HTML links that redirect a user from a webpage directly to specific content inside an Android app. [Article]

API

Application Program Interface Routines, protocols, and tools for building an application, that allow different pieces of software interact with each other.

API Call

A request for data through API by one application from another.

App Launch

Opening of an app. See also Session.

App Owner

aka Advertiser The party that owns an app and advertises it across various platforms in order to increase the quantity and quality of its user base.

App Store Analytics

Collecting and analyzing app data for App stores (Google Play, Apple App Store, etc).

ASO

App Store Optimisation Improving visibility of an app in an App store.

App ID

A unique identifier of an app. App IDs have different format depending on the OS they are built for. They can be found in the HTML address of the app page in the store.

Example of an Android App ID: https://play.google.com/store/apps/details?id=com.coolcompany.coolapp

Example of an App Store ID: https://itunes.apple.com/us/app/coolapp/id123456789

AppsFlyer ID

A unique ID generated by AppsFlyer when the app launches for the first time. The ID is unique per app per installation. This means that a new id is allocated if the app is deleted and then installed again. All events recorded in AppsFlyer contain the ID.

ARPU

Average Revenue Per User The average revenue generated by any user (whether paying or not paying) within a defined timeframe.

ARPPU

Average Revenue Per Paying User The average revenue generated per each paying user within a defined timeframe.

Assisted Installs

aka Multi-Touch Attribution Installs that involve multiple engagements through different campaigns or media sources, while only the last engagement is attributed to the install. [Article]

Attribution

Associating an install of an app or a post-install in-app event with a specific media source or a marketing campaign. [Article]

Audience

A group of people that the advertiser wants to target.

Audiences

AppsFlyer's tool that allows Advertisers to segment their users into audience groups for easy and precise targeting. [Article]

B

Banner

A graphic ad placed on a website and linking to a website or an app it advertises.

Bid

A price an advertiser is ready to pay for the campaign, paid on CPM, CPI, CPC or CPA basis.

Bundle ID

A unique ID assigned by Apple when an app is first created in iTunes Connect (can match a single app or a group of apps).

C

Campaign

A series of ads the purpose of which is to promote a certain product or service and to achieve a specific result.

Click

An action of clicking on an ad and being redirected to the advertised page.

Click URL

aka Attribution Link

Click-Through Attribution

Attribution of an install to a specific click on the ad.

Cohort

A group of users with common characteristics, used in data analysis in order to see users' behavioral patterns more precisely. [Article]

Conversion

Moving one step down the marketing funnel: e.g. clicking on an ad after viewing it, downloading an app after clicking on an ad. [Article]

Conversion Chain

The sequence of various conversion events, from viewing an ad to performing an in-app action (e.g. making a purchase).

Conversion Rate

The percentage of users that move from one step to another in the conversion chain.

CPA

Cost Per Action (Engagement) Advertising pricing model where the advertiser pays for each specified action (form submit, purchase, registration, etc).

CPC

Cost Per Click Advertising pricing model where the advertiser pays for each click on the ad.

CPI

Cost Per Install Advertising pricing model where the advertiser pays for each install.

CPM

Cost Per Mille, Cost Per Thousand Advertising pricing model where the advertiser pays for every 1000 impressions of the ad.

Creative

The concept, design, and artwork that go into a given ad.

Cross-Promotion Attribution

Attribution of marketing campaigns targeted at users of related apps.

CTR

Click-Through Rate The ratio of users who clicked on the ad divided by the number of users who saw it.

Customer User ID

Custom identifier defined by an app developer for user data cross-reference. [Article]

D

Data Locker

A solution for exporting all your raw data on a daily basis. It is done via a dedicated repository, from where the data can be pulled at any time. [Article]

DAU

Daily Active Users The number of unique users that have opened the app on a given day.

Deep Linking

Links that send a user to specific content inside an app instead of an app store or a website. [Article]

Deferred Deep Linking

Links that send a user to specific content inside an app after sending them to an app store or a website if they don't have an app installed before following the link.

DSP

Demand Side Platform A platform that allows buyers of digital advertising to manage multiple ad exchange and data exchange accounts through one interface.

Device ID

A unique identifier of any mobile device in the world. The ID number is stored on the mobile device itself and can be retrieved by any app downloaded and installed.

E

eCPA

Effective Cost Per Action The average effective cost per action: the total campaign cost divided by the number of effective actions (i.e., actions as a direct result of an ad click), as analyzed by AppsFlyer

eCPC

Effective Cost Per Click The average effective cost per click: the total campaign cost divided by the number of clicks, as analyzed by AppsFlyer

eCPI

Effective Cost Per Install The average effective cost per installation: the total campaign cost divided by the number of effective installations (i.e., installations as a direct result of an ad click), as analyzed by AppsFlyer

eCPM

Effective Cost Per Thousand The average effective cost per a thousand of impressions: the total campaign cost divided by the total number of impressions in thousands.

eRPA

Effective Revenue Per Action Total revenue divided by the number of occurrences a specific trigger event.

Engagement

User's interaction with an ad: an impression or a click.

Event

Any action that a user performs in an app: purchase, sign-in, passing a game level.

Event Counter

Total amount of performed in-app events.

Event Time

Timestamp for an occurred in-app event.

F

Fingerprinting

Attribution method based on identifying a device through publicly available parameters (e.g. device type, OS version, IP address, etc).

Fraud

An attempt to obtain attribution for installs using illegal methods. Mobile fraud benchmarks and tips

G

GAID

aka Google Advertising ID A unique identifier of Android users.

I

ID matching

Attribution method using unique identifiers like IDFA, GAID, OAID, Android ID, and IMEI . The identifier is retrieved from a click URL and compared to the identifier fetched by the AppsFlyer SDK.

IDFA

Identifier for Advertisers The unique identifier found on iOS devices and used by developers and marketers for advertising purposes. [Article]

IMEI

International Mobile Equipment Identity A unique identifier of a mobile device used by GSM networks to identify devices.

Impression

Viewing an ad for a minimum amount of time, regardless of any following clicks or installs.

In-app Events

Any action performed by a user after installing an app (login, purchase, completing a tutorial, etc).

Install

Downloading an app, installing and launching it.

Install Referrer

Attribution method based on using a Google Play referrer parameter.

Integrated Partner

Any Ad Network that has integration with AppsFlyer.

K

KPI

Key Performance Indicator A metric for evaluation of an app's performance, e.g. conversion rate, number of clicks, etc.

L

Landing Page

The first page a user sees after clicking on an ad.

LTV

Lifetime Value The accumulative value of revenue events performed by a user starting from the moment an app is installed. [Article]

Lookback Window

Maximum period of time after an engagement event within which an install can be attributed to the ad. [Article]

Loyal User

A user who installed an app and opened it at least three times. [Article]

M

Macros

Patterns used in attribution links and postbacks that define how certain input should be translated into the output (e.g. user data).

Master API

Customizable aggregated data API that allows you to create your own custom reports using any kind of KPIs and groupings. [Article]

MAU

Monthly Active Users A number of distinct users that used an app during the last 30 days or during a specific calendar month (depending on a report). [Article]

Media Source