Attribution discrepancies between AppsFlyer and the app stores

  • Advertisers

There are cases where the app stores record more installs than AppsFlyer meaning that AppsFlyer under attributes. In other instances, AppsFlyer records more installs than the app stores meaning AppsFlyer over attributes. This article contains explanations as to some of the causes of attribution discrepancies and how to reduce them.

There are inherent differences in the attribution models used by all players in the mobile attribution ecosystem. The same applies to AppsFlyer and the main app stores, (iOS) App Store and (Android) Google Play. Note: In this article, the two stores are referred to as app store or app stores. 

AF_vs_app_stores.png

The leading causes of discrepancies between AppsFlyer and the app stores are described here as well as tips to minimize discrepancies.

 Note

Discrepancies do not affect the accuracy of the non-organic installs count, because the AppsFlyer attribution model credits one install per ad click. This is true even for a specific user with more than one device registered in the app store.

Reasons that AppsFlyer may under attribute 

Reasons for under attribution by AppsFlyer
Cause App Stores AppsFlyer AppsFlyer tip


Install Definitions

App stores record installs after the user downloads and installs the app, whether the user later launches the app or not.

AppsFlyer records new installs only after the first launch. NoteUsers that never launch are not counted in AppsFlyer, even if they download and install (according to the App Store definition).

About 90% of mobile app downloads result in at least one launch, but this can vary significantly in different geos and verticals.

Install Record Date

App stores record the date of the download as the day of install

AppsFlyer records the date of the first launch as the day of install

In AppsFlyer use longer periods of time as your queried date range to minimize this discrepancy.

Time Zones

Data displays according to the local time zone of the advertiser.

By default, data displays using UTC±00:00 time zone. You can set the app-preferred time zone to reduce this discrepancy (details here).

Android User uninstalls and re-installs within the defined re-attribution window

In some views, Google Play shows two unique installs for the same user, regardless of the time that elapsed from the first install. Other views show unique users and therefore are more closely aligned with AppsFlyer.

During the re-attribution window of (default) three months from the original install, AppsFlyer doesn't attribute re-installs. You can set the re-attribution window from 1 to 24 months.

 Examples

  1. A user installed an app and did not launch it even once. AppsFlyer does not attribute the install. The app stores count this as a new install.
  2. A user installed an app and launched it for the first time after two weeks. The app stores record that install on the installation date, while AppsFlyer uses the date of the first launch of the app. In some cases, this can cause major discrepancies during a short period of time.

Reasons that AppsFlyer may over attribute

The main reason for AppsFlyer to record more installs than the stores is installation uniqueness. The definition for this in the app stores is different than that of AppsFlyer.

App stores attribute installs by unique users, that is one install per app store account regardless of the number of devices on which the app is installed.

AppsFlyer attributes installs by unique devices.

The following causes are all related to installation uniqueness:

Reasons for over attribution by AppsFlyer
Cause Description AppsFlyer tip

Upgrading an existing app install

An app is released without the AppsFlyer SDK and then re-released in the app stores with the AppsFlyer SDK integrated into it. AppsFlyer shows the re-release as organic installs. This peak usually drops after a few days as most users finish upgrading the app.

Multiple devices of a user install the same app

When an app is installed on the iPhone and iPad of the same iTunes user, iTunes measures this as one install, while AppsFlyer measures it as two installs.

You can trace these "double" installs using the customer user ID value. By generating a unique customer user ID for each new user, and by using the same value in all installs from the same user, you can filter out duplicate customer user IDs in the raw data installs report. This neutralizes this discrepancy cause.

An app user uninstalls and re-installs outside the defined re-attribution window When the re-attribution window (by default 3 months) passes from the original install time, the user is considered as new on AppsFlyer when re-installing.
iTunes however shows only one install per user, regardless of uninstalls and re-installs.

You can set the re-attribution window from 1 to 24 months.

User re-installs on an upgraded device

The app stores regard this as the same users but in AppsFlyer because its two devices its two installs.

AppsFlyer shows the uninstall info for the first device, that has stopped functioning.

Device ID reset and Limit Ad Tracking Fraud

Over 50% of fraudulent installs use these methods, causing the devices to appear as new devices, while for the stores the users stay the same.

AppsFlyer Protect360 anti-fraud solution detects if your app is suffering from these types of fraud.

Installs coming from out-of-store markets 

Out of store markets, pre-installs and APK sites deliver installs that are not recorded by Google Play.

If you're advertising in an Out-of-store Android market consult the documentation for the correct setup.

 Examples

  1. A user installed (and opened) an app on both their iPhone and iPad. AppsFlyer counts this as two installs, whereas the iOS app store counts it as a single install.
  2. A user upgraded to a new device, synced their app store account, and launched the app. AppsFlyer counts this as new organic install, whereas the app stores do not. 
  3. An app was released in 2016 without the AppsFlyer SDK. A user downloaded the app and used it. The app stores count that user, whereas AppsFlyer is still unaware of the user and did not count it. Then, in March 2017, the app, with the AppsFlyer's SDK integrated into it is released to the app stores. The user upgrades to the newest app version and launches it. AppsFlyer counts the install as a new Organic install, whereas the app stores do not, as the user was already registered in 2016.
    This can be a major cause for discrepancies, especially if the app has a large number of users from the period before the AppsFlyer SDK was integrated into the app. 
Was this article helpful?
8 out of 10 found this helpful

Page Contents: