どのようにお手伝いできますか?

Migration to AppsFlyer from other vendors

  • 更新

At a glance: Plan your migration to AppsFlyer from another attribution vendor. Understand how to avoid double charges, data duplication, and data loss during the migration period.

migration flow

他のベンダーからAppsFlyerへの移行

他のベンダーからAppsFlyerへ移行するには、主に以下の作業が必要です:

You can work on these tasks simultaneously. However, we recommend that you:

  • AppsFlyer SDKを搭載したアプリバージョンをリリースする前に、すべての作業を完了させてください。
  • デバイスID移行を実行する前に、既存のマーケティングキャンペーンを一時停止してください。

AppsFlyerとAdjustの計測比較

When considering migrating to AppsFlyer from another MMP, advertisers might want to compare both MMP attribution measurements across the same media sources and campaigns. However, not all media sources support measurement with more than one MMP. Those that do, may come with certain limitations and challenges to prevent attribution discrepancies. See more about Measuring attribution with multiple MMPs. 

タスク

The following table describes the scope of work required for each task. To see a precise breakdown of the general tasks, as well as to record your progress, download this spreadsheet

作業内容

タスク 必要な対応 Who's involved 作業時間の目安 Remarks
前提条件
  1. Create an AppsFlyer account.
  2. AppsFlyerにアプリを追加
  3. [オプション] 独自のアクティブユーザーの定義に合わせて、デフォルトで90日のリアトリビューション期間の設定を変更
マーケティング担当/AppsFlyer管理画面ユーザー 2時間  
SDK実装
  • AppsFlyer SDKをアプリに実装
  • S2SまたはSDKのアプリ内イベントをマッピング
  • アプリストアでアプリバージョンを更新
アプリ開発者 1‐2週間
  • 推奨:テスト用にテスト / 検証用アプリにAppsFlyer SDKを実装してください。
  • 本番アプリは、その他の作業が完了した後、アプリストアで更新する必要があります。
デバイス移行 [オプション] 既存ユーザーの重複計測を防ぐため、デバイスIDを移行します。 データエンジニア 1‐2週間
  • 移行前に既存のキャンペーンを一時停止し、アプリバージョンが更新されてから再開することをご検討ください。
  • 全てのユーザーをカバーするために移行最終日にデバイス移行を繰り返すことをご検討ください。 
キャンペーン移行
  • アドネットワークをAppsFlyerで連携してください。
  • 既存キャンペーンを以下から移行します:
    • SRN
    • SRN以外のアドネットワーク
    • オウンドメディア
マーケティング担当/UA(新規獲得)担当者 1‐3週間
データレポートの設定
  • 現在のレポート構成をAppsFlyerの構成に適応/マッピングします。
  • AppsFlyerレポートを受信する準備をします。
データエンジニア 2‐4週間  

SDK実装

SDK実装

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. Integrate the AppsFlyer SDK into the app.
    See the guides for Android and iOS SDK integration.
  2. Map in-app events you want to be recorded, using the AppsFlyer schemes.
    This can be done via SDK or S2S.
  3. Remove the competing attribution vendor's SDK.
    You can do this immediately and switch exclusively to AppsFlyer, or run both SDKs simultaneously for a few weeks. View a breakdown of these options in the table below.
     

    任意 更新されたアプリ
    バージョンのリリース後
    影響
    他社SDKを削除(推奨) 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.
    • Data validation is possible. Meaning, you can compare data from AppsFlyer and the other vendor.
    • Double attribution, which may cause double charges with ad networks. See example below.
    • 作業量がより多いです。
  4. After all other tasks in the scope of work are completed, update the app version with AppsFlyer SDK to the market. New users are attributed by AppsFlyer. 
    Note:
    • iOS、Google Play、および関連する全てのAndroidの外部ストアのアプリを更新してください。
    • 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, CUID) into AppsFlyer. 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 your previous vendor. For example, SRN double charges, which occur when users originally attributed to an SRN under your prior vendor, and who are still within the lookback window, are claimed by the SRN again under AppsFlyer.

 Example

  • 6月15日に、新規ユーザーがMeta広告をクリックしてアプリをインストールします。
  • On June 24 the user updates the app to the version with the AppsFlyer SDK, and launches. For AppsFlyer, this is a new user, that needs to be attributed in real time.
  • AppsFlyer queries Meta ads with the user device ID. Because the user is still within the Meta ads 28-day lookback window, Meta ads self-attributes the user. This causes a double charge to the app owner for the same user.

