Attribution Reporting API: 統合ガイド

デベロッパー プレビュー ベータ版

Android 版プライバシー サンドボックスのドキュメントをご覧になる際は、[デベロッパー プレビュー] または [ベータ版] ボタンで対象のプログラム バージョンを選択してください（手順が異なる場合があります）。

---

Attribution Reporting API は、クロスパーティ ユーザー ID に依存せずに、アプリとウェブを対象としたアトリビューションとコンバージョン測定の主要なユースケースをサポートするように設計されています。現在の一般的な設計と比較した場合、Attribution Reporting API の実装者は、前提となるいくつかの重要な考慮事項に留意する必要があります。

• イベントレベル レポートには、忠実度の低いコンバージョン データが含まれます。少数のコンバージョン値が適しています。
• 集計可能レポートには、忠実度の高いコンバージョン データが含まれます。ソリューションでは、ビジネス要件に基づいて、また上限である 128 ビット以内で集計キーを設計する必要があります。
• ソリューションのデータモデルと処理では、使用可能なトリガーのレート制限、トリガー イベントの送信の時間的遅延、API によって適用されるノイズを考慮する必要があります。

このガイドでは、統合の計画に役立つように全体像を提示します。これには、Android 版プライバシー サンドボックス デベロッパー プレビューの、現段階では実装されていない機能が含まれていることがあります。その場合は、タイムラインのガイダンスが提供されます。

このページでは、「ソース」とはクリックまたはビューのこと、「トリガー」とはコンバージョンのことです。

下図は、アトリビューションの統合のさまざまなワークフロー オプションを示しています。同じ列（緑色で囲んだ部分）に記載されているセクションは、並行して作業できます。たとえば、パートナー エンゲージメントはアプリ間イベントレベル アトリビューションと同時に行うことができます。

図 1. アトリビューションの統合のワークフロー

前提条件と準備

Attribution Reporting API に対する理解を深めるために、このセクションの手順を完了してください。これは、広告テクノロジー エコシステムで API を使用する際に有意義な結果を収集するための下準備となります。

API に慣れる

1. 設計案を読み、Attribution Reporting API とその機能に精通します。
2. デベロッパー ガイドを読み、ユースケースに必要なコードや API の呼び出しを組み込む方法を確認します。
3. 登録して Attribution Reporting API に関する最新情報を受け取ります。これにより、今後のリリースで追加される新機能を常に把握しておくことができます。

サンプルアプリのセットアップとテスト

1. 統合を開始する準備ができたら、Android Studio の最新のデベロッパー プレビューをセットアップします。
2. イベント登録とレポート配信用のモックサーバー エンドポイントをセットアップします。Google では、オンラインで入手可能なツールと組み合わせて使用できるモックを用意しています。
3. サンプルアプリでコードをダウンロードして実行し、ソースとトリガーの登録に慣れてください。
1. レポートの送信期間を設定します。API では、2 日間、7 日間、または 2～30 日間のカスタム期間がサポートされています。
2. サンプルアプリを実行して使用することでソースとトリガーを登録し、設定した期間が経過したら、イベントレベル レポートと暗号化された集計可能レポートを受け取ったことを確認します。レポートをデバッグする必要がある場合は、レポートジョブを強制的に実行することで、レポートをより迅速に生成できます。
3. アプリ間アトリビューションの結果を確認します。ラストタッチとインストール後の両方のケースで、この結果のデータが想定どおりであることを確認します。
4. クライアント API とサーバーの連携について確認したら、試しにサンプルアプリを使用して、独自の統合の指針にします。独自の本番環境サーバーをセットアップして、イベント登録呼び出しをアプリに追加します。

統合前

Android 版プライバシー サンドボックスに組織を登録します。この登録は、広告テクノロジー プラットフォームが不必要に重複するのを防ぐためのものです。そのような重複があると、ユーザーのアクティビティに関する必要以上に多くの情報にアクセスできるようになってしまいます。

パートナー エンゲージメント

