Migrate from Adjust to AppsFlyer

To create an AppsFlyer account:

1. Create an AppsFlyer account. 
2. Add account users with appropriate permissions.

To add your app in AppsFlyer:

1. Add your app in AppsFlyer.
2. [Optional] Change the default 90-day re-attribution window to align with your definition of active users.
3. As part of the app onboarding wizard in AppsFlyer, prepare and send an email to your developer with instructions and tasks for SDK integration and in-app event mapping.

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. Receive the email from the marketer with instructions and tasks for SDK integration and in-app event mapping.
2. Follow those email instructions and use the AppsFlyer SDK integration wizard to integrate the AppsFlyer SDK into the app.
   • The wizard takes the developer from installation to successful testing of the integration. It also guides the developer in defining in-app events and successfully testing their transmission to AppsFlyer. Learn more about the SDK integration wizard
   • See additional developer guides for Android and iOS SDK integration.
   • Map in-app events you want to be recorded, using the AppsFlyer schemes.
     This can be done via SDK or S2S.
3. Remove the Adjust SDK.
   You can do this immediately and switch exclusively to AppsFlyer, or run both SDKs simultaneously for a while. View a breakdown of these options in the table below.

   Option	What happens after updated app version release	Impact
   Remove the Adjust SDK (recommended)	Only AppsFlyer records new installs and updating users. Adjust still shows events performed by users, until the users update their app too.	Fast transition. No double attribution.
   Keep the Adjust SDK for a transition period	AppsFlyer and Adjust attribute new installs and report events. At a later date, remove the Adjust SDK.	Data validation is possible. Meaning, you can compare data from AppsFlyer and Adjust. Double attribution, which may cause double charges with ad networks. See example below. Higher workload.

4. After all other tasks in this migration article are completed, release the app version with the 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 migration is the process of uploading a list of your existing user device IDs (IDFA, IDFV, GAID) into AppsFlyer. (If you don't have all the device IDs needed, you can contact your CSM to help guide you through the migration process using CUID.) 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 Adjust. For example, SRN double charges, which occur when users originally attributed to an SRN under Adjust, and who are still within the lookback window, are claimed by the SRN again under AppsFlyer.

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: Displayed normally.
• Retention and cohort data: Migrated devices have no install record. As such, they aren't associated with any cohort, and can't be shown in the cohort and retention reports. 

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. See sample CSV
4. Send your AppsFlyer CSM the CSV.
   Your CSM will migrate the device IDs to AppsFlyer. 

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.

The following sections explain what is needed to enable AppsFlyer measurement for different types of media sources: SRNs, non-SRN ad networks, owned media, and SKAN. 

SRNs

SRNs reply to Mobile Measurement Partners (MMPs) when queried about engagements of specific devices. If AppsFlyer and Adjust 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.

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 links. OneLink 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 Adjust links into AppsFlyer OneLink links:

• Contact your CSM, who will assist you with transforming your owned media links to into OneLink links according to the channels and tools you currently use.

SKAN

For SKAdNetwork (SKAN) attribution, you can only have one SDK update the conversion value. Otherwise, SKAN data is rendered meaningless. Therefore, make sure that after migration, only the AppsFlyer SDK updates the SKAN conversion value.

Learn about setting up the SKAN conversion value in AppsFlyer.

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:

• Dashboards
• Export reports
• Push API
• Pull API
• Data Locker

Before migration, your systems store your attribution data from Adjust 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 to AppsFlyer.

Devices migrated to AppsFlyer with this method have their 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.

Attributed device migration CSV structure

CSV file rules:

• CSV file can contain user devices from multiple apps.
• Do not duplicate the same combination of device ID and app ID in multiple rows. If duplication occurs, the last occurrence in the file is used.
• All column headers must be included: app_id, platform, device_id, id_type, install_time, media_source, integrated_partner, campaign, campaign_id. Note: The order of the fields is important and must be maintained.
• You can add both IDFV and IDFA for the same device, but they must be in separate rows. All fields in the separate rows should be the same, except device_id.
• Each row must contain exactly 9 fields separated by commas.
• Leave non-mandatory fields empty (blank).
• Files can contain up to 5 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. 

See sample CSV

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.

Non-attributed device migration CSV file structure

Option	Columns	When to use	Example
1	App ID + IDFA/GAID/IDFV	If all your Android users have GAID identifiers. iOS only users
2	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. Note: Use the exact strings for the ID type column: advertiserId (also supports amazon_aid), idfa, idfv, android_id, imei. If you use android_id or imei, and later AppsFlyer receives a better identifier, a new attribution may be recorded.

CSV file rules:

• CSV file can contain user devices from multiple apps.
• Each row contains a single device ID per app. 
• Depending on the file structure option you choose, file columns must be as follows (and in the order listed):
  • Option 1: 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.

See sample CSV