 The Attribution Reporting API makes it possible to measure 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. And by the way, just in case you're confused, the API used to be called Conversion Measurement. Anyway, 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, and browsers have begun to restrict access to them. Attribution Reporting helps measure conversions without using cross-site identifiers. So how does the Attribution Reporting API actually work? Well, Attribution Reporting enables the measurement of two events that are linked together. For example, an interaction on a publisher website such as a user viewing or clicking an ad followed by a conversion on an advertiser's site. And that can result in an Attribution Report. This API is designed to support click-through conversion attribution measurement and view-through conversion measurement. Some features such as click-through measurement are available in the implementation of the API in the original origin trial. And by the way, just in case you're wondering, origin trials are a way to test a new or experimental web platform feature and give feedback before the feature is made available by default to all developers. Anyway, more features will be added to the implementation of the Attribution Reporting API in future experiments. And you can check the status of the different features on this page. So the API offers two types of attribution reports that can be used for different use cases. Event-level reports and aggregated reports. Event-level reports provide click or view-level visibility to the advertiser or ad tech company. This event-level data can then be joined with conversion data. So it's like a transaction-level report. Aggregate 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, well, how can we provide this granular data, including data joined across sites, while still preserving user privacy? Well, there are a few ways. To preserve user privacy, conversion side data is very limited and is noised, which means that instead of the real data, random data is sent in a small percentage of cases. It's actually 5% of the time in the current implementation in Chrome. And despite this added noise, it's possible to recover the true conversion count while preserving user privacy. 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 history is kept private on your device. Later, the browser sends an encrypted report to the advertiser or ad tech company for each conversion event, adding time delays and random data to further stifle attempts to identify users. And this enables both parties to measure the effectiveness of ad campaigns and to understand what behavior the ads are able to drive without tracking the user across sites. Aggregate reports are also part of the proposed attribution reporting API. Aggregate reports can enable sites to learn aggregate data. And 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 preserve user privacy, it's not possible to drill down enough to an individual event with high precision. And this is where differential privacy comes in. With differential privacy, as you access aggregate information, the noise applied on that data becomes proportionally smaller. So for aggregate reports, a combination of privacy techniques, a cross-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 aggregate can be used simultaneously. They're complementary. And other features being developed in this API include cross-device attribution reporting, app-to-web attribution reporting, and more. So that's attribution reporting in a nutshell. To find out more, take a look at the article and demo available from web.dev. And if you have comments or feedback on the API, you can create an issue on the API explainer on GitHub. You can track implementations of all the Privacy Sandbox APIs on this stage page. So thanks for watching. Be sure to catch the other videos in the Privacy Sandbox series.