多くの場合、広告テクノロジー パートナー（MMP / SSP / DSP）が、統合アトリビューション ソリューションを作成します。このセクションで説明する手順を実施することで、広告テクノロジー パートナーと適切に連携するための準備ができます。

1. Attribution Reporting API のテストと導入について協議するため、主な測定パートナーと話し合いの場を設ける。測定パートナーには、広告テクノロジー ネットワーク、SSP、DSP、広告主など、現在連携しているパートナーや連携を希望するパートナーが該当する。
2. 測定パートナーと協力し、初期テストから導入までの統合のタイムラインを定義する。
3. アトリビューション設計でカバーする領域を測定パートナーとの間で明確にする。
4. タイムラインとエンドツーエンドのテストにおいて歩調を合わせられるよう、測定パートナーどうしのコミュニケーション チャネルを確立する。
5. 測定パートナー間の大まかなデータフローを設計する。主な考慮事項は次のとおりです。
   • 測定パートナーは Attribution Reporting API にアトリビューション ソースをどのように登録するか。
   • 広告テクノロジー ネットワークは、Attribution Reporting API にトリガーをどのように登録するか。
   • 各広告テクノロジーはソースとトリガーの登録を完了する際、どのように API リクエストを検証し、レスポンスを返すか。
   • Attribution Reporting API 外のパートナーと共有する必要があるレポートはあるか。
   • パートナー全体で必要な統合ポイントや調整は他にあるか。たとえば、自社とパートナーは、コンバージョンの重複除去に対処する必要や、集計キーをそろえる必要があるか。
6. アプリからウェブのアトリビューションが適用可能な場合は、ウェブの測定パートナーとの話し合いの場を設け、Attribution Reporting API の設計、テスト、導入について協議する。ウェブ パートナーとの対話に際しても、上に挙げた質問が参考になります。

アプリ間イベントレベル アトリビューションのプロトタイピング

このセクションでは、アプリまたは SDK のイベントレベル レポートで基本的なアプリ間アトリビューションをセットアップします。集計サーバー アトリビューションのプロトタイピングを開始する前に、このセクションを完了する必要があります。

1. イベント レコードの収集サーバーをセットアップします。そのためには、所定の仕様でモックサーバーを生成するか、サンプル サーバーコードを使用して独自のサーバーをセットアップします。
2. 広告が表示されたら、SDK またはアプリにソースイベント登録の呼び出しを追加します。
   • 重要な考慮事項としては、次のようなものがあります。
     • ソースイベント ID が使用可能で、ソース登録 API 呼び出しに正しく渡されることを確認する。
     • InputEvent を渡してクリックソースを登録することもできることを確認する。
     • さまざまなタイプのイベントでどのようにソースの優先度を構成するかを決定する。たとえば、表示数に対するクリック数など、価値が高いとみなされるイベントには高い優先度を割り当てます。
     • テストでは、有効期限はデフォルト値で構わない。ただし、異なる有効期限を構成することもできます。
     • テストでは、フィルタとアトリビューション期間はデフォルトのままで構わない。
   • オプションの考慮事項は次のとおりです。
     • 準備ができている場合は、集計キーを設計する。
     • 他の測定パートナーとの連携方法を確立する際は、リダイレクト戦略を検討する。
3. コンバージョン イベントを記録するために、トリガー イベント登録を SDK またはアプリに追加します。
   • 重要な考慮事項としては、次のようなものがあります。
     • 返される忠実度が限定的であることを考慮したトリガーデータの定義: 広告主が必要とするコンバージョン タイプの数をどのように削減し、クリックについて 3 ビット、ビューについて 1 ビットという制限内に収めるか。
     • イベント レポートで使用可能なトリガーに関する制限: イベント レポートで受け取ることができるソースあたりの合計コンバージョン数をどのように減らすか。
   • オプションの考慮事項は次のとおりです。
     • 精度テストを行うまで重複排除キーの作成をスキップする。
     • シミュレーション テストのサポートの準備が整うまで、集計キーと値の作成をスキップする。
     • 他の測定パートナーとの連携方法を確立するまで、リダイレクトをスキップする。
     • テストでは、トリガーの優先度は重視されない。
     • 初期テストでは、フィルタは無視できることが多い。
