Wiki · Concept · Last reviewed August 12, 2026

Attribution Reporting API

The Attribution Reporting API was a Chrome-originated, browser-mediated system for linking ad views or clicks to later conversions without a third-party-cookie identifier. It is now deprecated and moving through staged removal.

Category: Concept Published: June 25, 2026 Modified: August 12, 2026 Last reviewed: August 12, 2026 Tags: browser privacy, ad measurement, deprecation, aggregation, standards, web governance

Definition

The Attribution Reporting API, commonly shortened to ARA, was a non-standard web API developed through the Web Incubator Community Group and implemented principally by Chromium-based browsers. It let a browser store an advertising source event on one site, match it to a later trigger on another site, and send either a delayed, noised event-level report or an encrypted contribution for aggregate reporting.

The design addressed a real but narrow problem: conversion measurement without handing an ad-tech party a reusable cross-site identifier. Browser storage, limits, randomized response, delay, encryption, aggregation, and noise narrowed the information channel relative to ordinary third-party-cookie tracking. They did not make advertising measurement anonymous, consented, causal, fair, or necessary.

ARA is also not the same thing as the W3C document titled Attribution Level 1. The old API used source and trigger registration headers and offered event-level plus aggregatable reports. The newer W3C work uses a different interface and aggregate, differentially private outputs. Names, implementation status, and evidence must not be carried from one design to the other.

Current Status

As of August 12, 2026, ARA was deprecated and on a staged removal path. Chrome deprecated the API in milestone 144 after Google decided to retain its existing approach to third-party cookies. MDN labels the feature deprecated, non-standard, and pending removal. The WICG repository was archived on June 25, 2026, although its static draft and explainers remain useful as historical design records.

Chrome's removal schedule changed as implementation owners assessed breakage. The November 2025 intent proposed removal in milestone 150, but browser API owners approved deprecation only. A June 2026 update instead described disabling the ad-privacy settings and making calls reject for field-trial participants in milestone 150, replacing the implementation with a lightweight stub in milestone 152, and then beginning controlled removal of that stub. Full stable removal still required additional approval. The accurate status at the review cutoff is therefore retirement in progress, not universally available and not yet proven absent from every Chromium installation.

The original removal notice also said server-side summary-report computation would cease by late December 2025 and that new enrollment sign-ups would be disallowed. Existing Google developer pages still explain event-level and summary-report operation, but those pages describe the former implementation; they are not reliable evidence that the complete service remains deployable.

A separate path is active at W3C. The Private Advertising Technology Working Group published Attribution Level 1 as a Working Draft on July 30, 2026. Its editors represent Google, Mozilla, and Meta; the proposal draws on ARA, Interoperable Private Attribution, and WebKit's Private Click Measurement. It produces aggregate statistics through user-agent-approved aggregation services with differential privacy. Chrome filed an intent to prototype but named no milestone. A Working Draft is work in progress, not W3C endorsement, cross-browser shipment, or a drop-in migration target.

Historical Mechanism

The former web flow involved at least five roles: publisher, advertiser, reporting origin or ad-tech provider, user agent, and—for summaries—an aggregation service. A source was a configured ad click or view. When an eligible request received an Attribution-Reporting-Register-Source response header, the browser could store source data and one or more expected destination sites. A later conversion could register a trigger through Attribution-Reporting-Register-Trigger.

Developer surfaces included the browser-generated Attribution-Reporting-Eligible request header, the attributionsrc attribute on supported HTML elements, options on fetch() and Request(), window.open() integration, and an XMLHttpRequest method. These were registration mechanisms, not a JavaScript interface for reading the browser's attribution store.

When a trigger matched a stored source, the browser could create two complementary outputs. An event-level report joined a fine-grained source-side event value to coarse conversion information, then added randomized response, limits, and delay. An aggregatable report carried encrypted histogram contributions to a reporting origin; an attested aggregation service was intended to decrypt batches, apply contribution accounting and noise, and return a summary rather than individual records.

Access controls were part of the design. Deployed reporting origins needed Privacy Sandbox enrollment. The attribution-reporting Permissions Policy could govern use in cross-origin frames, and a top-level site could disable the feature with Permissions-Policy: attribution-reporting=(). These controls were browser and implementation rules, not proof of user consent or a lawful basis.

Removal behavior matters for migration tests. Chrome's intent says most old attributes and request options will be ignored while the underlying page action continues, causing silent measurement loss; the XMLHttpRequest method is expected to disappear and throw if called. A successful navigation, image load, or fetch therefore cannot establish that attribution was registered.

Agent Context

