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

App_migration_summary.png

はじめに

他社のアトリビューションSDKベンダーからAppsFlyerに移行されますか?

ようこそ!正しいことをするのに遅すぎることは決してありません!

移行期間中の二重請求、データの重複、およびデータの損失を回避するため、移行は慎重に計画する必要があります。

AppsFlyerでは、オリジナルのアトリビューションデータを含む、全体のユーザーデバイスベースを移行可能です。

この記事では、AppsFlyerに移行する際にアカウント所有者が考慮すべき点と、移行をシームレスに実行する方法について説明します。この記事では、次のトピックについて説明します。

  • 他社SDKを削除するタイミング
  • 既存ユーザーの移行
  • 様々なプラットフォームでデータの継続性を維持する

はじめる前に

ユーザーと設定をAppsFlyerに移行する前に、次のことを行う必要があります。

  1. AppsFlyerアカウントを作成します(アカウントがない場合)。
  2. AppsFlyerアカウントでアプリを追加します。
  3. [オプション] アプリごとにリアトリビューションウィンドウを設定します(デフォルトは90日です)。

App_migration_detailed_flow.png

タスク1:アプリの準備

AppsFlyer SDKをアプリの次のバージョンリリースと統合し、新しいユーザーのアトリビューションを開始します。

注:このタスクは、タスク2および3と並行して実行するため、アプリを送信する(タスク4)前に完了する必要があります。

新しいバージョンの他社SDKはどのように処理しますか?

オプションは次の通りです。

オプション 新バージョンリリース後に
何が起こるか
影響
他社SDKを削除(推奨) AppsFlyerのみが、新規インストールと既存ユーザーを記録します。
他社SDKはユーザーがアプリを更新するまで実行したイベントを表示します。
重複アトリビューション無し
移行期間中に
他社SDKを保持する
AppsFlyerと他社SDKは、新規インストールとイベントをレポートします。後日、他社SDKを削除します。 重複アトリビューション有り - アドネットワークで二重請求が発生する可能性があります。次の例を参照してください。

 注意:

  • 第三者ストア (out-of-store) でAndroidアプリ広告を配信していますか?これらのストアでは、Google Playとともにアプリバージョンを忘れずに更新してください。
  • Androidアプリは、認識せずとも非公式のAPKサイトに存在している可能性があります(アプリのパッケージ名をウェブで検索して確認してください)。APKサイトは最新バージョンに更新するのに時間がかかるため、AppsFlyer SDKの実装がない古いバージョンをインストールするオーガニックユーザーを招く可能性があります。
  • アプリストアでのアプリ更新の公開は、完全に完了するまでに数日かかる場合があります。この段階でインストールするユーザーは、以前のバージョンを引き続き使用できます。

タスク2:既存ユーザーの移行

アプリのバージョンを送信した後、AppsFlyer SDKを使用すると、新しいユーザーがアトリビューションされ、AppsFlyerに正しく記録されます。

既存のアプリユーザーについては、以下を検討してください。

  1. 新しいオーガニックインストール: AppsFlyer SDKが実装されたアプリを初めて起動したとき、既存のユーザーは、元のソースに関係なく、AppsFlyerで新しいオーガニックユーザーとして分類されます。
  2. 二重請求: 新規ユーザーの初回起動時に、AppsFlyerはアプリが動作する広告ネットワークにクエリを実行します。FacebookやGoogle広告などのSRNは、指定のルックバック期間内に残っている場合、これらのユーザーを再びアトリビューション請求することがあります。

     例

    1. 6月15日に、新しいユーザーがFacebookの広告をクリックしてインストールします。
    2. 6月24日に、ユーザーが、AppsFlyer SDKが実装されているアプリに更新し、起動します。
    3. AppsFlyerでは、これは新しいユーザーであり、リアルタイムでアトリビューションする必要があります。
    4. AppsFlyerは、ユーザーの端末IDを使用してFacebookにクエリを実行します。
    5. ユーザーはまだFacebookの28日間のルックバック期間内にあるため、Facebookがユーザーをアトリビューションします。
    > これにより、同じユーザーのアプリ保持者に対して二重請求が発生します。

これらの問題を解決するために、AppsFlyerはデバイス移行プロセスを有効にします。

デバイス移行とは何ですか?

デバイス移行は、AppsFlyer SDKが実装された新しいアプリバージョンをリリースする前に 既存ユーザーの端末IDをAppsFlyerにアップロードするプロセスです。

移行されたデバイスがAppsFlyer SDKで初めて起動されたとき、AppsFlyerで新しいオーガニックインストールとして表示されません。さらに、AppsFlyerはSRNへデバイスのクエリを送信しないため、SRNは新しい非オーガニックインストールとしてアトリビューションを要求することはできません。これにより、上記で説明した2つの移行の問題が解決されます。

移行されたデバイスはどうなりますか?

