A Guide to Protected Audience API (Formerly – FLEDGE)

Google’s Protected Audience API (PAAPI) gives hope for marketers navigating the cookieless future.  

PAAPI, emerging from Privacy Sandbox, changes remarketing by prioritizing user privacy without compromising targeted campaign precision. This groundbreaking API is not just another tool—it’s a shift towards more ethical, transparent advertising practices. 

In this article we explore Protected Audience API, its mechanics, benefits, and the transformative impact it promises for the advertising ecosystem.

What is Protected Audience API? (Formerly – FLEDGE)

The Protected Audience API (PAAPI) is a part of the Privacy Sandbox initiative. It helps enhance online privacy while enabling advertisers to deliver personalized ads. 

Protected Audience API prevents third parties from tracking user browsing across websites. The browser can select relevant ads from websites the user has visited through on-device auctions enabled by the PAAPI.

This API allows advertisers to tailor their ads for specific audiences without accessing individual user data. Instead, this sensitive information is securely stored either on the user’s device or in a protected cloud environment, ensuring user privacy is maintained.

Developed by Google over approximately three to four years, its evolution involved several name changes, from TURTLEDOVE to FLEDGE, and finally to the Protected Audience API, reflecting its refinement based on industry feedback. 

Note: RTB House, alongside Google, contributed to the development of mechanisms within the PA API.

Google FLEDGE explained

FLEDGE (First Locally-Executed Decision over Groups Experiment) was a Privacy Sandbox proposal to let marketers target ads to custom audiences, based on audience members’ previous mobile app or web engagement, in ways that limit third-party data sharing. 

Now FLEDGE has been renamed to Protected Audience API.

Who is the protected audience API for?

The Protected Audience AP is for stakeholders in the digital advertising ecosystem who are preparing for a future without third-party cookies, focusing on privacy-friendly ways to understand and engage audiences.

However, PAAPI is designed primarily for advertisers, publishers, and adtech platforms:

• Advertisers who need sophisticated tools for targeting and retargeting users without relying on third-party cookies, which are being phased out due to privacy concerns.

PAAPI enables them to create and manage custom audience segments based on first-party data, facilitating personalized advertising campaigns while respecting user privacy.

• Publishers looking to offer advertisers the ability to reach their desired audience segments directly on their platforms, without compromising the privacy of their users.

By leveraging first-party cookies within the framework of PAAPI, publishers can participate in privacy-preserving ad auctions that maintain user anonymity across sites.

• Adtech platforms that are adapting to cookieless advertising by developing solutions that comply with new privacy standards. 

PAAPI provides these platforms with a mechanism to support their advertiser and publisher clients in targeting and retargeting efforts, ensuring that they can continue to offer valuable advertising capabilities.

Why do we need the Protected Audience API?

Traditionally, ad platforms tracked user behavior across multiple sites to understand interests, but this raised concerns about privacy and tracking. 

With the Protected Audience API, browsers can facilitate ad targeting without tracking users across sites. This benefits content publishers by enabling them to generate ad revenue without relying on cross-site tracking methods. 

Ultimately, the API ensures that user interests are stored locally on their device, enhancing privacy while still allowing for effective ad targeting based on user preferences.

When will the Protected Audience API be live?

The Protected Audience API is currently in Beta and available for testing on public devices. It’s expected to be generally available in the second half of 2024.

The origin trial for Protected Audience API was announced in Q1 2022 and started in April 2022. The Privacy Sandbox timeline shows that from the 3Q of 2023, most of the capabilities for the Protected Audience API are launched and available for 100% of Chrome traffic. 

However, Chrome expects refinements and optimizations as more companies test and use the APIs over time.

How Does the Protected Audience API Work?

The Protected Audience API uses interest groups to enable sites to display ads that are relevant to their users. Each interest group providing a bid is known as a buyer.

For example, when a user visits a website that sells running shoes and adds them to the cart, an interest group owner (e.g., a DSP) associated with the site creates an interest group (e.g.,“running gear”) and will ask the user’s browser to add membership for the interest group.

After that, when the same user visits the publisher site that sells ad space (e.g., a news website). The SSP associated with the site calls for the auction and sends the ad request to DSPs, the owners of interest groups the user is part of. 

