Migrating to AppsFlyer from other vendors

App_migration_summary.png

Introduction

Are you migrating to AppsFlyer from another attribution vendor?

Welcome! It's never too late to do the right thing! 

Your migration should be planned carefully, to avoid double charges, data duplicity and data loss during the migration period.

AppsFlyer enables migrating your entire user device base, including their original attribution data.

This article describes what account owners should consider when migrating to AppsFlyer, and how to perform the migration seamlessly. The article discusses the following topics:

  • When to remove the competitor's SDK
  • Migrating existing users
  • Keeping data continuity with different platforms

Before you start

Before migrating your users and configurations to AppsFlyer, you need to:

  1. Create your AppsFlyer account, if your company doesn't have one yet.
  2. Define your apps in your AppsFlyer account.
  3. [Optional] For each app, set the re-attribution window (the default is 90 days).

App_migration_detailed_flow.png

Task 1: Preparing your app

Integrate the AppsFlyer SDK with the app's next version release to start attributing your new users.

Note - this task should be completed 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
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.
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.

 Notes

  • 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: Migrating 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 first launch of the app with AppsFlyer SDK, existing users are attributed as new organic users in AppsFlyer, regardless the original source.
  2. Double charges: Upon 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 look back window.

     Example

    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 Facebook's 28 day lookback window, Facebook self-attributes the user. This causes double charge to the app owner for the same user.

To solve these issues, AppsFlyer enables the 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 with 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, that are active during the last re-attribution window period. For example, if your app has a 90 day re-attribution window, you should migrate the users, that had at least one session in the last 90 days.

How is Device migration performed?

To perform Device migration you need to send your AppsFlyer CSM a CSV file, which contains user device IDs and additional data. The CSV file can contain user devices from multiple apps, with each row representing a single device ID per app. 

There are two methods of migration - attributed and non-attributed, described below.

Attributed device 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.

CSV file columns:

Column name Column
name
on file
Description Mand-atory? Example/comment
App ID app_id

The App ID as appears in AppsFlyer dashboard.

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

Platform

platform

iOS or Android device.

 Yes "ios" or "android" (all lower case).

Device ID

device_id

Use GAID for your Android users, and IDFA for your iOS users.

GAID MUST be in lowercase.

IDFA MUST be in uppercase.

 Yes
  • GAID:
    9c9a82fb-d5de-4cd1-90c3-527441c11828
  • IDFA:
    9876F1SS-2983-3855-27RR-2R626772VFNB
ID type id_type

Use advertiserId for your Android users, and idfa for your iOS users.

Currently other identifiers, used by out-of-store markets (OAID, IMEI and Android ID) are not supported with attributed migration.
Use non-attributed migration for Android users, which are not from Google Play.

 Yes
  • "advertiserId" or "idfa".
  • Values are case-sensitive.
Install time 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.
 No
  • Must be a valid past date.
  • Example:
    2018-01-22T08:45:33.412
  • 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).
Media source media_source
AppsFlyer partner ID as appears in AppsFlyer dashboard.
 Yes
  • Make sure to get the list of the exact partner IDs from AppsFlyer.
    Examples: "Facebook Ads", "googleadwords_int".
  • For organic installs, use “organic”.
  • Values are case-sensitive.
Integrated
partner 
integrated_partner
Indicates whether the media source is an integrated partner or not (i.e. organic or custom media source).
 Yes  
  • "yes" or "no"
  • Values are case-sensitive.
Campaign name campaign
For more granular attribution details, supply the original campaign name.   No String 
Campaign ID campaign_id
   No String (no spaces allowed)

CSV file rules:

  • File MUST include all column headers as follows: app_id,platform,device_id,id_type,install_time,media_source,integrated_partner,
    campaign,campaign_id
  • Each row MUST contain exactly 9 fields and commas, although the non-mandatory fields may remain empty.
  • File can contain up to 20 million rows.
  • When creating multiple files use a unique file name for each of the files.
  • File may be compressed using ZIP or GZIP.
  • CSV file MUST be encoded in UTF-8.

Non-attributed device 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.

CSV file columns:

Columns When to use Example
App ID + IDFA/GAID
  • 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

CSV file rules:

  • File MUST include all column headers as follows: app_id,device_id for option 1 or 
  • app_id,device_id,id_type for option 2.
  • App IDs should be in lowercase.
  • All Android identifiers should be in lowercase.
  • IDFAs should be in uppercase.
  • File can contain up to 25 million rows.

Task 3: Keeping data continuity

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

In this chapter we explain the best practices with different media sources to avoid these migration issues.

With 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.

With 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 the SRNs in AppsFlyer.
  3. After submitting the app, resume campaigns with SRNs.

With 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:

  1. 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.
  2. 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's 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?