[Beta機能] AppsFlyer Webアトリビューション - 概要

概要:AppsFlyerのWebアトリビューション機能を利用すると、どのメディアソースやキャンペーンがユーザーをWebサイトへ誘導しているかを特定し、その訪問がその後のユーザー行動にどのような影響を与えているかを長期的に計測できます。初回訪問からLTV計測まで、ユーザーのインタラクションをエンドツーエンドで取得・アトリビューションできるため、ユーザー獲得(初回訪問者)とリエンゲージメントの両方に対応できます。

AppsFlyer Webアトリビューションについて

Webアトリビューションとは、どのメディアソースやキャンペーンがユーザーのWebサイト訪問を促し、その後の行動に影響を与えたかを特定するプロセスです。

Web訪問は、閲覧行動であると同時に、その訪問の直前に発生した広告エンゲージメントでもあります。モバイルアトリビューションではクリックとインストールを照合する必要がありますが、Web訪問では、遷移先URLやヘッダーにマーケティングソース情報が含まれるため、初回の照合を即時に行うことができます。

この記事では、AppsFlyerのWebアトリビューションのエンドツーエンドのプロセスを説明します。初回のWebサイト訪問からLTV計測まで、ユーザーのインタラクションがどのように取得、識別、計測されるかを解説します。このプロセスにより、初回訪問者を特定・アトリビューションするユーザー獲得と、再訪問ユーザーを対象としたキャンペーン効果を計測するリターゲティングまたはリエンゲージメントの両方に対応できます。

People-Based Attribution(PBA)をご利用の場合

現在 People-Based Attribution(PBA)をご利用の場合は、より詳細なアトリビューションと追加シグナルを活用できる AppsFlyer Web アトリビューションへの切り替えをご検討ください。

AppsFlyer Webアトリビューションのフロー

AppsFlyer Webアトリビューション のフローは、Webサイトへの生の訪問データを、実用的なマーケティングインサイトへ変換する一連のステップで構成されています。

  1. データ収集:Web SDK(Pixel)または Server-to-Server(S2S)API のいずれかを通じて、ユーザーのインタラクションデータを取得します。
  2. サイト訪問の記録トラフィックソースがまだ不明な場合でも、ユーザーのWebサイト到達を取得し、訪問イベントとして記録します。
  3. メディアソースの特定定義された優先順位に従ってURLパラメータを解析し、メディアソースを特定します。
  4. 30分間のID判定遅延:ユーザーログインによるID判別を可能にするため、アトリビューション判定を30分間遅らせます。
  5. ユーザー識別とデータ統合::現在のセッションを Customer User ID(CUID)やブラウザCookieと紐づけ、同一ユーザーとして継続的に計測できるようにします。
  6. ユーザー獲得イベント:UAルックバック期間内に発生した、獲得を定義するイベント(例:first_visit またはカスタム獲得イベント)を記録します。
  7. プレ獲得期間:初回訪問からUAイベントまでの間に発生した中間イベントをアトリビューションします。
  8. リエンゲージメントと再獲得:休眠期間の設定に基づいて再訪問ユーザーをアトリビューションし、その再訪問がリエンゲージメントか再獲得かを判定します。
  9. LTV計測:継続的なイベントや収益をアトリビューションし、アトリビューション期間の設定に基づいてユーザーのLTVを計測します。

AppsFlyer Web アトリビューションのプロセス - ステップ別解説

以降のセクションでは、各ステップについて詳しく説明します。

1. データ収集

ユーザーがランディングページに到達すると、AppsFlyer は連携済みのリスナーを通じて、そのユーザー行動を取得する必要があります。

  • Web SDK(ピクセル)Webサイトに直接実装する、または Google Tag Manager(GTM)経由で設定するクライアント側のスニペットです。
  • サーバー間(S2S)API:サーバー側で連携する、より堅牢な実装方法です。ブラウザによる計測制限や広告ブロッカーの影響を受けにくくできるほか、AppsFlyer にデータを送信する前に、必要な情報を追加できます。S2S連携は、顧客側のサーバーから直接行うことも、Google Tag Manager Server Side 経由で行うこともできます。

2. サイト訪問の計測

セッションデータが収集されると、システムは初回訪問レコードを作成するかどうかを判定します。このレコードは、実際にメディアソースを判定してアトリビューションを行う前に、ユーザーの生の行動データを取得するための前処理レイヤーとして機能します。すべてのセッションがサイト訪問として記録されるわけではありません。

AppsFlyer は、新しいセッションとしてユーザーがサイトにアクセスした場合、または判別可能な流入元パラメータが含まれている場合に、訪問を記録します。一方で、除外対象ドメインからの訪問は記録しません。こうした訪問記録のルールにより、セッションの重複カウントを防ぎます。

詳細は、「サイト訪問の記録」をご覧ください。

3. メディアソースの判定

データが収集され、サイト訪問が記録されると、AppsFlyer のエンジンは定義された優先順位に沿ってその情報を評価します。このウォーターフォール方式では、AppsFlyer固有のパラメータと市場で一般的に使われている標準パラメータの両方に対応しているため、移行時に既存のアトリビューションリンクを変更する必要はありません。ウォーターフォール内で最初に一致したシグナルが、訪問元の判定に使用されます。

  • PID:まず、AppsFlyer独自のパラメータがあるかを確認します。
  • UTMパラメーター:PID が存在しない場合は、utm_source などの標準タグを確認します。
  • クリックID:次に、Google Click ID(gclid)や TikTok Click ID(ttclid)など、媒体固有のIDを確認します。
  • リファラー:最後のフォールバックとして、ユーザーがサイトに到達する直前に閲覧していたURLを特定します。

詳細については、「メディアソースの判定」をご覧ください

4. 30分間のID判定遅延

