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.
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:
Attribution is essential to optimizing user acquisition, re-engagement efforts, and results.
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:
AppsFlyer uses a number of attribution methods, listed in the table that follows:
| Method | \nUses device ID | \nTechnique | \nAttributed by | \nAndroid (Google Play and third-party stores) | \niOS | \nUniversal Windows Platform (UWP) | \nCTV, PC, and console platforms (3) | \n
| \nReferrer (1) | \nNo | \nDeterministic | \nAppsFlyer | \nYes (2) | \nNo | \nYes | \nNo | \n
| \nDevice ID matching (1) | \nYes | \nDeterministic | \nAppsFlyer | \nYes | \nYes | \nYes | \nYes | \n
| \nProbabilistic modeling (1) | \nNo | \nProbabilistic | \nAppsFlyer | \nYes | \nYes | \nNo | \nYes | \n
| \nPreload (1) | \nNo | \nDeterministic | \nAppsFlyer | \nYes | \nNo | \nYes | \nNo | \n
| SKAdNetwork (SKAN) | \nNo | \nDeterministic | \nApple | \nNo | \nYes | \nNo | \nNo | \n
| \nApple Search Ads (1) | \nNo | \nDeterministic | \nApple | \nNo | \nYes | \nNo | \nNo | \n
| \nDeep link (1) | \nNo | \nDeterministic | \nAppsFlyer | \nYes | \nYes | \nYes | \nNo | \n
| (1) Sometimes referred to as the \"Classic\" attribution method in AppsFlyer dashboards and reports. (2) Supported by some third-party stores. (3) See full list of CTV, PC, and console platforms. |
Upon a new install, if there is more than one valid engagement, AppsFlyer prioritizes clicks over impressions, and deterministic over probabilistic methods. The attribution methods are utilized according to the priorities shown in the chart.
Find below detailed descriptions of AppsFlyer attribution models.
A classic attribution method in which 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.
\nDevice ID matching is the primary attribution method on iOS, but requires ATT consent.
\nAvailable IDs are:
\nDevice IDs can be hashed using SHA1 or MD5 on attribution links.
\nA classic attribution method in which 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.
\nAppsFlyer queries the relevant SRNs using the unique device ID of the new install, where the device ID is available, and ATT consent has been granted on iOS. 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.
\nAppsFlyer uses probabilistic modeling as a privacy-preserving statistical method to report on how app developers’ marketing campaigns are performing. It produces aggregate campaign-level performance reports for app developers.
\nImplementation characteristics
\nA classic attribution method for preload campaigns, when apps are installed on a user's device by a preload partner, either at the factory or upon device activation. Preload partners can be:
\nThere are 3 methods to attribute preload campaigns. All three methods can be used simultaneously; they don't interfere with each other’s mechanisms.
\nThe 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.
\n| Preload attribution method | \nUse case | \nDevice activation-to-app launch info* | \nLookback window** | \nMatch-type in raw data | \n
|---|---|---|---|---|
| \nAppsFlyer referrer* | \n
| \nYes | \n
| \n
| \n
| \nGoogle Play auto-install** | \nPreloaded upon device activation (for Google Play apps) | \nNo | \n
| \npreload_pai | \n
| \nPreload in factory via System Property or manifest (Android)** | \n
| \nNo | \nNo limit | \npreload_conf | \n
| \n * 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. \nFor 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. \n** 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. \n\n |
A classic attribution method for re-engagements only, when 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.
See the sections that follow for a full breakdown of which particular attribution methods are supported, depending on:
| Media source | \nFeature | \nAttribution method | \n|
|---|---|---|---|
| Android | \niOS | \n||
| Owned media: email (including ESPs), SMS, social media posts, influencers/affiliates, print, etc. | \nOneLink | \n
| \nProbabilistic modeling | \n
| Owned mobile website/landing page with paid or organic incoming traffic | \nSmart Banners | \n
| \nProbabilistic modeling | \n
| OneLink Smart Script | \n
| \nProbabilistic modeling | \n|
| Owned mobile apps | \nUser invites/referral | \n
| \nProbabilistic modeling | \n
| Cross-promotion | \n
| \nDevice ID matching (subject to ATT consent) | \n
| Media source | \nAttribution method | \n||
|---|---|---|---|
| Android | \niOS | \nCTV, PC, and console platforms | \n|
| SRNs | \nDevice ID matching | \n
| \nDevice ID matching | \n
| \n
| \n
| \n\n |
| Pre-installed on device | \nPre-installs | \n-- | \n\n |
Attribution is performed based on click-through and view-through engagements, using AppsFlyer's various campaign measurement methods.
Most installs are the result of user clicks on ads, like banners, videos, and interstitials.
\nUpon 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.
\n| \n Attribution type\n | \n\n Attribution method\n | \nRange | \nDefault | \n
|---|---|---|---|
| \n Click-Through \n(All integrated partners) \n\n | \n Referrer, ID Matching | \n1–30 Days | \n7 Days | \n
| Probabilistic modeling | \n0–24 Hours | \n\n
| \n
Users who view ads but do not click on them can be attributed to the ad network serving the ad.
\nThe lookback window for view-through attribution:
\nThis 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.
\nIn cases where both a click and an impression occur, the click always prevails, as it's an active engagement.
\n| Attribution type | \nAttribution method | \nRange | \n\nDefault | \n
|---|---|---|---|
| \n View-through (for selected integrated partners) \n\n | \nID Matching | \n0-24 Hours | \n1 Day | \n
| Probabilistic modeling | \n0-24 Hours | \n
| \n
To enable the view-through attribution:
\nEngaged clicks occur when users click an ad and remain in the same context—engaging with the ad—without being redirected to the app store or launching the app. For example, interactions may include staying within a playable ad, interacting with in-ad elements, or continuing to browse content within the ad container. For more information, see: About enhanced engagement types.
\n| Attribution type | \nAttribution method | \nRange | \nDefault | \n
|---|---|---|---|
Engaged click (for selected integrated partners) | \nID Matching | \n1–7 Days 1-23 hours | \n2 Days | \n
| \n | Probabilistic modeling | \n0–24 Hours | \n
| \n
Engaged views occur when users view an ad and take a qualifying action—such as watching a video beyond a certain threshold or interacting with an ad unit—without clicking. These actions signal intent and are used to attribute the install. For more information, see: About enhanced engagement types.
\n| Attribution type | \nAttribution method | \nRange | \nDefault | \n
|---|---|---|---|
Engaged view (for selected integrated partners) | \nID Matching | \n1–7 Days 1-23 hours | \n2 Days | \n
| \n | Probabilistic modeling | \n0–24 Hours | \n
| \n
To enable engaged view attribution:
\nAppsFlyer uses the device ID or unique AppsFlyer ID for attributions (an app install, reinstall, or re-attribution) to attribute in-app events to the media source. Advertisers can use this information to follow user journeys in their app's raw data. In aggregate day, the device ID/AppsFlyer ID is used to calculate the number of unique users, for example the number of unique users that perform an in-app event.
\nFor more information about event attribution, click here.
\nAppsFlyer fully attributes only one media source per install, usually using the last ad click or the last ad impression (if there were no clicks).
\nAssisted 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.
\nAssisting networks are shown as contributors to the install in AppsFlyer.
\nFor more information, click here.
\nA 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:
\nFor device testing and multiple installs, register the device in AppsFlyer. If you don't register the device only the first install is recorded.
\nNote that AppsFlyer enables better accuracy for attributing iOS reinstalls without advertiser ID. You can enable this feature on the App Settings page.
\nWhen 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.
\nA 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.
\n