Attribution Reporting updates in June 2022

The Attribution Reporting proposal is changing for Chrome version 104, with new API mechanisms, functionality, and updates to the aggregation service.

# Who are these updates for?

These updates are for you if:

• You already are familiar with the API—for example, if you've been observing or participating in the discussions on the WICG repository and want to understand the changes made to the API.
• You're using the Attribution Reporting API in a demo or plan to test in the origin trial.

If you're just getting started with this API and/or have not experimented with it yet, go directly to the introduction to the API instead.

# Attribution Reporting API updates

The API handbook and Attribution Reporting demo have been updated to reflect the latest changes to the Attribution Reporting client-side API.

Most changes don't require action. Those that do require updates for your implementation have been highlighted below.

# (Action required) unified headers for registration

The headers have been unified. There is now just one header for sources and one for triggers, formatted in JSON.

• To register attribution sources, you can respond to registration requests with the header Attribution-Reporting-Register-Source.
• To complete trigger registration, set the Attribution-Reporting-Register-Trigger header.

This change requires action. Refer to the API handbook for more information.

# (Action required) aggregation keys are now a dictionary

To register attribution sources, continue to use aggregation_keys, but now stored as a JSON dictionary instead of a list.

For example:

"aggregation_keys": {
    // Generate a "0x159" key piece for the key named "campaignCounts".
    "campaignCounts": "0x159", // User saw ad from campaign 345 (out of 511)

    // Generates a "0x5" key piece (low order bits of the key) for 
    // the key named "geoValue".
    "geoValue": "0x5" // Source-side geo region = 5 (US), out of a possible ~100 regions
 }

This change requires action. Refer to the API handbook for more information.

# Report generation

You can choose to generate only aggregatable reports, which can be aggregated into summary reports. If your filters don't match any event triggers, then no event-level reports will be generated.

# Unified debug key setting

The debug key should now be set in the source and trigger headers, instead of with separate headers. Learn more about how to debug reports.

# Register attribution sources

Script tags can now be used to register attribution sources, similar to support for the <img> tag.

# More API updates

Other changes that have been made and cited in the API handbook include:

• Sources can be registered with JavaScript request APIs.
• window.registerSource was removed.
• It is now optional to include a value for attributionsrc when registering sources.
• Attribution-Reporting-Eligible header added to incoming source registration requests.
• There was a minor change to encodeURIComponent.
• The privacy budget key was removed from the shared_info field in aggregatable reports.

# Support for the Aggregation Service

In Chrome 104, we intend to update the format of some information inside of aggregatable reports. We are currently building support for this change in the Aggregation Service. This document will be updated, as well the changelog, after the changes are shipped.

We've gathered a document of practical tips and strategies to generate summary reports. There are a number of insights, including:

• Overview of noise in summary report generation
• A detailed explanation of dimensions, keys, and values
• Aggregation keys in practice, including a key structure map
• Aggregatable values in practice, and implications of the contribution budget
• Guide to experimenting with epsilon

# Read more about the updates

• Read the API handbook.
• Read What you should know about the API.
• Read Experiment with Attribution Reporting: Strategy and tips for summary reports.

The header image is from Diana Polekhina on Unsplash.