多くのユーザーはサイト訪問から30分以内にログインするため、AppsFlyer はアトリビューション判定を意図的に30分間遅らせます。この遅延により、CUID(Customer User ID)を取得し、Cookieの有効期限が切れている既存ユーザーでも元の流入元と正しく紐づけられるため、「オーガニック」と誤判定されることを防ぎます。

5. ユーザー識別とデータ統合

流入元が特定され、30分間の遅延が完了すると、システムは分断されたユーザーセッションを1つのユーザージャーニーとして統合します。

  • CUIDによる統合:Customer User ID(例:ハッシュ化されたメールアドレス)が取得できた場合、エンジンはそのセッションを、ユーザーのクロスデバイス履歴と紐づけます。
  • Cookieによるフォールバック:CUID が利用できない場合は、ブラウザCookieを利用して識別を行います。ただし、Cookie はデバイス依存であり、安定性はCUIDより低くなります。

6. ユーザー獲得イベント

ユーザー識別が完了すると、エンジンはそのユーザーを「獲得済み」と判定するための特定アクションを確認します。業界標準では first_visit が使用されますが、これは必ずしも質の高いシグナルとは限りません。例えば、ユーザーが誤って広告をクリックしたり、すぐ離脱したりするケースもあります。登録完了や購入完了などのカスタム獲得イベントを設定することで、LTV(顧客生涯価値)を、単なる興味本位のクリックではなく、実際に価値ある行動を生み出したマーケティングソースへ正しく紐づけることができます。

ユーザー獲得イベントが発生すると、アトリビューションエンジンは、ルックバック期間(ユーザー獲得)の期間分だけ遡り、アトリビューション対象となる非オーガニック訪問を探します。この設定は、ユーザー訪問からUAイベント完了まで許容される最大期間を定義します(デフォルト設定:30日)このルックバック期間内に非オーガニックタッチポイントが見つからない場合、そのUAイベントはオーガニックとして扱われ、アトリビューションされません。カスタムイベントのルックバック期間は、Webアプリを AppsFlyer に追加する際に設定できます。詳細は「ルックバック期間(ユーザー獲得)」をご覧ください。

ビジネスモデルによって、ユーザー獲得トリガーとして定義するイベントは異なります。例えば:

  • 登録完了イベント(例:銀行アプリ):サインアップフローが正常完了した時点で、獲得イベントが発火します。
  • 初回注文イベント(例:フードデリバリーアプリ):商品閲覧やカート追加は対象とならず、購入完了時のみイベントが発火します。
  • サブスクリプション開始イベント(例:動画配信サービスやSaaSアプリ):トライアル開始やアプリインストールではなく、サブスクリプション契約確定時に獲得イベントとして記録されます。

ユーザー獲得イベント設定の詳細は、「ユーザー獲得設定」をご覧ください。

7. プレ獲得期間

ユーザー識別が完了してから正式な獲得イベントが発生するまでの間には、「プレ獲得期間(Pre-acquisition period)」と呼ばれる期間が存在する場合があります。これは、デフォルトの first_visit ではなく、カスタムユーザー獲得(UA)イベントを設定している場合にのみ関連します。この期間中、ユーザーは正式な獲得イベント(例:登録完了や初回購入)に至る前に、カート追加、商品閲覧、コンテンツ閲覧など、重要な行動を行うことがあります。

AppsFlyer は、これらのプレ獲得イベントを取得し、該当するマーケティングソースへアトリビューションしたうえで、レポート上では プレ獲得 として区別して表示します。プレ獲得アトリビューションと獲得後アトリビューションの主な違いは、アトリビューション期間にあります。プレ獲得期間では、これらのイベントが正式なUAイベント発生前に起きているため、アトリビューション期間は短く設定され、UAイベントのルックバック期間と同じになります。一方で、カスタムUAイベントが発生してユーザーが正式に獲得されると、アトリビューション期間はLTV計測向けに拡張され、そのユーザーを獲得したマーケティングソースへ長期的な成果が紐づけられます。

8. リエンゲージメントと再獲得

ユーザー獲得後、ユーザーが後日サイトへ再訪することがあります。既存ユーザーが広告をクリックしてサイトを再訪問した場合、リエンゲージメント(再訪問)アトリビューションが発生します。

リエンゲージメントは既存ユーザーを対象としますが、長期間非アクティブだったユーザーの再訪は「再獲得」として扱われる場合があります。再獲得の対象となるには、まず 休眠期間(デフォルト:90日)を超えている必要があります。この設定は、ユーザーを「離脱済み」と見なすために必要な非アクティブな期間を定義します。この期間経過後にユーザーが再訪すると、Webアトリビューションのエンジンは通常の再訪問ではなく、新たなユーザー獲得イベントとして記録します。

詳細は、「リエンゲージメント設定」および「再獲得設定」をご覧ください。

9. LTV計測

ユーザーが最初の獲得キャンペーンによって流入した場合でも、その後のリターゲティング施策によって再訪した場合でも、最終的な目的は、そのユーザーが長期的にもたらす価値を計測することです。ユーザーが特定の流入元へ正常にアトリビューションされると、システムは継続的なユーザー行動を計測し、LTV(顧客生涯価値)を算出します。

この計測はアトリビューション期間の設定に基づいて行われ、デフォルトでは「Forever(半永久)」に設定されています。これにより、リピート購入やサブスクリプション更新など、その後のすべての行動が、最初にユーザーをサイトへ誘導したマーケティングソースへ継続的に紐づけられます。この長期的なデータを取得することで、単純なコンバージョン数だけではなく、キャンペーンごとの真のROAS(広告費用対効果)を把握できるようになります。

アトリビューション期間の設定の詳細は、「アトリビューション期間」をご覧ください。