汇总服务

汇总服务会根据原始可汇总报告生成摘要报告，其中包含详细的转化数据和覆盖面衡量结果。广告技术平台在客户端有两个主要汇总入口点，可通过 Attribution Reporting API 或 Private Aggregation API 将报告发送到汇总服务。

实现状态

可用性

Proposal Status
Aggregation Service support for Amazon Web Services (AWS) across Attribution Reporting API, Private Aggregation API
Explainer		 Available
Aggregation Service support for Google Cloud across Attribution Reporting API, Private Aggregation API
Explainer		 Available
Aggregation Service site enrollment and multi-origin aggregation. Site enrollment includes mapping of a site to cloud accounts (AWS, or GCP). To aggregate multiple origins, they must be of the same site.
FAQs on GitHub
Site aggregation API documentation 		Available
The Aggregation Service's epsilon value will be kept as a range of up to 64, to facilitate experimentation and feedback on different parameters.
Submit ARA epsilon feedback.
Submit PAA epsilon feedback.		 Available. We will provide advanced notice to the ecosystem before the epsilon range values are updated.
More flexible contribution filtering for Aggregation Service queries
Explainer		 Available
Process for budget recovery post-disasters (errors, misconfigurations, and so on)
Explainer		 Available
Mechanism to review the percentage of shared IDs recovered by an ad tech using budget recovery and suspend future recoveries for excessive recoveries planned for H1 2025
Accenture operating as one of the Coordinators on AWS
Developer Blog		 Available
Independent party operating as one of the Coordinators on Google Cloud
Developer blog		 Available
Aggregation Service support for Aggregate Debug Reporting on Attribution Reporting API
Explainer		 Available

关键术语和概念

如果您考虑在广告技术工作流中使用汇总服务，以下术语和概念应该能让您更深入地了解这项新的汇总流程可以为您的团队提供哪些帮助：

Term Description
Aggregation Service An ad tech-operated service that processes aggregatable reports to create a summary report.
Aggregatable Reports

可汇总报告是从各个用户设备发送的加密报告。这些报告包含有关跨网站用户行为和转化的数据。转化（有时称为归因触发器事件）和关联的指标由广告主或广告技术平台定义。每个报告都会加密，以防止多方访问基础数据。

Learn more about aggregatable reports.
Aggregatable Report Accounting A distributed ledger located in both coordinators that tracks allocated privacy budget and enforces the 'No Duplicates' rule. This is the privacy preserving mechanism, located and run within coordinators, that ensures that no report passes through Aggregation Service beyond the allocated privacy budget. Read more on batching strategies on how it relates to aggregatable reports.
Aggregatable Report Accounting Budget References to the budget that ensures reports are not processed more than once.
Trusted Execution Environment (TEE)

可信执行环境是计算机硬件和软件的一种特殊配置， 验证计算机上运行的软件的确切版本。TEEs 允许外部各方验证软件是否完全按照 软件制造商声称可以，不多或少。

如需详细了解用于 Privacy Sandbox 提案的 TEE，请参阅 Protected Audience API 服务说明文档 以及汇总服务说明。
Coordinators

协调者是负责密钥管理和可汇总报告的会计核算的实体。协调者维护已获批准的汇总服务配置的哈希列表，并配置对解密密钥的访问权限。
Shared ID Computed value that consists of: shared_info, reporting_origin, destination_site (available for Attribution Reporting API only), source_registration-time (available for Attribution Reporting API only), scheduled_report_time, version. This means that multiple reports belong to the same shared ID should they share the same attributes of the shared_info field. This plays an important role within Aggregatable Report Accounting. Read more about Trusted Servers.
Summary Report

摘要报告是一种 Attribution Reporting API 和 Private Aggregation API 报告类型。摘要报告包含汇总的用户数据，并且可能包含添加了噪声的详细转化数据。摘要报告由汇总报告组成。与事件级报告相比，摘要报告具有更大的灵活性和数据模型，尤其是对于某些应用场景（例如转化价值）。
Reporting Origin