4. 広告のソースイベントが生成されていることと、トリガーによってイベント レポートの作成が発生することをテストします。

シミュレーション テスト

このセクションでは、現在のコンバージョンをイベント レポートと集計可能レポートに移動すると、レポート システムと最適化システムにどのような影響があるかをテストする手順について説明します。これにより、統合が完了する前に影響のテストを開始できます。

テストは、過去のコンバージョン レコードに基づいてイベント レポートと集計可能レポートの生成をシミュレートし、シミュレートされた集計サーバーから集計結果を取得することで行われます。これらの結果を過去のコンバージョン数と比較することで、レポートの精度がどのように変化するかを確認できます。

推定コンバージョン率の計算などの最適化モデルをこれらのレポートでトレーニングし、そのモデルの精度を現在のデータを基に構築されたモデルと比較できます。これは、異なる集計キーの構造とその結果への影響をテストする機会ともなります。

1. ローカルマシンに Measurement Simulation ライブラリを設定します。
2. シミュレートされたレポート生成ツールに対応するよう、どのようにコンバージョン データをフォーマットする必要があるかについて、仕様を確認します。
3. ビジネス要件に基づいて集計キーを設計します。
   • 重要な考慮事項としては、次のようなものがあります。
     • クライアントやパートナーが集計する必要がある重要なディメンションを考慮し、それらに評価を集中させる。
     • 要件に必要な集計ディメンションとカーディナリティの最小数を判断する。
     • ソース側とトリガー側のキー部分が 128 ビットを超えないようにする。
     • ソリューションがトリガー イベントごとに複数の値に寄与する場合は、予算に対する割合の最大値 L1 に対して値をスケーリングする。これにより、ノイズの影響を最小限に抑えることができます。
     • こちらの例で、キャンペーン レベルで集計コンバージョン数を収集するキーと、地域レベルで集計購入額を収集するキーの設定方法を説明しています。
4. レポート生成ツールを実行して、イベント レポートと集計可能レポートを作成します。
5. シミュレートされた集計サーバーを使用して集計可能レポートを実行し、概要レポートを取得します。
6. ユーティリティ テストを実行します。
   • イベントレベル レポートと概要レポートのコンバージョンの合計を、過去のコンバージョン データと比較し、コンバージョン レポートの精度を判断します。最良の結果を得られるように、ボリュームがある、広告主の基盤の代表的な部分でレポートのテストと比較を実行します。
   • イベントレベル レポートのデータと、場合によっては概要レポートのデータに基づいて、モデルを再トレーニングします。過去のトレーニング データで構築されたモデルと精度を比較します。
   • さまざまなバッチ戦略を試し、それらが結果にどのように影響するかを確認してください。
     • 重要な考慮事項としては、次のようなものがあります。
     • 入札単価を調整するための概要レポートの適時性。
     • デバイス上の関連付け可能なイベントの平均頻度。たとえば、購入イベントの過去データに基づく休眠ユーザーの復帰。
     • ノイズレベル。バッチ数が多いほど集計は小さくなり、集計が小さいほど適用されるノイズが多くなります。

集計サーバー アトリビューションのプロトタイピング: セットアップ

この手順により、ソースイベントとトリガー イベントに関する集計可能レポートを確実に受け取れるようになります。

1. 集計サーバーをセットアップします。
   • AWS アカウントをセットアップします。
   • コーディネーターとともに集計サービスに登録します。
   • 提供されたバイナリから AWS で集計サーバーをセットアップします。
2. ビジネス要件に基づいて集計キーを設計します。アプリ間イベントレベルのセクションでこのタスクをすでに完了している場合は、この手順をスキップできます。
3. 集計可能レポートの収集サーバーをセットアップします。アプリ間イベントレベルのセクションで作成した場合は、再利用できます。

