Wiki · Concept · Last reviewed June 25, 2026

Aggregation Service

Aggregation Service is Privacy Sandbox infrastructure for processing encrypted aggregatable reports into summary reports without exposing raw per-user reports to ordinary ad-tech systems.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: browser privacy, ad measurement, aggregation, TEE, surveillance

Definition

Aggregation Service is the Privacy Sandbox service layer that processes aggregatable reports and returns summary reports. Google describes it as a way for ad-tech operators to measure campaign performance across sites without relying on cookies or other tracking methods. It belongs beside the Attribution Reporting API and Private Aggregation API, which can generate the encrypted reports that the service later aggregates.

The service is not a browser API by itself. It is cloud infrastructure, operated by an enrolled ad-tech party, that receives encrypted report batches and runs approved aggregation code in a trusted execution environment. The output is a summary report for campaign analysis, reach measurement, conversion measurement, or related aggregate reporting.

As of the Google documentation reviewed for this page, Aggregation Service is described as generally available to ad techs, with support for Amazon Web Services and Google Cloud across Attribution Reporting and Private Aggregation use cases. That status should not be generalized into a claim that all browsers, jurisdictions, or advertising systems use it.

Mechanism

The basic flow is report generation, collection, batching, secure processing, and summary output. A browser or Android device creates encrypted aggregatable reports through a supported Privacy Sandbox API. The reporting origin stores reports, batches them, and sends a job to the Aggregation Service. Google documentation says the service processes those reports in a trusted execution environment and produces summary reports from raw aggregatable reports.

The WICG Attribution Reporting TEE design explains the security premise: decryption and aggregation happen inside an isolated environment, while attestation checks that the ad-tech-operated service is running approved code before it receives decryption keys. Privacy Sandbox coordinator services provide key management, aggregatable report accounting, and attestation support.

The public repository for privacysandbox/aggregation-service contains instructions and scripts for setup and testing locally and in cloud deployments. Google's enrollment documentation says access to Privacy Sandbox relevance and measurement APIs requires developer enrollment, and that some services require additional information such as cloud-provider details.

Agent Context

Aggregation Service matters for AI Browsers and Computer Use because browser agents can create the activity that later becomes aggregate evidence. An agent might view ads, load embedded frames, compare products, trigger conversions, or run repeated tests. Those actions can contribute to a summary report even when no ordinary page script receives a raw per-user record.

For agent governance, the distinction between raw data and aggregate output is necessary but incomplete. A summary report still influences bidding, targeting, budget allocation, fraud controls, dashboards, and product decisions. Agent logs should record when automated browsing contributed to measurement, and separate the user's delegated task from the advertising system's inferred signal.

Governance Use

A serious deployment record should name the reporting origins, APIs that generated reports, batching rules, cloud provider, TEE technology, aggregation code version, coordinator, key-management path, report-accounting controls, privacy budget, epsilon configuration, filtering rules, debug-report settings, retention period, and recovery process for misconfigured or failed jobs.

Governance should also name the downstream decision. A summary report used for billing has different consequences from one used for ad optimization, audience analysis, fraud detection, model training, or executive performance reporting. Aggregation is a privacy control, not a purpose limitation.

Limits

Aggregation Service does not prove consent, fairness, accuracy, data minimization, or lawful processing. It prevents certain parties from reading raw encrypted inputs during the intended workflow, but it still creates a measurable output for institutional use. The governance question shifts from "who saw the individual report?" to "who defined the buckets, who received the summary, and what decisions did it justify?"

TEE and coordinator designs also introduce their own trust surface. Operators must depend on approved binaries, attestation, cloud configuration, coordinator availability, key management, batch uniqueness, budget accounting, and incident response. A system can be technically aggregated while still being socially opaque.

Review Record

Source Discipline

Claims about service availability, supported clouds, setup, batching, epsilon range, and Privacy Sandbox enrollment should cite Google Privacy Sandbox documentation. Claims about TEE design and attestation should cite the WICG Attribution Reporting TEE document. Claims about operator obligations, coordinator functions, approved code, key management, and report accounting should cite the Coordinator Service terms. Claims about actual deployments require operator evidence, not only platform documentation.

Spiralist Reading

Spiralism reads Aggregation Service as the institutionalization of privacy-preserving measurement. It narrows one dangerous pipe: raw person-level reports. But it also preserves the premise that behavior should become campaign evidence. The service deserves neither dismissal nor reverence. It deserves an audit trail: the bucket, the budget, the coordinator, the cloud, the recipient, and the decision made from the summary.

Sources

Return to Wiki