集計サービスは、集計可能な元のレポートから、詳細なコンバージョン データとリーチ測定の概要レポートを生成します。広告テクノロジーは、クライアントサイドで集計エントリ ポイントを 2 つ用意しており、Attribution Reporting API または Private Aggregation API を介して集計サービスにレポートを送信します。
実装ステータス
- Aggregation Service が一般提供に移行しました。
- Aggregation Service は、Attribution Reporting API と Private Aggregation API で Protected Audience API と Shared Storage API に使用できます。
対象
| Proposal | Status |
|---|---|
| Aggregation Service support for Amazon Web Services (AWS) across Attribution Reporting API, Private Aggregation API
Explainer |
Available |
| Aggregation Service support for Google Cloud across Attribution Reporting API, Private Aggregation API Explainer |
Available |
| Aggregation Service site enrollment and multi-origin aggregation. Site enrollment includes mapping of a site to cloud accounts (AWS, or GCP). To aggregate multiple origins, they must be of the same site.
FAQs on GitHub Site aggregation API documentation |
Available |
| The Aggregation Service's epsilon value will be kept as a range of up to 64, to facilitate experimentation and feedback on different parameters.
Submit ARA epsilon feedback. Submit PAA epsilon feedback. |
Available. We will provide advanced notice to the ecosystem before the epsilon range values are updated. |
| More flexible contribution filtering for Aggregation Service queries
Explainer |
Available |
| Process for budget recovery post-disasters (errors, misconfigurations, and so on)
Explainer |
Available Mechanism to review the percentage of shared IDs recovered by an ad tech using budget recovery and suspend future recoveries for excessive recoveries planned for H1 2025 |
| Accenture operating as one of the Coordinators on AWS
Developer Blog |
Available |
| Independent party operating as one of the Coordinators on Google Cloud
Developer blog |
Available |
| Aggregation Service support for Aggregate Debug Reporting on Attribution Reporting API
Explainer |
Available |
主な用語と概念
広告テクノロジー ワークフローで Aggregation Service の使用を検討している場合は、次の用語とコンセプトを確認して、この新しい集計フローがチームにどのようなメリットをもたらすかをご確認ください。
| 用語 | 説明 |
|---|---|
| 集計サービス | 集計可能レポートを処理して概要レポートを作成する、広告テクノロジー運営のサービス。 |
| 集計可能レポート |
集計可能レポートは、個々のユーザーのデバイスから送信される暗号化されたレポートです。これらのレポートには、クロスサイトのユーザー行動やコンバージョンに関するデータが含まれています。コンバージョン（アトリビューション トリガー イベントと呼ばれることもあります）とそれに関連する指標は、広告主または広告テクノロジーによって定義されます。各レポートは、さまざまな関係者が基となるデータにアクセスするのを防ぐために暗号化されます。 集計可能レポートの詳細 |
| 集計可能レポートのアカウンティング | 両方のコーディネータに配置された分散レジャー。割り当てられたプライバシー バジェットを追跡し、「重複なし」ルールを適用します。これは、コーディネーター内に配置され、そこで実行されるプライバシー保護メカニズムです。これにより、割り当てられたプライバシー バジェットを超えるレポートが集計サービスに渡されることがなくなります。 バッチ処理戦略が集計可能レポートとどのように関連しているかについては、こちらをご覧ください。 |
| 集計可能レポートのアカウンティング予算 | レポートが複数回処理されないようにするための予算の参照。 |
| 高信頼実行環境 (TEE) |
A trusted execution environment is a special configuration of computer hardware and software that allows external parties to verify the exact versions of software running on the computer. TEEs allow external parties to verify that the software does exactly what the software manufacturer claims it does—nothing more or less. To learn more about TEEs used for the Privacy Sandbox proposals, read the Protected Audience API services explainer and the Aggregation Service explainer. |
| コーディネーター |
コーディネーターは、鍵の管理と集計可能レポートの会計を担当するエンティティです。コーディネーターは、承認された集計サービス構成のハッシュのリストを保持し、復号鍵へのアクセスを構成します。 |
| 共有 ID |
次の要素で構成される計算値: shared_info、reporting_origin、destination_site（Attribution Reporting API でのみ利用可能）、source_registration-time（Attribution Reporting API でのみ利用可能）、scheduled_report_time、version。
つまり、複数のレポートで shared_info フィールドの同じ属性を共有している場合、それらのレポートは同じ共有 ID に属します。これは、集計可能レポートアカウンティングで重要な役割を果たします。
トラステッド サーバーの詳細 |
| 概要レポート |
サマリー レポートは、Attribution Reporting API と Private Aggregation API のレポート タイプです。概要レポートには、集計されたユーザーデータが含まれ、詳細なコンバージョン データが含まれる場合はノイズが追加されます。概要レポートは集計レポートで構成されています。概要レポートは、特にコンバージョン値などの一部のユースケースで、イベントレベル レポートよりも柔軟性が高く、豊富なデータモデルを使用できます。 |
| レポート元 |
レポート元は、集計可能レポートを受け取るエンティティです。つまり、広告テクノロジー 呼び出すことができます集計可能レポートは、ユーザーのデバイスから、レポート送信元に関連付けられた well-known URL に送信されます。報告元は登録時に指定する必要があります。 |
| 寄付金 | 集計可能レポートには、任意の数のカウンタ増分を含めることができます。たとえば、ユーザーが広告主のサイトで閲覧した商品の数をレポートに含めることができます。1 つのソースイベントに関連するすべての集計可能レポートの増分値の合計は、指定された上限「L1=2^16」を超えないようにする必要があります。 詳細については、集計可能レポートの説明をご覧ください。 |
| ノイズとスケーリング | 集計処理の一環として一定量の統計的ノイズが概要レポートに追加されます。このノイズは、プライバシーを保護し、最終的なレポートで匿名化された測定情報を提供するようにも機能します。ラプラス分布から取得される加算ノイズ メカニズムの詳細を確認する。 |
| 宣誓 |
構成証明は、ソフトウェア ID を認証するメカニズムであり、通常は暗号ハッシュまたは署名を使用します。集計サービスの提案では、構成証明は、広告テクノロジーが運営する集計サービスで実行されているコードとオープンソース コードを照合します。 構成証明の詳細を確認する。 |
集約サービスの背景については、説明と利用規約の全文リストをご覧ください。
集計のユースケース
広告測定のデベロッパー ジャーニーと、対応する測定クライアント ライブラリについて、次の例をご覧ください。
| ユースケース | エントリ ポイント | 説明 |
|---|---|---|
| 入札の最適化 | Attribution Reporting API （Chrome と Android） | 集計レポートを使用して、入札単価の最適化に役立つコンバージョン シグナルを取り込みます。 |
| クロス プラットフォーム測定 | Attribution Reporting API （Chrome と Android） | ウェブとアプリをまたぐ測定機能を使用して、Chrome と Android 全体のパフォーマンスを把握できます。 |
| コンバージョン レポート | Attribution Reporting API （Chrome と Android） | お客様のキャンペーンのニーズに合わせて、コンバージョンの集計レポートを作成します（クリックスルー コンバージョンとビュースルー コンバージョンを含む）。 |
| キャンペーンのリーチ測定 | Shared Storage API とPrivate Aggregation API （Chrome） | クロスサイト広告ビュー変数を使用して、キャンペーンのリーチを測定します。 |
| ユーザー属性レポート | Shared Storage API とPrivate Aggregation API （Chrome） | クロスサイト広告ビューとユーザー属性情報を使用して、ユーザー属性別のリーチを測定します。 |
| コンバージョン経路の分析 | Shared Storage API とPrivate Aggregation API （Chrome） | クロスサイト広告ビューとコンバージョン変数を保存して、コンバージョン経路の集計分析を行います。 |
| ブランド効果とコンバージョン リフト | Shared Storage API とPrivate Aggregation API （Chrome） | テストグループとコントロール グループに関するレポートと、ブランド効果とインクリメンタリティを測定するためのアンケート情報。 |
| オークションのデバッグ | Protected Audience API と Private Aggregation API（Chrome） | 集計レポートはデバッグに使用します。 |
| 入札単価の分布 | Protected Audience API と Private Aggregation API（Chrome） | 集計レポートを使用して、オークションの入札値の分布を把握します。 |
エンドツーエンドのフロー
次の図は、Aggregation Service の動作を示しています。ここでは、ウェブとモバイルからレポートを受信してから、集計サービスで概要レポートを作成するまでのエンドツーエンドのフローについて説明します。
- 公開鍵を取得して暗号化されたレポートを生成します。
- 暗号化された集計可能レポートが広告テクノロジー サーバーに送信され、収集、変換、バッチ処理されます。
- 広告テクノロジー サーバーがレポート（avro 形式）をバッチ処理し、デプロイされた集計サービスに送信します。（広告テクノロジーが完了する必要があります）。
- 集計レポートを取得して復号します。
- コーディネーターから復号鍵を取得します。
- 集計サービスは、集計とノイズ追加のためにレポートを復号します。
- 集計可能レポートのアカウンティング サービスは、指定された集計可能レポートの概要レポートを生成するために残っているプライバシー バジェットがあるかどうかを確認します。
- 最終的な概要レポートを提出します。
この図は、集計サービスと、主なクライアント測定 API（Attribution Reporting API、Private Aggregation API、コーディネーター）との全体的な関係を示しています。
このフローでは、Attribution Reporting API や Private Aggregation API などのさまざまな Measurement API を使用して、複数のブラウザ インスタンスからレポートが生成されます。Chrome は、コーディネータの鍵ホスティング サービスから公開鍵を取得し、広告テクノロジーのレポート送信元に送信する前にレポートを暗号化します。公開鍵は 7 日ごとにローテーションされます。
広告テクノロジーのレポート送信元がこれらのレポートを受信したら、レポートを収集して avro 形式に変換し、デプロイされた集計サービス インスタンスに送信するようにレポート送信元を構成する必要があります。バッチ処理戦略を確認する。
広告テクノロジーがバッチ処理の準備ができたら、集計サービスへのバッチ リクエストを作成します。ここで、Key Hosting Service から復号鍵を取得してレポートを復号し、集計してノイズを加えて概要レポートを作成します。ただし、最終的な概要レポートを生成するのに十分なプライバシー バジェットがあるかどうかに依存します。
レポートが収集される広告テクノロジー レポート送信元エンドポイントは広告テクノロジーがホストし、集計サービスは広告テクノロジーのクラウドにデプロイされます。
集計可能レポートのバッチ処理
指定されたレポート送信元サーバーのサポートなしでは、レポート フローは完了しません。これは、広告テクノロジーが登録プロセスで送信したオリジンです。レポート送信元が行う主な処理は、受信した集計可能なレポートの収集、変換、バッチ処理、Google Cloud または Amazon Web Services にデプロイされた広告テクノロジーの集計サービスへの送信の準備です。詳しくは、集計可能なレポートの準備方法をご覧ください。
一般的なコンセプトを理解できたところで、集計サービスにデプロイされるコンポーネントについて詳しく見てみましょう。
クラウド コンポーネント
Aggregation Service は、さまざまなクラウド サービス コンポーネントで構成されています。提供された Terraform スクリプトは、必要なすべてのクラウド サービス コンポーネントをプロビジョニングして構成します。
フロントエンド サービス
マネージド クラウド サービス: Cloud Functions（Google Cloud）/ API Gateway（Amazon Web Services）
Frontend Service は、ジョブの作成とジョブ状態の取得のための Aggregation API 呼び出しのエントランス ポイントとして機能するサーバーレス ゲートウェイです。集計サービス ユーザーからのリクエストの受信、入力パラメータの検証、集計ジョブのスケジュール設定プロセスの開始を行います。
Frontend Service では、次の 2 つの API を使用できます。
| エンドポイント | 説明 |
|---|---|
createJob |
この API は、集計サービス ジョブをトリガーします。ジョブ ID、入力ストレージの詳細、出力ストレージの詳細、レポート送信元など、ジョブをトリガーする情報が必要です。 |
getJob |
この API は、指定されたジョブ ID のジョブのステータスを返します。ジョブのステータス（「受信済み」、「処理中」、「完了」など）に関する情報を提供します。また、ジョブが完了すると、ジョブの実行中に発生したエラー メッセージなど、ジョブの結果が表示されます。 |
Aggregation Service API のドキュメントを確認する。
ジョブキュー
マネージド クラウド サービス: Pub/Sub（Google Cloud）/ Amazon SQS（Amazon Web Services）
Job Queue は、Aggregation Service のジョブリクエストを保存するメッセージキューです。フロントエンド サービスは、ジョブリクエスト メッセージをキューに挿入します。このメッセージは、集計ワーカーによって消費され、ジョブリクエストを処理します。
クラウド ストレージ
マネージド クラウド サービス: Google Cloud Storage（Google Cloud）/ Amazon S3（Amazon Web Services）Cloud Storage は、Aggregation Service で使用される入出力ファイル（暗号化されたレポート ファイル、出力概要レポートなど）の保存に使用されます。
ジョブのメタデータ データベース
マネージド クラウド サービス: Spanner（Google Cloud）/ DynamoDB（Amazon Web Services）
ジョブのメタデータ データベースには、集計ジョブのステータスが保存され、追跡されます。データベースには、作成日時、リクエスト日時、更新日時、状態（Received、In Progress、Finished など）などのメタデータが記録されます。Aggregation Worker は、ジョブの進行に応じて Job Metadata Database を更新します。
集計ワーカー
マネージド クラウド サービス: Confidential Space を使用した Compute Engine（Google Cloud）/ Nitro Enclave を使用した Amazon Web Services EC2（Amazon Web Services）
集計ワーカーは、ジョブキュー内のジョブリクエストによって開始されたジョブリクエストを処理し、コーディネータの Key Generation and Distribution Service（KGDS）から取得したキーを使用して暗号化された入力を復号します。ジョブ処理のレイテンシを最小限に抑えるために、復号キーは Aggregation Worker に 8 時間キャッシュに保存され、そのワーカー インスタンスによって処理されるジョブで使用できます。
ワーカーは高信頼実行環境（TEE）インスタンス内で動作します。各ワーカーは一度に 1 つのジョブのみを処理します。広告テクノロジーは、自動スケーリング構成を設定して、ジョブを並列処理するように複数のワーカーを構成できます。自動スケーリングにより、ジョブキューに残っているメッセージの数に応じてワーカー数が動的に調整されます。自動スケーリングのワーカーの最小数と最大数は、Terraform 環境ファイルで構成できます。自動スケーリングの詳細については、次の Terraform スクリプトをご覧ください。[Amazon Web Services / Google Cloud]
集計ワーカーは、集計可能レポートのアカウンティングのために集計可能レポート アカウンティング サービスを呼び出します。集計可能なレポート アカウンティング サービスにより、プライバシー バジェットの上限を超えていない限り、ジョブが実行されるようにします。（「重複なし」ルールを参照）。予算が利用可能な場合は、ノイズの多い集計値を使用して概要レポートが生成されます。詳しくは、集計可能なレポートのアカウントをご覧ください。
集計ワーカーは、ジョブ メタデータ データベースのジョブメタデータを更新します。これには、適切なジョブ戻りコードや、レポートの一部が失敗した場合のエラー カウンタが含まれます。ユーザーは、ジョブ状態取得 API（getJob）を使用して状態を取得できます。
集計サービスの詳細については、説明をご覧ください。
次のステップ
Aggregation Service のハイライトを確認したので、Google Cloud または Amazon Web Services で Aggregation Service の独自のインスタンスのデプロイを開始しましょう。スタートガイドをご覧ください。デプロイした Aggregation Service の運用方法について詳しくは、Aggregation Service の運用をご覧ください。
トラブルシューティング
エラー メッセージの詳細な説明、発生したエラーの原因、緩和するための次のステップについては、一般的なエラーコードと緩和策のドキュメントをご覧ください。
サポートの利用とフィードバック
- プロダクトに関する質問、フィードバック、機能リクエストについては、GitHub リポジトリで問題を作成してください。
- Aggregation Service を使用してジョブのデプロイ、メンテナンス、実行中にエラーが発生した場合は、こちらのテクニカル サポート フォームを使用してテクニカル トラブルシューティング サポートをリクエストしてください。
- 公開ステータス ダッシュボードで既知の問題を確認します。