akash...@google.com, lin...@chromium.org, john...@chromium.org
Attribution Reporting with event-level reports
Attribution Reporting API with Aggregatable Reports
Aggregation Service for the Attribution Reporting API
https://wicg.github.io/attribution-reporting-api/
Internals > AttributionReporting
We are landing the following changes to the Attribution Reporting API focused on:
additional debugging support by supporting new verbose debug reports
improving privacy & security by adding additional gating to source verbose debug reports
improving rate limit accounting by separating the attribution count for the two ARA report types
Split attribution rate-limit into separate event & aggregate rate-limits
(1, 2) Additional verbose debug reports and (4) splitting the attribution rate limit into separate limits for event and aggregate are fully backwards compatible changes. Feature (3) gating all source verbose debug reports is a backwards incompatible change because now source-destination-limit and source-destination-rate-limit verbose debug reports now require the ar_debug cookie to be set at source registration time. This is not a major concern because all other current source verbose debug signals already require the ar_debug cookie to be set and most ad-techs would already be setting this cookie at source registration time.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
The attribution reporting feature bundle will be supported on all platforms with the exception of Android WebView
Yes
This feature bundle is anticipated to ship as part of Chrome 125.
https://chromestatus.com/feature/5146883686400000
Previous I2S:
Intent to Ship: Attribution Reporting API
Intent to Ship: Attribution Reporting features M117
Intent to Ship: Attribution Reporting features M118
Intent to Ship: Attribution Reporting features M119
Intent to Ship: Attribution Reporting features M120
Intent to Ship: Attribution Reporting features M121
Intent to Ship: Attribution Reporting features M123
Intent to Ship: Attribution Reporting features M124
--
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/194f8cc0-03b3-47e5-ad1c-0938c1a686ben%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdvBLuqLjqL5iv6s8GbpKhV1rr5XujoBd6d7F%3Dc4a2qhw%40mail.gmail.com.
Apologies for the delay here - it's a bit challenging to review 4 features at once.
(Aside: it seems like this particular intent could have been
split into 2... one for 2 debug report features, and another for
rate limits?)
Contact emailsakash...@google.com, lin...@chromium.org, john...@chromium.org
ExplainerAttribution Reporting with event-level reports
Attribution Reporting API with Aggregatable Reports
Aggregation Service for the Attribution Reporting API
Specificationhttps://wicg.github.io/attribution-reporting-api/
Blink componentInternals > AttributionReporting
SummaryWe are landing the following changes to the Attribution Reporting API focused on:
additional debugging support by supporting new verbose debug reports
improving privacy & security by adding additional gating to source verbose debug reports
improving rate limit accounting by separating the attribution count for the two ARA report types
Explainer/Spec changes
Risks
Interoperability and Compatibility(1, 2) Additional verbose debug reports and (4) splitting the attribution rate limit into separate limits for event and aggregate are fully backwards compatible changes. Feature (3) gating all source verbose debug reports is a backwards incompatible change because now source-destination-limit and source-destination-rate-limit verbose debug reports now require the ar_debug cookie to be set at source registration time. This is not a major concern because all other current source verbose debug signals already require the ar_debug cookie to be set and most ad-techs would already be setting this cookie at source registration time.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
The attribution reporting feature bundle will be supported on all platforms with the exception of Android WebView
Is this feature fully tested by web-platform-tests?Yes
Estimated milestonesThis feature bundle is anticipated to ship as part of Chrome 125.
Link to entry on the Chrome Platform Statushttps://chromestatus.com/feature/5146883686400000
Links to previous Intent discussionsPrevious I2S:
Intent to Ship: Attribution Reporting API
Intent to Ship: Attribution Reporting features M117
Intent to Ship: Attribution Reporting features M118
Intent to Ship: Attribution Reporting features M119
Intent to Ship: Attribution Reporting features M120
Intent to Ship: Attribution Reporting features M121
Intent to Ship: Attribution Reporting features M123
Intent to Ship: Attribution Reporting features M124
Thanks,Akash
Hi Mike,
We have not fully considered adding this functionality to WPT and it may be challenging due to delays and noise added by the Attribution Reporting API, but we will evaluate what is possible here.
Thanks for the suggestions regarding the features. We will make sure to break apart the I2S based on features that can be grouped together in the future.
Regarding the motivation for the features:
1. Spec verbose debug report for max channel capacity and max trigger states cardinality
For debugging completeness of potential errors that can occur. This is an important debug error signal for the flexible event level reporting feature.Regarding the interoperability and compatibility question, it is currently not possible to register for a specific error signal. The API caller would register to receive a debug report and the API then provides the error that occurs (assuming an error occurs). Additionally, it would be extremely unlikely for sites to only be interested in the source-destination-limit and source-destination-rate-limit errors, since they would most likely be interested in also understanding any error signals that may be impacting their conversions as well.
Thanks,
Akash
Thanks Akash.
This is not quite the level of detail I was hoping for (I've more
or less grokked that from the commits themselves), but I'm
satisfied with the compat implications of always requiring the
ar_debug cookie.
LGTM1
Hi Mike,
We have not fully considered adding this functionality to WPT and it may be challenging due to delays and noise added by the Attribution Reporting API, but we will evaluate what is possible here.
Currently the API supports a feature called Flexible Event-Level reporting, which gives API callers additional customization capabilities by allowing them to change the number of conversion reports, number and length of reporting windows, and trigger data cardinality per source that they register.
As part of Flexible Event-Level, the API only allows configurations that do not exceed our current privacy bar (i.e. max channel capacity) of 11.5 bits of information gain for clicks and 6.5 bits of information gain for views. So currently if an ad-tech using Flexible Event-Level chooses a configuration that exceeds the current privacy bar their registration will fail silently. With the addition of the “max channel capacity limit” verbose signal, ad-techs will now be able to receive a verbose debug report telling them that they have exceeded the “max channel capacity” and will allow them to know that they need to use a different configuration and allow them to identify why their source registrations may be failing. This new verbose debug report will also help with future features that may be taken into account when calculating the information gain for a given configuration.
Similarly, as part of ARA source registrations and Flexible Event-Level, an ad-tech can customize their trigger data cardinality up to a maximum of 32 trigger states. The “max trigger states cardinality limit” verbose signal, will allow ad-techs to know if they have set a source registration that exceeds this maximum threshold on the trigger data cardinality, making the API easier to debug for ad-techs.
Currently the API has a rate limit that only allows a maximum of 1 reporting origin per {source site, reporting site, 1 day} per source registration. This limit is in place to help prevent ad-techs from cycling through multiple different reporting origins as a way to measure additional information on a user.
Currently if an ad-tech exceeds this limit, their source registration will fail silently. In order to make the debugging process easier and help ad-techs identify a potential cause of data loss, the API will now provide a verbose signal for this error any time an ad-tech’s registration exceeds the limit.
Currently the API provides 9 different source verbose debug signals. All of these signals require that the ad-tech has set the ar_debug cookie on the source in order to receive the verbose debug signal, except for two errors: “source-destination-limit” and “source-destination-rate-limit”.
In order to reduce complexity for ad-techs so that there is no difference in when an ar_debug cookie needs to be set in order to receive a debug report across the different error signals, this change will now require the ar_debug cookie to be set for all source verbose debug signals.
This change also has the added benefit of improving privacy by adding an additional check for the two rate limits listed above.
Currently the API has a single attribution rate limit of 100 attributions per {source site, destination site, reporting} per 30 days, and this limit is across both report types supported in the API (i.e. event-level reports and aggregate reports). For example, currently if 1 trigger registration generates both an event-level report and aggregate report this will count as 1 towards the attribution limit. And if the attribution limit is hit, neither event-level report nor aggregatable report is created.
Now that the API supports a subset of Flexible event-level, there may be scenarios where 1 trigger registration can generate multiple event-level reports, but still only 1 aggregate report. Because of this new behavior it would not be accurate to count and may negatively impact ad-techs if the API tracks the rate limit across both report types.
With this change, the API will now track the attribution rate limit separately for each report type. So in the example above, where a trigger registration generates multiple event-level attribution reports, these will only count for the event-level report limit, and not impact the aggregate attribution rate limit, which will allow ad-techs to continue generating aggregate reports.
Additionally, this separation of rate limits will also provide better report deletion accounting in the API in scenarios where a pending event-level report is scheduled to be sent at a later time, but then gets replaced by a higher priority newly generated event-level report. In the current API this scenario counts as 2 attribution reports, when in reality the first report is never sent since it is replaced by the higher priority second report. With this change, the API will only count this as 1 report towards the attribution rate limit, and specifically the event-level report count, and not the aggregate report count.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2fb1a68d-bdc7-4428-ab3f-858b7cabd91en%40chromium.org.