Intent to Ship: Attribution Reporting API

1,784 views
Skip to first unread message

John Delaney

unread,
Jun 20, 2023, 4:35:14 PM6/20/23
to blink-dev
Contact emails

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).



Anticipated spec changes

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

unread,
Jun 23, 2023, 3:04:09 AM6/23/23
to John Delaney, blink-dev
On Tue, Jun 20, 2023 at 10:35 PM John Delaney <john...@chromium.org> wrote:
Contact emails

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/). 


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?
 

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.


I appreciate y'all's engagement with that proposal and your commitment.
 
--
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

unread,
Jun 26, 2023, 6:01:42 AM6/26/23
to John Delaney, blink-dev
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.
* One thing I just now realized (apologies for not catching this sooner), is that it'd be better to fully integrate the FencedFrames monkeypatch into the FencedFrames spec. I wouldn't consider this a blocker to shipping.

Rick Byers

unread,
Jun 26, 2023, 12:08:22 PM6/26/23
to Yoav Weiss, John Delaney, blink-dev
There's clearly a lot of interop risk around all the different proposals in this space. At the same time, it's clear this is one of the most important aspects to the ads industry and so the huge amount of collaborative experimentation and open sharing of information on pros/cons seems net beneficial to the industry to me. I'm optimistic that we'll see convergence over time. 

On Mon, Jun 26, 2023 at 6:01 AM Yoav Weiss <yoav...@chromium.org> wrote:
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.

+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.


John Delaney

unread,
Jun 27, 2023, 3:44:05 PM6/27/23
to Rick Byers, Yoav Weiss, blink-dev
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.

Yoav Weiss

unread,
Jun 28, 2023, 5:23:37 AM6/28/23
to John Delaney, Rick Byers, blink-dev
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.

Rick Byers

unread,
Jul 6, 2023, 8:29:20 PM7/6/23
to Yoav Weiss, John Delaney, blink-dev
On Wed, Jun 28, 2023 at 5:23 AM Yoav Weiss <yoav...@chromium.org> wrote:

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.

Reviewing the current state of those issues, it seems things are in pretty good shape, with a few small loose ends to tie up that don't seem too risky to. me. 

LGTM1

Chris Harrelson

unread,
Jul 10, 2023, 12:15:42 PM7/10/23
to Rick Byers, Yoav Weiss, John Delaney, blink-dev
LGTM2

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

unread,
Jul 10, 2023, 3:56:53 PM7/10/23
to Chris Harrelson, Rick Byers, Yoav Weiss, John Delaney, blink-dev

LGTM3

Anthony Garant

unread,
Nov 10, 2023, 5:10:15 PM11/10/23
to blink-dev, Mike Taylor, Yoav Weiss, John Delaney, blink-dev, Chris Harrelson, Rick Byers

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.
--
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.
--
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.
--
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.
Reply all
Reply to author
Forward
0 new messages