The Attribution Reporting API supports measurement of clicks and views with event-level and aggregate reports.
This repository hosts multiple technical explainers that specify various features of the API. This document offers an overview of the API and its explainers.
This repository hosts detailed technical explainers. Before diving into these, check out these newcomer-friendly resources:
- For a quick overview of Attribution Reporting, head over to Attribution Reporting in five minutes.
- For an an in-depth introduction to the API's use cases, features, and privacy model, read Introduction to Attribution Reporting.
These articles, as well as additional API guides and blogposts for this API, are listed here.
This API is being incubated and developed in the open. Here are ways to participate:
- 🗓 Join the bi-weekly meetings (every second week). In these calls, participants discuss API design proposals and how the API could support various measurement use cases. You can add topics to the next meeting's agenda at any time. Everyone is welcome to join these discussions⏤only make sure to join the WICG.
- ☝️ Open an issue to ask questions, propose features, or discuss use cases. If you're unsure how to formulate your issue, see examples like this issue and this issue. You can also join the conversation in existing issues.
Note: If you have implementation questions, for example if you're running an origin trial in Chrome and have technical questions, join the Attribution Reporting mailing list for developers and ask your question. If you have general technical questions on your use case, consider opening an issue on the Privacy Sandbox dev support repository.
The Attribution Reporting API makes it possible to measure when an ad click or view leads to a conversion on an advertiser site, such as a sale or a sign-up. The API doesn't rely on third-party cookies or mechanisms that can be used to identify individual users across sites.
The API enables two types of attribution reports:
- Event-level reports associate a particular event on the ad side (a click, view or touch) with coarse conversion data. To preserve user privacy, conversion-side data is coarse and noised, reports are not sent immediately, and the number of conversions is limited.
- Aggregate reports are not tied with a specific event on the ad side. These reports provide richer, higher-fidelity conversion data than event-level reports. A combination of privacy techniques across cryptography, distribution of trust, and differential privacy help reduce the risk of identity joining across sites.
These two report types can be used simultaneously. They're complementary.
🕙 Last updated: June 2021
All the features below are proposals under incubation. This list evolves over time.
Attribute cross-site click-through or view-through conversions with reports at a per-event level. See details in the Explainer: event-level reports for views and in the Explainer: event-level reports for clicks.
Implementation status:
Click-through: 🟢 available for experimentation in Chrome
. See the origin trial.
View-through: 🟤 not implemented yet (all browsers)
Attribution reports for aggregated conversions (both clicks and views). Complements the event-level reports. See details in the Explainer.
Implementation status: 🟤 not implemented yet (all browsers)
Attribution reports for web conversions for ad clicks (touches) or views that occurred within an Android app. See details in the Explainer.
Implementation status: 🟤 not implemented yet (all browsers)
Attribute conversions occurring across distinct devices, i.e. as distinct web browser instances. See details in the Explainer.
Implementation status: 🟤 not implemented yet (all browsers)
API guides and blogposts for this API are listed here.