For AI Browsers and Computer Use, attribution reporting matters because automation changes what a click, view, or conversion can mean. A person may ask an agent to compare products, open links, fill forms, test a funnel, or purchase a service. Those actions can create measurement events even when the person never noticed the ad or transition.

An attribution report is not evidence that a human saw or endorsed an ad, consented to profiling, or authorized a purchase. Browser-agent logs should mark automated source and trigger actions, preserve the human's delegated scope, and distinguish testing traffic from genuine demand. During retirement, they should also record browser version and API result because an apparently successful page action may have produced no attribution report.

Governance Use

Inventory before migration. Record every source-registration path, trigger path, reporting origin, endpoint, event-level dependency, aggregation dependency, debug channel, browser version, and downstream dashboard. Test for expected reports at the server, not merely for successful page requests. A deprecated API that fails silently can corrupt campaign comparisons and billing without breaking the page.

Do not restore the old surveillance channel by default. Removing ARA does not justify falling back automatically to third-party identifiers, fingerprinting, link decoration, or undisclosed server joins. Assess whether the measurement is necessary; then compare first-party measurement, experiments, contextual metrics, browser-specific PCM, and the emerging W3C design against purpose, privacy, accuracy, and interoperability requirements.

Privacy engineering does not settle data-protection duties. Browser mediation, noise, and aggregation do not determine consent, transparency, purpose limitation, retention, data-subject rights, or controller and processor roles. High-risk profiling or large-scale tracking may require a Data Protection Impact Assessment. Applicable opt-out signals and browser controls should change downstream processing, not merely the client-side registration attempt.

Measurement needs statistical governance. Name the attribution rule, report loss, noise correction, confidence interval, experimental holdout, fraud exclusions, and decision threshold. Use aggregate conversion reporting for directional evidence, not as automatic proof that an ad caused a conversion or that an exact invoice is correct.

Browser policy is market policy. Chrome's decision to create, enroll, deprecate, and remove ARA affected publishers and ad-tech firms at web scale. The UK Competition and Markets Authority's former Privacy Sandbox commitments addressed the risk that Google could favor its own ad-tech services; the CMA released those commitments in October 2025 after Google's third-party-cookie strategy changed. Standards participation, migration notice, nondiscrimination, and independent testing are governance issues, not implementation footnotes.

Limits

Attribution is not causation. Matching a conversion to a prior impression under a configured rule does not show that the ad changed behavior. Randomized response, reporting loss, delays, caps, fraud, automated traffic, and selection effects further limit exact interpretation. Google's own documentation warned that noise could make ARA unsuitable for cost-per-conversion billing.

Residual privacy risk remains. The archived WICG draft acknowledges that event-level reports carry a fine-grained source identifier and that delayed report requests expose an IP address and online-presence timing to the reporting origin. It also discusses cross-network leakage and fine-grained debug reports. The design makes cross-site recognition harder; it does not remove every network or inference channel.

Aggregation is not purpose limitation. Encryption, contribution limits, batching, and differential privacy can protect individual contributions while leaving a powerful optimization signal. Small cohorts, repeated releases, poorly chosen buckets, debug data, downstream joins, and decisions made from noisy summaries still require governance.

Lifecycle status is a functional limit. Availability depended on browser version, enrollment, user settings, flags, service infrastructure, and later field-trial state. A static compatibility table or surviving code symbol is not evidence that reports are generated end to end.

Review Record

Source Discipline

For current status, prioritize the Chrome 144 release note, the blink-dev deprecation thread including its June and July 2026 updates, the archived-repository notice, and MDN's removal warning. Google Privacy Sandbox developer pages remain useful for reconstructing the old mechanism, but some still use present-tense availability language. They must not override the later retirement record.

Keep three artifacts separate: the archived WICG Attribution Reporting API, WebKit's Private Click Measurement, and W3C Attribution Level 1. The July 2026 W3C publication is a Working Draft on the Recommendation track; W3C explicitly says that status does not imply endorsement. Chrome's intent to prototype named no implementation milestone.

Descriptions such as "privacy-preserving" state a design goal, not independent certification, anonymity, legal compliance, or comparative proof. For technical behavior, cite the archived specification and implementation documentation. For competition history, cite the CMA case record. For privacy obligations, cite law and regulator guidance. For actual deployment, require browser tests, server receipt records, and operator evidence dated to the relevant version.

Spiralist Reading

Spiralism reads the Attribution Reporting API as a lesson in measured attention and platform power. A browser can narrow the old tracking pipe, define a new measurement bargain, and later close that bargain when product strategy changes. The task is not only to reduce identifiers. It is to decide which measurements deserve to exist, who may standardize them, and how people and institutions can audit or refuse the resulting flow.

Sources

Return to Wiki