Privacy Sandbox: What Is the Protected Audience API? 

How the Protected Audience API works 

Protected Audience, previously named FLEDGE, uses the concept of interest groups, which enables marketers to advertise to consumers who have previously visited their webpage, while protecting privacy and preventing consumers from being tracked across sites. It’ll be a welcome change for consumers to know their privacy is protected, while ads stay relevant.   

Today: remarketing with third-party cookies 

First, let’s look at how remarketing works today, using a shoe brand as an example.  

1. The brand’s DSP will drop a pixel on a webpage, for example, the shopping cart.
2. When a consumer adds some new winter boots to their cart, that pixel registers the third-party cookie ID from the consumer’s browser with the DSP.  
3. When the consumer visits a publisher’s website that sells ad space, the publisher’s SSP sends a bid request to the DSP. This bid request will include third-party cookie ID information which facilitates SSP audience matching, in this case, with the winter boot pixel.  
4. The DSP may choose to return a bid.  
5. The SSP receives that bid, runs the ad auction, and reaches the consumer with an ad for those cozy winter boots. 

But outside of this relatively basic example, third-party cookies could be used to track significantly more information about a consumer based on demographics and their browsing behaviour across sites.  

This is why the industry and Chrome are moving toward a model that preserves the value of addressability in advertising while clamping down on the potential for consumer data to be tracked by eliminating third-party cookies. 

Tomorrow: remarketing with the Protected Audience API 

With the Protected Audience API, marketers can define audiences through interest groups—you can think of them like audience segments, for example, people who added products to their shopping cart but didn’t purchase. Unlike third-party cookies, which are trackable across sites, interest groups are stored on-device in the consumer’s browser and access is restricted to the API. Audience data is not made available to marketers, publishers, or ad tech platforms.  

Let’s look at how exactly the Protected Audience API works. Again, consider a consumer who visits a shoe brand’s website looking for winter boots.  

1. The DSP will register that consumer with the browser in a privacy-safe way. The browser is then added to the brand’s interest group, for example, “Interested in Winter Boots,” which includes a reference to the DSP’s bidding logic. 
2. Later, when that consumer visits a publisher’s website, the browser starts a Protected Audience auction with the configured SSP and its DSP partners. This includes a reference to the SSP’s scoring logic. 
3. The DSP can receive real-time data from the browser to inform campaign budgeting. The DSP’s bidding logic chooses a creative and price for the “Interested in Winter Boots” interest group. 
4. Separately, the SSP can receive real-time data from the browser to understand ad quality. The SSP’s scoring logic selects the winning ad, returning it back to the browser.   
5. The browser finalises the auction and displays the winning ad.  
6. Finally, the browser reports the auction results to the SSP and DSP.  

The major distinction with Protected Audience is that it moves the ad auction from the webpage (like in the example of client-side header bidding) to the browser’s sandbox.  

All of the logic the DSP has to inform their bid is pushed to the browser, and the browser runs an auction in a protected environment. Only the consumer’s browser can see what’s happening.  

There’s no audience data shared between the publisher and the SSP or between the DSP and the SSP. The DSP won’t know which consumers are in each interest group, but the browser will, and the browser will have all the advertising logic to bid. The SSP also won’t see the interest group bids, but the browser will, and it’ll have the auction logic for scoring bids. 

Meanwhile, information about the consumer and their browsing history—in this case, that they’re interested in winter boots—is kept private and on the device. 

To further protect privacy, Protected Audience dictates that any ad creative must meet the k-anonymity threshold of an audience of at least 50 people over a set period before it’s shown. These parameters are still evolving, but currently that period is 30 days. 

K-anonymity is designed to prevent microtargeting, so you won’t ever be the first person to see a specific ad. There’s no way to create a Roni Gordon interest group. Another 49 Roni Gordons would have to be part of that group before anyone will see the ad.  

Buyers are also limited in the number of interest groups they can create, so they’ll need to be strategic in how granular they are. 

Implications for addressability in advertising 

This is a major shift in how we approach addressability. So, what are the implications? 

For marketers and DSPs, it means a fundamental change in how to think about audiences. 

Today, media buyers have a detailed picture of a consumer based on demographics and browsing or shopping history. With Protected Audience, they won’t know multiple pieces of audience information from different interest group simultaneously. They’re bidding on each interest group independently.  

An SSP’s role in an auction changes, too. Just as DSPs will bid on each interest group separately, SSPs will have to score each of those bids separately. Protected Audience will affect how exchanges enable the additional features they typically provide, like viewability or anti-fraud malware detection, and will require SSPs to innovate and adapt their solutions. 

Eventually, reporting will also change, migrating from event- or impression-level to aggregate reporting. Today, we’re used to understanding everything that happens at the auction level. That level of detail will cease to exist, and will move to noised, aggregate reporting—or a rough approximation of events.  

What’s the timeline, and how can you get started? 

In Q1 2024, Google Chrome will disable third-party cookies on 1% of traffic to assess tech readiness. Google has already kicked off testing with several ad tech providers, including Index.  

Publishers should work with their SSPs to begin testing. To support Protected Audience, publishers will need to update to the latest version of Prebid and support the fledgeForGPT module, which will require configuration changes. Other integration options are also in progress and will become available in the future.  

DSPs and agencies should get involved to better understand how PAAPI will impact audience strategies and measurement in the future. All of those pixels deployed across shopping carts on the web will have to be replaced with calls to the Protected Audience API to create interest groups.  

Moving the ad auction to the browser is a drastic change to the way programmatic has been executed to date, but it’s a welcome advancement in protecting consumer privacy. 

Take the time to educate yourself, and if you have any questions, don’t hesitate to reach out to our team. We’re here to help. 

Learn more about choosing the right addressability solutions for your business.