集計可能なレポートのプライバシー保護

集計サービスは、未加工の集計可能レポートから、詳細なコンバージョンデータとリーチ測定の概要レポートを生成します。ユーザーデータのプライバシーとセキュリティを維持するため、Aggregation Service では、差分プライバシー（DP）をサポートするフレームワークを使用して、レポートで個々のユーザーについて明らかにされる情報の量を定量化し、制限します。

このガイドでは、個々のユーザーに関するデータの安全性を維持するのに役立つ集計可能なレポートを作成するためのツールと戦略について説明します。

ノイズが追加された概要レポートを作成する
貢献予算を設定する
レポートのバッチ処理の戦略
- 重複するレポートを一括で処理する
- 共通の共有 ID を含むレポートを処理する
事前宣言された集計キーを使用する

ノイズが追加された概要レポート

集計可能レポートをバッチ処理すると、集計サービスによって概要レポートが作成されます。この概要レポートは、すべての事前定義済みドメインキーのすべての貢献度を合計したもので、統計ノイズが追加されています。

レポートに追加されるノイズは、集計されるレポートの数、個々のレポートの値、集計されたレポートの値には依存しません。ノイズは Laplace 分布の離散バージョンから抽出され、対応する Measurement API とプライバシーパラメータ epsilon に応じてクライアントによって適用される貢献予算（L1 感度）にスケーリングされます。

ノイズとそのレポートデータへの影響について詳しくは、概要レポートのノイズについてをご覧ください。

予算に対する割合

サマリーレポートの感度を制御するため、呼び出しで渡される貢献度の数は、貢献度の上限（貢献度予算とも呼ばれます）に結び付けられます。貢献度予算は、Attribution Reporting API を使用しているか、Private Aggregation API を使用しているかによって異なります。

各 API の貢献予算の設定方法については、次の API ドキュメントのセクションをご覧ください。

レポートのバッチ処理戦略

集計可能なレポートをバッチ処理する場合は、プライバシー制限を超えないようにバッチ処理戦略を最適化することが重要です。レポートを正しくバッチ処理するための 2 つの重要なコンセプトは、「重複なし」ルールと「互いに素なバッチ」の考え方です。

「重複なし」ルール

集計サービスは「重複なし」ルールを適用します。このルールでは、report_id で一意に識別される集計可能レポートは、1 つのバッチに 1 回しか表示できないと規定されています。集計可能レポートがバッチごとに複数回表示された場合、最初のレポートが集計に含まれ、同じ report_id を持つ後続のレポートは破棄され、バッチは正常に完了します。

また、同じ共有 ID を複数のバッチで使用することはできません。共有 ID が以前のバッチにすでに含まれていて、そのバッチが成功している場合、同じ共有 ID を含む後続のバッチは失敗します。

同じレポートは 1 つのバッチにつき 1 回しか使用できません。 — **図 1.** レポートがバッチに複数回表示される場合、集計には最初のインスタンスが含まれ、同じ ID の後続のレポートは破棄されます。

「重複なし」ルールがない場合、攻撃者は、1 つのバッチまたは複数のバッチにレポートの重複コピーを含めることでバッチの内容を操作し、特定のバッチの内容に関する情報を取得する可能性があります。

レポートのバッチ内または複数のバッチ間で「重複なし」ルールを適用する方法については、バッチ内の重複レポートをご覧ください。

不連続バッチ

バッチ間の重複を回避するため、集計サービスでは重複しないバッチが適用されます。つまり、2 つ以上のバッチに、共通の共有 ID を持つレポートを含めることはできません。共有 ID は、集計可能レポートの shared_info フィールドから収集されたデータと、ジョブリクエストのフィルタリング ID を組み合わせたものです。フィルタリング ID が指定されていない場合は、デフォルトの 0 が使用されます。

次の shared_info フィールドの例では、API、attribution_destination（Attribution Reporting 用）、reporting_origin、scheduled_report_time、source_registration_time（Attribution Reporting 用）、version を確認できます。これらのフィールド（report_id を除く）は、ジョブリクエストのフィルタリング ID とともに、共有 ID に寄与します。

