Discrepancies between App Store/Google Play and AppsFlyer

  • Advertisers

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, App (iOS) Store and Google (Android) Play. In this article, we'll refer to the two stores as the App Stores. 

In some cases, the App Stores may record more installs than AppsFlyer meaning that AppsFlyer under attributes. In other cases, AppsFlyer records more installs than the App Stores meaning AppsFlyer over attributes. 

AF_vs_app_stores.png

The main 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. This is because the AppsFlyer attribution model credits one install per ad click. This is true even if a specific user has more than one device registered in their 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 (by the App Store definition).

Roughly 90% of all mobile app downloads result in at least one launch. However, this varies drastically between 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

On appsFlyer dashboard use longer periods of time as your queried date range to minimize this discrepancy.

Time Zones

Data is displayed according to the local time zone of the advertiser.

By default data is displayed according to UTC±00:00 time zone. You can set the preferred time zone per each app you own, and minimize this discrepancy (details here).

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

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

Inside the re-attribution window, which is by default 3 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 your app and did not even launch it once. AppsFlyer does not attribute the install, whereas the App Stores still count this as a new install.
  2. A user installed your app and launched it for the first time two weeks later. Google/iTunes record that install on the installation date, while AppsFlyer records the date of the first launch of the app. In some cases, this can cause major discrepancies in 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 AppsFlyer's.

App Stores attribute installs of unique users, i.e. one install per Google or iTunes account regardless of the number of devices on which the app is installed.

AppsFlyer attributes installs on unique devices.

The following causes are all related to Installation uniqueness:

Reasons for over attribution by AppsFlyer
Cause Description AppsFlyer tip

Upgrading existing app install

If an app is released without the AppsFlyer SDK and is later re-released in the App Stores with the AppsFlyer SDK integrated into it, AppsFlyer shows a peak of new 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 considers this to be a single install, while AppsFlyer considers this as two installs.

You can trace these "double" installs using the customer user ID value. If you generate a unique customer user ID for each new user, and use the same value on all installs from the same user, then you can filter out duplicate customer user IDs from the raw data installs report, which nuetralizes this discrepancy cause.

iOS 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

Same user for the stores, but two different devices for AppsFlyer.

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's Protect360 anti-fraud solution can easily detect if your app is suffering from these types of fraud.

Installs coming from out of Google Play

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

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

 Examples

  1. A user installed (and opened) an app on both his or her iPhone and iPad. AppsFlyer counts this as two installs, whereas the App Store counts it as a single install.
  2. A user has upgraded to a new device, synced the device to his or her 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 user and does not count it. Then, in March 2017, the app, that now has AppsFlyer's SDK integrated into it, releases a new version to the store. The user upgrades to the newest app version and launches it. AppsFlyer counts the install as a new Organic install, whereas the store does not, as the user was already registered in 2016.
    This can be a major cause for discrepancies, especially if the app has a large user install base from the period prior to the AppsFlyer SDK integration.
Was this article helpful?
8 out of 10 found this helpful

Page Contents: