Migrating apps to AppsFlyer
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:
- Create your AppsFlyer account, if your company doesn't have one yet.
- Define your apps in your AppsFlyer account.
- [Optional] For each app, set the re-attribution window (the default is 90 days).
Task 1: Preparing your app
Integrate the AppsFlyer SDK with the app's next version release to start attributing your new users.
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: 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:
- 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.
- 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:
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.
App ID as it appears in AppsFlyer dashboard
Device platform: iOS or Android
iOS: IDFA or IDFV
iOS: idfa or idfv
Currently, other identifiers, OAID, IMEI, and Android ID are not supported.
The original app install time with the ISO 8601 UTC format:
For more granular attribution details, supply the original campaign name.
For more granular attribution details, supply the original campaign id.
Format: String no spaces permitted
CSV file rules:
- File must include all column headers as follows: app_id,platform,device_id,id_type,install_time,media_source,integrated_partner,
- Each row must contain exactly 9 fields and commas. Non-mandatory fields can be left empty.
- File can contain up to 20 million rows.
- When creating multiple files use a unique file name for each file.
- File may be compressed using ZIP or GZIP.
- Data must be encoded in UTF-8.
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 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.
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.
- Pause campaigns with SRNs at least one day before creating the device migration file.
- Configure the SRNs in AppsFlyer.
- 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.
- 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.
Read here how a leading digital entertainment company in India, Hungama, seamlessly migrated to AppsFlyer with over 65 million monthly users.