為保護資料的私密性與安全性，匯總服務採用支援差異化隱私 (DP) 的架構。工具和機制用於量化及限制個別使用者的資訊量。讓我們來討論其中幾項隱私權防護措施。
在摘要報表中加入雜訊
廣告技術將可匯總報表批次處理後，匯總服務會建立摘要報表。摘要報表是所有預先定義的網域鍵貢獻的匯總，並加入統計雜訊。
在報表中加入雜訊，不會影響報表匯總值、個別報表值或匯總報表值的數量。
雜訊是從 Laplace 分配函式的離散版本中擷取，並依據用戶端依據對應的評估 API 和隱私權參數 epsilon 強制執行的貢獻預算 (L1 敏感度) 進行縮放。進一步瞭解噪音。
貢獻範圍界定
視使用的評估用戶端 API (Attribution Reporting API 或 Private Aggregation API) 而定，呼叫傳遞的貢獻數量會有特定貢獻限制，以控制摘要報表的機密程度。
如要進一步瞭解每個 API 的貢獻預算，請參閱各 API 的下列章節：
「沒有重複」規則
規則指出，可匯總報表 (由 report_id 唯一識別) 在單一批次中只能出現一次。如果可匯總報表在每個批次中出現超過一次，匯總中就會包含第一份報表，並捨棄含有相同 report_id 的後續報表。該批次會順利完成。
這項規則也指明，同一份報表不能出現在多個批次中。如果報表已在先前的批次中成功匯入，則後續批次就無法再匯入該報表。後者批次會以失敗告終。
如未設定這些規則，攻擊者就能在單一或多個批次中加入報表的副本，藉此操控批次內容，進而深入瞭解特定批次的內容。
匯總服務引入的另一個概念是其中一個不相交批次。也就是說，兩個以上的批次不應有共用相同共用 ID 的報表。
共用 ID 是從可匯總報表的 shared_info 欄位收集的資料組合。以下是 shared_info 欄位的範例。我們可以看到 API、version、attribution_destination (適用於 Attribution Reporting)、reporting_origin、scheduled_report_time 和 source_registration_time (用於 Attribution Reporting)。除了 report_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。
請參考以下範例，瞭解兩份報表如何共用相同的共用 ID。以下是 Report1 和 Report2 的「分享資訊」欄位範例。
兩份報表都使用相同的 API、版本、attribution_destination、reporting_origin 和 source_registration_time。由於 report_id 不屬於共用 ID，因此我們可以忽略這項差異。唯一的差別為 scheduled_report_time。進一步調查時，Report1 的 scheduled_report_time 為 February 19, 2024 9:08:10 PM，Report2 的 scheduled_report_time 則為 February 19, 2024 9:55:10 PM。由於 scheduled_report_time 會截斷至小時，因此我們可以看到兩份報表都將 February 19, 2024 9 PM 設為 scheduled_report_time。由於所有欄位都相同，我們可以確認兩份報表具有相同的共用 ID。
觀察 scheduled_report_time。
| Report1 共用資訊 | Report2 共用資訊 |
|---|---|
| "shared_info": { | "shared_info": { |
| "API": "attribution-reporting", | "API": "attribution-reporting", |
| "attribution_destination": "https://shop.dev", | "attribution_destination": "https://shop.dev", |
| "report_id": "5b052748-...", | "report_id": "1a1b25aa-...", |
| "reporting_origin": "https://dsp.dev", | "reporting_origin": "https://dsp.dev", |
| "scheduled_report_time": "1708376890", | "scheduled_report_time": "1708379710", |
| "source_registration_time": "0", | "source_registration_time": "0", |
| "version": "0.1" | "version": "0.1" |
| } | } |
確認兩份報表都具有相同的共用 ID 後，您必須將兩份報表納入同一批次。
如果 Report1 在先前成功的批次中進行批次處理，而 Report2 則在後續批次中處理，則含有 Report2 的批次會失敗，並顯示 PRIVACY_BUDGET_EXHAUSTED 錯誤。如果發生這種情況，請移除在先前批次中成功批次處理的共用 ID 的報表，然後再試一次。
如要進一步瞭解批次處理，請參閱批次處理策略指南。
預先宣告匯總鍵
將批次提交至匯總服務時，必須同時包含從報表來源收到的可匯總報表，以及輸出網域檔案。輸出網域包含從可匯總報表擷取的鍵或值區。
從隱私權的角度來看，即使沒有實際報表與特定鍵相符，系統仍會在輸出網域中預先宣告的所有鍵中加入雜訊。指定輸出網域可防範攻擊，避免輸出內容中出現可揭露單一使用者/事件的值。舉例來說，如果您只向一位使用者放送廣告活動，在輸出內容中收到一個鍵 (即使有雜訊)，就表示該使用者稍後完成轉換。透過指定網域，我們可以確定該網域不會揭露任何使用者貢獻內容。
鍵或值區是廣告技術透過 Attribution Reporting API 或 Private Aggregation API 宣告的 128 位元鍵。廣告技術可以使用這些鍵來為要追蹤的維度編碼。
系統只會將預先宣告的鍵視為匯總作業，並納入摘要報表。在摘要報表中，值區的匯總值會加入統計雜訊，並反映在已建立的摘要報表中。
基本上，如果匯出網域檔案中包含匯總鍵，但該鍵並未出現在任何批次報表中，即使匯總值為零，最終摘要報表的值也可能不會為零，因為系統會加入雜訊來保護隱私權。
請注意，本文撰寫時將考慮名為「金鑰探索」的功能。索引鍵探索功能可讓廣告技術處理可匯總的檔案，不必事先宣告鍵，但為了在先前提到的情境中保護隱私權，系統會執行額外的門檻步驟。