Get started with Attribution Reporting

Here's where to start, including setup and a quick overview.

Choose a report type

Using the Attribution Reporting API, you can generate two types of reports: event-level and summary reports. Event-level reports require less setup than aggregatable/summary reports, so they may be a good place to start. Summary reports require integration with the Aggregation Service; event-level reports don't.

You can set up reporting for both event-level and summary reports. They are complementary.

Event-level reports

Event-level reports associate a particular ad click or view (on the ad side) with data on the conversion side. To preserve user privacy by limiting the joining of user identity across sites, conversion-side data is very limited, and the data is noisy.

Summary reports

A summary report is an Attribution Reporting API and Private Aggregation API report type. A summary report includes aggregated user data and can contain detailed conversion data, with noise added. Summary reports are made up of aggregate reports.

Implementation

You can get started by trying out the steps that follow.

Note that for a given event source, it's possible to generate both an event-level and an aggregatable report. The demo walks you through the process.

Event-level report generation

Here are the minimum steps to follow to generate event-level reports:

  1. Register a source. Refer to Register attribution sources for the instructions. Note that the steps are different for clicks and views.

  2. Register a trigger. Refer to Register attribution triggers for the instructions.

  3. Set up an endpoint with the following URL:

    {REPORTING_ENDPOINT}/.well-known/attribution-reporting/report-event-attribution

    Refer to the example code in adtech.js to see the post method. More information on .well-known is here.

More details on event-level reports here.

Summary report generation

To generate summary reports, follow these high-level steps:

  1. Register a source. Refer to Register attribution sources for the instructions. Note that the steps are different for clicks and views. Additional details can be found in Attribution source registration.

  2. Register a trigger. Refer to Register attribution triggers for the instructions.

  3. Set up an endpoint for aggregatable reports with the following URL: {REPORTING_ENDPOINT}/.well-known/attribution-reporting/report-aggregate-attribution

    Refer to the [example code in adtech.js](https://github.com/GoogleChromeLabs/trust-safety-demo/blob/8f3d874b79ab0c8a15822fbcd09e94042aee7dcd/conversion-measurement/functions/apps/adtech.js#L334) to see the `post` method. More information on [.well-known](https://en.wikipedia.org/wiki/Well-known_URI) is here.
    
  4. Batch and send the reports for further processing by the Aggregation Service which will produce summary reports. Refer to batched aggregatable reports.

More details on summary reports here.

Learn how to set up debug reports in the Attribution reporting debugging series.

Summary reports additional concepts

In addition to understanding the implementation steps here, the following concepts will help you plan your summary reporting strategy:

Optional steps

  1. Set up filters (optional):
    1. Follow the instructions in Define custom rules using filters.
    2. Review details specific to filters for aggregatable reports in the triggers section of the explainer.

Don't forget feature detection

Before you use the API, detect if it hasn't been blocked on the page via a Permissions-Policy. To do so, run the following code:

if (document.featurePolicy.allowsFeature('attribution-reporting')) {
  // the Attribution Reporting API is enabled
}

If this feature-detection check returns true, the API is allowed in the context (page) where the check is run.

Note that this check alone isn't a guarantee that the API is usable on that page; the user may have disabled the API via their browser settings, or they may have other settings that prevent the API from being used. In order to protect user privacy, there is no way to check for this programmatically.

Next steps

If you're ready to begin implementation, check out these docs:

If you're still in the planning stage, take a look at these docs: