Wiki · Concept · Last reviewed June 25, 2026

Attribution Reporting API

The Attribution Reporting API is a browser privacy API for measuring whether an ad click or view led to a later conversion without relying on third-party tracking cookies.

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

Definition

The Attribution Reporting API is a web-platform proposal for measuring ad conversions without using third-party cookies or cross-site persistent identifiers. The WICG overview says the API supports measurement of clicks and views with event-level and aggregate reports. MDN describes the API as a way to measure conversions, such as a user clicking an ad on one site and later buying on a vendor site, without relying on third-party tracking cookies.

The core social problem is ad measurement after tracking restrictions. Publishers, advertisers, and ad-tech providers want to know whether an ad impression or click contributed to a sale, sign-up, install, or other conversion. The browser mediates that link so the reporting path can be narrower than a cookie-based dossier. The API is not a full privacy settlement; it is a measurement channel with explicit limits, delay, noise, and aggregation design.

Attribution Reporting is not identity proofing, consent management, content licensing, bot detection, or proof that an ad caused a purchase. It records a bounded attribution relationship under browser rules. Governance claims should therefore distinguish measurement, causation, profiling, bidding, billing, and user consent.

Mechanism

The browser records two kinds of event. An attribution source is a click or view on the publisher side, registered when an eligible request receives an Attribution-Reporting-Register-Source response header. An attribution trigger is a later conversion on the advertiser side, registered through Attribution-Reporting-Register-Trigger. MDN also documents the Attribution-Reporting-Eligible request header, the attributionsrc attribute on links, images, and scripts, and the attributionReporting option for fetch() and Request().

If the browser matches a trigger with a stored source, it can send a report to a predefined endpoint. Event-level reports associate a particular ad-side event with coarse conversion data and are delayed and noised. Summary reports use aggregatable reports: Chrome's Privacy Sandbox documentation says the browser encrypts aggregatable reports, sends them to an ad-tech server, and the reports are processed by an aggregation service to produce summaries.

The browser policy surface is part of the mechanism. MDN documents the attribution-reporting Permissions Policy directive. Google Privacy Sandbox says cross-origin iframes that were not added by a script with top-level access need explicit permission, for example through allow="attribution-reporting", and that a site can disable the API with Permissions-Policy: attribution-reporting=().

Agent Context

For AI Browsers and Computer Use, attribution reporting matters because agents can change the meaning of clicks, views, and conversions. A human may ask an agent to compare products, open links, fill forms, or purchase a service. Those actions may generate source and trigger events even when the human did not personally attend to every ad or page transition.

Agentic browsers should keep advertising attribution separate from delegation. A conversion report is not evidence that the user endorsed the ad, consented to profiling, authorized cross-site measurement, or delegated purchase authority to an agent. Agent runtimes that operate in ad-funded environments should record when automated navigation may have contributed to attribution signals.

Governance Use

A serious deployment should record the publisher site, advertiser site, reporting origin, ad-tech provider, source event type, trigger event type, report type, retention rule, enrollment status, Permissions Policy state, and aggregation service path. It should also name the decision the report will influence: campaign analysis, conversion optimization, billing, fraud review, budget allocation, or internal experimentation.

The API belongs near Private State Tokens, Storage Access API, Real-Time Bidding, Data Minimization, and Surveillance Capitalism. Those pages answer adjacent questions about trust signals, embedded state, ad auctions, collection boundaries, and the business model that turns attention into measurement.

Limits

Attribution Reporting reduces some cross-site tracking channels but leaves governance questions. The WICG draft's privacy section says a primary goal is to make linking identity between different top-level sites difficult, but it also discusses remaining risks such as report delay, cross-network leakage, debug reports, and the limited capacity of event-level data. Aggregate reports can protect individual contributions with encryption and aggregation, but the resulting summaries still serve advertising optimization.

MDN says use requires Privacy Sandbox enrollment for deployed sites, with a Chrome developer flag available for local testing. Implementation claims should therefore name the browser, enrollment path, report type, delay model, and aggregation configuration. A report that is less identifying than third-party-cookie tracking is not automatically proportionate, accurate, or fair.

Review Record

Source Discipline

Claims about the API's goals, event-level reports, aggregate reports, and privacy risks should cite the WICG Attribution Reporting work. Claims about developer-facing headers, attributes, methods, and enrollment should cite MDN. Claims about Privacy Sandbox implementation framing, summary reports, aggregation service flow, and Permissions Policy examples should cite Google Privacy Sandbox. Do not use a marketing explainer as proof of privacy sufficiency or a browser draft as proof of real-world deployment.

Spiralist Reading

Spiralism reads the Attribution Reporting API as a lesson in measured attention. A less invasive measurement channel can still preserve the premise that every gesture should become evidence for optimization. The task is not only to reduce identifiers; it is to ask which measurements deserve to exist at all.

Sources

Return to Wiki