Migrating to AppsFlyer from other vendors

At a glance: If you are migrating to AppsFlyer from another attribution vendor, use this guide to plan the migration. Understand how to avoid double charges, data duplicity, and data loss during the migration period. Follow the procedures in the guide to migrate existing users, maintain data continuity, and to know when you can remove the other vendor's attribution SDK from the app. 


Before you start

Complete the following before migrating data:  

  1. Create an AppsFlyer account
  2. Add the app in AppsFlyer
  3. [Optional] Change the default 90-day re-attribution window 

Migration to AppsFlyer detailed flow


Task 1: Prepare the app

Integrate the AppsFlyer SDK into the app. Release the version with AppsFlyer SDK to the market. New users will be attributed via AppsFlyer. 

Complete this task before submitting your app (task 4), so it could be done in parallel with tasks 2 and 3.

What should you do with the attribution competitor's SDK in the new version?

Your options are:

Option What happens after
new version release
Remove competitor's SDK (recommended) Only AppsFlyer records new installs and updating users.
Competitor still shows events performed by users, until the users update their app too.
No double attribution.
Keep competitor's SDK for a transition period AppsFlyer and competitor attribute new installs and report events. At a later date, remove the competitor's SDK. Double attribution, which may cause double charges with ad networks. See example below.


  • Do you promote your Android app in out-of-store markets? Remember to update your app version in these markets along with the Google Play.
  • Your Android app may exist in unofficial APK sites, even if you don't know it (search the web for your app's package name to find out). APK sites take some time to update to the latest version, so they may bring organic users, which install old versions without AppsFlyer SDK.
  • App update roll outs in the app stores may take up to a couple of days to fully complete. Users installing during this phase may still get the previous version.

Task 2: Migrate existing users

After submitting the app version, with the AppsFlyer SDK, new users are attributed and recorded in AppsFlyer correctly.

For the existing app users, consider the following:

  1. New organic installs: Upon the first launch of the app with AppsFlyer SDK, existing users are attributed as new organic users in AppsFlyer, regardless of the original source.
  2. Double charges: Upon the first launch of new users, AppsFlyer queries the ad networks, which the app works with. SRNs, like Facebook or Google Ads, may claim attribution again for these users, if they are still within their lookback window.


    A new user clicks on an ad in Facebook and installs on June 15.
    On June 24 the user updates the app, which now has AppsFlyer SDK, and launches. For AppsFlyer, this is a new user, that needs to be attributed in real-time.
    AppsFlyer queries Facebook with the user's device ID. Because the user is still within the Facebook 28 day lookback window, Facebook self-attributes the user. This causes a double charge to the app owner for the same user.

To solve these issues, AppsFlyer provides a device migration process.

What is Device migration?

Device migration is the process of uploading your existing users device IDs into AppsFlyer, before releasing the new app version, which has the AppsFlyer SDK.

When a migrated device launches for the first time using the AppsFlyer SDK, it doesn't show as a new organic install in AppsFlyer. Furthermore, AppsFlyer doesn't query the SRNs about the device, and so it can't be claimed by them as a new non-organic install. This solves the two migration issues explained above.

What happens to migrated devices?

Migrated devices reflect in AppsFlyer as follows:

  • Installs data: Similar to Re-installs, migrated devices have no install data. Migrated devices installs are not displayed in AppsFlyer.
  • In-app events and sessions data: Recorded and displayed as organic for non-attributed device migration method, or attributed to the media source and campaign, if using the attributed method
  • Retargeting: Re-attributions and re-engagements are displayed normally.
  • Activity data: Shown as part of the organic data.
  • Retention and cohort data: Migrated devices have no install date, and as such aren't associated with any cohort, and can't shown in the Retention and cohort reports. 

Which devices should be migrated?

Should you migrate all your users, or only users that recently installed your app?

Consider the following:

Users, that installed your app long ago, are mostly inactive users. If these users engage with your ads, install, and become active again, this is important attribution data. Migrating all your users will prevent you from getting this data.

On the other hand, your app may have veteran users, that are still active. By migrating only users that recently installed, you may be charged for "acquiring" existing users, when they engage with ads for your app, shortly before the migration.

We recommend migrating users, active during the current re-attribution window period. For example, if your app has a 90-day re-attribution window, migrate the users, that had at least one session during the previous 90 days.

To migrate devices: 

Send your AppsFlyer CSM a CSV file, as detailed in this section. The CSV file can contain user devices from multiple apps. Each row contains a single device ID per app. 

Use one of the following migration methods:

Attributed migration

Devices migrated to AppsFlyer with this method are recorded according to their given attribution. Their in-app events and sessions data are also recorded and displayed accordingly.

Description Mand-atory Examples

App ID as it appears in AppsFlyer dashboard

  • Android: com.great.app1 
  • iOS: id123456789


Device platform: iOS or Android

  • ios
  • android


