AppsFlyer attribution model

At a glance: AppsFlyer determines the media source motivating a user to install or re-engage with an app and attributes the user action to that source using the AppsFlyer attribution model. 


What is attribution?

Attribution is the act of determining what motivated (caused) a user to install an app or to perform post-install acts like re-engagement and re-attribution. The attribution result is either:

  • A non-organic media source: The user interacted (usually by way of impression or click) with a media source.
  • Organic: The user did not interact with a media source. Note! For ease of understanding, we often refer to a user as being attributed organically. We know that this is not strictly true, as users installing organically aren't attributed at all. 

Attribution is essential to optimizing user acquisition, re-engagement efforts, and results.


Want to know more about attribution? Check out this short, informative course on the AppsFlyer Learning Portal.

What is an app install?

The Attribution Model is a set of rules, that determine how credit for an event is assigned to touchpoints in conversion paths. Each of the players in the app marketing ecosystem, Google Play, App Store, Apple, CTV, PC, and console platforms, ad networks such as Meta ads and X Ads, and mobile measurement companies, have their own attribution models. Each counts installs and events differently.

What's important is not the difference between the models but rather that the rules are clear and are implemented in a manner that is unbiased. Enabling advertisers to optimize campaigns and compare the quality of user performance.

It is important to understand the models and rules of the players you work with. Most important is to understand the model and nuances of the methods supported by AppsFlyer.

In AppsFlyer, an attributable event occurs when any of the following occur:

  • In the context of user acquisition: An install is recorded and attributed after the user downloads and launches the app. This means that in AppsFlyer, the timestamp of an app install is the first launch. In contrast, ad networks use the engagement time and App stores use the download time.
  • In the context of retargeting:
    • Re-engagement
    • Re-attribution 

Attribution methods

AppsFlyer uses a number of attribution methods, listed in the table that follows: 

Method Uses device ID Technique

Attributed by

Android (1)


iOS  Window Universal Platform CTV, PC, and console platforms (3)
Referrer No Deterministic AppsFlyer Yes (2) No Yes No
Device ID matching Yes Deterministic AppsFlyer Yes  Yes Yes Yes
Probabilistic modeling No Probabilistic AppsFlyer Yes  Yes  No Yes
Aggregated Advanced Privacy (AAP) No Aggregate AppsFlyer No Yes No No
Preload No Deterministic AppsFlyer Yes No Yes No
SKAdNetwork (SKAN) No Deterministic Apple No Yes No No
Apple Search Ads No Deterministic Apple No Yes No No
Deep link No Deterministic AppsFlyer Yes Yes Yes No

(1) Google Play and third-party stores

(2) Supported by some third-party stores

(3) See full list of CTV, PC, and console platforms


The attribution methods are utilized according to the priorities shown in the chart. Upon a new install, if there is more than one valid engagement, AppsFlyer prioritizes clicks over impressions, and deterministic over probabilistic methods

Attribution method priorities 23.png

Find below detailed descriptions of AppsFlyer attribution models.

Install referrer (Android only)

  • Android apps downloaded from Google Play and some other app stores are usually attributed by the install referrer method. The referrer provides the original URL, clicked before redirecting to the Android store. This is the primary method for Android attribution. Currently, Google Play, Huawei app store, Samsung Galaxy Store, and Xiaomi GetApps Store, support install referrer attribution. Alternative app store attribution using the referrer.
  • Meta install referrer: AppsFlyer supports Meta ads attribution for Android apps by receiving ad campaign metadata from a device’s local storage. This data is used for attribution measurement (Meta on-device attribution).

Device ID matching

The ad network, which has access to the user's device, sends the device ID to AppsFlyer on the click URL, or when notifying AppsFlyer that an impression has been served. This allows AppsFlyer to match the click device ID with the device ID fetched by the AppsFlyer SDK.

Device ID matching is the primary attribution method on iOS.

Available IDs are:

  • iOS devices: IDFA, IDFV
  • Android devices: having Google Play services: GAID 
  • Android devices without Google Play services: OAID, Android ID, IMEI, Fire ID 

Device IDs can be hashed using SHA1 or MD5 on attribution links.

Device ID matching using IDFV (iOS)

  • The identifier for vendors (IDFV) is available in iOS 6.0+. It is not subject to Apple ATTrackingManager and LAT mechanisms. It is always available and can be used for cross-promotional advertising of apps from the same vendor. 
  • AppsFlyer SDK collects IDFV by default. 
  • According to Apple, The value of this property is the same for apps that come from the same vendor running on the same device. 
  • An IDFV is generated by Apple when the user installs the first app of a given vendor. Meaning, Apple checks that there are no other apps from the same vendor on the device. As a result, deleting all the apps of a given vendor and then installing an app from the same vendor results in a new IDFV. 
  • You should send IDFV if available. It improves attribution. We make use of IDFV in a number of scenarios including: 
    • Cross-promotion attribution.
    • Reinstall attribution on the same device.
    • Raw data reporting.
    • Audiences.

Device ID matching for self-reporting networks 

Upon the first app launch, AppsFlyer checks in the app settings if traffic is expected from any of the self-reporting networks (SRNs), like Meta ads, Snapchat, and Google Ads. 

AppsFlyer queries the relevant SRNs using the unique device ID of the new install. The query uses Mobile Measurement Partners (MMP) APIs as defined by the SRNs. Based on the response, AppsFlyer may attribute the new uses to an SRN.

Probabilistic modeling

Probabilistic modeling is a statistical technique leveraging machine learning to estimate campaign performance. Probabilistic modeling parameters are collected:

  • Initially on the click or ad view (if enabled)
  • Again when the app is launched

Implementation characteristics

  • Uses statistics and is not based on unique IDs.
  • Is a fallback method, used in the absence of a referer or advertising IDs. Deterministic attribution methods, i.e., clicks with referrer or ID matching, are given priority if they occur within the lookback window. 
  • The attribution window is determined by AppsFlyer dynamically, based on the user network. The window duration is adaptive but shorter than the window of other methods (up to 24 hours).
  • Click-through probabilistic modeling is always enabled. 
  • View-through probabilistic modeling needs to be enabled in the app settings page and in the integration tab of non-SRNs. For CTV, PC, and console apps, this is enabled by default.

Probabilistic modeling parameters for ad networks

Ad networks implementing Probabilistic modeling attribution must send the following parameters via  the attribution link or via HTTP request headers:

Aggregated Advanced Privacy (AAP)

Aggregated Advanced Privacy (AAP) exposes campaign performance results in an aggregated manner, preventing any option to track users across apps and websites owned by different companies, and the ability to uniquely identify a user or a device.

AAP utilizes the Apple SKAdNetwork privacy levels as a minimum benchmark for its privacy-preserving thresholds. AAP is the default attribution model for Apple devices operating on ios 14.5+, except in cases that are explicitly permitted by Apple, such as owned media, and ATT consented users.

Unlike the other attribution methods described, the AAP machine learning algorithm's goal is to maximize the accuracy of the campaign’s aggregated performance, not the end-user attribution accuracy.

Preload campaigns

In preload campaigns, apps are installed on a user's device by a preload partner, either at the factory or upon device activation. Preload partners can be:

  • Original Equipment Manufacturers (OEMs)
  • App discovery platforms
  • Mobile carriers

There are 3 methods to attribute preload campaigns. All three methods can be used simultaneously; they don't interfere with each other’s mechanisms.

The 3 methods and some of the main specifications are outlined in the table that follows. Click the links to learn more about each preload method.

Preload attribution method Use case Device activation-to-app launch info* Lookback window** Match-type in raw data
AppsFlyer referrer*
  • Preloaded in factory
  • Preloaded upon device activation
  • Up to 180 days
  • Default is 90 days
  • Preload: preload_rfr
  • Click to download: af_referrer
Google Play auto-install**

Preloaded upon device activation (for Google Play apps)

  • Up to 180 days
  • Default is 90 days
Preload in factory via System Property or manifest (Android)**
  • Preloaded in factory
  • Preloaded upon device activation

No limit


* The AppsFlyer referrer preload solution provides visibility and measurement capabilities between the first device activation and the first app launch. This lets you see how many devices were activated with the app preloaded on the devices by a specific partner, and then see when the app is launched for the first time.

For the two other methods, attribution is determined only after the user launches the app for the first time, the number of devices that had the app installed before the first launch isn't available.

** It can take days or weeks, starting from the first time the user turns on their device until they launch the preloaded app for the first time. Consequently, AppsFlyer gives preload campaigns the highest priority in determining attribution, with longer lookback windows.


Deep link

For re-engagements only, users aren't redirected to an app store to download the app. Therefore, the information in the URL can be directly connected to the click (and subsequent app open). This attribution method is referred to as deep link, since it's the deep link URL that carries the information used to attribute the re-engagement.

Attribution methods per media source and AppsFlyer feature

See the sections that follow for a full breakdown of which particular attribution methods are supported, depending on:

  • Media source: owned or paid
  • AppsFlyer feature used
  • User device: Android or iOS

Owned media

Media source Feature Attribution method
Android iOS
Owned media: email (including ESPs), SMS, social media posts, influencers/affiliates, print, etc. OneLink
  • Install referrer
  • Probabilistic modeling

Probabilistic modeling

Owned mobile website/landing page with paid or organic incoming traffic Smart Banners
  • Install referrer
  • Probabilistic modeling
Probabilistic modeling
OneLink Smart Script
  • Install referrer
  • Probabilistic modeling
Probabilistic modeling
Owned mobile apps User invites/referral
  • Install referrer
  • Probabilistic modeling

Probabilistic modeling

  • Install referrer
  • Device ID matching
Device ID matching

Paid media

Media source Attribution method
Android iOS CTV, PC, and console platforms

Device ID matching

  • Device ID matching
  • AAP (iOS 14.5+)
  • SKAdNetwork (iOS 14+)

Device ID matching


  • Install referrer
  • Device ID matching
  • Probabilistic modeling
  • Device ID matching
  • Probabilistic modeling (before iOS 14.5)
  • AAP (iOS 14.5+)
  • SKAdNetwork (iOS 14+)

Pre-installed on device

Pre-installs --  

User engagement attribution types

Attribution is performed based on click-through and view-through engagements. Media source attribution is achieved by making use of device ID matching and probabilistic modeling techniques.

Click-through attribution

Most installs are the result of user clicks on ads, like banners, videos, and interstitials.

Upon the ad click, a click lookback window opens having a default duration of 7 days. Installs occurring within the lookback window period are non-organic and are attributed to the media source. Installs that occur after the duration of the lookback window are considered as organic installs. Often referred to as being organically attributed. 

  • A seven-day click lookback window is regarded as the industry standard. Set the window duration in accordance with your agreement with the media source. 
  • Align SRN lookback windows with the duration determined by the SRN. 

Attribution type

Attribution method




(All integrated partners)


Referrer, ID Matching

1–30 Days

7 Days

Probabilistic modeling

0–24 Hours

  • Adaptive
  • Determined by AppsFlyer

Learn more about lookback windows

View-through attribution

Users who view ads but do not click on them can be attributed to the ad network serving the ad.

The lookback window for view-through attribution:

  • is shorter than that of click-through attribution
  • is configurable.

This is especially helpful for video ad networks that traditionally have low CTRs on their video ads, but also for traditional ad networks serving regular ads.

In cases where both a click and an impression occur, the click always prevails, as it's an active engagement.

Attribution type

Attribution method



View-through (for selected integrated partners)


ID Matching

0-24 Hours

1 Day

Probabilistic modeling

0-24 hours

  • Adaptive
  • Determined by AppsFlyer

To enable the view-through attribution:

Learn more about view-through attribution

Advanced attribution topics

In-app events

AppsFlyer creates a unique AppsFlyer ID for an app install that is associated with attribution details. This enables the platform to attribute in-app events to the original media source. Advertisers can use this information to follow user journeys in their app's raw data. In aggregate day, the AppsFlyer ID is used to calculate the number of unique users, for example the number of unique users (attributions with a unique AppsFlyer ID_ that perform an in-app event.

For more information about event attribution, click here.

Assisted installs

AppsFlyer fully attributes only one media source per install, usually using the last ad click or the last ad impression (if there were no clicks).

Assisted Installs (AKA multi-touch attribution) are installs where the media source/campaign was not the last touchpoint but touched the user before the install and the touch took place within the attribution lookback window.

Assisting networks are shown as contributors to the install in AppsFlyer.

For more information, click here.


A reinstall occurs when a user installs the app, uninstalls it, and then reinstalls it. Reinstall attribution is regulated by the re-attribution window as follows:

  • If the reinstall occurs after the expiry of the re-attribution window: a new install is recorded.
  • If the reinstall occurs during the re-attribution window, one of the following applies:
    • If the user engaged with a retargeting campaign before the reinstall: a retargeting reinstall (AKA re-attribution) is recorded.
    • If the user did not engage with a campaign or engaged with a UA campaign: no install is recorded. Depending on the Post Reinstall Events Attribution state, in-app events of these reinstalling users are either attributed to organic or to the original install. 

For device testing and multiple installs, register the device in AppsFlyer. If you don't register the device only the first install is recorded.

Note that AppsFlyer enables better accuracy for attributing iOS reinstalls without advertiser ID. You can enable this feature on the App Settings page.

Reinstalling iOS apps that are backed up in iCloud

When an application is backed up using iCloud and later restored (on the same device or on another device), AppsFlyer doesn't count it as a new install or reinstall. A user who restores an app from iCloud maintains their AppsFlyer ID and attribution data.

Retargeting attribution


A user who re-installs an app within the re-attribution window (90 days by default) is considered a re-attribution. If this install occurs after engaging with a retargeting campaign, it is recorded as a retargeting reinstall AKA re-attribution and is reported in retargeting

App updates

  • When existing users update the app to a subsequent version, this is not treated as a countable attribution event, if the user was previously attributed by AppsFlyer. Note! If you migrate to AppsFlyer from a different MMP existing users on the first app-open, after migration, are attributed to organic. 
  • Metrics relating to the number of users per app version are available in the SDK Information dashboard.