 Hi, I'm JoLynn Yao, Product Manager for the Privacy Sandbox Attribution Reporting API. Today we'll share with you some pointers on getting started with the Attribution Reporting API in the Privacy Sandbox, but before we get started, let's do a round of introductions with our name, role on the project, and favorite dessert. I'll go first. I can't say no to a slice of dark chocolate cake. Hi there, I'm Georgia Franklin, a Product Manager on the Privacy Sandbox, and I love anything homemade, especially apple pie with some vanilla ice cream. Hello, I'm Erin Walsh, a Developer Relations Engineer working on the Privacy Sandbox. My favorite dessert is the chocolate trifle my mom and sister make for my birthday. That sounds great. Thanks, you too. I'll begin by reviewing what the Privacy Sandbox is and how their Attribution Reporting API works, then Erin will walk you through performing attribution across web and Android, and finally, Georgia will talk about enrollment and how to get started with using the Attribution Reporting API. The vision for Privacy Sandbox involves both rethinking and building together. We're rethinking Chrome and Android as platforms for privacy and developing new approaches like purpose-built technologies to support key use cases. And we're doing this in a transparent, open, and collaborative fashion, consulting with stakeholders from across the industry to ensure that this vision works for everyone. There are three main advertising-focused APIs which are being developed for both web and Android. We generally expect they'll be most useful at different stages of the marketing funnel, as you see from top to bottom here. Today, we'll do a deep dive on the Attribution Reporting API. Before we talk about how the API works, let's first level set on the use cases. The Attribution Reporting API is meant to enable conversion measurement. The goal of conversion measurement is to understand how much real-world value is being driven by interaction with ads. For example, if a user searches for a product and clicks on an ad, do they actually purchase the item? By joining ad interactions like clicks and views with conversions like purchases, we can measure the value of showing ads. This helps advertisers understand the return on investment for different types of ads to make better decisions about how to spend their advertising budget. Publishers need to be able to demonstrate the value of showing ads on their app or site versus somewhere else on the internet. And finally, ad texts that, as a set of ad providers, help connect advertisers and publishers, facilitate measurement on ad performance, and optimize the advertising budget being spent. Two primary use cases of measurement are reporting and optimization. Advertisers can use reporting insights to tweak their buying strategies and can use optimization strategies to finely tune bidding for specific ad slots. The good news is that these core measurement goals are aligned with privacy. You don't need data about individual users to drive these business decisions. Rather, you're looking for large patterns that are robust to outliers. So, how does the ecosystem solve these use cases today? Today, the platform includes persistent cross-site identifiers like third-party cookies in Chrome or device IDs on Android. Ad texts can associate a user's behavior with these identifiers. For example, let's say a user watches an ad on a publisher site, clicks on the ad, navigates to the advertiser's site, and then makes a purchase. All of these events are associated with an identifier and sent off of the device to be joined or enriched with other signals later. The value to ad tech and advertisers is straightforward. They want to understand whether their advertising campaigns are effective. There is value to users as well, where seeing more relevant ads improves the user experience on the internet. But this can be taken too far, for example, when these user actions are joined with other signals off the device without clear user controls. A very simple solution to this would be removing these cross-site or cross-app identifiers like third-party cookies or device IDs. However, to play that out a bit, today ad techs have options other than platform-supported identifiers to track users. For example, they could choose to use device or browser fingerprinting that tracks users across apps and sites without any controls. These options may be lower fidelity and lower availability than platform-supported identifiers, but we can't ignore their existence. Instead, Privacy Sandbox supports purpose-built platform APIs like the Attribution Reporting API. The aim is to better provide alternatives for legacy technologies like third-party cookies, and it's vital to have these privacy-preserving alternative paths that support the needs of the ecosystem. If we don't, we risk an increase in the unwanted tracking we talked about earlier. It's important that we avoid such an outcome as we work hard to phase out legacy technologies and strengthen user privacy. So, how does the Attribution Reporting API work? When a user views or clicks on an ad, the ad tech registers the event with the API, which is available on the Chrome browser or the Android device. If the user later engages with the advertiser, for example, makes a purchase on the advertiser's site or installs the advertiser's app, then the ad tech can register the conversion with the API. The API sends out event-level and summary reports, which have randomized delays, structural limits, and noise built in as privacy-preserving measures. Diving into the two different report types in more detail, event-level reporting will likely be used for insights that relate to ad optimization and attribution modeling. Event reports, as their name suggests, provide high-fidelity line-item data on the ad event that happened. This is paired with limited, noisy data about the conversion. Additionally, event reports are sent on a timing delay to further prevent the ability to use them to identify the user. For example, with event reports, the ad tech could understand that a conversion was attributed to a specific ad impression but would receive limited information on what that conversion represents. Summary reporting, on the other hand, will likely be used for higher-level insights like ROI analysis or campaign performance reporting. Summary reports support more flexible reporting needs and conversion data, such as purchase value, but in an aggregated report. Ad techs have flexibility on what reporting dimensions they want to include on both the ad event and the conversion, and then summary values for each set of dimensions is added to the report. For example, the ad tech could use summary reports to understand the total number of conversions and revenue associated with a specific ad campaign. The more granular dimensions the ad tech sets, the more impact applied noise will have on the summary report. Here's an example of how event-level reports are generated and sent to ad techs. When the ad click happens, ad tech calls the attribution reporting API and registers a new attribution source. The ad tech can set a source event ID which identifies that specific ad event. When the conversion happens, the ad tech calls the API and registers a new trigger. The ad tech can set trigger data, which represents a very limited amount of data about the conversion, for example just the high-level type of conversion like a purchase versus a mailing list signup. If the trigger is matched or attributed to the source, the API will generate and send an event-level report. Our privacy protections for event-level reports fall into three categories. Structural Limits. The report will contain the source event ID, which can be tied back to the specific ad clicker view, but very limited trigger data, which is not enough information for the ad tech to link to a specific conversion and perform a cross-site or cross-app join. Noise and Rate Limits. We apply noise to every event report and we limit the number of reports an ad tech can receive and the number of ad techs that can measure on a given publisher. Reporting Windows and Delay. Reports cannot be sent on data more than 30 days old and ad techs must choose which reports are highest priority. Additionally, reports are sent with a randomized delay. Now let's switch gears and talk about summary reports. Imagine the advertiser wants to know the total number of conversions for each type of campaign they run and the total purchase value attributed to ads served in each geo area and for each product category. When the ad tech calls the API to register the ad click or the source, they will also include aggregation keys, which represent the source side dimensions they want to report on. In this case, that's the campaign and the geographic region where the ad was served. When the ad tech calls the API to register the conversion or the trigger, they will include aggregatable trigger data, which represents the trigger side dimensions they want to report on. In this case, that's the product category of the purchase. They'll also include aggregatable values, which represent the metrics they want to report on. That is the purchase count and the purchase value in this example. Similarly to event level reports, if the trigger is attributed to the source, the API will generate and send back an encrypted aggregatable report. However, unlike event level reports, there are few extra steps before the ad tech can get back a readable summary report. The aggregatable reports the ad tech receives are encrypted, so the ad tech can't read them. Instead, the ad tech must send them to their aggregation service to process in a trusted execution environment or TEE. The TEE will decrypt the reports, sum them up, add noise, and return the summarized values. In this example, the true purchase value of all conversions was $50,000, but the report returned $53,000 due to randomized noise added. To recap, our privacy protections for summary reports fall into three categories that are very similar to those for event level reports, just implemented in a different way. We have structural protections, noise, and rate limits in place to prevent summary reports from being used to identify our user across multiple sites or apps. Additionally, summary reports are not sent on data from more than 30 days ago and are sent with a randomized delay. Now I'll pass it to Erin who will walk you through attribution across web and app. Thanks, Dylan. Now that we know a little more about what the Attribution Reporting API is and how it works, let's talk about what I think is one of the most exciting features of the Attribution Reporting API. Measurement across mobile browsers like Chrome and Android apps. Privacy Sandbox natively supports cross web and app attribution. Today, we will use Chrome as an example because cross web and app attribution is currently available in Chrome Origin Trials. The Privacy Sandbox on Android supports integration with any mobile browser. Additionally, the cross web and app attribution proposal is generic enough to be supported on other mobile platforms, although the initial focus is on Android support, so that's what will be covered today. So what does it mean to perform web-to-app attribution? It means if a user clicks an ad in a Chrome mobile browser and then goes on to later make a purchase in an Android app, the Attribution Reporting API can directly attribute that conversion performed in the Android app to the ad shown in the Chrome mobile browser. So how is this implemented in code? Let's walk through an example. First, you'll want to make sure that cross web and app measurement is available in your web code base. To do this, when you register an event, include the header Attribution Reporting Eligible in your request to the Reporting Origin. The browser will broadcast if OS level support is available to the Reporting Origin server with a dictionary structured request header. Then, you will want to continue to register that the ad was clicked, otherwise known as registering a source. If OS support is available, the Reporting Origin should send back a response with the string structured header Attribution Reporting Register OS source, which includes the URL indicating where to register the source. The response is similar to how a Reporting Origin would respond when performing web-to-web measurement, but in this case it indicates that the Android OS should handle the reporting instead of the Chrome browser. The response metadata includes both web and app destinations. These destination fields specify the website and app package where Attribution will be triggered for the source. Under the hood, the Attribution Reporting Register OS source header signals the Android OS to call Register Web Source, which takes the metadata from the header and packages it up to send to the ad tech URL specified in Attribution Reporting Register OS source. The developer does not need to call Register Web Source directly. Now you have finished registering your source for web-to-app Attribution. Then, once the user makes a purchase in an Android app, you'll want to capture that in your Android code base by invoking Attribution Reporting API's measurement manager object to call the Register Trigger function. This is the same as how you would register a trigger in an app-to-app measurement case. Now that you have registered your source on Chrome and trigger on Android, the Attribution Reporting API can connect the pieces and credit the ad shown to the web to the purchase made in an app. This also works the other way. If a user clicks an ad in an Android app and then completes the purchase on a Chrome mobile browser, that attribution can be performed as well. The implementation steps are similar to the web-to-app use case that we just went over. First, you would start by calling Register Source on Android, the same as you would for an app-to-app use case. Then, use the Attribution Reporting eligible request header to determine OS support on Chrome. If OS support is available, use the Attribution Reporting Register OS Trigger string-structured response header to register the trigger and include the URL to which you want your trigger data to be sent. In the same way, you can use the OS support headers on Chrome to indicate that the Android OS should perform the attribution. The source ads shown on Android and the conversion made on the Chrome mobile browser are now able to be attributed to one another. For more information on cross-web and app attribution, including privacy considerations, check out the documentation linked in the description of this video. And now, I will hand it over to Georgia to tell us how to get started with enrollment. Now that you know a little more about the Attribution Reporting API and the Privacy Sandbox, we would love for you to check it out for yourself. You can start by enrolling your company and setting up an origin trial, developer preview, or beta release in your development environment. What is developer enrollment? That's a great question! Developer enrollment is a new process we are rolling out in June for the relevance and measurement privacy sandbox APIs across Chrome and Android. We want to make sure these technologies are used as intended and with transparency. And this process helps us do that by verifying the entities calling the APIs and gathering data needed to properly configure and utilize the APIs. Completion of this new process will be required starting in August. You may already know that enrollment is currently required for access to the Android relevance and measurement APIs, and you can continue to use this existing process until the new one launches. Now, why are we asking you to enroll? That's another great question! Protecting user privacy is paramount to the Privacy Sandbox. This enrollment process adds an additional layer of protections on top of the structural restrictions enforced within each API by adding transparency to who is collecting the data and limiting how much data they can receive. To provide auditable transparency, enrollment information about the company will be made public. And to limit how much data an API caller can receive, we've already incorporated rate limits for each developer into the relevance and measurement APIs. Enrollment allows us to better enforce those rate limits by using an independent third party for developer verification purposes. This verification process will also help ensure that one developer can't impersonate another developer and limit their usage of the APIs. Lastly, this effort brings the Privacy Sandbox Chrome and Android ecosystems to a shared enrollment process, which ensures you won't have to duplicate verification efforts across platforms. During enrollment, you will provide contact details, business identification, including your organization's DUNS number, other inputs necessary for your API or server configurations such as sites or SDKs used to call the APIs, and the APIs you are requesting to use, for example, attribution reporting. We intend for this process to be lightweight so that developers can easily set up and begin testing. Extra assistance in transitioning to this new enrollment process will be provided for currently enrolled Android testers, and Google support channels will be available to address any enrollment-related questions. To enroll, developers will need to agree to specific statements, also known as attestations, about the usage of the enrolled Privacy Sandbox APIs. This helps reduce the risk of these APIs being used improperly, beyond their intended purpose to enable key business use cases while limiting cross-site tracking. To learn more about enrollment and attestations, you can read through the documentation on our Chrome and Android developer sites. You can also learn more about the Privacy Sandbox by checking out other Io talks including preparing for the end of third-party cookies and 10 things to know about the Privacy Sandbox on Android. Thanks for watching!