The advertisers return the bid, SSP scores the bids and returns the winning ad to the ad server, and then it is rendered on the website. Since it is an in-device auction, the bidding code and bid scoring logic are downloaded to the device, and the browser will run the auction and return the winning bid.

Source: Privacy Sandbox 

What is an interest group?

Protected Audience API interest groups contain a group of users with common interests to be used in remarketing. Every PAAPI’s interest group has an owner who creates it for different user cases. 

Note: The data in the interest group can be updated and enabled for up to 30 days. 

In the table below you can see examples of different types of Protected Audience API interest groups, owners, and specific use cases.

Within Google Chrome, there are limitations on the number of interest groups created by a single owner and the total number of owners who can create interest groups. 

More specifically:

• 1000 interest groups per owner. Meaning that a single entity, whether an advertiser, publisher, or ad tech company, can create up to 1000 distinct interest groups.

• 1000 interest group owners. This limitation pertains to the number of entities (owners) that can create interest groups within Chrome. For example, if multiple advertisers, publishers, and ad tech companies use the Protected Audience API, collectively, they can create up to 1000 unique interest group owners.

Note: These limitations are not strict restrictions but rather guidelines to ensure the system operates smoothly and efficiently. They are designed to prevent excessive usage that could impact performance or overwhelm the system. In regular operation, most users or organizations would not encounter these limits. 

What is a buyer?

In the Protected Audience API, a buyer refers to a party that possesses an interest group and participates in ad auctions. 

For example, an advertiser may directly act on its behalf, while a demand-side platform (DSP) may represent multiple advertisers, and an interest group owner may work on behalf of several advertisers. 

Buyers undertake 3 main tasks: 

1. Deciding whether to join an auction.
2. Selecting ads and determining bid amounts. 
3. Reporting the results of the auction. 

These tasks are automated through code provided by the buyer, which is executed during the ad auction process within the Protected Audience API.

How do the ad auctions work?

In simple terms, ad auctions in the Protected Audience API involve:

• Sellers initiating auctions.
• Inviting buyers to bid on ad space.
• Evaluating bids.
• Displaying the winning ad in a privacy-preserving manner.
• Reporting the outcome to the relevant parties.

To showcase the process in more detail, here’s the workflow of how the Protected Audience API ad auctions work:

1. When a user visits a website that displays ads, the seller (such as a publisher or SSP) starts an auction to sell ad space.

2. The seller determines which ad space is available for sale and invites buyers (owners of interest groups) to participate in the auction. The seller also sets criteria for the ad and provides code to score bids.

3. Each invited buyer’s code runs to generate a bid, providing details like the bid’s value, URL for an ad creative, and other relevant data. Buyers can access real-time data from their Key/Value services during the auction.

4. The seller’s code evaluates each bid and selects a winner based on criteria like bid value and other data. The seller may use their Key/Value service for real-time data. If no bid surpasses a contextual ad’s value, the contextual ad wins. 

5. The winning ad is returned as a fenced frame config object, preserving privacy. The config object displays the ad creative, hiding the URL from the seller and publisher. Alternatively, if the resolveToConfig flag is not set, the winning ad is returned as an opaque URN that can be used to render the ad in an iframe.

6. The auction outcome is reported to the seller and winning buyers.

Protected Audience API and Remarketing

The Protected Audience API enables retargeting in a privacy-preserving manner by using first-party data and moving the bidding process to the browser or a secure cloud environment. 

This process begins with advertisers and DSPs defining interest groups based on user behaviors. Users are then assigned to these interest groups through a JavaScript call, which records details like the interest group name, its owner, user signals, and configuration information for bidding and ad delivery—all stored locally on the user’s device.

This setup ensures that while the DSP is aware of the user’s inclusion in an interest group, it does not have access to detailed user information, thus maintaining anonymity. The system employs a k-anonymity principle to ensure that interest groups are only formed when they include sufficient users, enhancing privacy. 

For the actual bidding, information stored in the user’s browser (e.g., product IDs and potential conversion likelihood) is used to personalize ads and determine bid amounts. 

The auction process involves scoring bids based on criteria provided by the seller, including the bid’s value and the ad’s relevance. Winning bids result in ads being displayed in a fenced frame on the user’s device, restricting data exchange and preserving privacy.

