 The Protected Audience API is part of the Privacy Sandbox, a series of proposals to satisfy cross-site use cases but without third-party cookies or other tracking mechanisms. The Protected Audience API is designed to support an advertiser who would like to build up an audience, in other words a group of people they want to show an ad to. And later the advertiser can target and add to that audience as a whole without being able to learn the browsing habits of any individual's behaviour in that audience. This audience data can be shared across sites in a privacy-preserving manner to run a remarketing ad campaign allowing the advertiser to connect with a group of people who previously interacted with their website. Now for example, imagine you're looking at running shoes in an online shoe store but you don't make a purchase and then at a later time that advertiser may be interested in showing you an ad for those running shoes while you're visiting a different site. So why do we need the Protected Audience API? Well, understanding user interests can result in more relevant ads than simply choosing ads based on contextual data. Traditionally ad platforms have learnt about user interests by tracking their behaviour across sites and with the deprecation of third party cookies the ad techs will lose that ability. So we need a new way to present relevant ads to users but without tracking them across the web. The Protected Audience API is the replacement API to run an ad auction involving cross site audience data while preserving user privacy. With the Protected Audience API, the user's browser, not the advertiser or ad tech platform holds information about what the advertiser thinks a person is interested in. And when a user is visiting an advertiser site, the advertiser has the opportunity to add the user to an interest group. This audience data becomes stored on device and it becomes available in a secure execution environment to the advertisers only during an ad auction. At a later time when the user visits a publisher site, a site that displays ads, the user's browser runs an ad auction where the buyers and the sellers business logics are executed in a secure environment. In this secure environment, like a workload running locally in the user's browser or a trusted execution environment, user data such as the interest group data is protected. The website the user is visiting and the third parties participating in an ad auction cannot learn about the user's ad interests. And this allows advertisers to show relevant ads while keeping your interests and browsing activity private. Now in this example, the advertiser, the shoe store doesn't learn what pages your viewing and the ad publisher, the news site doesn't learn about your interest in running shoes. So how exactly does the protected audience API actually work? Well, let's see an example from start to finish. Now I'll show you some JavaScript here, but don't worry if you're not a coder, you should still be able to follow along. In this example, a user visits a page on a site that wants to advertise its products, you know, like the online shoe store I mentioned before, and the advertiser site or the ad tech it uses to participate in an ad auction on their behalf, such as a demand side platform, asks the user's browser to join an ad interest group by calling, well, join ad interest group. And when adding a user to an interest group, the advertiser specifies the ad associated with the interest group and the location of the bidding logic to be executed when the ad auction runs later. The buyer can also add contextual data to the interest group, which becomes available when the buyer's bidding logic is executed in a secure environment. Later on, the user visits a site that displays ads, such as a news publisher, and the user's browser runs an auction to choose an ad. And the seller in this auction might be the site itself or a third party acting on its behalf, such as a supply side ad platform. The buyers are third parties bidding for the site's ad inventory, you know, the space where ads can be displayed, such as demand side platforms acting on behalf of advertisers. The seller in this ad auction has two jobs, choose which buyers can participate and choose which bid is most desirable based on each bid's price and other metadata. The seller initiates the ad auction by calling run ad auction with data including the buyers that are participating in the auction, the seller's contextual data, the location of the seller's ad scoring logic, and the location of the seller's real-time signal server. When the auction starts, the browser reads the interest group data of the buyers participating in the auction. And then the browser fetches the bid generation logic along with real-time signals from each buyer. The browser executes each buyer's bidding logic in a secure environment like a workload or trusted execution environment and supplies the logic with the audience data. Each bidding logic returns a bid price which signifies how much the buyer is willing to pay for the interest group. And then the browser fetches and executes the seller's scoring logic in a secure environment where the seller has the opportunity to provide a desirability score of each buyer's bid. And finally, the browser will select the bid with the highest desirability score as the winner of the ad auction. And after the auction, the winning ad is returned. And the winning ad is rendered into a HTML element called a fenced frame which severely restricts the communication between the Embedder and the ad. And this makes sure that the publisher cannot learn what ad has been rendered to the user. So that's the Protected Audience API in a nutshell. To find out more, take a look at the article here. We have a demo that shows a simple example of using the Protected Audience API to join an ad interest group and then initiate an on-device auction. If you have comments about the API design, file an issue on the explainer. And if you have feedback or questions about this video or, you know, 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. So thanks for watching and be sure to check out the other videos in the Privacy Sandbox series.