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:
- Create an AppsFlyer account
- Add the app in AppsFlyer
- [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:
- 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:
- 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.
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:
- 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.
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 SRNs in AppsFlyer.
- 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.
- 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.