 The Attribution Reporting API makes it possible to get a report when action from a user leads to a conversion. For example, a user clicks or views an ad and then later completes a purchase. The Attribution Reporting API is part of the Privacy Sandbox, a series of proposals to satisfy cross-site use cases without third-party cookies or other tracking mechanisms. I'm Sam Dutton, a developer advocate with the Privacy Sandbox team, and in this video, I'll provide an overview of Attribution Reporting. Now, I won't go too deep technically, but if you prefer something more straightforward, check out our resources at PrivacySandbox.com. To find out more about Attribution Reporting for Android, take a look at the API Developer's Guide. Now, historically, third-party cookies and other mechanisms have been used to track your activity as you interact with sites across the web, and many people are concerned about the privacy implications of these cross-site identifiers. Chrome is planning to deprecate third-party cookies and introduce features to reduce cross-site tracking. Attribution Reporting helps measure conversions but without cross-site identifiers. So, how does the Attribution Reporting API work? Well, Attribution Reporting enables the reporting of two events that are connected. For example, an interaction on a publisher website when a user clicks on an ad followed by a conversion on an advertiser site can result in an Attribution Report. Now, to allow this to happen, ad tech developers need to configure code on both the ad side and on the conversion side. On the ad side, such as a publisher site, code is added to enable the browser to record clicks or views along with contextual data, and that is known as a source event. On the conversion side, such as an online store, code is added to enable the browser to record when the user makes a conversion, such as a purchase, and that's known as a trigger event. The browser can then generate reports providing data about the source event and the trigger event, and this means that the Attribution Reporting API enables the browser to match views or clicks with conversions and generate reports, but without sharing more about the user's activity. So, let's go through the whole Attribution Reporting process step by step, and after that, I'll go into each step in a little more detail. Now, imagine a person visits a publisher site, say news.example. The site has ads on it managed by an ad tech company, say adtech.example. Now, adtech.example has added Attribution Reporting code to the ads on the page so that the browser records views and clicks along with some contextual data such as the ID of the ad creative. The person sees an ad for shoes and then clicks on an ad, and that takes them to the advertiser's site, say shoes.example, and eventually they buy the shoes. In other words, the person has converted from being a website visitor on news.example to being a buyer on shoes.example. After the conversion, the browser sends conversion reports to the ad tech company and maybe the advertiser and the publisher as well. Ads can be configured to enable two types of report, event level reports and aggregatable reports. Now, event level reports have more detailed ad side data such as the creative ID for an ad or geographical information, and event level reports associate a specific ad click or view event with a conversion. Now, to help preserve user privacy, the conversion side data is very limited and some random data is added called noise. Event level reports are useful for learning how to improve return on investment. In particular, these reports can be used to optimize ad placement. For example, say click ID 20000400600 on news.example for a contextual ad has led to a purchase on shoes.example. Event level reports are sent directly though with a delay to increase privacy. Aggregatable reports can have more detailed conversion side data such as information about products and revenue and they're not linked to a specific event on the ad side. Typically, page code on the conversion side will be configured by an ad tech platform to enable the browser to record an aggregatable report. Periodically, the browser batches aggregatable reports together and sends them to the ad tech platform collection service. Now, the ad tech platform collects the reports and then sends them to a service known as an aggregation service. And the aggregation service combines the aggregatable reports and decrypts them, adds some random data noise to help protect user privacy and finally creates a summary report which is made available to the ad tech company. Summary reports are useful for reporting use cases. For example, campaign ID 1234567 on news.example has led to 518 conversions on shoes.example and to a total spend of $38174. And half of the conversions were from users in New York City, USA. And that can help your team decide what your next ad campaign should target to generate a higher total spend. So now let's go into each individual step in a little bit more detail. On the ad side, ad tech code needs to configure ads to enable the browser to use the attribution reporting API to record clicks or views. And there are two stages to this. First, configure an ad so the browser makes a request to a specified URL when there's a click or a view. In other words, instruct the browser to register an attribution event source for interactions with the ad. When an interaction with the ad results in a request, respond to the request with a header to provide contextual data and confirm that the browser should record the attribution event. In other words, an attribution source is an ad related event, a click or view, to which an ad tech can attach contextual reporting data such as an ad creative ID or information about the campaign or geography. To register a link tag as a source for a click event, you can use code like this. And when the link is clicked, the browser makes a request to the URL configured in the attribution source attribute of the link. Instead of using a link tag, you can configure an image or script tag to register attribution source events or use fetch or window.open. I won't go into more detail here, but you can find out more from our documentation. So, yeah, to register an ad as an attribution source for a view event, you can use an image with an attribution source attribute or a script tag with an attribution source attribute. Alternatively, you can use fetch. And this code effectively simulates what an HTML request with attribution source would do. When an attribution source event is registered, the browser makes a call to the server you specified as the attribution source. The next step for both clicks and views is for the ad tech server to send a response that includes the attribution reporting or register source header. The response will also include contextual data about the ad click. And code might look like this. Use source event ID to map the event to any granular information you need at ad serving time. The destination value is where a conversion is expected to occur, and this enables the browser to connect an ad click or view event with a conversion. So next, let's take a look at the conversion side. For example, when a user clicks on an ad and then makes a purchase. On the conversion side, the ad tech needs to configure a page to enable the browser to use the attribution reporting API to record conversions. And that's known as registering an attribution trigger. Registering an attribution trigger is similar to registering an attribution source event. First, you need to initiate the trigger registration, and then you complete the trigger registration by responding with the trigger registration header. You can register a trigger using a pixel, an image tag or with a script tag. The origin for source must match the origin that performed the source registration. An attribution can only be triggered on a page whose ETLD plus one matches the site that was provided in the destination on source registration. For a pixel image, you can add attribution source either with or without a value. Using a URL causes the browser to initiate a separate keep alive fetch request, one for each URL, which includes the attribution reporting eligible request header. Performing trigger registration with a script tag behaves identically to image. The code here shows the use of fetch, and this code effectively simulates what an HTML request with attribution source would do. Upon receiving the browser request, respond and include in your response the attribution reporting register trigger header. So the API offers two types of attribution reports that can be used for different use cases. Event level reports and summary reports. Event level reports provide click or view level visibility to the advertiser or ad tech company. This event level data can be joined with conversion data, so it's like a transaction level report. Summary reports enable sites to learn aggregate data and not any data associated with a particular click or user. So event level reports associate a particular ad click or view on the ad side with data on the conversion side. But how can we provide this granular data, including data joined across sites while still protecting user privacy? Well, there are a few ways. To preserve user privacy, conversion side data is very limited and is noisy, which means that random data is sent in a small percentage of cases instead of real data. With this API, no user identifying data is shared between sites as you browse the web. Instead, the browser keeps track of the ad conversions and your browsing activity is kept private on your device. Later, the browser sends a report to the advertiser or ad tech company for each conversion event, adding time delays and random data to help stop attempts to identify users. Now this enables advertisers and ad tech companies to measure the effectiveness of ad campaigns and understand what behavior the ads are able to drive, but without tracking the user across sites. Summary reports are also proposed as part of attribution reporting. Summary reports can enable sites to learn aggregate data. These reports are more flexible. They join detailed click and view data with more detailed conversion data than event level reports, for example, purchase value or a cart's contents. But that data is aggregated. To protect user privacy, it's not possible to drill down to an individual event with high precision. Noise is added to protect user privacy and this means that you can access aggregate information, but noise random data is applied and less data will be more relative error. Now the goal of this mechanism is to have a framework which can support differentially private measurement. For summary reports, a combination of privacy techniques across cryptography, distribution of trust and differential privacy helps reduce the risk of identity being joined across sites. In other words, the API is designed to protect against leaking cross site identity. Both report types, event level and summary reports can be used simultaneously. They're complementary. Now other features being developed in this API include cross device attribution reporting. App to web reporting is currently available in Origin Trial and Chrome plans to move this to general availability early in 2024. You can find out more from the excellent Google IO session getting started with attribution reporting and take a look at the article and demo available from developer.chrome.com. You can check the status of the different features on this page and if you have comments or feedback, you can file an issue on the API explainer on GitHub. If you have feedback or questions about this video or any questions about using the API, file an issue on our Privacy Sandbox Dev Support repo and you can track implementations of all the Privacy Sandbox APIs on our status page. To learn more about Privacy Sandbox on Android, take a look at the SDK and API documentation. So thanks for watching and be sure to check out the other videos in the Privacy Sandbox series.