Your Guide to Protected Audience API

Google is coming for your cookies, and not the tasty kind lying safely in a tin in your kitchen, but the third-party ones that sit in your browser, watching, waiting, and storing all kinds of information. This has major implications, some good and some bad, for marketers and consumers alike. It also means that many of our old tools will soon become obsolete. However, you don’t need to crack open your tin of real cookies and start stress-eating yet. There are plenty of new tools on their way, one of which we’re going to get into today: The Protected Audience API.

In this article, you will learn:

• What the Protected Audience API is.
• What role it will play in the cookieless future.
• How the Protected Audience API relates to the Topics API.
• Ways you can use the Protected Audience API in your cookieless marketing strategy.

What is the Protected Audience API?

Let’s start by figuring out what the Protected Audience API (PA API) is. It is part of the Privacy Sandbox initiative, which is a project aimed at improving online privacy while still providing advertisers with the tools they need to reach users with tailored advertising. It has been developed and fine-tuned by Google over the course of the last 3-4 years, changing its name three times—starting with TURTLEDOVE, then FLEDGE, before finally landing on the Protected Audience API. Its development has been based on feedback from the industry, and RTB House was the only company (other than Google) which authored mechanisms implemented in PA API as a whole.

Protected Audience API is designed to allow advertisers to personalize their ads based on custom audiences and disallow them from getting user-specific information, which sits securely stored on the user’s device or in a safe cloud environment.

How does the Protected Audience API work in a retargeting context?

The protected Audience API combines first-party data and the ability to bring the bidding process to the browser or a safe cloud environment in order to enable advertisers to deliver personalized adverts without privacy headaches.

Initially, the advertiser and its vendor (DSP) need to define interest groups for the campaign. Then, users end up being assigned to those interest groups after expressing a predefined set of behaviors (for example, by visiting three different football kit models and putting one of them in the basket without checking out) by triggering the JavaScript call “joinADInterestGroup().” Under these circumstances, the browser records:

• The name of the interest group: for example, “football-jersey,”
• The owner of the interest group: for example, ‘https://dsp.example,’
• User signals (saved on the user’s device): e.g., favorite football club,
• Interest group configuration information to allow the browser to access bidding code, ad code, and real-time data if the group’s owner is invited to bid in an ad auction.

The DSP doesn’t receive any information about the user beyond the fact that they are part of their specific interest group. However, as IDs of products which the user has interacted with are stored in the user’s browser, a highly personalized banner can be automatically displayed when the auction is won. Anonymity is further assured by a k-anonymity feature, which prevents an interest group from being created until a sufficient number of users are part of it; at the time of writing, that is 50 users.

Aside from the personalization ensured by RTB House’s PLTD (Product-Level Turtledove), another mechanism authored by us, OBTD (Outcome-Based Turtledove), allows us to automatically estimate how much DSP should bid to reflect items’ value and user’s likelihood of conversion. Pieces of information like the value of the items displayed and/or put in the basket are stored in the user’s browser to be later accounted for during the on-device auction by using logic predefined by DSP.

After all that, when bids are finally placed, they need to be analyzed to draw a winner. To do this, the seller provides the browser with code to score bids, which includes each bid’s value, the ad creative URL, and other data returned from each buyer. This score measures a bid’s desirability and rejects any ad that can’t beat a contextual ad winner.

Now, a SupplySide Provider (SSP), or the site itself, can run an auction based on their own logic, which can include setting preferential treatment for certain buyers and preventing certain types of ads from displaying next to their published content.

Once a bid wins, the ad is displayed on the user’s device within a fenced frame, which restricts communication between the website and the embedded ad, thus preserving user privacy. The final outcome of the bid is then reported to the seller and buyer.

What role will cookies play in the Protected Audience API?

While third-party cookies will be soon eliminated from Chrome and substituted with the Privacy Sandbox, first-party cookies will continue to play an important role. First-party cookies are those that collect specific information about a user’s actions on a website for the publisher to use. Unlike third-party cookies, these do not track users across multiple sites, but their collection and utilization is contained within a single website. That’s why this partitioned approach will be heavily leveraged by a range of cookieless solutions.

What makes Protected Audience API special is that, while harnessing first-party data, it is capable of extending its reach privately to other publisher’s websites, assuming they (or their SSPs) use PAAPI auctions.

This replicates much of the functionality of third-party cookies without the challenges posed by cross-site tracking, as individual users are going to be indistinguishable from one site to another.

What are the potential benefits and risks of the Protected Audience API?

Alright, so now we know how it works, let’s take a look at the potential benefits and potential risks of the Protected Audience API:

Potential Risks

There are a few risks and challenges posed by the Protected Audience API:

• Protected Audience API is only available for Chrome users—other Chromium-based browsers (such as Edge or Opera) might want to benefit from what Privacy Sandbox has to offer, but at the time of writing, only Chrome will host PAAPI.
• No cross-device capabilities—those who want multichannel solutions will need to accept that the current shape of PAAPI relies on capturing interest groups across a single device only.
• Protected Audience is a complex API—and if advertisers don’t have a large team and plenty of resources to dedicate to cookieless buying, they should consider working with DSPs like RTB House, who have spent the last 3-4 years perfecting their Protected Audience API-based retargeting solution.

Benefits of the Protected Audience API

While these challenges are real, they are offset by the potential benefits on offer.

• Privacy-friendly by design—by reducing the privacy concerns associated with third-party cookies, advertisers will be able to overcome one of the biggest objections users currently have with ads and appease regulators who are continuously developing new laws which restrict many existing advertising solutions. With ongoing oversight of CMA (British Competition and Markets Authority) during the Privacy Sandbox’s development and of its open-source code, solutions based on it are future-proof.
• Ads personalization and bid evaluation is preserved—thanks to RTB House’s proposals, the foundational rules of retargeting won’t cease to exist, as PAAPI allows both displaying highly personalized ads and accounting for the value of items that users have interacted with.
• Huge scale from day one—PAAPI will be available all across Chrome, the most popular browser in the World. Data regarding users who have opted in will be accessible, with minimal traffic lost once cookies are retired.
• Enhanced control over how ads are delivered—the system gives publishers more control over what ads are actually displayed on their site. This can help to limit the risks posed by malicious advertising and improve the overall quality of ads on a publication, which may help to improve their long-term effectiveness.

Protected Audience API vs TopicsAPI

What about the other major tool in the Privacy Sandbox’s belt: TopicsAPI? Well, in some ways, it works similarly to the Protected Audience API. It’s designed to group users based on their perceived interests, providing a way for advertisers to connect with them. However, the way it groups users is different.

Topics API labels websites according to its fixed taxonomy and, based on the user’s browsing history, delivers some high-level information about their interests. It’s a straightforward tool designed only to be used for simple upper-funnel campaigns. PAAPI, on the other hand, is much more sophisticated—allowing you to tailor your own interest groups and even enhance its capabilities with what other mechanisms have to offer. If used correctly, PAAPI can be strengthened with signals from Topics API or other cookieless standards. This doesn’t mean that the Topics API is any better or worse than the Protected Audience API; it is just another tool that advertisers can use to reach users in a privacy-friendly manner.

What is the Protected Audience API Implementation Timeline?

The Protected Audience API is currently undergoing full-scale testing, called General Availability. The next big milestone to look out for is the depreciation of third-party cookies for 1% of Chrome users, which is slated for Q1 2024.

As the cookieless depreciation timeline advances, the industry will have an opportunity to test and review the different solutions based on Google Privacy Sandbox, including the Topics API and Protected Audience API. This feedback will help to improve these concepts over time.

The best time to prepare for the cookieless was yesterday

The next best time is today. While cookieless advertising is a huge challenge, the solutions offered via the Privacy Sandbox, like the Protected Audience API, also represent a big opportunity. That’s why it’s so important to start preparing for these changes today. To help you get started, we’ve created a checklist for the cookieless future:

However, this is just the first step. If you want to take your cookieless retargeting strategy to the next level, you should be looking to work with partners who understand the Privacy Sandbox. Partners like RTB House. We have been involved in the Privacy Sandbox since the beginning and have helped to shape the Protected Audience API through our work on the Turtledove and FLEDGE proposals. Our proprietary Deep Learning algorithm will make an even bigger difference in times when data about users will be more scarce and fragmented across the open web.