可匯總報表的隱私權保護措施

匯總服務會根據原始可匯總報表，產生詳細轉換資料和觸及評估的摘要報表。為確保使用者資料的隱私和安全性，匯總服務會使用支援差異化隱私 (DP)的架構，量化並限制這些報表揭露的個別使用者資訊量。

本指南將說明建立可匯總的報表所需的工具和策略，協助您保護個別使用者的資料安全：

含有雜訊的摘要報表

當您將可匯總報表批次處理時，匯總服務會建立摘要報表。這份摘要報表是所有預先定義網域鍵的所有貢獻總和，並加入統計雜訊。

報表中新增的雜訊不會受到匯總報表數量、個別報表值或匯總報表值的影響。雜訊會從 Laplace 分布的離散版本繪製，並根據對應的評估 API 和隱私權參數 epsilon，由用戶端強制設為貢獻預算 (L1 敏感度)。

如要進一步瞭解雜訊及其對報表資料的影響，請參閱「瞭解摘要報表中的雜訊」。

貢獻預算

為控制摘要報表的敏感度，在呼叫中傳遞的貢獻次數會與特定貢獻邊界限制 (又稱為貢獻預算) 綁定。視您使用的是 Attribution Reporting API 還是 Private Aggregation API，貢獻預算會有所不同。

如要進一步瞭解如何為各 API 設定貢獻預算，請參閱下列 API 說明文件章節：

報表批次處理策略

當您匯出可匯總的報表時，請務必最佳化匯出策略，以免超出隱私權限制。如要正確匯出報表，請務必瞭解「不重複」規則和不重疊批次的概念。

「禁止重複」規則

匯總服務會強制執行「不重複」規則。這項規則指出，可匯總的報表 (由 report_id 唯一識別) 在單一批次中只能出現一次。如果每批可匯總報表出現多次，系統會將第一份報表納入匯總，並捨棄後續含有相同 report_id 的報表，然後批次便會順利完成。

這項規則也指出，同一個共用 ID 不得出現在多個批次中。如果某個共用 ID 已納入先前成功的批次，後續批次也包含相同的共用 ID 時，後續批次就會失敗。

每批資料只能使用同一份報表。
圖 1. 如果報表在一批資料中出現多次，匯總資料會納入第一個出現的報表，並捨棄後續同 ID 的報表。

如果沒有「不重複」規則，攻擊者就能在單一或多個批次中加入重複的報表副本，藉此操控批次內容，進而掌握特定批次的內容。

如要進一步瞭解如何在單一報表批次或多個報表批次中套用「不重複」規則，請參閱「報表批次中的重複報表」。

不重疊批次

為避免批次重疊，匯總服務會強制執行不重疊的批次。也就是說，兩個以上的批次不得包含共用相同共用 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"
}

定期報表的時間分別為「2024 年 2 月 19 日 9 點 8 分 10 秒」(Report1) 和「2024 年 2 月 19 日 9 點 55 分 10 秒」(Report2)。由於 scheduled_report_time 欄位的值會截斷至小時，因此兩份報表都將 1708376890 (「2024 年 2 月 19 日晚上 9 點」的編碼值) 做為 scheduled_report_time 欄位的值。

由於其他所有欄位和篩選 ID 都相同，因此兩份報表都會使用相同的共用 ID。由於兩份報表都使用相同的共用 ID，因此必須一併納入同一批次。

如果 Report1 是在先前成功的批次中進行批次處理，而 Report2 是在後續批次中處理，則含有 Report2 的批次會因 PRIVACY_BUDGET_EXHAUSTED 錯誤而失敗。發生這種情況時，請移除已在先前批次中成功匯入的共用 ID 報表，然後再試一次。如要進一步瞭解這項錯誤，請參閱「匯總服務的錯誤代碼和緩解措施」。

含有相同共用 ID 的報表應納入同一批次。
圖 2. 批次 2 包含的報表與批次 1 中的報表共用 ID，因此批次 2 會失敗。

預先宣告的匯總鍵

將批次報表提交至匯總服務時，必須同時包含從報表來源收到的可匯總報表，以及輸出網域檔案。輸出網域包含從可匯總報表擷取的鍵或分層。

從隱私權的角度來看，即使沒有實際報表與特定鍵相符，系統仍會在輸出網域中預先宣告的所有鍵中加入雜訊。指定輸出網域可防範攻擊，避免輸出內容中出現可揭露單一使用者或事件的值。舉例來說，如果您只向一位使用者放送廣告活動，輸出內容中出現的鍵會顯示使用者稍後完成轉換，即使有雜訊干擾也一樣。先指定這個網域，即可確保系統不會透露任何使用者貢獻內容。

您可以在 Attribution Reporting API 或 Private Aggregation API 中宣告這些 128 位元鍵，並使用這些鍵編碼要追蹤的維度。

系統只會將預先宣告的鍵納入匯總並列入摘要報表。摘要報表中桶的匯總值會加入統計雜訊，這會反映在建立的摘要報表中。

Aggregation Service 中的隱私權批次。
圖 3. 摘要報表只包含預先宣告的鍵 (又稱為值區)。

如果匯出網域檔案中包含匯總鍵，但未出現在批次報表中，即使匯總值為零，最終摘要報表仍可能會非零，因為系統會為了保護隱私權而加入雜訊。