［Beta機能］ユーザーベースのクロスプラットフォームアトリビューション

ユーザーベースアトリビューションとは？

ユーザーベースアトリビューションは、 顧客ID（Customer User ID）という永続的なユーザー識別子を用いて、複数プラットフォームにまたがるコンバージョンイベントを紐づけるモデルです。このモデルでは、CUIDを用いて、ユーザーの最初のコンバージョンまたはリエンゲージメントイベントを獲得したメディアソースへ、その後のすべてのアクティビティを紐づけます。
 

クロスプラットフォームのユーザージャーニー例

たとえば、ユーザーが Google の Web 広告をクリックし、デスクトップブラウザで登録と初回購入を行います。その後、同じユーザーが Instagram のモバイル広告をクリックし、モバイルアプリをインストールしてアプリ内購入を完了します。さらに 1 週間後、そのユーザーはその広告主の CTV アプリをインストールし、同じ CUID でサインインしてサブスクリプション登録を行います。

CUID がプラットフォームを横断してユーザーを識別するため、そして Google の Web キャンペーンがその CUID が紐づく最初の非オーガニックイベントであるため、モバイルアプリでの購入や CTV でのサブスクリプションなど、すべての後続のアクティビティは Google のWebキャンペーンに紐づけて計測されます。

ユーザーベース vs デバイスベースアトリビューション

このモデルは、デバイスベースアトリビューションにおける重要な課題を解決します。デバイスベースアトリビューションでは、各デバイスが別々のユーザーとして扱われるため、プラットフォームをまたいだユーザージャーニーが分断されてしまいます。一方、ユーザー中心のアトリビューションでは、永続的なCUIDを利用してデバイス横断でイベントを紐づけるため、一貫性のある計測、正確なキャンペーン評価、そしてプロダクトライン全体におけるLTV（ライフタイムバリュー）の正確な把握が可能になります。

以下の例は、デバイスベースとユーザーベースの違いを示しています。

ユーザーが Meta の Web 広告をクリックし、広告主のウェブサイトに遷移してサインアップし、アカウントを作成します。その後、同じユーザーが広告主の iOS アプリをインストールし、ログインして 50 ドルの購入を行います。数日後、そのユーザーは YouTube の広告を見て広告主の PC アプリをインストールし、再びログインして 100 ドルの購入を行います。

デバイスベースのアトリビューションでは、この一連の行動に対して Meta Ads の貢献は 0 ドルになりますが、ユーザーベースアトリビューションでは合計 150 ドルが Meta に紐づきます。以下の表は、このジャーニーが両モデルでどのように成果を紐づけられるかを示しています。

イベントがクロスプラットフォームアトリビューションの候補になる理由

クロスプラットフォームアトリビューションの対象となるイベントは、以下の条件をすべて満たしている必要があります：

• CUID が含まれていること：イベントには、デバイスやプラットフォームをまたいでユーザーを一意に識別するための永続的な Customer User ID（ログイン ID やハッシュ化メールなど、広告主が提供するCUID）が含まれている必要があります。 
  • イベントに CUID が含まれていない場合でも、同じappsflyer_id を共有していれば、CUID を含む最初のイベントが到着する最大 4 時間前まで遡って CUID を補完できます （詳細は後述の「CUID 補完処理期間」を参照してください）。
  • CUID がなく、補完もできないイベントもクロスプラットフォームアトリビューションには含まれますが、この場合は従来のデバイスレベルのアトリビューションによって処理されます。このような場合、アトリビューションはデバイスレベル（クラシック）のアトリビューション方法を使用して決定されます。
• 同じプロダクトラインに属していること：イベントを生成したアプリは、同じブランドの関連アプリ（iOS、Android、CTV など）をまとめたプロダクトラインに含まれている必要があります詳細は、クロスプラットフォーム計測のためのアプリのグループ化を参照してください。
• 休眠復元期間内であること：休眠復元期間とは、CUID を引き続き「アクティブ」と見なし、そのプロダクトライン内のアトリビューション対象とする期間（例：7〜390日）です。この期間内に CUID が確認されない場合、過去のアトリビューションマッピングは破棄されます。 
• イベントにデバイスレベルのアトリビューション情報が含まれていること：media source や campaign ID など、AppsFlyer の従来のデバイスベースアトリビューションモデルで取得されるパラメータがイベント情報に含まれている必要があります。

