Attribution model explained

AppsFlyer_AttributionFlow_us-en.png

What is attribution?  

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

  • Non-organic media source if the user interacted (usually by way of impression or click) with a media source.
  • Organic if the user did not interact with a media source.

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

What is a mobile app install?

The Attribution Model is a set of rules, used to determine how credit for an event is assigned to touchpoints in conversion paths. All players in the mobile marketing ecosystem, Google Play, App Store, ad networks such as Facebook and Twitter, and mobile measurement companies, have their own mobile attribution models. Each player counts installs and events differently.

It is important, to understand the attribution model of the players you work with. Most important is to understand the AppsFlyer attribution model.  

In AppsFlyer, an install is recorded after the user downloads and launches the mobile app. This means that the timestamp of an app install is the first launch. This compared to ad networks that use the engagement time and App stores that use the download time.

AppsFlyer attribution methods

 
Attribution method

Android

(Google Play and alternative app stores)

iOS  Universal Windows Platform (UWP)
Referrer Yes*  No Yes
Device ID (advertising ID) matching Yes   Yes Yes
Probabilistic modeling Yes  Yes  No
TV attribution Yes Yes Yes
* Supported by some alternative app stores

 AppsFlyer employs different attribution methods, depending on the device platform and availability.

Install referrer (Android only)

Android apps downloaded from Google Play and alternative app stores are usually attributed by referral. The referrer provides the original URL, clicked before redirecting to the Android store. This is the primary method for Android attribution. Currently, Google Play and Huawei app store support install referrer attribution.  Alternative app store attribution using the referrer.

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 starting with 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.
  • 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. 

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 Facebook, 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 established by collecting temporary parameters about the device.

Probabilistic modeling parameters are collected:

  • initially on the first click or ad view (if enabled)
  • again when the app is launched and matching attempted.

Probabilistic modeling:

  • Is a fallback method, used in the absence of a referer or advertising ID. It is highly accurate (over 90%). Nevertheless, deterministic attribution methods are given priority. 
  • Parameters used in this model include device-related parameters, such as IP address and OS version.
  • Is a statistical method not based on a unique ID.
  • Loses to clicks with referrer or ID matching, if they occur within the lookback window.
  • The attribution window is determined by AppsFlyer dynamically, based on user network and the uniqueness of IP address. 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 relevant non-SRNs integration tab. 

IP_uniqueness.png 

TV attribution

AppsFlyer supports the attribution of organic installs to TV and radio campaigns under the TV media source. An organic install is TV attributed when all of the following occur:

  • The download, install, and the first launch together takes place a short time after the commercial is aired.
  • The user is physically located in the country where the ad is aired. The option to limit to a specific city is permitted.

Methods of TV attribution:

  • File Loading
  • TV Integrated Partners
  • Shazam

See Integrating with TV Attribution Measurement Partners.

Pre-installs

AppsFlyer supports attributing app installs when the app was installed on the device prior to the user purchasing the device.

Because there is no preceding user engagement, click-through, or view-through, installations are attributed on the first launch using the AppsFlyer SDK API. See Configuring and Testing Pre-install Campaigns for Android

User engagement attribution types

AppsFlyer records and uses two types of different user engagement attribution types: click-through and view-through. 

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.

AppsFlyer recommends using seven-day click lookback windows, being the industry standard. You can set the lookback window in the range of 1-30 days based on your agreement with the media source. The lookback window of Facebook is 28 days, Twitter 14 days, and Google Ads 30 days. 

Attribution type

 

Attribution method

 

Click lookback window

Range

Recommended
(default)

Click-Through

(All Integrated Partners)

 

Referrer, ID Matching

1 – 30 Days

7 Days

Probabilistic modeling

Adaptive

Up to 24 hours

The Probabilistic modeling click lookback window has an adaptive lookback window, with a maximum of 24 hours, in order to maintain a high degree of accuracy.

For more information about AppsFlyer lookback windows, click here.

View-through attribution

Attribution of users who view mobile 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.

To enable the view-through attribution, set the lookback window in the configuration window.

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.

Attribution Type

Attribution Method

Range

Recommended
(default)

View-Through

(Selected Integrated Partners)

ID Matching

1 Hour - 2 Days

1 Day

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

For more information about view-through attribution, click here.

Advanced attribution topics

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.

Reinstalls

 

AppsFlyer records new app installations on a device when:

  • The app was never previously installed
    OR
  • The app was already installed, has been uninstalled and then reinstalled after the re-attribution window from the original install date has passed.

Reinstalls within the re-attribution window are therefore not attributed to any media source, including organic. In-app events of reinstalling devices are attributed to organic.

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

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 and appears as such in the AppsFlyer Retargeting Dashboard, if acquired from a retargeting campaign.

For more information, click here.

App updates

When existing users update their app, AppsFlyer does not consider them as new users, nor show the reinstall in any way on the dashboard. You can see the distribution of your new app versions and more on the SDK information page.

The exception to this rule is when an app, that has an active user base, first integrates the AppsFlyer SDK. When existing users, update to a new version, which includes AppsFlyer SDK, AppsFlyer shows them as new organic usersT

Was this article helpful?