"shared_info": {
  "API": "attribution-reporting",
  "attribution_destination": "https://privacy-sandbox-demos-shop.dev",
  "report_id": "5b052748-f5fb-4f14-b291-de03484ed59e",
  "reporting_origin": "https://privacy-sandbox-demos-dsp.dev",
  "scheduled_report_time": "1707786751",
  "source_registration_time": "0",
  "version": "0.1"
}

source_registration_time は日単位で切り捨てられ、scheduled_report_time は時間単位で切り捨てられるため、同じ共有 ID を持つレポートが存在します。この例では、Report1 と Report2 に共有情報フィールドがあります。どちらのレポートも、API、バージョン、attribution_destination、reporting_origin、source_registration_time は同じです。report_id は共有 ID の一部ではないため、この違いは無視できます。

次の Report1 と Report2 の例では、scheduled_report_time の値は同じです。

Report1 の共有情報:

"shared_info": {
  "API": "attribution-reporting",
  "attribution_destination": "https://shop.dev",
  "report_id": "5b052748-...",
  "reporting_origin": "https://dsp.dev",
  "scheduled_report_time": "1708376890",
  "source_registration_time": "0",
  "version": "0.1"
}

Report2 の共有情報:

"shared_info": {
  "API": "attribution-reporting",
  "attribution_destination": "https://shop.dev",
  "report_id": "5b052748-...",
  "reporting_origin": "https://dsp.dev",
  "scheduled_report_time": "1708376890",
  "source_registration_time": "0",
  "version": "0.1"
}

スケジュール設定されたレポートの時間は、Report1 が「2024 年 2 月 19 日午後 9 時 8 分 10 秒」、Report2 が「2024 年 2 月 19 日午後 9 時 55 分 10 秒」です。scheduled_report_time フィールドの値は時間に切り捨てられるため、両方のレポートの scheduled_report_time フィールドの値は 1708376890（「2024 年 2 月 19 日午後 9 時」のエンコード値）になります。

他のすべてのフィールドとフィルタリング ID が同じであるため、両方のレポートの共有 ID は同じになります。両方のレポートに同じ共有 ID があるため、両方とも同じバッチに含める必要があります。

Report1 が以前に成功したバッチでバッチ処理され、Report2 が後続のバッチで処理される場合、Report2 を含むバッチは PRIVACY_BUDGET_EXHAUSTED エラーで失敗します。この場合は、以前のバッチでバッチ処理が成功した共有 ID のレポートを削除して、もう一度お試しください。このエラーの詳細については、集計サービスのエラーコードと軽減策をご覧ください。

共通の共有 ID を持つレポートは、同じバッチに含める必要があります。 — **図 2.** バッチ 2 には、バッチ 1 のレポートと共通の共有 ID を持つレポートが含まれているため、バッチ 2 は失敗します。

事前宣言された集計キー

バッチを集計サービスに送信する際は、レポート作成元から受け取った集計可能レポートと出力ドメインファイルの両方を含める必要があります。出力ドメインには、集計可能レポートから取得されたキー（バケット）が含まれます。

プライバシーの観点から、実際にはレポートが特定のキーと一致しない場合でも、出力ドメインで事前に宣言されたすべてのキーにノイズが追加されます。出力ドメインを指定すると、出力にキーが存在することで単一のユーザーまたはイベントに関する情報が漏洩する攻撃を防ぐことができます。たとえば、1 人のユーザーにのみキャンペーンを表示した場合、出力でキーを受け取ると、ノイズが追加されていても、そのユーザーが後でコンバージョンしたことがわかります。このドメインを最初に指定することで、ユーザーの投稿に関する情報が公開されないようにすることができます。

これらの 128 ビットキーは、Attribution Reporting API または Private Aggregation API のいずれかで宣言し、トラッキングするディメンションのエンコードに使用できます。

事前宣言されたキーのみが集計の対象となり、概要レポートに含まれます。概要レポートのバケットの集計値には統計ノイズが追加され、作成された概要レポートに反映されます。

Aggregation Service のプライバシーバッチ。 — **図 3.** 概要レポートには、バケットとも呼ばれる事前宣言されたキーのみが含まれます。

集計キーが出力ドメインファイルに含まれているものの、バッチレポートに存在しない場合、集計値がゼロであっても、プライバシー保護のためにノイズが追加されるため、最終的な概要レポートはゼロ以外になる可能性があります。

集計可能なレポートのプライバシー保護 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。