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

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

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

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

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

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

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

拠出予算

概要レポートの精度を制御するため、呼び出しで渡される貢献の数は、特定の貢献の上限（貢献の予算）に関連付けられています。貢献度予算は、Attribution Reporting API と Private Aggregation API のどちらを使用するかによって異なります。

各 API のコントリビューション バジェットを設定する方法について詳しくは、次の API のドキュメントをご覧ください。

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

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

「重複なし」ルール

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

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

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

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

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

不連続なバッチ

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

次の shared_info フィールドの例では、API、attribution_destination（アトリビューション レポート用）、reporting_origin、scheduled_report_time、source_registration_time（アトリビューション レポート用）、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"
}

レポートのスケジュール設定時刻は、レポート 1 が「2024 年 2 月 19 日午後 9 時 8 分 10 秒」、レポート 2 が「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 のレポートを削除して、もう一度お試しください。このエラーの詳細については、Aggregation Service のエラーコードと緩和策をご覧ください。

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

事前宣言された集計キー

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

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

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

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

集計サービスのプライバシー バッチ。
図 3. 概要レポートには、事前宣言されたキー（バケット）のみが含まれます。

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