Migrating to AppsFlyer from other vendors

  • Advertisers
  • Agencies

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.

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: Integrating AppsFlyer SDK

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

However, what should you do with the 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

  1. 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.
  2. 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.
  3. 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. 
  • 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 app IDs and device IDs. The CSV file can contain user devices from multiple apps, with each row representing a single device ID per app. 

CSV file rules:

  • Include the column headers app_iddevice_id (and 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

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

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?
1 out of 1 found this helpful