This entire process allows for highly personalized retargeting ads to be served without compromising user privacy, using on-device data and anonymization techniques.

Protected Audience API vs. Traditional Targeting Methods

Traditional targeting methods mostly relied on third-party cookies to track user behavior across websites. In this case, user data was often shared with multiple third parties, raising privacy issues and user tracking across the web.

The key distinction lies in PAAPI’s ability to deliver personalized ads by using local user data and predefined behaviors within a framework that ensures user anonymity and minimizes privacy concerns. 

Benefits and Drawbacks of Protected Audience API

Protected Audience API can be an efficient, and control-enhancing solution for digital advertising, addressing the industry’s shift away from third-party cookies while still enabling effective ad targeting and optimization.

Nonetheless, while PAAPI aims to provide a privacy-preserving method for audience targeting in a cookieless future, its current limitations and requirements may pose significant challenges for widespread adoption and effective use. 

Let’s look at the main benefits and drawbacks of Protected Audience API below. 

Benefits of PAAPI

Here are 10 main benefits Protected Audience API offers:

1. Privacy-friendly. It addresses privacy concerns associated with third-party cookies, aligning with user expectations and regulatory demands. The involvement of the British Competition and Markets Authority (CMA) and the open-source nature of the Privacy Sandbox ensure that solutions based on this API are future-proof and privacy-compliant.

2. Preservation of personalization and bid evaluation. The API maintains the ability to display personalized ads and evaluate bids based on user interactions with products, ensuring that the core functions of retargeting remain intact.

3. Immediate large scale. Given its availability across Chrome—the most widely used browser—Protected Audience API ensures a vast reach from the outset, minimizing traffic loss with the phasing out of cookies.

4. Enhanced ad delivery control. Publishers gain more control over the ads displayed on their sites, reducing the risk of malicious ads and potentially enhancing the quality and effectiveness of advertisements.

5. User privacy protection. It offers a significant advancement in protecting user privacy, enabling personalized communication without sharing user data with third parties. This is particularly beneficial for businesses concerned about privacy implications of remarketing.

6. App install ads filtering. A feature that allows app developers to filter out existing users from app install ad campaigns, optimizing acquisition costs by preventing ads from being shown to current app users.

7. User bidding signals. Allows for granular, device-level bid optimization through user bidding signals, enhancing ad platforms’ bidding strategies with privacy-centric data enrichment.

8. Greater control over the bidding process. Advertisers can choose which auctions to participate in, giving them more control over their bidding strategies and potentially improving ad performance and ROI.

9. Cost savings on DSPs. By reducing the reliance on DSPs, advertisers can save costs associated with licensing or CPM fees, providing a more cost-effective advertising solution.

10. Better targeting and ad performance. The API facilitates improved targeting by allowing advertisers to generate bids that are scored by sellers for desirability. This system ensures that the highest desirability score wins the ad placement, leading to more effective targeting and optimized ad spend.

Drawbacks of PAAPI

We’ve gathered 7 main drawbacks of Protected Audience API:

1. Limited browser support. It is exclusively available for Chrome users at the moment. This limitation means that users of other browsers, such as Edge or Opera, cannot benefit from the Protected Audience API, potentially reducing its reach and utility.

2. No cross-device capabilities. The API is designed to work on a single device basis, lacking the ability to track or target users across multiple devices. This limitation is a significant drawback for marketers seeking multichannel advertising solutions, as it restricts the ability to understand and target audience behavior holistically.

3. Complexity and resource intensity. Implementing and leveraging the Protected Audience API effectively requires significant resources and expertise. Advertisers without a large team or sufficient resources may find it challenging to use, potentially necessitating partnerships with DSPs like RTB House that specialize in Protected Audience API-based solutions.

4. Active app requirement for audience addition. Users can only be added to custom audiences when the app is active and in the device’s foreground. This requirement complicates audience targeting strategies, as it necessitates real-time or proactive audience segmentation, contrasting with systems that allow retroactive audience creation.

5. User control uncertainties. Although Android users will have control over which apps can add them to custom audiences, the specific details and implications of this user control mechanism are not fully outlined. While disruptive opt-out rates are not anticipated, the lack of clarity could create uncertainty for advertisers planning to use the API.