アトリビューションソースはどのように決定されるか

このモデルでは、特定のユーザー（CUID）に紐づくすべてのイベントが、そのユーザーの最初のコンバージョンを発生させたメディアソースに紐づけて計測されます。

元となるメディアソースは、以下のロジックで決まります：

• プロダクトライン内で CUID を含む各アプリ内イベントについて、AppsFlyer はその CUID に紐づく最も早い起動イベント（有効なメディアソースが付与されているイベント）を特定します。
• そのローンチイベントに対して従来のデバイスベースアトリビューションが割り当てたメディアソースが、その後のアプリ内イベントに対するアトリビューションソースとなります。
• このメディアソースは、その CUID とプロダクトラインに紐づくすべての後続イベントに対し、クロスプラットフォームにおけるユーザー獲得元 として使用されます。
• アプリ内イベントにCUIDが含まれていない場合、AppsFlyerは1〜4時間の補完処理期間内でCUID補完を試みます。 
• 補完期間外に CUID なしイベントが到着した場合も、クロスプラットフォームアトリビューションには含まれますが、デバイスレベルの従来のアトリビューションロジックで紐づけ先のメディアソースが決定されます。

CUID 補完処理期間

CUID 補完処理期間とは、AppsFlyer が新しく到着したアプリ内イベントに対して CUID を遡って補完する 1〜4 時間の処理期間のことです。この仕組みによって、一部のイベントに CUID が含まれていなくても、クロスプラットフォームアトリビューションが可能となります。

CUID補完の仕組み

• AppsFlyer は 1〜4 時間ごとに処理ジョブを実行します。
• イベントが CUID を含まない場合でも、CUID を含む別のイベントと同じ appsflyer_id を持っていれば、AppsFlyer は欠落した CUID を補完します。
• 補完が適用されるのは、処理期間内に到着したイベントのみです。

CUID補完の例

• 8:01：appsflyer_id = XYZ の初回起動イベントを記録。
• 9:00：appsflyer_id = XYZとcuid = 123 が含まれた サインアップ イベントを記録。
• 12:00：4時間の補完処理期間が終了し、AppsFlyer は最初の 初回起動 イベントに cuid = 123 を遡って補完。
• 12:30：appsflyer_id = XYZをもつ購入イベントは記録されますが、CUIDは含まれていません。 
• イベント到着時点で補完処理間が終了しているため、AppsFlyerは cuid = 123 をこのイベントへ紐づけません。

CUID補完の制限

• CUID が含まれないイベントが1〜4時間の処理期間外に到着した場合、それらは従来の AppsFlyer アトリビューションを使って処理され、クロスプラットフォームアトリビューションの結果に追加されます。
• CUID の補完は、処理期間を超えて遡及的に適用されることはありません。

クロスプラットフォームアトリビューションの設定

クロスプラットフォームアトリビューションを設定するには、AppsFlyer でいくつかの設定を行い、アプリ側のコードに特定の SDK 関数を実装する必要があります。 

• AppsFlyerの管理画面上では、アプリをプロダクトラインに割り当て、クロスプラットフォームアトリビューションを有効化し、休眠復元期間を設定してください。 詳細については「プロダクトラインの設定」を参照してください。
• アプリでは、AppsFlyer SDK を使って CUID を含むイベントを送信するよう設定してください。開発者向けの手順については「Customer User ID の設定」を参照してください。

クロスプラットフォームアトリビューション結果の表示

• レポート：クロスプラットフォームアトリビューションの結果は、Data Locker の「End-user events cross-platform report」で確認できます。

• マイダッシュボード：「クロスプラットフォーム」のテンプレートで確認可能です。ダッシュボードテンプレートの選択の詳細については、カスタムダッシュボードの作成を参照してください。