匯總服務會根據原始可匯總報表,產生詳細轉換資料和觸及評估的摘要報表。為確保使用者資料的隱私和安全性,匯總服務會使用支援差異化隱私 (DP)的架構,量化並限制這些報表揭露的個別使用者資訊量。
本指南將說明建立可匯總的報表所需的工具和策略,協助您保護個別使用者的資料安全:
含有雜訊的摘要報表
當您將可匯總報表批次處理時,匯總服務會建立摘要報表。這份摘要報表是所有預先定義網域鍵的所有貢獻總和,並加入統計雜訊。
報表中新增的雜訊不會受到匯總報表數量、個別報表值或匯總報表值的影響。雜訊會從 Laplace 分布的離散版本繪製,並根據對應的評估 API 和隱私權參數 epsilon
,由用戶端強制設為貢獻預算 (L1
敏感度)。
如要進一步瞭解雜訊及其對報表資料的影響,請參閱「瞭解摘要報表中的雜訊」。
貢獻預算
為控制摘要報表的敏感度,在呼叫中傳遞的貢獻次數會與特定貢獻邊界限制 (又稱為貢獻預算) 綁定。視您使用的是 Attribution Reporting API 還是 Private Aggregation API,貢獻預算會有所不同。
如要進一步瞭解如何為各 API 設定貢獻預算,請參閱下列 API 說明文件章節:
報表批次處理策略
當您匯出可匯總的報表時,請務必最佳化匯出策略,以免超出隱私權限制。如要正確匯出報表,請務必瞭解「不重複」規則和不重疊批次的概念。
「禁止重複」規則
匯總服務會強制執行「不重複」規則。這項規則指出,可匯總的報表 (由 report_id
唯一識別) 在單一批次中只能出現一次。如果每批可匯總報表出現多次,系統會將第一份報表納入匯總,並捨棄後續含有相同 report_id
的報表,然後批次便會順利完成。
這項規則也指出,同一個共用 ID 不得出現在多個批次中。如果某個共用 ID 已納入先前成功的批次,後續批次也包含相同的共用 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 報表,然後再試一次。如要進一步瞭解這項錯誤,請參閱「匯總服務的錯誤代碼和緩解措施」。

預先宣告的匯總鍵
將批次報表提交至匯總服務時,必須同時包含從報表來源收到的可匯總報表,以及輸出網域檔案。輸出網域包含從可匯總報表擷取的鍵或分層。
從隱私權的角度來看,即使沒有實際報表與特定鍵相符,系統仍會在輸出網域中預先宣告的所有鍵中加入雜訊。指定輸出網域可防範攻擊,避免輸出內容中出現可揭露單一使用者或事件的值。舉例來說,如果您只向一位使用者放送廣告活動,輸出內容中出現的鍵會顯示使用者稍後完成轉換,即使有雜訊干擾也一樣。先指定這個網域,即可確保系統不會透露任何使用者貢獻內容。
您可以在 Attribution Reporting API 或 Private Aggregation API 中宣告這些 128 位元鍵,並使用這些鍵編碼要追蹤的維度。
系統只會將預先宣告的鍵納入匯總並列入摘要報表。摘要報表中桶的匯總值會加入統計雜訊,這會反映在建立的摘要報表中。

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