移行されたデバイスは、AppsFlyerに次のように反映されます。

  • インストールデータ: 再インストールと同様に、移行されたデバイスにはインストールデータがありません。移行されたデバイスのインストールはAppsFlyerに表示されません。
  • アプリ内イベントとセッションデータ: 非アトリビューションデバイス移行としてオーガニックとして記録・表示されるか、または、アトリビューションデバイス移行を使用している場合はメディアソースとキャンペーンにアトリビューションされます。
  • リターゲティング: リアトリビューションとリエンゲージメントは通常どおり表示されます。
  • アクティビティデータ: オーガニックデータの一部として表示されます。
  • リテンションおよびコホートデータ: 移行されたデバイスにはインストール日がないため、どのコホートにも関連付けられていないため、リテンションおよびコホートレポートに表示できません。

どのデバイスを移行する必要がありますか?

すべてのユーザーを移行する必要がありますか、それともアプリを最近インストールしたユーザーのみを移行する必要がありますか?

以下を検討してください。

アプリをずっと前にインストールしたユーザーは、ほとんどが非アクティブユーザーです。これらのユーザーが広告を操作してインストールし、再びアクティブになった場合、これは重要なアトリビューションデータです。すべてのユーザーをデバイス移行をすると、このデータを取得できなくなります。

一方、アプリには、まだアクティブなベテランユーザーがいる場合があります。最近インストールしたユーザーのみを移行すると、このベテラン既存ユーザーが移行の直前に広告に接触した際、このユーザーを"獲得した" と請求される場合があります。

AppsFlyerは、直近のリアトリビューション期間中にアクティブなユーザーを移行することをお勧めします。たとえば、アプリに90日間のリアトリビューション期間が設定されている場合、過去90日間に少なくとも1つのセッション(起動)を行ったユーザーを移行する必要があります。

デバイス移行はどのように行われますか?

デバイス移行を実行するには、ユーザの端末IDと他追加データが含まれたCSVファイルを、あなたのAppsFlyerカスタマーサクセスマネジャーへ送信してください。CSVファイルには複数アプリのユーザー端末を含めることができ、各行はアプリごとに1つの端末IDを表します。

移行には、アトリビューションと非アトリビューションの2つの方法があります。

アトリビューションデバイス移行

この方法でAppsFlyerに移行されたデバイスは、指定されたアトリビューションに従って記録されます。アプリ内イベントとセッションデータも記録され、それに応じて表示されます。

CSVファイルの列:

列名 ファイルの列名 説明 必須? 例 / コメント
アプリID app_id

AppsFlyerダッシュボードに表示されるアプリID

はい
  • Android: com.great.app1 
  • iOS: id123456789

Platform

platform

iOSもしくはAndroidデバイス

はい "ios" または "android"(すべて小文字)

端末ID

device_id

Androidユーザーの場合は GAID, iOSユーザーの場合は IDFAを使用

GAIDは小文字でなければなりません。

IDFAは大文字でなければなりません。

はい
  • GAID:
    9c9a82fb-d5de-4cd1-90c3-527441c11828
  • IDFA:
    9876F1SS-2983-3855-27RR-2R626772VFNB
IDタイプ id_type

Androidユーザーの場合は advertiserId, iOSユーザーの場合は idfa を使用

現在、第三者ストア (out-of-store) で使用される他の識別子 (OAID, IMEI, Android ID) は、アトリビューションデバイス移行ではサポートされていません。
Google Play以外のAndroidユーザーには、非アトリビューションデバイス移行を使用してください。

はい
  • "advertiserId" または "idfa"
  • 値は大文字と小文字が区別されます。
インストール時間 install_time ISO 8601 UTC形式のオリジナルのアプリインストール時間:
yyyy-mm-ddTHH:MM:SS.SSS
提供がない場合、代わりにデバイス移行された時間が使用されます。
いいえ
  • 有効な過去の日付である必要があります。
  • 例:
    2018-01-22T08:45:33.412
  • インストール日がファイルの作成日より過去であり、かつアプリのリアトリビューション期間外のたデバイスは、アトリビューションとともに移行されず、最初の起動時に新しいインストールとして扱われます。
    例:5月1日に移行ファイルが作成され、リアトリビューション期間は30日です。インストール時間が4月1日より前のすべてのデバイスは、アトリビューションされません。最初の起動では、これらのデバイスは新規インストール(ほとんどの場合はオーガニック)として扱われます。
メディアソース media_source AppsFlyerダッシュボードに表示されるAppsFlyerパートナーID
はい
  • 正確なパートナーIDのリストを担当のCSMから取得してください。
    例:"Facebook Ads", "googleadwords_int"
  • オーガニックインストールの場合は "organic" を使用します
  • 値は大文字と小文字が区別されます。
連携済みパートナー integrated_partner
メディアソースが連携済みパートナーかどうかを示します例:オーガニックもしくはカスタムメディアソース はい  
  • "yes" または "no"
  • 値は大文字と小文字が区別されます。
