Intent to Ship: Attribution Reporting API

[John Delaney]

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:

• Report verification

• Flexible event-level configurations

• Support for multiple aggregation services

• Custom lookback windows

• Aggregate debug reporting

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]

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]

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]

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.

https://github.com/WICG/attribution-reporting-api/issues/488

https://github.com/WICG/attribution-reporting-api/issues/221

https://github.com/WICG/attribution-reporting-api/issues/220

https://github.com/WICG/attribution-reporting-api/issues/358

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]

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]

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]

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]

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]

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.