Android: GAID 



  • GAID (lower case): 9c9a82fb-d5de-4cd1-90c3-527441c11828
  • IDFA (upper case): 9876F1SS-2983-3855-27RR-2R626772VFNB
  • IDFV (upper case): A7328D98-A973-402A-8B87-D22A8611F2AF

Android: advertiserId 

iOS:idfa or idfv

Currently, other identifiers, OAID, IMEI, and Android ID are not supported. 
Use non-attributed migration for Android users, which are not from Google Play.

  • advertiserId
  • idfa
  • idfv

The original app install time with the ISO 8601 UTC format:
If not provided, migration time is used instead.

  • Must be a valid past date.
  • Devices with install time preceding file creation date minus app re-attribution window are not migrated with attribution, and upon first launch are treated as new installs.
    Example: A migration file is created on May 1 and the re-attribution window is 30 days. All devices with install time before April 1 are not attributed. With their first launch, these devices are treated as new installs (most likely organic).


  • AppsFlyer partner ID as appears in AppsFlyer dashboard.
  • Make sure to get the list of the exact partner IDs from AppsFlyer.
  • Format: Values are case-sensitive

Non-organic: facebook_int, googleadwords_int

Organic: organic

  • Indicates whether the media source is an integrated partner or not. Meaning organic or custom media source.
  • Format: Values are case sensitive
  • yes
  • no

For more granular attribution details, supply the original campaign name.

Format: String


 For more granular attribution details, supply the original campaign id.

Format: String no spaces permitted

Attrbiuted device migration CSV structure

CSV file rules:

  • All column headers must be included: app_id,platform,device_id,id_type,install_time,media_source,integrated_partner,
  • Each row must contain exactly 9 fields separated by commas.
  • Leave non-mandatory fields empty (blank)
  • Files can contain up to 20 million rows.
  • If you have multiple files, give each file a unique name.
  • Encode data using UTF-8.
  • [Optonal] Compress files using ZIP or GZIP.

Non-attributed migration

Devices migrated to AppsFlyer with this method are recorded as organic users.
Their in-app events and sessions data are also recorded and displayed as organic.

Columns When to use Example
  • If all your Android users have GAID identifiers.
  • iOS only users 
App ID + Device ID + Device ID type
  • If some of your Android users have only IMEI or Android ID , but not GAID (out-of store markets, Android versions below 4.4.2).
  • Android ID needs to have a hexadecimal format.

Use the exact strings for the ID type column: advertiserId, idfa, android_id, imei.

Non-attributed device migration CSV file structure

CSV file rules:

  • Files must include all column headers as follows:
    • Option1: File must include all column headers as follows: app_id,device_id 
    • Option 2: app_id,device_id,id_type 
  • App IDs in lowercase
  • Android identifiers in lowercase
  • IDFA/IDFV in uppercase
  • Up to 25 million rows permitted

Task 3: Keep data continuity

When you submit the app version, having the AppsFlyer SDK, you may still have active campaigns running on different media sources. This can cause duplicate charges, or alternately, loss of attribution data.

Using attribution links

Attribution links record the engagements of users and are subsequently used to attribute the engagements, that become actual installs. Therefore, users that have recorded engagements with other attribution vendor's links, and then have their first launch after the switch over to AppsFlyer, are attributed as organic users.

Best practice: 98% of users install within the first seven days following their ad engagement. We recommend to stop all campaigns with attribution links at least seven days before creating the device migration file.

Via SRNs

SRNs reply to MMPs (Mobile Measurement Partners), when queried about engagements of specific devices. If two MMPs, for example AppsFlyer and a competing attribution vendor, query the same SRN about the same device install, it may incur double charges.

Best practice:

  1. Pause campaigns with SRNs at least one day before creating the device migration file.
  2. Configure SRNs in AppsFlyer.
  3. After submitting the app, resume SRN campaigns/

Using other platforms

Other platforms, like your internal BI system or 3rd Party analytics platforms, aim for keeping data continuity, despite the switch over.

Best practice:

  • Before the app submit, configure AppsFlyer to send data to the relevant partner or platform, for example, by using Push API. This takes care of new users and existing users, that upgrade to the app version with AppsFlyer SDK.
  • To continue recording existing users in your BI system, until they upgrade to the version with AppsFlyer SDK, keep the relevant configuration with the old attribution vendor for 30 days.

Task 4: Submit app version with AppsFlyer SDK

Enjoy using AppsFlyer! 

Task 5 (optional): Getting report data

You can get report data into your internal systems from AppsFlyer using a number of methods like APIs, CSV downloads, and Data locker.

Since your systems probably store your attribution data from your current vendor, they will need adapting to AppsFlyer reports structure and fields.

To save you lots of time and work, we have already done this.

Contact AppsFlyer for information on adapting your reports data from Adjust, Branch/Tune or Kochava to AppsFlyer.

Case study

Read here how a leading digital entertainment company in India, Hungama, seamlessly migrated to AppsFlyer with over 65 million monthly users. 

Was this article helpful?