可汇总报告的隐私保护措施

汇总服务可根据原始的可汇总报告生成详细转化数据和覆盖面指标的摘要报告。为确保用户数据的私密性和安全性，汇总服务使用支持差分隐私 (DP) 的框架来量化和限制这些报告中有关个别用户的信息量。

本指南将讨论用于创建可汇总报告的工具和策略，这些报告有助于确保有关个别用户的数据安全无虞：

• 创建添加了噪声的摘要报告
• 设置贡献预算
• 报告批处理策略
  • 批量处理重复报告
  • 处理具有共同共享 ID 的报告
• 使用预声明的聚合键

添加了噪声的摘要报告

当您批量处理可汇总的报告时，汇总服务会创建摘要报告。此汇总报告是所有预定义网域键的所有贡献的汇总，并添加了统计噪声。

添加到报告中的噪声不取决于汇总的报告数量、单个报告值或汇总的报告值。噪声是从离散版 Laplace 分布中抽取的，并根据客户端强制执行的贡献预算（L1 敏感度）进行缩放，该预算取决于相应的衡量 API 和隐私参数 epsilon。

如需详细了解噪声及其对报告数据的影响，请参阅了解摘要报告中的噪声。

贡献预算

为了控制摘要报告的敏感度，在调用中传递的贡献数量与特定的贡献边界限制（也称为贡献预算）相关联。贡献预算因您使用的是 Attribution Reporting API 还是 Private Aggregation API 而异。

如需详细了解如何为每个 API 设置贡献预算，请参阅以下 API 文档部分：

• Attribution Reporting API 贡献边界和预算
• Private Aggregation API 贡献限额
• Private Aggregation 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 位密钥，并使用它们来编码您要跟踪的维度。

只有预先声明的键才会被纳入汇总范围，并包含在摘要报告中。总结报告中各个分桶的汇总值添加了统计噪声，这会反映在生成的总结报告中。

如果输出网域文件中包含某个汇总键，但该键不在批次报告中，即使汇总值为零，最终的摘要报告也可能不为零，因为为了保护隐私而添加了噪声。