Migrating to AppsFlyer from other vendors

At a glance: Plan your migration to AppsFlyer from another attribution vendor. Understand how to avoid double charges, data duplication, and data loss during the migration period.

migration flow

Overview

Migrating to AppsFlyer from another vendor includes the following main tasks:

You can work on these tasks simultaneously. However, we recommend that you:

  • Complete all of the tasks before releasing your updated app with the AppsFlyer SDK. 
  • Pause existing marketing campaigns before performing the device ID migration. 

Tasks

The following table describes the scope of work required for each task. To record your progress, download this spreadsheet.

Scope of work
Task Action required Who's involved Estimated time Remarks
Prerequisites
  1. Create an AppsFlyer account.
  2. Add the app in AppsFlyer.
  3. [Optional] Change the default 90-day re-attribution window to align with your definition of active users.
Marketer/AppsFlyer dashboard user

2 hours

 
SDK integration
  • Integrate AppsFlyer SDK in your app.
  • Map S2S or SDK in-app events.
  • Update app version in app stores.
App developers

1-2 weeks

App must be updated in app stores after all other tasks are completed.

Device migration [optional] Migrate device IDs to avoid double attribution of your existing users. Data engineer 1-2 weeks Consider pausing existing campaigns before migration, and resuming them after app version is updated. 
Campaign migration

Migrate existing campaigns from: 

  • SRNs
  • Non-SRN ad networks
  • Owned media
Marketer/UA manager 1-3 weeks
Data report setup
  • Adapt/map your current report structures to AppsFlyer structures.
  • Prepare to receive AppsFlyer reports.
Data engineer 2-4 weeks  

SDK integration

SDK integration

The AppsFlyer SDK integrated into the app is the link between the app and the AppsFlyer platform. It reports app installs, app opens, in-app events, and so on.

To integrate the AppsFlyer SDK:

  1. Integrate the AppsFlyer SDK into the app.
    See the guides for Android and iOS SDK integration.
  2. Map in-app events you want to be recorded, using the AppsFlyer schemes.
    This can be done via SDK or S2S.
  3. Remove the competing attribution vendor's SDK.
    You can do this immediately and switch exclusively to AppsFlyer, or run both SDKs simultaneously for a few weeks. View a breakdown of these options in the table below.
    Option What happens after
    updated app version release
    Impact
    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.
    • Fast transition.
    • 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.
    • Data validation is possible. Meaning, you can compare data from AppsFlyer and the other vendor.
    • Double attribution, which may cause double charges with ad networks. See example below.
    • Higher workload.
  4. After all other tasks in the scope of work are completed, update the app version with AppsFlyer SDK to the market. New users are attributed by AppsFlyer. 
    Note:
    • Make sure to update the app for iOS, Google Play, and any relevant Android out-of-store markets.
    • 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 rollouts in the app stores can take a couple of days to fully complete. Users installing during this phase may still get the previous version.

Device migrationoptional

About device migration

Device migration is the process of uploading a list of your existing user device IDs (IDFA, IDFV, GAID, CUID) into AppsFlyer. You should perform this process before releasing the new app version, which will include the AppsFlyer SDK. There are two options when migrating devices, attributed or non-attributed migration.

Device migration solves data issues associated with existing app users who downloaded the app, and were attributed by your previous vendor. For example, SRN double charges, which occur when users originally attributed to an SRN under your prior vendor, and who are still within the lookback window, are claimed by the SRN again under AppsFlyer.

 Example

  • A new user clicks on an ad in Facebook and installs your app on June 15.
  • On June 24 the user updates the app to the version with the 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 device ID. Because the user is still within Facebook's 28-day lookback window, Facebook self-attributes the user. This causes a double charge to the app owner for the same user.

Once you migrate devices, data reflects in AppsFlyer as follows:

  • Installs data: Similar to re-installs, migrated devices have no install data. Migrated device 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. As such, they aren't associated with any cohort, and can't be shown in the Retention and cohort reports. 

How to migrate devices

To migrate devices: 

  1. Decide which user population to migrate. You can migrate all existing users (which may prevent you from getting accurate re-attribution data from AppsFlyer), or users that only recently installed your app (which may lead to double charges of somewhat older users).
    We recommend migrating users who are active during your current re-attribution window period. For example, if your app has a 90-day re-attribution window, migrate those users who have at least one session during the previous 90 days.
  2. [Optional] Tell the marketer/UA manager to pause existing marketing campaigns (from SRNs, non-SRN ad networks, owned media, etc.) until after the device migration.
    If you decide not to pause campaigns, migrate any remaining device IDs from the other vendor as soon as the updated app version with the AppsFlyer SDK is released to app stores. 
  3. Prepare a CSV file based on the user population selected, using either the attributed or non-attributed migration structure.
  4. Send your AppsFlyer CSM the CSV.
    Your CSM will migrate the device IDs to AppsFlyer. 

