Announcement: Chrome 113: New features and changes in the Attribution Reporting API
1,005 views
Skip to first unread message
Maud Nalpas
unread,
Apr 5, 2023, 11:31:21 AM4/5/23
Reply to author
Sign in to reply to author
Forward
Sign in to forward
Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to Attribution Reporting API announcements
Hi API testers,
New features have landed in Chrome 113, to address tester feedback we've received:
Support for multiple sets of OR filters
Removal of non-privacy-related trigger JSON size limits
(temporary) (potentially breaking) Removal of background request on context menus
(temporary) Reporting windows test
All these changes are in Chrome 113, which is Canary (already 114) and Dev at the time of this writing—and soon Beta and Stable. The fourth change is an exception: while it's landed in Chrome 113, it will only be enabled in non-stable channels for now.
Change #1: Support for multiple sets of OR filters
About this change:
This is mostly a convenience change for filter declaration.
If you use filters and if some of your logic is duplicated as described here, consider if this change helps you eliminate that duplication by refactoring your code.
Change #2: Removal of non-privacy-related trigger JSON size limits
About this change:
Individual limitations on trigger data object size, filters object size, and aggregatable deduplication keys that were not privacy-related have been removed. (The 1-bit or 3-bit trigger data limitation for event-level reports, and the contribution budget for aggregatable reports, remain. These are privacy protections.) The only limitation is now on the total header size, which is the same limitation Chrome has for headers in general.
As a result of this change, Chrome is allowing strictly more trigger registrations.
You may observe that some trigger configurations that were previously rejected due to these limitations now successfully register after this change.
Change #3 (temporary) (potentially breaking): Removal of background requests on context menus
About this change:
While we investigate solutions to this bug, we're temporarily removing the background path support for context menu clicks, and supporting only the foreground path.
What should you do?
No code changes are needed from your side.
Expect some minor loss. Your code is impacted only if you use attributionsrc on anchor tags with a specific URL set (attributionsrc=... as opposed to attributionsrc as an empty attribute). This change temporarily breaks such flows. Background context menu registrations represent less than 0.5% of source registrations.
Change #4 (temporary): Reporting windows test
About this change:
We've received your feedback regarding reporting delays: some reports are being received after the expected amount of time, namely after the expected delay. To address that feedback, we're testing new values for the first and second reporting windows for event-level reports (clicks), and reduced delays for aggregatable reports. Review the details of the test here.
For now, we're running this test in non-stable channels only (Chrome Canary, Dev, Beta).
After running this experiment and collecting feedback, we will follow up with updates.
What should you do?
No code changes are needed from your side.
If you're testing on non-stable channels, be aware that you may receive some reports sooner than you previously have.
Consider sharing your feedback on the reporting windows and ranges that would be most useful to test based on your use cases. To do so, comment on this GitHub issue.
Note that your custom report windows, if you have set any, remain — but due to the test, you may receive reports earlier than these custom windows. Example: If you've set event_report_window to 1 day, for a browser where the temporary experiment is a first window of 2 hours, the first window takes precedence over event_report_window. A report for a conversion that happens 1 hour after clicking on an ad will be sent 2 hours after click.
Questions/Feedback If you experience any issue, or have any implementation questions about these features and changes, please file an issue in our developer support repository.