报告来源是接收可汇总报告的实体，也就是调用 Attribution Reporting API 的广告技术平台。可汇总报告的来源 将用户设备转到与报告关联的已知网址 来源。此报告来源应在注册期间指定。
Contribution Bonding Aggregatable reports may contain an arbitrary number of counter increments. For example, a report may contain a count of products that a user has viewed on an advertiser's site. The sum of increments in all aggregatable reports related to a single source event must not exceed a given limit, `L1=2^16`. Learn more in the aggregatable reports explainer.
Noise & Scaling A certain amount of statistical noise is added to summary reports as a part of the aggregation process that also functions to preserve privacy and ensure the final reports provide anonymized measurement information. Read more about additive noise mechanism, which is drawn from Laplace distribution.
Attestation

认证是一种用于对软件身份进行身份验证的机制，通常使用加密哈希或签名。对于汇总服务方案，证明会将广告技术平台运营的汇总服务中运行的代码与开放源代码进行匹配。

Read more about attestation.

请阅读我们的说明和完整条款列表，详细了解汇总服务背后的故事。

汇总用例

我们来考虑以下广告效果衡量开发者历程及其对应的衡量客户端库。

使用场景 入口点 说明
出价优化 Attribution Reporting API （Chrome 和 Android） 使用汇总报告提取转化信号，以便进行出价优化。
跨平台衡量 Attribution Reporting API （Chrome 和 Android） 使用跨网站和应用衡量功能，了解在 Chrome 和 Android 设备上的效果。
转化报告 Attribution Reporting API （Chrome 和 Android） 根据客户的广告系列需求（包括点击型转化和浏览型转化）生成汇总的转化报告。
广告系列覆盖面衡量 Shared Storage API 和 Private Aggregation API (Chrome) 使用跨网站广告浏览变量来衡量广告系列的覆盖面。
受众特征报告 Shared Storage API 和 Private Aggregation API (Chrome) 使用跨网站广告观看和受众特征信息来按受众特征衡量覆盖面。
转化路径分析 Shared Storage API 和Private Aggregation API (Chrome) 存储跨网站广告观看和转化变量，以执行汇总的转化路径分析。
品牌提升效果和转化量提升情况 Shared Storage API 和 Private Aggregation API (Chrome) 针对测试组/对照组和投票信息生成报告，以衡量品牌提升效果和增量效果。
竞价调试 Protected Audience API 和 Private Aggregation API (Chrome) 使用汇总报告进行调试。
出价分布情况 Protected Audience API 和 Private Aggregation API (Chrome) 使用汇总报告来捕获竞价出价值的分布情况。

端到端流程

下图展示了汇总服务的运作方式。我们将着重介绍从接收来自网页和移动设备的报告到在汇总服务中创建摘要报告的端到端流程。

端到端汇总服务流

  1. 提取公钥以生成加密报告。
  2. 发送到广告技术平台服务器以进行收集、转换和分批处理的经过加密的可汇总报告。
  3. 广告技术平台服务器将报告（avro 格式）分批发送到已部署的汇总服务。（必须由广告技术平台完成）。
  4. 检索要解密的汇总报告。
  5. 从协调器检索解密密钥。
  6. 汇总服务会解密报告以进行汇总和添加噪声。
  7. 可汇总报告的会计核算服务会检查是否还有隐私预算可用于为给定的可汇总报告生成摘要报告。
  8. 提交最终摘要报告。

在该图表中，您可以看到汇总服务与主要客户端衡量 API Attribution Reporting API、Private Aggregation API 和协调者的总体关系。

该流程从不同的效果衡量 API（例如 Attribution Reporting API 或 Private Aggregation API）开始，这些 API 会从多个浏览器实例生成报告。Chrome 会从协调器中的密钥托管服务获取公钥，以便在将报告发送到广告技术平台的报告来源之前对其进行加密。公钥每 7 天轮替一次。

广告技术平台的报告来源收到这些报告后，应将报告来源配置为收集这些报告并将其转换为 avro 格式，然后发送到其部署的汇总服务实例。请参阅批处理策略。

广告技术平台准备好进行批处理后，会向汇总服务创建一个批量请求，通过从 Key Hosting Service 检索解密密钥来解密报告，然后进行汇总和添加噪声以创建摘要报告。请注意，这取决于隐私预算是否足以生成最终摘要报告。

收集报告的广告技术报告来源端点由广告技术平台托管，而汇总服务部署在广告技术平台的云中。

对可汇总报告进行批量处理