Attributed migration

Devices migrated to AppsFlyer with this method have their installs, in-app events, and sessions recorded and displayed according to the media source reported by the previous attribution vendor, and according to the ad networks' data retention policies.

Column
name
Description Mand-atory Examples
app_id

App ID as it appears in AppsFlyer dashboard

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

platform

Device platform: iOS or Android

Yes
  • ios
  • android

device_id

Android: GAID 

iOS: IDFA or IDFV

 

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

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.

Yes
  • advertiserId
  • idfa
  • idfv
install_time

The original app install time with the ISO 8601 UTC format:
yyyy-mm-ddTHH:MM:SS.SSS
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).
No

2018-01-22T08:45:33.412

media_source
  • Either:
    • AppsFlyer partner ID as appears in AppsFlyer dashboard
    • Custom media source (cannot be a partner ID).
  • Make sure to get the list of the exact partner IDs from AppsFlyer.
  • Format: Values are case-sensitive
Yes


Non-organic: facebook_int, googleadwords_int

Organic: organic

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

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

Format: String

No  
campaign_id

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

Format: String no spaces permitted

No  
Attributed device migration CSV structure

CSV file rules:

  • CSV file can contain user devices from multiple apps.
  • Each row contains a single device ID per app. 
  • All column headers must be included: app_id,platform,device_id,id_type,install_time,media_source,integrated_partner,
    campaign,campaign_id
  • 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.
  • [Optional] Compress files using ZIP or GZIP.

Non-attributed migration

Devices migrated to AppsFlyer with this method are recorded (but do not display) as organic users. Their in-app events and sessions are also recorded and displayed as organic.

Columns When to use Example
App ID + IDFA/GAID/IDFV
  • If all your Android users have GAID identifiers.
  • iOS only users 
device_migration_file_option_1.png
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.

device_migration_file_option_2.png
Non-attributed device migration CSV file structure

CSV file rules:

  • CSV file can contain user devices from multiple apps.
  • Each row contains a single device ID per app. 
  • 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

Campaign migration

Switch existing marketing campaigns to AppsFlyer to enable AppsFlyer attribution, and avoid duplicate charges and the loss of attribution data.

Note: You can choose to only migrate a few marketing campaigns at a time. In this case, you can segment the ones you want to migrate by media source (for example, ad network or agency), geo, or campaign. 

SRNs

SRNs reply to Mobile Measurement Partners (MMPs) 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, you may incur double charges.

To migrate SRN campaigns:

  • Activate and configure relevant SRNs in AppsFlyer.

 Note

  • SRNs can run multiple MMPs (except Facebook and Twitter).
  • Facebook cannot de-duplicate in-app events.

Non-SRN ad networks

Ad network attribution links record the engagements of users and are subsequently used to attribute the engagements that become actual installs.

To migrate non-SRN ad network campaigns:

  1. Activate the relevant ad networks in AppsFlyer.
  2. Generate AppsFlyer attribution links for each ad network.
  3. Switch the existing links in each of your campaigns with the AppsFlyer attribution links. 

Owned media

Owned media refers to attribution links you use in:

  • Content sharing
  • Web-to-app
  • Email
  • SMS
  • Social media posts
  • Blogs
  • Internet communities (Quora, etc.)
  • and more...

For these campaigns, AppsFlyer uses OneLink custom links. OneLink custom links redirect users based on their device to the correct app store, directly into the app, or to a web URL/landing page.

To change your links for other vendors into AppsFlyer OneLinks:

  • Contact your CSM, who will assist you with the bulk migration of all your links. 

Data report setup

Adapt and map report structures

Before migration, your systems store your attribution data from your current vendor according to the reporting structures, fields, and parameters you have set up with them. For AppsFlyer to correctly report data, you must adapt and map your current report structures to AppsFlyer report structure, fields, and parameters.

To adapt/map your report structures:

  • Contact your AppsFlyer CSM for help in quickly adapting/migrating your report data structures from Adjust, Branch/Tune, or Kochava to AppsFlyer.

Prepare report methods

You can get raw and aggregate report data from AppsFlyer using a number of methods. Familiarize yourself with the methods and set up the ones that are relevant to you.

Reporting methods include:

  • Export CSV
  • Push API
  • Pull API
  • Data Locker

Case study

Read about how a leading digital entertainment company in IndiaHungama—seamlessly migrated to AppsFlyer with over 65 million monthly users. 

Was this article helpful?