Intent to Ship: Attribution Reporting API
John Delaney
john...@chromium.org, cshar...@chromium.org
Explainer
https://github.com/WICG/conversion-measurement-api/blob/main/EVENT.md
https://github.com/WICG/conversion-measurement-api/blob/main/AGGREGATE.md
https://github.com/WICG/conversion-measurement-api/blob/main/AGGREGATION_SERVICE_TEE.md
Specification
https://wicg.github.io/conversion-measurement-api
Summary
This API measures ad conversions (e.g. purchases) and attributes them to ad interactions without using cross-site persistent identifiers like third-party cookies. The API allows measurement through both event-level reports sent directly from the browser, and aggregatable reports which can be processed through a trusted service to create summary reports of attribution data.
While we believe the current version of the API covers the core use cases, we are working in parallel to ship future updates with a number of auxiliary features that are still in development, including multiple aggregation service coordinator support and report verification, among others.
Blink component
Internals > AttributionReporting
TAG review
https://github.com/w3ctag/design-reviews/issues/724
TAG review status
Pending
Risks
Interoperability and Compatibility
There are several other different attribution measurement proposals from a variety of browser vendors and companies, each offering different forms of privacy and utility.
Safari has proposed and implemented Private Click Measurement (https://privacycg.github.io/private-click-measurement/).
Interoperable Private Attribution (https://github.com/patcg-individual-drafts/ipa/blob/main/IPA-End-to-End.md) has been proposed by Mozilla and Meta for Private Measurement within the Private Advertising Technology Community Group. See https://github.com/patcg-individual-drafts/ipa/issues/59 for our position on this proposal.
Gecko: No official position (https://github.com/mozilla/standards-positions/issues/791)
WebKit: No official position (https://github.com/WebKit/standards-positions/issues/180)
Web developers: Positive engagement in origin trial from 9+ testers
See the post: Why Chrome plans to ship the Attribution Reporting API (https://developer.chrome.com/docs/privacy-sandbox/attribution-reporting/chrome-shipping/) for additional context on interop risk and how we are thinking about the other proposals and the active work being done in this space.
Ergonomics
Attribution Reporting allows integration via HTTP headers and common loading APIs, which are widely used for attribution measurement today to ease adoption.
Activation
A successful API flow involves registering multiple events across multiple different navigations/pages. API reports contain either coarse or encrypted information that can be difficult to compare directly with cookie-based measurement. The current proposal includes a debugging mode to facilitate testing and integration.
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
No
Debuggability
The proposal includes debugging features (https://wicg.github.io/attribution-reporting-api/#issue-verbose-debug-report-request), which are gated behind SameSite=None cookies to support migration from existing cookie-based measurement to the Attribution Reporting API.
Developer documentation on debug reports: Debug Attribution Reporting
Developer documentation on Noise Lab: Experiment with summary report design decisions
Attribution Reporting API Internals: chrome://attribution-internals/
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
No, this feature is not supported on Android WebView. We plan to support WebView attribution measurement through Cross App and Web Attribution Reporting (https://groups.google.com/a/chromium.org/g/blink-dev/c/gTvI5x-qex8/m/tK2huQq9AwAJ )
Is this feature fully tested by web-platform-tests?
Reports sent through the API are subject to large delays and noise. Most tests are currently internal web tests, and we are proposing new WebDriver APIs to support testing via web-platform-tests. See this doc for more information on the complexities of testing this feature.
DevTrial instructions
https://developer.chrome.com/docs/privacy-sandbox/attribution-reporting/
Requires code in //chrome?
False
Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1014604
Estimated milestones
We intend to do an incremental ramp to 100% in Stable starting with Chrome Release M115 (see https://chromiumdash.appspot.com/schedule).
We have a number of auxiliary features we are planning to add support for:
These are backwards compatible changes which add new reporting capabilities not possible in the core API.
We anticipate potential changes to certain parameters and limits in response to developer feedback.
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/6412002824028160
Links to previous Intent discussions
Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/7B0ldtZR_68/m/GjLBu0n4DgAJ
Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/jEnNpideO1Y/m/nlEDdjmnCgAJ
Intent to Extend Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/jEnNpideO1Y/m/nlEDdjmnCgAJ
This intent message was generated by Chrome Platform Status.
Yoav Weiss
Contact emailsjohn...@chromium.org, cshar...@chromium.org
Explainerhttps://github.com/WICG/conversion-measurement-api/blob/main/EVENT.md
https://github.com/WICG/conversion-measurement-api/blob/main/AGGREGATE.md
https://github.com/WICG/conversion-measurement-api/blob/main/AGGREGATION_SERVICE_TEE.md
Specificationhttps://wicg.github.io/conversion-measurement-api
SummaryThis API measures ad conversions (e.g. purchases) and attributes them to ad interactions without using cross-site persistent identifiers like third-party cookies. The API allows measurement through both event-level reports sent directly from the browser, and aggregatable reports which can be processed through a trusted service to create summary reports of attribution data.
While we believe the current version of the API covers the core use cases, we are working in parallel to ship future updates with a number of auxiliary features that are still in development, including multiple aggregation service coordinator support and report verification, among others.
Blink componentInternals > AttributionReporting
TAG reviewhttps://github.com/w3ctag/design-reviews/issues/724
TAG review statusPending
Risks
Interoperability and CompatibilityThere are several other different attribution measurement proposals from a variety of browser vendors and companies, each offering different forms of privacy and utility.
Safari has proposed and implemented Private Click Measurement (https://privacycg.github.io/private-click-measurement/).
Interoperable Private Attribution (https://github.com/patcg-individual-drafts/ipa/blob/main/IPA-End-to-End.md) has been proposed by Mozilla and Meta for Private Measurement within the Private Advertising Technology Community Group. See https://github.com/patcg-individual-drafts/ipa/issues/59 for our position on this proposal.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9402d8f1-1700-4eb3-8709-eaba907784aen%40chromium.org.
Yoav Weiss
Rick Byers
A few words with my spec-mentor hat on:* I reviewed the specification, and I believe it is well-integrated with other web platform specifications.* There's one case where I think the algorithm can be more precise, but I wouldn't consider this a blocker.* The choice of JSON header values is non-orthodox, but I was convinced that Structured Fields cannot support the API's use case. (due to nesting)* There are 85 open issues. It'd probably be good to give them labels that'd enable reviewers to see how many of them may impact compat.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUD87zTwdL-bF-TkXO9ZDZx_Zsj%2B4MJQ0LZ3PSENVRzDw%40mail.gmail.com.
John Delaney
Can you expand (or point to existing docs) about the differences between this and PCM? What's the likelihood of future convergence? What are developers expected to do in the meantime?
Unfortunately, while we were able to converge with the PCM authors on nomenclature, the Attribution Reporting API differs substantially from PCM in quite a few ways. We don’t have a detailed write-up of all the differences, but if it seems useful we can draft a document in our repo outlining detailed differences (tracking issue here). Here is a short summary:
ARA has support for "viewed" impressions, where PCM only supports clicks
The ability for attribution to be scoped to, and reports sent to, third parties (issue)
Registration is performed via different mechanisms, HTTP headers for ARA, PCM uses a combination of html attributes and .well-known request parsing (see this issue as an example of divergence)
Reports contain different types of information, for example a 64-bit identifier in event-level ARA, and an 8 bit identifier PCM
Different limitations on the number and timing of reports which are sent (issue)
There is some documentation on high-level design dimensions within PATCG here.
Future convergence right now is not entirely clear, but it's something we are actively working on in the PATCG.
We expect that developers will develop for these measurement APIs when they are providing value for their use-cases and customers, and that this will require multiple different implementations switched on UA currently. It's worth noting that, at present, the API surfaces for these two APIs do not conflict with each other (PCM won't cause any issues in Chrome and vice versa).
+1. I spent 30 min looking over open issues, and while many didn't have responses yet they largely all felt like possible future extensions. Here's a couple which seemed to me to be worthy of at least a response or follow-up (if not a resolution) before I'd be comfortable approving the I2S. There may be others though, so I'd appreciate at least a quick triage pass by experts on the team to focus API owner attention on the issues which may cause future compat problems or otherwise inhibit an interoperable implementation.
Yoav Weiss
Thanks, Yoav and Rick for the questions/discussion. See responses below.Can you expand (or point to existing docs) about the differences between this and PCM? What's the likelihood of future convergence? What are developers expected to do in the meantime?Unfortunately, while we were able to converge with the PCM authors on nomenclature, the Attribution Reporting API differs substantially from PCM in quite a few ways. We don’t have a detailed write-up of all the differences, but if it seems useful we can draft a document in our repo outlining detailed differences (tracking issue here). Here is a short summary:
ARA has support for "viewed" impressions, where PCM only supports clicks
The ability for attribution to be scoped to, and reports sent to, third parties (issue)
Registration is performed via different mechanisms, HTTP headers for ARA, PCM uses a combination of html attributes and .well-known request parsing (see this issue as an example of divergence)
Reports contain different types of information, for example a 64-bit identifier in event-level ARA, and an 8 bit identifier PCM
Different limitations on the number and timing of reports which are sent (issue)
There is some documentation on high-level design dimensions within PATCG here.
Future convergence right now is not entirely clear, but it's something we are actively working on in the PATCG.
We expect that developers will develop for these measurement APIs when they are providing value for their use-cases and customers, and that this will require multiple different implementations switched on UA currently. It's worth noting that, at present, the API surfaces for these two APIs do not conflict with each other (PCM won't cause any issues in Chrome and vice versa).
+1. I spent 30 min looking over open issues, and while many didn't have responses yet they largely all felt like possible future extensions. Here's a couple which seemed to me to be worthy of at least a response or follow-up (if not a resolution) before I'd be comfortable approving the I2S. There may be others though, so I'd appreciate at least a quick triage pass by experts on the team to focus API owner attention on the issues which may cause future compat problems or otherwise inhibit an interoperable implementation.We went through and added a "compat" label for issues that we feel have compat risk. For the issues linked here, we are following up on those individually and will provide an update soon.
Rick Byers
On Tue, Jun 27, 2023 at 9:43 PM John Delaney <john...@chromium.org> wrote:Thanks, Yoav and Rick for the questions/discussion. See responses below.Can you expand (or point to existing docs) about the differences between this and PCM? What's the likelihood of future convergence? What are developers expected to do in the meantime?Unfortunately, while we were able to converge with the PCM authors on nomenclature, the Attribution Reporting API differs substantially from PCM in quite a few ways. We don’t have a detailed write-up of all the differences, but if it seems useful we can draft a document in our repo outlining detailed differences (tracking issue here). Here is a short summary:
ARA has support for "viewed" impressions, where PCM only supports clicks
The ability for attribution to be scoped to, and reports sent to, third parties (issue)
Registration is performed via different mechanisms, HTTP headers for ARA, PCM uses a combination of html attributes and .well-known request parsing (see this issue as an example of divergence)
Reports contain different types of information, for example a 64-bit identifier in event-level ARA, and an 8 bit identifier PCM
Different limitations on the number and timing of reports which are sent (issue)
There is some documentation on high-level design dimensions within PATCG here.
Future convergence right now is not entirely clear, but it's something we are actively working on in the PATCG.
We expect that developers will develop for these measurement APIs when they are providing value for their use-cases and customers, and that this will require multiple different implementations switched on UA currently. It's worth noting that, at present, the API surfaces for these two APIs do not conflict with each other (PCM won't cause any issues in Chrome and vice versa).
+1. I spent 30 min looking over open issues, and while many didn't have responses yet they largely all felt like possible future extensions. Here's a couple which seemed to me to be worthy of at least a response or follow-up (if not a resolution) before I'd be comfortable approving the I2S. There may be others though, so I'd appreciate at least a quick triage pass by experts on the team to focus API owner attention on the issues which may cause future compat problems or otherwise inhibit an interoperable implementation.We went through and added a "compat" label for issues that we feel have compat risk. For the issues linked here, we are following up on those individually and will provide an update soon.Thanks! Going through the issues, I see a couple that I'm not sure have real compat implications, but 4 more that do seem like it'd be good to settle (or at least have a mental image of future-compatible changes) before shipping.
Chris Harrelson
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8OgcRphN%2BUYnLhGQBJOtxybRLxxhA%3D13cLXj%3DFMRSOZw%40mail.gmail.com.
Mike Taylor
LGTM3
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8-cQad%3D8mExu8CcNGR_W%2BDJa916_SPWsMCQQ60r9L9jw%40mail.gmail.com.
Anthony Garant
Replying to this thread for visibility on a vendor-specific value change.
We see from UMA metrics that ~6% of sources are being dropped due to the 1024 sources per source origin limit. The issue was also reported by external testers.
The limit will be increased from 1024 to 4096. This change will be effective from the Chrome Release M120.
LGTM2
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9402d8f1-1700-4eb3-8709-eaba907784aen%40chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUD87zTwdL-bF-TkXO9ZDZx_Zsj%2B4MJQ0LZ3PSENVRzDw%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8OgcRphN%2BUYnLhGQBJOtxybRLxxhA%3D13cLXj%3DFMRSOZw%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.