デバイスを移行すると、データは以下のようにAppsFlyerに反映されます:

  • 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.
  • リターゲティング:リアトリビューションとリエンゲージメントは通常通り計測されます。
  • アクティビティデータ:正常に表示されます。
  • 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 Retention and Cohort reports. 

 Note

If the app is not opened within 180 days from the migration date, all of the migrated device data is deleted. Consequently, if the app is opened after the 180 days period, a new install will be recorded.

デバイス移行の方法

デバイス移管を行うには: 

  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. 

Attributed migration

この方法でAppsFlyerに移行したデバイスは、アプリ内イベント、セッションが記録され、以前の計測ベンダーが計測したメディアソース、およびアドネットワークのデータ保持ポリシーに従って表示されます。

流入経路を含む移行のCSVファイルの構成

Column
name
Description Mand-atory Examples
app_id
 
App ID as it appears in AppsFlyer dashboard Yes
  • Android: com.great.app1
  • iOS: id123456789
platform
 
Device platform: ios or android Yes
  • ios
  • android
device_id
 
  • Android: gaid, android_id, 
  • iOS: IDFV (recommended, if available) or IDFA
  • 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.
Yes
  • gaid (lower case): 9c9a82fb-d5de-4cd1-90c3-527441c11828
  • android_id (lower case): f35aea8908254891
  • IDFV (upper case): A7328D98-A973-402A-8B87-D22A8611F2AF
  • IDFA (upper case): 9876F1SS-2983-3855-27RR-2R626772VFNB

     

id_type
 
  • Android: 
    • advertiserId  
    • android_id
    • amazon_aid
  • iOS:
    • idfa  
    • idfv
  • Currently, other identifiers, OAID, IMEI are not supported. 
    Use non-attributed migration for Android users, which are not from Google Play.

Note

android_id is not collected by the AppsFlyer SDK by default. If you use android_id as your identifier, make sure to collect it in your SDK integration.

Yes
  • advertiserId
  • android_id
  • idfa
  • idfv
  • amazon_aid (lower case): df07c7dc-cea7-4a89-b328-810ff5acb15d
install_time
 
The original app install time with the ISO 8601 UTC format:
yyyy-mm-ddTHH:MM:SS.SSS
No 2018-01-22T08:45:33.412
media_source
 
  • Either:
    • AppsFlyer partner ID
    • Custom media source (cannot be a partner ID).
  • To get the list of partner IDs as required by AppsFlyer:
  • Format: Values are case-sensitive
Yes


Non-organic: facebook_int, googleadwords_int

Organic: organic

integrated_partner
 
  • Indicates whether the media source is an integrated partner or not. Meaning organic or custom media source.
     
  • Format: Values are case sensitive
Yes
  • yes
  • no (if media_source is custom)
campaign
 

For more granular attribution details, supply the original campaign name.

Format: String

No  
campaign_id
 

 For more granular attribution details, supply the original campaign id.

Format: String no spaces permitted

No  

CSVファイルのルール:

  • このCSVファイルには複数アプリのユーザーデバイスデータを含めることができます(複数アプリでまとめて移行する際)。
  • 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.
  • 各行には、カンマで区切られた9つの項目を含めてください。
  • 必要ない項目の値は空 (blank) にしてください。
  • Files can contain up to 5 million rows.
  • 複数ファイルになる場合には、ファイル毎に一意の名前をつけてください。
  • UTF-8を使って、データをエンコードしてください。
  • [任意] ZIPもしくはGZIPを使って、ファイルを圧縮してください。
     