集計サーバー アトリビューションのプロトタイピング: 統合

ここから先に進む前に、必ず集計サーバー アトリビューションのプロトタイピング: セットアップのセクション、またはアプリ間イベントレベル アトリビューションのプロトタイピングのセクションをご覧ください**。

1. 集計キーのデータをソースイベントとトリガー イベントに追加します。そのために、キャンペーン ID など、広告イベントに関するデータを SDK またはアプリに渡して、集計キーに含める必要がある場合があります。
2. 集計キーのデータで登録したソースイベントとトリガー イベントからアプリ間の集計可能レポートを収集します。
3. これらの集計可能レポートを集計サーバーで実行する際、さまざまなバッチ戦略をテストして、結果にどのように影響するかを確認します。

オプション機能を使用して設計を繰り返す

以下は、測定ソリューションに含めることができる追加機能です。

Debug API を使用してデバッグキーを生成する（強く推奨）

注: この機能は公開ベータ版で利用可能になる予定です。

1. デバッグキーを設定すると、ソースイベントまたはトリガー イベントの未変更レポートを、Attribution Reporting API によって生成されたレポートと一緒に受け取れます。デバッグキーを使用すると、統合中にレポートを比較してバグを見つけることができます。

アトリビューションの動作をカスタマイズする

1. インストール後のトリガーのアトリビューション
   • この機能は、インストール後のトリガーを、インストールを促したアトリビューション ソースに関連付ける必要がある場合に使用できます。これは、それより新しい有効なアトリビューション ソースが他にある場合でも正しく動作します。
   • たとえば、ユーザーがインストールを促す広告をクリックし、インストール後、別の広告をクリックして購入を行ったとします。この場合、広告テクノロジー企業は購入をリエンゲージメント クリックではなくファースト クリックに関連付けたいと考える場合があります。
2. フィルタを使ってイベントレベル レポートのデータを微調整する
   • コンバージョン フィルタを設定すると、選択したトリガーを無視して、それをイベント レポートから除外できます。アトリビューション ソースあたりのトリガーの数には制限があります。フィルタを使用することで、特に有用な情報を提供するトリガーのみをイベント レポートに含めることができます。
   • フィルタを使用して一部のトリガーを選択的に除外し、それらを事実上無視することもできます。たとえば、アプリ インストールの促進を目的としたキャンペーンがある場合、インストール後のトリガーをフィルタリングしてそのキャンペーンのソースに関連付けないようにできます。
   • フィルタは、ソースデータに基づいてトリガーデータをカスタマイズするためにも使用できます。たとえば、ソースに "product" : ["1234"] を指定した場合、「product」はフィルタキー、「1234」は値です。フィルタキーが「product」で値が「1234」以外のトリガーは無視されます。
3. カスタマイズしたソースとトリガーの優先度
   • 1 つのトリガーに複数のアトリビューション ソースを関連付けることができる場合や、複数のトリガーを 1 つのソースに関連付けることができる場合、64 ビット符号付き整数を使用して、特定のソース / トリガー アトリビューションを他よりも優先できます。

MMP などとの連携

1. ソースイベントとトリガー イベントで他のサードパーティにリダイレクトする
   • 複数の広告テクノロジー プラットフォームがリクエストを登録できるようにリダイレクト URL を設定できます。これはアトリビューションでクロスネットワークの重複除去を有効にするために使用できます。
2. 重複除去キー
   • 広告主が複数の広告テクノロジー プラットフォームを使用して同じトリガー イベントを登録する場合は、重複除去キーを使用して重複レポートのあいまいさを排除できます。重複除去キーが指定されていない場合、重複するトリガーが一意なものとして各広告テクノロジー プラットフォームにレポートされる可能性があります。

クロス プラットフォーム測定の活用

1. アプリとウェブにわたるアトリビューション（第 4 四半期の後半に利用可能）
   • ユーザーがアプリ内で広告を表示した後、モバイルまたはアプリのブラウザでコンバージョンを達成する場合（またはその逆の場合）のユースケースがサポートされます。