Announcement: Chrome 114: New features and changes in Attribution Reporting
Maud Nalpas
Hi API testers,
New features for the Attribution Reporting API have landed in Chrome 114:
Changes to fetch/XHR integration (migration may be required)
Support for lists in attributionsrc
Cross App and Web Attribution Measurement
Database migration (may cause report loss)
Chrome 114 is currently in Beta and soon in Stable.
Change #1: Changes to fetch/XHR integration (migration required for fetch and XHR calls)
About this change:
Before this change, in order for fetch/XHR requests to be eligible for the API, you had to manually add the Attribution-Reporting-Eligible request header (which for other integrations e.g. with attributionsrc is added automatically by the browser).
After this change, manually adding the header will no longer work to grant eligibility. Instead you need to use an API surface built into fetch and XHR.
Thanks to this change, only truly eligible requests will now be marked as eligible. This prevents potential bugs and report loss, where requests may have been marked as eligible when in reality they weren't (request made from a non-HTTPS origin, API blocked via Permissions-Policy…).
Requesting developers to mark the request as eligible on behalf of the browser was a stop-gap until we could implement this new approach.
What should you do?
Remove the Attribution-Reporting-Eligible header in places where you added it manually to fetch or XHR. Replace it with a configuration object as documented in the explainer and updated handbook.
Review the example migration for details.
Make sure to continue feature-detecting before you use the API.
Documentation:
Review the updated fetch calls examples in the handbook.
Review the example migration and explainer for details.
See this thread.
Change #2: Support for lists in attributionsrc
About this change:
You can now list multiple sites as attribution sources in attributionsrc.
This is useful if multiple reporting origins want to register a source on a navigation, but cannot appear in a redirect chain for some reason.
What should you do?
No code change is required from your side. This change is non-breaking and backwards-compatible.
If this new feature is useful for your use case — for example if your use case requires several reporters, but redirects are not an option — consider listing several sites as attribution sources.
Documentation:
Review the updated attributionsrc section in the handbook.
Change #3: Cross App and Web Attribution Measurement
About this change:
The origin trial for Cross App and Web Attribution Measurement is active.
Note: there is no traffic on Beta yet. Check out this thread for updates as traffic ramps up.
What should you do?
Testers may see a new header (Attribution-Reporting-Support) that specifies whether Cross App and Web Attribution is available.
If the Cross App and Web Attribution Measurement use case of interest to you, use the new Attribution-Reporting-Register-OS-Source and Attribution-Reporting-Register-OS-Trigger headers to register sources and triggers with Android. If it's not, you can ignore the new header Attribution-Reporting-Support.
Documentation:
Change #4: Database migration (may cause report loss)
About this change:
As previously announced, attribution Reporting API data saved in Chrome 113 and earlier versions will be lost after updating to Chrome 114. Apologies for the inconvenience.
Triggers will not be attributed to sources registered in Chrome 113 and earlier versions. For example, if a user clicks on an ad in Chrome 113, then upgrades to Chrome 114 and later converts for that ad, the corresponding report will be lost.
Reports created in Chrome 113 and earlier versions, and that have not been sent yet (i.e. pending) will also be lost.
What should you do?
No code change is required from your side.
Expect some report loss.
Questions/Feedback
If you experience any issue or have any implementation questions on these features and changes, please file an issue in our developer support repository.