如果没有指定的报告来源服务器的帮助，报告流程将无法完成。这是广告技术平台在注册过程中提交的来源。报告来源负责执行的主要操作包括收集、转换和批量处理收到的可汇总报告，并准备将其发送到广告技术平台在 Google Cloud 或 Amazon Web Services 中部署的汇总服务。详细了解如何准备可汇总报告。

现在您已经了解了大致的概念，接下来我们详细了解一下将在汇总服务中部署的组件。

Cloud 组件

汇总服务由各种云服务组件组成。提供的 Terraform 脚本会预配和配置所有必要的云服务组件。

汇总服务云组件

前端服务

代管式云服务：Cloud Functions (Google Cloud) / API Gateway (Amazon Web Services)

前端服务是一种无服务器网关，可用作用于创建作业和检索作业状态的 Aggregation API 调用的入口点。它负责接收来自汇总服务用户的请求、验证输入参数，以及启动汇总作业调度流程。

前端服务中提供了两个 API：

端点 说明
createJob 此 API 会触发汇总服务作业。它需要包含用于触发作业的相关信息，例如作业 ID、输入存储空间详细信息、输出存储空间详细信息、报告来源等。
getJob 此 API 可返回指定作业 ID 的作业状态。它提供有关作业状态的信息，如“已收到”、“进行中”或“已完成”。此外，如果作业已完成，则会显示作业结果，包括作业执行期间遇到的所有错误消息。

查看 Aggregation Service API 文档。

作业队列

代管式 Cloud Service：Pub/Sub (Google Cloud) / Amazon SQS (Amazon Web Services)

作业队列是一个消息队列，用于存储汇总服务的作业请求。前端服务会将作业请求消息插入队列，然后汇总工作器会使用这些消息来处理作业请求。

Cloud Storage

代管式云服务：Google Cloud Storage (Google Cloud) / Amazon S3 (Amazon Web Services) Cloud Storage 用于存储汇总服务使用的输入和输出文件（例如：加密的报告文件、输出摘要报告等）。

作业元数据数据库

托管式云服务：Spanner（Google Cloud）/DynamoDB（Amazon Web Services）

作业元数据数据库可存储并跟踪汇总作业的状态。数据库会记录创建时间、请求时间、更新时间和状态（例如“已收到”“正在处理”“已完成”等）等元数据。Aggregation Worker 会随着作业的进行而更新作业元数据数据库。

聚合工作器

托管云服务：带有机密空间的 Compute Engine (Google Cloud)/带有 Nitro Enclave 的 Amazon Web Services EC2 (Amazon Web Services)

Aggregation Worker 会处理作业队列中的作业请求发起的作业请求，并使用从协调器中的密钥生成和分发服务 (KGDS) 中提取的密钥来解密已加密的输入。为了最大限度地缩短作业处理延迟时间，解密密钥会在 Aggregation Worker 中缓存 8 小时，可用于该工作器实例处理的作业。

工作器在可信执行环境 (TEE) 实例中运行。每个工作器一次仅处理一项作业。广告技术平台可以通过设置自动扩缩配置来配置多个工作器以并行处理作业。通过自动扩缩，系统会根据作业队列中剩余的消息数量动态调整工作器数量。您可以通过 Terraform 环境文件来配置自动扩缩的工作器数量下限和上限。如需详细了解自动扩缩，请参阅以下 Terraform 脚本。[Amazon Web Services / Google Cloud]

Aggregation Worker 会调用 Aggregatable Report Accounting 服务以进行可汇总的报告核算。可汇总的报告会计服务可确保仅在未超出隐私预算限制时运行作业。（请参阅“无重复”规则）。如果预算可用，系统会使用噪声汇总生成摘要报告。详细了解可汇总报告的会计核算。

汇总工作器会更新作业元数据库中的作业元数据，包括适当的作业返回代码和报告错误计数器（如果部分报告失败）。用户可以使用作业状态检索 API (getJob) 提取状态。

有关汇总服务的详细说明，请参阅我们的说明。

后续步骤

现在，您已了解聚合服务的亮点，接下来您可以通过 Google Cloud 或 Amazon Web Services 部署您自己的聚合服务实例，请查看使用入门部分；如果您需要详细了解如何运行已部署的聚合服务，请点击此链接，详细了解如何操作聚合服务。

问题排查

如需详细了解错误消息、可能导致您遇到的错误的原因，以及采取缓解措施的后续步骤，请参阅我们的常见错误代码和缓解措施文档。

获取支持和提供反馈