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
to Attribution Reporting API announcements
Hi API testers,

New features have landed in Chrome 113, to address tester feedback we've received: 
  1. Support for multiple sets of OR filters
  2. Removal of non-privacy-related trigger JSON size limits
  3. (temporary) (potentially breaking) Removal of background request on context menus
  4. (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.
  • Documentation
  • What should you do?
    • 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.
  • Documentation:
    • Review the old and new limits here.
  • What should you do?
    • No code changes are needed from your side. 
    • 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.
Reply all
Reply to author
Forward
0 new messages