Wiki · Concept · Last reviewed June 25, 2026

Private Aggregation API

The Private Aggregation API was a Privacy Sandbox mechanism for producing aggregate reports from cross-site worklets without exposing the underlying per-user data to ordinary page JavaScript.

Category: Concept Updated: June 25, 2026 Tags: browser privacy, aggregation, ad measurement, worklets, surveillance

Definition

The Private Aggregation API was a browser proposal for measuring aggregate, cross-site data in a privacy-preserving way. The PATCG draft says potentially identifying cross-site data is placed into encrypted aggregatable reports that can only be processed by an aggregation service, where noise and query limits are applied. Google Privacy Sandbox describes the API as a way to generate aggregate data reports from Shared Storage API and Protected Audience API contexts.

The problem was not ordinary analytics. It was measurement from isolated contexts that can see cross-site information but should not reveal raw per-user values. Examples include ad reach, demographic summaries, frequency measurement, conversion-adjacent diagnostics, and A/B outcomes produced from worklets. Private Aggregation tried to move the answer from "tell me what this user did" to "contribute a bounded value to a later aggregate."

Status changed in 2025. Chrome Platform Status lists a plan to deprecate and remove the API, and the blink-dev intent says it was originally designed for a future without third-party cookies. The entry should therefore be read as a record of a discontinued Privacy Sandbox design, not as a stable cross-browser standard.

Mechanism

The core call was a contribution from an isolated context to a histogram. Google documentation shows worklet code calling privateAggregation.contributeToHistogram() with a bucket and value. The bucket is the dimension being counted, and the value is the contribution to that bucket. The browser packages those contributions into an aggregatable report rather than returning the raw result to the embedding page.

Reports were intended to be encrypted, collected by an ad-tech reporting origin, batched, and processed by an Aggregation Service. Google describes that service as operating in a trusted execution environment and producing summary reports from encrypted aggregatable reports. The PATCG draft also discusses contribution limits, aggregation coordinator choice, and restrictions intended to prevent a caller from using aggregation as a covert per-user channel.

The mechanism sat between other APIs. Shared Storage could use Private Aggregation through the run() output gate. Protected Audience could use it for aggregate auction reporting. Attribution Reporting API used a related summary-report path through aggregation infrastructure, but its source/trigger model was separate.

Agent Context

For AI Browsers and Computer Use, Private Aggregation matters because an agent can produce the actions that become aggregate measurements. A shopping agent, research assistant, or testing bot might view ads, click offers, load embedded frames, or trigger worklet paths. Those actions may contribute to summary reports without creating a visible per-user log entry in the page.

Agent logs should separate user intent from measurement contribution. A bucketed aggregate does not show the agent's reasoning, the human's consent, or the downstream decision made from the summary. If an agent operates in an ad-funded surface, the audit record should name when automated navigation could have contributed to aggregate measurement.

Governance Use

A deployment record should name the top-level site, worklet origin, calling API, reporting origin, aggregation service operator, coordinator, bucket design, value scale, contribution limits, report delay, batching rule, noise setting, retention, debug path, enrollment status, and removal fallback. It should also state the purpose: reach, frequency, demographic summary, experiment result, fraud signal, or another aggregate metric.

The API belongs near Shared Storage API, Attribution Reporting API, Protected Audience API, Real-Time Bidding, and Data Minimization. These pages separate hidden storage, conversion measurement, ad auctions, market machinery, and collection limits.

Limits

Private Aggregation was not consent, anonymity, fairness, or proof that a measurement should exist. It reduced access to raw cross-site data by turning individual contributions into encrypted reports and noisy summaries. But the aggregate can still drive ad optimization, market segmentation, product decisions, fraud models, and resource allocation. A private pipe can still feed a coercive dashboard.

Aggregation also creates design risk. Poor bucket design, small cohorts, repeated queries, debugging features, and downstream joins can weaken privacy. The aggregation service and coordinator become new governance surfaces. The planned deprecation is a second limit: an audit should not treat a discontinued browser feature as available infrastructure.

Review Record

Source Discipline

Claims about aggregatable reports, encryption, contribution limits, and aggregation coordinator design should cite the PATCG draft. Claims about worklet use, buckets, values, Shared Storage and Protected Audience integration, and developer workflow should cite Google Privacy Sandbox. Claims about Aggregation Service processing should cite Google's Aggregation Service documentation. Claims about deprecation should cite Chrome Platform Status and blink-dev.

Spiralist Reading

Spiralism reads Private Aggregation as a lesson in statistical power. A system can stop exposing the single person and still make the crowd legible enough to steer. That is not automatically bad; aggregate knowledge can reduce harm and waste. But it should make governance sharper, not softer. The question is who chooses the buckets, who receives the summaries, and who lives under decisions made from them.

Sources

Return to Wiki