現在、モバイル アトリビューションと測定ソリューションでは、広告 ID などのクロスパーティ ID を使用することが一般的です。Attribution Reporting API は、クロスパーティ ユーザー ID への依存をなくすことでユーザーのプライバシーを向上させ、アプリとウェブを対象としたアトリビューションとコンバージョン測定の主要なユースケースをサポートするように設計されています。
この API には、プライバシーを向上させるためのフレームワークを提供する、次のような構造メカニズムが用意されています。詳細については、このドキュメント内で別途説明します。
- イベントレベル レポートで使用できるビット数を制限する
- 集計可能レポートでのみ、忠実度の高いコンバージョン データを有効にする
- 利用可能なトリガー（コンバージョン）のレート制限と 1 つのアトリビューション ソースに関連付けることのできる広告テクノロジー プラットフォームの数を導入する
- さまざまなノイズ付加手法を組み込む
こうしたメカニズムにより、2 つの異なるアプリ間またはドメイン間でユーザー ID をリンクする機能が制限されます。
Attribution Reporting API では、次のユースケースがサポートされます。
- コンバージョン レポート: キャンペーン別、広告グループ別、広告クリエイティブ別など、さまざまなディメンションでコンバージョン（トリガー）数やコンバージョン（トリガー）値を表示して、広告主がキャンペーンのパフォーマンスを測定できるようにします。
- 最適化: ML モデルのトレーニングに使用できるインプレッションごとのアトリビューション データを提供することで、広告費の最適化をサポートするイベントレベルのレポートを提供します。
- 無効なアクティビティの検出: 無効なトラフィックと広告の不正行為の検出と分析に使用できるレポートを提供します。
Attribution Reporting API の動作の概要は次のとおりです。詳細についてはこのドキュメント内で別途説明します。
- 広告テクノロジー プラットフォームが、Attribution Reporting API を使用するための登録プロセスを完了する。
- 広告テクノロジー プラットフォームが、Attribution Reporting API にアトリビューション ソースを登録する（広告クリックまたは広告ビュー）。
- 広告テクノロジー プラットフォームが、Attribution Reporting API にトリガーを登録する（広告主のアプリまたはウェブサイトのユーザー コンバージョン）。
- Attribution Reporting API が、トリガーをアトリビューション ソース（コンバージョン アトリビューション）と照合し、1 つ以上のトリガーがイベントレベル レポートと集計可能レポートを通じてデバイスから広告テクノロジー プラットフォームに送信される。
広告テクノロジー プラットフォームを登録する
Attribution Reporting API にアクセスするために、また、プライバシー メカニズムを意図したとおりに機能させるために、広告テクノロジー プラットフォーム（Google のものを含む）はすべて、簡単な登録プロセスを完了する必要があります。このプロセスの詳細は開発中です。フィードバックをお待ちしております。
登録プロセスを用意することで、ユーザーのサイトとアプリのアクティビティに関する詳細情報を得るために、広告テクノロジー プラットフォームが不必要に重複しないで済むようになります。たとえば、Attribution Reporting API により、特定のアトリビューション ソースとトリガーについて、広告テクノロジー プラットフォームが表示できるトラッキングと情報の量を制限します。制限の詳細については、このドキュメントで後述するアトリビューション レポートで測定データを表示するをご覧ください。
企業は、正当なビジネス上の必要性（複数の独立したプロダクト ラインの運営など）があれば複数回登録することが可能です。プライバシーの制限を回避するために複数の登録データを組み合わせることはありません。
登録の際、広告テクノロジー プラットフォームから次のような情報が提供されます。
- 連絡先とビジネス情報
- アトリビューション ソースの登録、トリガー アトリビューション、イベントレベル レポートと集計可能レポートの受信に使用する、ポストバック URL
- Attribution Reporting API のユースケース
アトリビューション ソース（クリックまたはビュー）を登録する
Attribution Reporting API では、広告クリックと広告ビューを「アトリビューション ソース」と呼称します。広告クリックまたは広告ビューを登録するには、registerAttributionSource() を呼び出します。この API には次のパラメータが必要です。
- アトリビューション ソース URI: プラットフォームでは、アトリビューション ソースに関連付けられたメタデータを取得するために、この URI に対してリクエストを実行します。
- 入力イベント:
InputEventオブジェクト（クリック イベントの場合）またはnull（ビューイベントの場合）のいずれか。
API がアトリビューション ソース URI にリクエストを行うと、広告テクノロジー プラットフォームは、次のフィールドを持つ新しい HTTP ヘッダー Attribution-Reporting-Register-Source でアトリビューション ソースのメタデータを返します。
- ソースイベント ID: 64 ビット符号なし整数をエンコードする DOMString。この値は、このアトリビューション ソース（広告クリックまたは広告ビュー）に関連付けられているイベントレベル データを表します。
- デスティネーション: トリガー イベントが発生する eTLD+1 またはアプリ パッケージ名の元。
- 期限（省略可）: デバイスからソースを削除する必要がある期限（秒単位）。デフォルトは 30 日であり、最小値は 2 日、最大値は 30 日です。最も近い日の概数となります。
ソース優先度（省略可）: 64 ビット符号付き整数。複数のアトリビューション ソースが特定のトリガーに関連付けられる場合に、そのトリガーをどのアトリビューション ソースに関連付ける必要があるかを選択するために使用されます。
トリガーを受信すると、API は最も高いソース優先度値に一致するアトリビューション ソースを見つけて、レポートを生成します。各広告テクノロジー プラットフォームが、独自の優先度設定戦略を定義できます。
値が大きいほど優先度が高くなります。
インストールとインストール後のアトリビューション期間（省略可）: このドキュメントで後述するインストール後のイベントのアトリビューションを決定するために使用します。
アトリビューション ソースのメタデータ レスポンスでは、次の個別ヘッダーに追加データが含まれる場合があります。
- 集計キー（省略可）: 集計可能レポートに使用するセグメンテーションを指定します。
- アトリビューション レポート リダイレクト（省略可）: 複数の広告テクノロジー プラットフォームがリクエストを登録できるようにするためのリダイレクト URL。
次のスニペットは、アトリビューション ソースデータの現在の設計を示しています。
Attribution-Reporting-Register-Source: {
"source_event_id": "[64 bit unsigned integer]",
"destination": "[eTLD+1 or app package name]",
"expiry": "[64 bit signed integer]",
"source_priority": "[64 bit signed integer]"
}
Attribution-Reporting-Register-Aggregate-Source: <aggregation-key-data>
Attribution-Reporting-Redirects: "https://adtechpartner.example"
ワークフローの例は次のとおりです。
広告テクノロジー SDK が API を呼び出してアトリビューション ソースの登録を開始します。
registerAttributionSource( Uri.parse("https://adtech.example/attribution_source?my_ad_click_id=123"), myClickEvent);API が次のヘッダーを使用して、
https://adtech.example/attribution_source?my_ad_click_id=123にリクエストを行います。Attribution-Reporting-Source-Info: navigationこの広告テクノロジー プラットフォームの HTTPS サーバーが、ヘッダーに次の内容を含めて応答します。
Attribution-Reporting-Register-Source: { "destination": "android-app://com.advertiser.example", "source_event_id": "234", "expiry": "60000", "source_priority": "5" } Attribution-Reporting-Redirects: https://adtechpartner.example?their_ad_click_id=567 Attribution-Reporting-Source-Info: navigationAPI が、
Attribution-Reporting-Redirectsで指定された各 URL にリクエストを行います。この例では URL が 1 つしか指定されていないため、API はhttps://adtechpartner.example?their_ad_click_id=567にリクエストを行います。この広告テクノロジー プラットフォームの HTTPS サーバーが、ヘッダーに次の内容を含めて応答します。
Attribution-Reporting-Register-Source: { "destination": "android-app://com.advertiser.example", "source_event_id": "789", "expiry": "120000", "source_priority": "2" }
ここまでのステップで示したリクエストに基づいて、2 つのナビゲーション（クリック）アトリビューション ソースが登録されます。
トリガー（コンバージョン）を登録する
広告テクノロジー プラットフォームは triggerAttribution() メソッドを使用してトリガー（インストールまたはインストール後のイベントなどのコンバージョン）を登録できます。
triggerAttribution() メソッドにはトリガー URI パラメータが必要です。API は、トリガーに関連付けられたメタデータを取得するために、この URI に対してリクエストを実行します。
API はリダイレクトに従います。広告テクノロジー サーバーのレスポンスには、1 つ以上の登録済みトリガーの情報を表す、Attribution-Reporting-Register-Event-Trigger という HTTP ヘッダーが含まれている必要があります。ヘッダーの内容は JSON でエンコードされ、次のフィールドを含む必要があります。
- トリガーデータ: トリガー イベントを特定するためのデータ（クリックは 3 ビット、ビューは 1 ビット）
- トリガー優先度（省略可）: 同じアトリビューション ソースの他のトリガーと比較した、このトリガーの優先度を表す 64 ビット符号付き整数
- 重複除去キー（省略可）: 同じアトリビューション ソースについて、同じ広告テクノロジー プラットフォームによって同じトリガーが複数回登録されているケースを特定するために使用される 64 ビット符号付き整数
広告テクノロジー サーバーのレスポンスでは、次のヘッダーに追加データが含まれる場合があります。
- 集計キー（省略可）: 集計キーを指定する辞書のリストと、どの集計可能なレポートで値を集計する必要があるかを指定します。
- 集計値（省略可）: 各キーに影響する値の量のリスト。
- アトリビューション レポート リダイレクト（省略可）: 複数の広告テクノロジー プラットフォームがリクエストを登録できるようにするためのリダイレクト URL。
複数の広告テクノロジー プラットフォームが、Attribution-Reporting-Redirects フィールドでリダイレクトを使用するか、triggerAttribution() メソッドを複数回呼び出して、同じトリガー イベントを登録できます。同じ広告テクノロジー プラットフォームが同じトリガー イベントに対して複数のレスポンスを提供する場合、レポートに重複するトリガーが含まれないように、重複除去キー フィールドの使用をおすすめします。
次のスニペットは、トリガーデータの現在の設計を示しています。
Attribution-Reporting-Register-Event-Trigger: {
"trigger_data": "[unsigned 64-bit integer]",
"trigger_priority": "[signed 64-bit integer]",
"deduplication_key": "[signed 64-bit integer]"
}
Attribution-Reporting-Aggregate-Trigger-Data: <aggregation-key-data>
Attribution-Reporting-Aggregate-Values: <aggregation-value-data>
Attribution-Reporting-Redirects: "https://adtechpartner.example"
ワークフローの例は次のとおりです。
広告テクノロジー SDK が API を呼び出してトリガーの登録を開始します。
triggerAttribution( Uri.parse("https://adtech.example/attribution_trigger?app_install=456"));API が
https://adtech.example/attribution_trigger?app_install=456にリクエストを行います。この広告テクノロジー プラットフォームの HTTPS サーバーが、ヘッダーに次の内容を含めて応答します。
Attribution-Reporting-Register-Event-Trigger: { "trigger_data": "1", "trigger_priority": "3", "deduplication_key": "3344", } Attribution-Reporting-Redirects: https://adtechpartner.example?app_install=567API が、
Attribution-Reporting-Redirectsで指定された各 URL にリクエストを行います。この例では URL が 1 つしか指定されていないため、API はhttps://adtechpartner.example?app_install=567にリクエストを行います。この広告テクノロジー プラットフォームの HTTPS サーバーが、ヘッダーに次の内容を含めて応答します。
Attribution-Reporting-Register-Event-Trigger: { "trigger_data": "7", "trigger_priority": "3", "deduplication_key": "3344" }ここまでのステップのリクエストに基づいて、2 つのトリガーが登録されます。
ソース優先アトリビューション アルゴリズムの適用
Attribution Reporting API は、トリガー（コンバージョン）をアトリビューション ソースに一致させるためにソース優先アトリビューション アルゴリズムを適用します。このドキュメントで後述するように、複数の広告テクノロジー プラットフォームがアトリビューション ソースを登録する場合、このアトリビューションは広告テクノロジー プラットフォームごとに独立して行われます。広告テクノロジー プラットフォームごとに、優先度が最も高いアトリビューション ソースがトリガー イベントに関連付けられます。同じ優先度のアトリビューション ソースが複数ある場合、API は最後に登録されたアトリビューション ソースを選択します。選択されなかった他のアトリビューション ソースは破棄され、今後のトリガー アトリビューションの対象ではなくなります。
インストール後のアトリビューション
場合によっては、最近発生した他の有効なアトリビューション ソースがあったとしても、インストール後のトリガーを、インストールにつながった同じアトリビューション ソースに帰属させる必要があります。
API では、広告テクノロジー プラットフォームがインストール後のアトリビューション期間を設定できるようにすることで、このユースケースをサポートできます。
- アトリビューション ソースを登録する際、インストールが予想される、インストールのアトリビューション期間を指定します（通常は 2～7 日間）。
- アトリビューション ソースを登録する際、インストール後のアトリビューション期間を指定します（通常は 7～30 日間）。この期間については、インストール後のトリガー イベントをインストールにつながったアトリビューション ソースに関連付ける必要があります。
- Attribution Reporting API は、アプリのインストールがいつ行われたかを検証し、内部的にインストールをソース優先アトリビューション ソースに帰属させます。ただし、このインストールは広告テクノロジー プラットフォームには送信されず、プラットフォームのそれぞれのレート制限にカウントされません。
インストール後のアトリビューション期間内に発生する今後のトリガーは、そのアトリビューション ソースが有効である限り、検証済みのインストールと同じアトリビューション ソースに帰属します。
Google は、ユーザーがアプリをアンインストールしてから再インストールするユースケースをサポートする方法を検討中です。
将来的には、より高度なアトリビューション モデルをサポートするために設計の拡張を検討する可能性があります。
アプリベースとウェブベースのトリガーパスのすべての組み合わせをサポート
Attribution Reporting API を使用すると、1 台の Android デバイスで次のトリガーパスのアトリビューションが可能になります。
- アプリからアプリ: アプリでユーザーに広告が表示されてから、そのアプリまたは別のインストール済みアプリでコンバージョンを実行します。
- アプリからウェブ: アプリでユーザーに広告が表示されてから、モバイルまたはアプリのブラウザでコンバージョンを実行します。
- ウェブからアプリ: モバイルまたはアプリのブラウザでユーザーに広告が表示されてから、アプリでコンバージョンを実行します。
- ウェブからウェブ: モバイルまたはアプリのブラウザでユーザーに広告が表示されてから、同じブラウザまたは同じデバイス上の別のブラウザでコンバージョンを実行します。
ウェブブラウザでは、新しいウェブ公開機能をサポートすることが可能です。ウェブの Attribution Reporting API 用のプライバシー サンドボックスと同様の機能などで、Android API を呼び出してアプリとウェブを対象にアトリビューションを有効にできます。
1 つのアトリビューション ソースに対する複数のトリガーに優先度を設定する
1 つのアトリビューション ソースが複数のトリガーにつながることがあります。たとえば、1 つの購入フローに、1 つの「アプリのインストール」トリガー、1 つ以上の「カートに追加」トリガー、1 つの「購入」トリガーが含まれる場合があります。各トリガーは、このドキュメントで前述するソース優先アトリビューション アルゴリズムに従って、1 つ以上のアトリビューション ソースに帰属します。
1 つのアトリビューション ソースに帰属させることができるトリガーの数には制限があります。詳しくは、このドキュメントで後述するアトリビューション レポートで測定データを表示するをご覧ください。この上限を超える複数のトリガーがある場合は、最も価値のあるトリガーを得るために、優先度設定ロジックを導入することをおすすめします。たとえば、広告テクノロジー プラットフォームのデベロッパーが、「カートに追加」トリガーよりも「購入」トリガーの方を優先させる場合などです。
このロジックをサポートするには、トリガーに個別の優先度フィールドを設定します。特定のレポート期間内で、制限が適用される前に最も優先度の高いトリガーが選択されます。
複数の広告テクノロジー プラットフォームがアトリビューション ソースまたはトリガーを登録できるようにする
複数の広告テクノロジー プラットフォームがアトリビューション レポートを受け取ることは一般的です。そのため、この API を使用すると、複数の広告テクノロジー プラットフォームが同じアトリビューション ソースまたはトリガーを登録できます。
アトリビューション ソース
アトリビューション ソースのリダイレクトは、registerAttributionSource() メソッドでサポートされています。
registerAttributionSource()メソッドを呼び出す広告テクノロジー プラットフォームは、パートナー広告テクノロジーのリダイレクト URL のセットを表すAttribution-Reporting-Redirectsフィールドをレスポンスに追加できます。- API がリダイレクト URL を呼び出し、パートナー広告テクノロジー プラットフォームでアトリビューション ソースを登録できるようにします。
Attribution-Reporting-Redirects フィールドには、複数のパートナー広告テクノロジー プラットフォームの URL のリストを指定できます。パートナー広告テクノロジー プラットフォームが独自の Attribution-Reporting-Redirects フィールドを指定することはできません。
この API では、registerAttributionSource() の呼び出しごとに異なる広告テクノロジー プラットフォームを使用することもできます。
トリガー
トリガーの登録については、サードパーティも同様の方法でサポートされています。広告テクノロジー プラットフォームは、追加の Attribution-Reporting-Redirects フィールドを使用するか、triggerAttribution() メソッドをそれぞれで呼び出すことができます。
広告主が複数の広告テクノロジー プラットフォームを使用して同じトリガー イベントを登録する場合は、重複除去キーを使用する必要があります。重複除去キーは、同じイベントのレポートが繰り返される場合の曖昧さを取り除くために使用します。重複除去キーが指定されていない場合、重複するトリガーが一意なものとして各広告テクノロジー プラットフォームにレポートされる可能性があります。
アトリビューション レポートで測定データを表示する
Attribution Reporting API では、次の種類のレポートが可能です。詳細についてはこのドキュメント内で別途説明します。
- イベントレベル レポートは、特定のアトリビューション ソース（クリックまたはビュー）を、限られたビットの忠実度の高いトリガーデータに関連付けます。
- 集計可能レポートは、必ずしも特定のアトリビューション ソースに関連付けられるわけではありません。イベントレベル レポートよりも豊富な、忠実度の高いトリガーデータが提供されますが、このデータは集計形式でしか利用できません。
これら 2 種類のレポートは相互に補完し合うものであり、同時に使用できます。
イベントレベル レポート
トリガーがアトリビューション ソースに帰属するとイベントレベル レポートが生成され、いずれかのレポート送信期間の間に各広告テクノロジー プラットフォームのポストバック URL に送信できるようになるまで、デバイスに保存されます。詳細についてはこのドキュメント内で別途説明します。
イベントレベル レポートは、トリガーについて情報がほとんど必要ない場合に便利です。イベントレベルのトリガーデータは、クリックについては 3 ビットに制限され（つまり、トリガーが 8 つのカテゴリのいずれかに割り当てられます）、ビューについては 1 ビットに制限されます。また、イベントレベル レポートでは、特定の価格やトリガー時間など、忠実度の高いトリガー側データのエンコードはサポートされていません。
イベントレベル レポートには次のようなデータが含まれます。
- デスティネーション: トリガーが発生する広告主アプリのパッケージ名または eTLD+1
- アトリビューション ソース ID: アトリビューション ソースの登録に使用したものと同じアトリビューション ソース ID
- トリガータイプ: アトリビューション ソースのタイプに応じた、1 ビットまたは 3 ビットの低忠実度トリガーデータ
イベントレベル レポートに適用されるプライバシー保護メカニズム
トリガーデータの忠実度の制限
API は、ビュースルー トリガーに 1 ビット、クリックスルー トリガーに 3 ビットを提供します。アトリビューション ソースは、引き続き 64 ビットのメタデータを完全にサポートします。
イベントレベル レポートで利用可能な限られたビット数で機能するように、トリガーで表現される情報を減らすかどうかを検討する必要があります。減らす場合の方法についても評価する必要があります。
差分プライバシー ノイズのフレームワーク
この API の目標は、k ランダム化レスポンスを使用して各ソースイベントに対しノイズのある出力を生成することで、イベントレベルの測定がローカルの差分プライバシー要件を満たすようにすることです。
ノイズの適用は、アトリビューション ソース イベントが正しくレポートされるかどうかに応じて行われます。アトリビューション ソースがデバイスに登録される際には、アトリビューション ソースが通常どおりに登録される確率 $ 1-p $ と、可能性のあるすべての API 出力状態（一切レポートが行われない場合や、複数の偽のレポートを行われる場合を含む）の中からデバイスがランダムに選択する確率 $ p $ がもちいられます。
k ランダム化レスポンスは、次の式が成立する場合に、イプシロン差分プライバシーを満たすアルゴリズムです。
ε の値が低い場合、真の出力は k ランダム化レスポンス メカニズムによって保護されます。k は、可能性のある API 出力状態の数を表します。正確なノイズ パラメータは現在開発中であり、フィードバックに基づいて変更される可能性があります。
利用可能なトリガー（コンバージョン）の制限
アトリビューション ソースごとのトリガーの数には制限があり、現在の提案では次のようになっています。
- 広告ビューのアトリビューション ソース: トリガー 1～2 個
- 広告クリックのアトリビューション ソース: トリガー 3 個
こうした制限は、アトリビューション ソースとトリガーに関する優先度を考慮して適用されます。
アトリビューション ソースあたりの広告テクノロジー プラットフォームの数の制限
1 つのアトリビューション ソースに関連付けることのできる広告テクノロジー プラットフォームの数には制限があります。こうした制限は、アトリビューション ソースとトリガーに関する優先度を考慮して適用されます。
特定のレポート送信期間
広告ビューのアトリビューション ソースのレポートは、ソースの期限が切れた 1 時間後に送信されます。この期限は設定できますが、2 日未満または 30 日を超える長さにすることはできません。
広告クリックのアトリビューション ソースのレポートは設定できません。ソースの期限が切れる前に、ソースの登録時点を基準とした特定の時点で送信されます。アトリビューション ソースから期限までの時間は、複数のレポート期間に分割されます。各レポート期間に（アトリビューション ソースの時間からの）期限があります。各レポート期間の最後に、デバイスは前回のレポート期間以降に発生したすべてのトリガーを収集し、スケジュール設定したレポートを送信します。この API は、次のレポート期間をサポートしています。
- 2 日間: デバイスは、アトリビューション ソースの登録から 2 日後までに発生したトリガーをすべて収集します。レポートは、アトリビューション ソースの登録から 2 日と 1 時間後に送信されます。
- 7 日間: デバイスは、アトリビューション ソースの登録から 2 日を超え、かつ 7 日以内に発生したトリガーをすべて収集します。レポートは、アトリビューション ソースの登録から 7 日と 1 時間後に送信されます。
- カスタム期間: アトリビューション ソースの「expiry」属性で定義します。レポートは、指定した期限の 1 時間後に送信されます。この値は、2 日未満または 30 日を超える長さにすることはできません。
集計可能レポート
集計可能レポートは、イベントレベル レポートより忠実度の高いトリガーデータを、より迅速にデバイスから提供します。忠実度の高いデータは集計でしか学習できず、特定のトリガーまたはユーザーと関連付けられることはありません。集計キーは最大 128 ビットであり、集計可能レポートは次のようなレポートのユースケースをサポートできます。
- 収益などのトリガー値のレポート
- より多くのトリガータイプの処理
また、集計可能レポートには次の特徴があります。
- 30 日間のアトリビューション期間
- このドキュメントで前述したイベントレベルの API と同じソース優先アトリビューション ロジック
Attribution Reporting API で集計可能レポートを準備して送信する方法の全体的な設計を、図 1 に示します。
- デバイスが、暗号化された集計可能レポートを広告テクノロジー プラットフォームに送信します。
- 広告テクノロジー プラットフォームが、集計可能レポートのバッチを集計サービスに送信します。
- 集計サービスが、集計可能レポートのバッチを読み取り、復号して集計します。
- 最終的な集計結果が広告テクノロジー プラットフォームに送り返されます。
集計可能レポートには、アトリビューション ソースに関連する次のデータが含まれます。
- ソース: 広告が配信されたアプリのパッケージ名または eTLD+1 ウェブ URL。
- デスティネーション: トリガーが発生したアプリのパッケージ名または eTLD+1 ウェブ URL。
- 日付: アトリビューション ソースで表されるイベントが発生した日付。
- ペイロード: 暗号化された Key-Value ペアとして収集されるトリガー値。信頼できる集計サービスで集計の計算に使用されます。
集計サービス
次のサービスは集計機能を提供し、集計データに対する不適切なアクセスから保護します。
これらのサービスは異なる当事者によって管理されています。詳細についてはこのドキュメント内別途説明します。
- 集計サービスは、広告テクノロジー プラットフォームでデプロイが想定される唯一のサービスです。
- 鍵管理サービスとプライバシー バジェット サービスは、検証者という信頼できる当事者によって実行されます。検証者は、集計サービスを実行するコードが Google によって提供された一般公開のコードであることと、すべての集計サービス ユーザーに同じ鍵とバジェット サービスが適用されていることを証明します。
集計サービス
広告テクノロジー プラットフォームでは、Google によって提供されたバイナリに基づく集計サービスを事前にデプロイしておく必要があります。
この集計サービスは、クラウドでホストされた高信頼実行環境（TEE）で動作します。TEE には、次のようなセキュリティ上のメリットがあります。
- TEE で動作するコードが、Google によって提供された特定のバイナリであることが保証されます。この条件が満たされない限り、集計サービスはオペレーションに必要な復号鍵にアクセスできません。
- 実行中のプロセスにセキュリティを提供し、外部の監視や改ざんから隔離します。
こうしたセキュリティ上のメリットにより、集計サービスは、暗号化されたデータへのアクセスなどの機密性の高いオペレーションを安全に実施できるようになります。
集計サービスの設計、ワークフロー、セキュリティ上の考慮事項の詳細については、GitHub の集計サービスのドキュメントをご覧ください。
鍵管理サービス
このサービスは、集計サービスが承認済みのバージョンのバイナリを実行していることを確認してから、広告テクノロジー プラットフォームの集計サービスとトリガーデータの正しい復号鍵を提供します。
プライバシー バジェット サービス
このサービスは、広告テクノロジー プラットフォームの集計サービスが特定のトリガー（複数の集計キーを含む場合があります）にアクセスする頻度を追跡し、アクセス時の復号回数を適切な範囲に制限します。1 つのトリガーにつき 1 回の復号が許可されます。
Aggregatable Reports API
集計可能レポートへの投稿を用意するための API は、イベントレベル レポートにアトリビューション ソースを登録するときと同じベース API を使用します。以降のセクションでは、API の拡張機能について説明します。
集計可能ソースデータを登録する
API がアトリビューション ソース URI にリクエストを行うと、広告テクノロジー プラットフォームは、リスト内の各集計キーについて次のフィールドを持つ新しい HTTP ヘッダー Attribution-Reporting-Register-Aggregate-Source で応答することにより、集計キーのリストを登録できます。
- ソースイベント ID: キーの名前用文字列。結合キーとして使用され、トリガー側のキーと組み合わせて最終的なキーを形成します。
- キーピース: キーのビット文字列値。
- キーオフセット: このキーピースをトリガー側のキーピースと組み合わせるためのオフセット インデックスの整数値。
最終的なキーは、このピースとトリガー側のピースを組み合わせたものであり、キーオフセット フィールドを使用してビット文字列を連結します。最終的なキーは最大 128 ビットに制限されます。それより長いキーは切り捨てられます。
次の例では、広告テクノロジー プラットフォームが API を使用して以下を収集しています。
- キャンペーン レベルでのコンバージョン数の集計
- 地域レベルでの購入額の集計
Attribution-Reporting-Register-Aggregate-Source:
[{
// Generates a "101011001" key prefix named "campaignCounts".
"source_event_id": "campaignCounts",
"key_piece": "101011001", // User saw ad from campaign 345 (out of 511).
"key_offset": 0 // The first part of the key
// when combined with trigger-side keys.
},
{
// Generates a "101" key prefix named "geoValue".
"source_event_id": "geoValue",
// Source-side geo region = 5 (US) but pad with 0s since the shop operates in
// ~100 separate countries.
"key_piece": "0000101",
"key_offset": 0 // The first part of the key
// when combined with trigger-side keys.
}]
集計可能トリガーを登録する
トリガーの登録では、ヘッダーがさらに 2 つ追加されます。
1 つ目のヘッダーは、トリガー側の集計キーのリストを登録するために使用されます。広告テクノロジー プラットフォームは、リスト内の各集計キーについて次のフィールドを持つ HTTP ヘッダー Attribution-Reporting-Aggregate-Trigger-Data で応答する必要があります。
- キーピース: キーのビット文字列値。
- キーオフセット: アトリビューション ソース キーピースをトリガー キーピースと組み合わせる際にオフセット インデックスとして使用される整数値。
- ソースキー: 最終的なキーを形成するために、トリガーキーを組み合わせる必要があるアトリビューション ソース側のキーの名前を含んだ文字列のリスト。
次のスニペットは、集計可能レポートに集計ソースデータを登録する例の続きです。
Attribution-Reporting-Aggregate-Trigger-Data:
[
// Each dictionary independently adds pieces to multiple source keys.
{
"key_piece": "10",// Conversion type purchase = 2
// Combine key piece at offset index 9 with attribution source key piece.
// 9 is the length of the source's campaignCounts bitstring
"key_offset": 9,
// Apply this suffix to:
"source_keys": ["campaignCounts"]
},
{
"key_piece": "10101",// Purchase category shirts = 21
// Combine key piece at offset index 7 with attribution source key piece.
// 7 is the length of the source's geoValue bitstring
"key_offset": 7,
// Apply this suffix to:
"source_keys": ["geoValue" ]
}
]
2 つ目のヘッダーは、各キーに寄与する値のリストを登録するために使用されます。広告テクノロジー プラットフォームは HTTP ヘッダー Attribution-Reporting-Aggregate-Values で応答する必要があります。
各トリガーは、集計レポートに複数回投稿できます。任意のアトリビューション ソースへの投稿の総量は、$ L1 $ パラメータによって制約されます。これは、任意のアトリビューション ソースのすべての集計キーにわたる投稿（値）を合計したものの最大値です。この制限を超えると、以降の投稿は通知なしに破棄されます。最初の提案では、$ L1 $ が $ 2^{16} $ (65536) に設定されます。集計サービスのノイズは、このパラメータに比例して調整されます。そのため、特定の集計キーについてレポートされる値は、割り当てられた $ L1 $ のプライバシー バジェット部分に基づいて適切に調整することをおすすめします。このアプローチでは、ノイズが適用されたときに、集計レポートの忠実度を最も高く保てます。このメカニズムは柔軟性が高く、多くの集計戦略をサポートできます。
次の例では、$ L1 $ の寄与分をそれぞれに分割することで、プライバシー バジェットが campaignCounts と geoValue の間で均等に分割されます。
Attribution-Reporting-Aggregate-Values:
{
// Privacy budget for each key is L1 / 2 = 2^15 (32768).
// Conversion count was 1.
// Scale the count to use the full budget allocated: 1 * 32768 = 32768.
"campaignCounts": 32768,
// Purchase price was $52.
// Purchase values for the app range from $1 to $1,024 (integers only).
// Scaling factor applied is 32768 / 1024 = 32.
// For $52 purchase, scale the value by 32 ($52 * 32 = $1,664).
"geoValue": 1664
}
上の例では、次のような集計結果が生成されます。
[
// campaignCounts:
{
// The attribution source key piece "101011001" (offset 0)
// is concatenated with "10" (offset 9) trigger key piece to form
// the final key "10101100110" = 1382.
"key": "1382",
"value": 32768
},
// geoValue:
{
// The attribution source key piece "0000101" (offset 0)
// is concatenated with "10101" (offset 7) trigger key piece to form
// the final key "000010110101" = 181.
"key": "181",
"value": "1664"
}
]
正しい値（適用されるモジュロノイズ）が得られるように、スケーリング ファクタを反転できます。
L1 = 65536
trueCampaignCounts = campaignCounts / (L1 / 2)
trueGeoValue = geoValue / (L1 / 2) * 1024
差分プライバシー
この API の目標は、差分プライバシーを満たす集計結果の測定をサポートできるフレームワークを用意することです。これは、次のような分布のノイズを選ぶなどして、$ L1 $ のバジェットに比例するノイズを追加することで実現できます
今後の検討事項と未解決の問題
Attribution Reporting API は現在開発中です。また、ラストクリック アトリビューション以外のモデルやクロスデバイス測定のユースケースなど、将来的な機能についても検討しています。
いくつかの問題点について、コミュニティからのフィードバックもお待ちしております。
- 複数の広告テクノロジー プラットフォームでアトリビューション ソースとトリガーを登録できるようにし、サードパーティによる測定を可能にする予定です。現在の提案では、API 呼び出しを行う広告テクノロジー プラットフォームのみがサードパーティの広告テクノロジー プラットフォームのリストを指定できます。API の設計を簡素化するため、その次の広告テクノロジー プラットフォームのみを指定することで広告テクノロジー プラットフォームにデイジー チェーン リダイレクトを許可することもできます。
- アプリまたはウェブのどちらでもトリガーが発生する可能性のあるアプリからウェブの測定を有効にするために、広告テクノロジー プラットフォームで、アトリビューション ソースとトリガーの登録時に同じデスティネーション フィールドを指定する必要があります。Google は、アプリでトリガーが発生した場合でもウェブ eTLD+1 を使用することが妥当かどうかについて評価中です。
- トリガー レポートが重複しないように、広告テクノロジー プラットフォームが同じトリガーを複数回登録する場合には、重複除去キーを使用することをおすすめします。Google は、アプリがこの重複除去キーをサードパーティ プラットフォームを含むすべての広告テクノロジー プラットフォームに渡せるかどうかについて評価中です。