キャンペーン名 campaign より粒度の高いアトリビューションの詳細については、元のキャンペーン名を入力してください。 いいえ String型
Campaign ID campaign_id   いいえ String型(スペース不可)

CSVファイルのルール:

  • ファイルには、すべての列ヘッダーを次のように含める必要があります:
    app_id,platform,device_id,id_type,install_time,media_source,integrated_partner,campaign,campaign_id
  • 各行には 9つのフィールドとカンマが含まれている必要がありますが、必須ではないフィールドは空のままでかまいません。
  • ファイルには最大2,000万行を含めることができます。
  • 複数のファイルを作成する場合は、ファイルごとに一意のファイル名を使用してください。
  • ファイルは、ZIPまたはGZIPを使用して圧縮できます。
  • CSVファイルはUTF-8でエンコードする必要があります。

非アトリビューションデバイス移行

この方法でAppsFlyerに移行されたデバイスは、オーガニックユーザーとして記録されます。
アプリ内イベントとセッションデータも記録され、オーガニックとして表示されます。

CSVファイルの列:

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

ID type列には正確な文字列を使用します:advertiserId, idfa, android_id, imei

device_migration_file_option_2.png

CSVファイルのルール:

  • ファイルには、次のようにすべての列ヘッダーを含まなければなりません: app_id,device_id
  • もしくは、app_id,device_id,id_type
  • アプリIDは小文字にする必要があります
  • すべてのAndroid識別子は小文字にする必要があります
  • IDFAは大文字にする必要があります
  • ファイルには最大2,500万行を含めることができます

タスク3:データの継続性を維持する

AppsFlyer SDKが実装されたアプリバージョンを送信すると、さまざまなメディアソースに配信されているアクティブな広告キャンペーンが引き続き存在する可能性があります。これにより、請求が重複したり、アトリビューションデータが失われたりする可能性があります。

このチャプターでは、これらの問題を回避するための、異なるメディアソースのベストプラクティスを説明します。

計測リンク使用の場合

計測リンクは、ユーザーのエンゲージメントを記録し、その後、エンゲージメントのアトリビューションに使用され、実際のインストールになります。したがって、他のアトリビューションSDKベンダーの計測リンクの接触を記録し、AppsFlyerへの切り替え後に最初の起動を行ったユーザーは、オーガニックユーザーとして分類されます。

ベストプラクティス: ユーザーの98%が、広告接触後の最初の7日以内にインストールします。AppsFlyerは、デバイス移行ファイルを作成する前に、計測リンクを使用している全ての広告キャンペーンを最短でも7日停止することを推奨します。

SRN(サーバー連携)媒体の場合

SRNは、特定のデバイスのエンゲージメントについて照会されると、MMP(モバイル測定パートナー)に応答します。2つのMMP、たとえばAppsFlyerと競合するアトリビューションベンダーが同じデバイスのインストールについて同じSRNにクエリを実行すると、2倍の料金が発生する可能性があります。

ベストプラクティス

  1. デバイス移行のファイル作成する前に、少なくとも1日、SRN媒体のキャンペーンを停止する
  2. AppsFlyerダッシュボードでSRN設定します。
  3. アプリを送信したら、SRNを使用してキャンペーンを再開します。

他媒体 / プラットフォームの場合

内部BIシステムやサードパーティの分析プラットフォームなど、他のプラットフォームは、SDK切り替えの際もデータの継続性を維持することができます。

ベストプラクティス

  1. アプリを送信する前に、たとえばPush APIを使用して、関連するパートナーまたはプラットフォームにデータを送信するように設定します。これにより、AppsFlyer SDKでアプリバージョンにアップグレードする新規ユーザーと既存ユーザーが処理されます。
  2. BIシステムで既存のユーザーを記録し続けるには、ユーザーがAppsFlyer SDKを使用するバージョンにアップグレードするまで、関連する構成を古いアトリビューション SDKベンダーに30日間保管します。

タスク4:AppsFlyer SDKを使用してアプリのバージョンを送信する

AppsFlyerをお楽しみください!

タスク5(オプション):レポートデータの取得

API, CSVダウンロードやData Lockerなどの方法を使用して、AppsFlyerからあなたの社内システムへレポートデータを取得することができます。

お使いの社内システムは、現在のSDKアトリビューションベンダーからアトリビューションデータを格納している可能性が高いため、AppsFlyerのレポート構造とフィールドへの適応が必要になります。

多くの時間と作業を節約するために、これをすでに実行しています。

レポートデータをAdjust, Branch, Tune, またはKochavaからAppsFlyerに適用させる方法については、担当のカスタマーサクセスマネジャーへお問い合わせください。

ケーススタディ

こちらから、月間アクティブユーザー数6,500万人を超えるインドの大手デジタルエンターテインメント企業であるHungamaが、AppsFlyerにシームレスに移行した方法をご覧ください。

この記事は役に立ちましたか?