6. SDK requirement for advertiser-originated custom audiences. The shift to on-device audience management means that advertisers must either incorporate specific abilities directly into their app’s SDKs or utilize designated ad tech platforms for custom audience segmentation and management. This requirement represents a shift from previous practices where advertisers could manually upload custom audiences or use direct API integrations.

7. Technical and operational overhead. Similar to advertiser-originated custom audiences, ad platform-originated custom audiences also require an SDK for adding users to custom audiences. This requirement creates additional technical and operational challenges for both advertisers and ad platforms, potentially complicating the process of audience segmentation and management.

Protected Audience API vs TopicsAPI 

The Protected Audience API (PAAPI) and Google Topics API are components of the Privacy Sandbox initiative, designed to enable privacy-friendly advertising. However, they differ significantly in their approach to user grouping and information delivery. 

• Topics API enables access to predetermined user groups.

Topics API operates by categorizing websites into a fixed taxonomy and uses users’ browsing history to provide high-level interest data, making it suitable for simple, upper-funnel advertising campaigns. 

• Protected Audience API gives more control to target custom audiences.

PAAPI offers more sophistication, allowing advertisers to create tailored interest groups and enhance targeting by incorporating additional signals, including those from Topics API and other cookieless solutions. 

Simply put, while Topics API focuses on broad interest categories, PAAPI provides the flexibility to define and refine audience segments more precisely, offering a more customizable tool for advertisers aiming for targeted engagement.

GAM in Protected Audience API 

Google Ad Manager (GAM) has become a crucial platform for publishers using the Protected Audience API due to its unique integration and auction management capabilities. 

In the PAAPI framework, all bidding and auction processes occur within the user’s browser, ensuring interest group data remains private. 

GAM distinguishes itself by having a feature, explicitly developed at its request by Chrome, that allows it to non-transparently integrate the results of a contextual auction (the best bid identified outside of PAAPI) with its own bidding process. 

As a result, GAM can seamlessly compare bids from both contextual auctions and PAAPI auctions, identifying the highest bid across both platforms. GAM facilitates the auction process and ensures that publishers can include Google Ads in their auctions, representing a significant portion of PAAPI transactions. 

Essentially, publishers looking to maximize their revenue through PAAPI are incentivized to use GAM as their primary ad-selling platform due to its exclusive capabilities and integration with Google Ads.

Compliance and Privacy with Protected Audience API 

PAAPI auctions enable the use of first-party cookies in a way that allows users to remain anonymous and indistinguishable when moving from one site to another, thereby offering a solution that balances personalization with privacy.

In the Protected Audience API (PAAPI) context, first-party cookies retain a significant role, even when third-party cookies are phased. 

First-party cookies, which collect data on user interactions within a single website without tracking users across multiple sites, continue to be valuable for publishers. They enable the collection of user-specific information on-site, facilitating personalized experiences or analytics within the borders of that website. 

The PAAPI stands out by utilizing this first-party data to extend audience reach across different publishers’ websites in a privacy-preserving manner. It achieves functionalities similar to third-party cookies (targeting and audience building) without the privacy concerns associated with cross-site tracking. 

Conclusion

Protected Audience API (PAAPI) marks a significant leap towards a privacy-first future, offering a blueprint for balancing effective marketing with user privacy. 

PAAPI offers publishers a path to sustain ad revenues while respecting user privacy. Advertisers, on the other hand, gain a powerful tool for precision targeting and retargeting without infringing on consumer privacy.

Incorporating GAM with PAAPI provides a seamless, integrated auction system that maximizes ad revenue and optimizes ad delivery. This combination is indispensable for publishers looking to leverage the full potential of PAAPI (particularly for those wishing to incorporate Google Ads in their auctions).

Staying up-to-date on PAAPI’s developments is not just recommended, it’s essential. Understanding and utilizing PAAPI ensures that marketers can continue to reach their desired audiences effectively amidst tightening privacy regulations and shifting consumer expectations.

About Anete Jodzevica

Anete is a content marketing specialist at Setupad. In addition to writing articles, she works at gathering information, verifying data, and explaining complex concepts to others. Anete believes that simplicity is the key to brilliance.

View all posts by Anete Jodzevica