匯總服務會根據原始可匯總報表，產生詳細轉換資料和觸及評估的摘要報表。為確保使用者資料的隱私權和安全性，匯總服務採用支援差異化隱私 (DP) 的架構，量化並限制這些報表揭露的個別使用者資訊量。
本指南將討論相關工具和策略，協助您建立可匯總的報表，確保個別使用者的資料安全無虞：
加入雜訊的摘要報表
匯總服務會根據您批次處理的可匯總報表，建立摘要報表。這份摘要報表會匯總所有預先定義網域金鑰的所有貢獻，並加入統計雜訊。
報表新增的干擾與匯總報表數量、個別報表值或匯總報表值無關。雜訊是從 Laplace 分布的離散版本中擷取，並根據用戶端強制執行的貢獻預算 (L1 敏感度) 進行調整，而貢獻預算取決於對應的 Measurement API 和隱私權參數 epsilon。
如要進一步瞭解雜訊及其對報表資料的影響，請參閱「瞭解摘要報表中的雜訊」。
捐款預算
如要控管摘要報表的敏感度，在呼叫中傳遞的貢獻數會與特定貢獻界限 (也稱為貢獻預算) 相關聯。視您使用 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 (適用於 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。在本例中，「報表 1」和「報表 2」共用資訊欄位。這兩份報表具有相同的 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 點 08 分 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 報表，然後再試一次。如要進一步瞭解這項錯誤，請參閱「匯總服務的錯誤代碼和解決方法」。
預先宣告的匯總鍵
向匯總服務提交批次時，必須同時包含從報表來源收到的可匯總報表，以及輸出網域檔案。輸出網域包含從可匯總報表擷取的鍵或值區。
就隱私權而言，即使沒有與特定鍵相符的實際報表，系統也會在輸出網域中預先宣告的所有鍵中加入雜訊。指定輸出網域可防範攻擊，避免輸出中的鍵值洩漏單一使用者或事件的相關資訊。舉例來說，如果您只向一位使用者放送廣告活動，即使加入雜訊，輸出內容中收到金鑰仍會顯示該使用者稍後完成轉換。先指定這個網域，可確保不會洩漏任何使用者貢獻內容的資訊。
您可以在 Attribution Reporting API 或 Private Aggregation API 中宣告這些 128 位元金鑰，並用來編碼要追蹤的維度。
系統只會匯總預先宣告的鍵，並將其納入摘要報表。摘要報表中各區間的匯總值已加入統計雜訊，因此建立的摘要報表會反映這項變更。
如果輸出網域檔案中包含匯總鍵，但批次報表中沒有，即使匯總值為零，最終摘要報表也可能不為零，因為系統會加入雜訊來保護隱私權。