サンプルCSVはこちら

Non-attributed migration

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.

流入経路を含まないデバイス移管のCSVファイルの構成

任意 列 いつ使うか 例
1 App ID + IDFA/GAID/IDFV
  • すべてのAndroidユーザーがGAID識別子を持っている場合
  • iOSのみのユーザー 
device_migration_file_option_1.png
2 App ID + Device ID + Device ID type
  • Androidユーザーの一部がIMEIまたはAndroid IDのみを持ち、GAIDを持たない場合(第三者ストア以外では、Androidバージョンは4.4.2以下)
  • Android IDは16進数形式である必要があります。

Note:

  • ID type列には、advertiserId (amazon_aidも対応), idfa, idfv, android_id, imei という正確な文字列を使用します。
  • android_id または imeiを使用していて、後日 AppsFlyer がより良い識別子を受取った場合、新しい計測結果が記録されることがあります。
  • android_id and imei are not collected by the AppsFlyer SDK by default. If you use either of these identifiers, make sure to collect them in your SDK integration.
device_migration_file_option_2.png

CSVファイルのルール:

  • このCSVファイルには複数アプリのユーザーデバイスデータを含めることができます(複数アプリでまとめて移行する際)。
  • Each row contains a single device ID per app.
  • 選択したファイル構造オプションに応じて、ファイルのカラムは以下の通りでなければならない(リストされた順序である必要があります):
    • オプション1: app_id,device_id
    • オプション2: app_id,device_id,id_type
  • App_IDは小文字で入力してください。
  • Androidの各種IDもすべて小文字で入力してください。
  • IDFA/IDFVはすべて大文字で入力してください。
  • Up to 25 million rows permitted

サンプルCSVはこちら

キャンペーン移行

既存のマーケティングキャンペーンをAppsFlyerに切り替えることで、AppsFlyerでの計測を有効にし、重複請求や計測データの損失を回避できます。

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. 

SRN

SRNs reply to Mobile Measurement Partners (MMPs) 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, you may incur double charges.

To migrate SRN campaigns:

  • AppsFlyer管理画面で、関連するSRNとの連携を有効に設定します。

 Note

  • SRNでは、複数のMMPを同時に実行できます(Meta adsとTwitterを除く)。
  • Meta Adsはアプリ内イベントの重複排除ができません。

SRN以外のアドネットワーク

アドネットワークの計測リンクは、ユーザーの広告接触を記録しており、広告とのエンゲージメントが結果的にインストールに至った場合の計測に使用されます。

To migrate non-SRN ad network campaigns:

  1. AppsFlyerにて、関連するアドネットワークとの連携設定を有効にします。
  2. 各アドネットワークのAppsFlyer計測リンクを生成します。
  3. 各キャンペーンの既存リンクをAppsFlyerの計測リンクに切り替えます。 

オウンドメディア

オウンドメディアとは、以下の媒体で使用される計測リンクを指します:

  • コンテンツのシェア
  • Web-to-app
  • Email
  • SMS
  • ソーシャルメディアの投稿
  • ブログ
  • インターネットコミュニティ(Quoraなど)
  • 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 current owned media links into AppsFlyer OneLink links:

  • CSMにご連絡いただければ、現在お使いのチャネルやツールに応じて、オウンドメディアリンクをOneLinkリンクに変換するお手伝いをいたします。

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.

データレポートの設定

レポート構造の適用とマッピング

Before migration, your systems store your attribution data from your current vendor 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.

レポート構造を適応/マッピングする方法:

  • Adjust、Branch/Tune、Kochavaから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.

次のようなレポーティング方法があります:

  • ダッシュボード
  • Export reports
  • Push API
  • Pull API
  • Data Locker