The Protected Audience API is the most critical component of the privacy sandbox for audience addressability.
As we’re all aware, Google has announced intentions to remove the third-party cookie from the Google Chrome Browser, outside of small groups of Related Web Sites, sometime near the end of 2024.
The date is hard to identify precisely, as it will proceed with a phase-out after the end of a study period conducted under the binding supervision of the United Kingdom Competitive Markets Authority and a subsequent 60 or 120 standstill period.
The speed of the phase-out after the end of the standstill is unknown, however, if it were initiated on July 1st and lasted 120 days, it would have begun with the mid-November Chrome release, just in time for Thanksgiving dinner and Black Friday and Cyber Monday holiday shopping kick-off.
In the Q3 2023 progress report, the CMA provided very explicit guidance that the date is currently not possible to pin down, as the beginning of the standstill is contingent on addressing any competitive concerns that arise in the test period, which begins in Q1 2024.
This has all been quite well documented in other sources, however, there remains widespread unfamiliarity with what replaces the third-party cookie (and non-partitioned local storage) for non-authenticated audience addressability in Google Chrome browsers and how publishers can participate in the testing beginning in 2024.
If publisher feedback is to be incorporated before the standstill, publisher participation is critical to achieve this.
What Is PAAPI (Protected Audience API)?
The Protected Audience API (PAAPI) is the most critical component of the privacy sandbox for audience addressability. It is a towering technical achievement — in its infancy and with growing pains ahead — yet it holds the promise of completely reorganizing the advertising technology workflow and marketplace dynamics for non-authenticated web and app users.
Alongside the Topics API and Attribution APIs, PAAPI is intended to preserve the ability of publishers to monetize Chrome users while simultaneously protecting those users from the perceived intrusiveness of the combined weight of the targeting capabilities of the existing advertising technology marketplace.
For the typical publisher, a non-authenticated Chrome user generates approximately thrice the advertising value of users of other browsers, largely because of these capabilities. This means, that as Chrome has about half the user market share, its users represent three-quarters of publisher advertising revenue.
Nothing less than continued access to a free and open internet is at stake. If these APIs are not effective, the likely outcome is widespread gating of information behind registration for publishers to remain viable; or for a transition of content and advertising revenue to the panopticon-like walled gardens of enormous platforms.
How Does PAAPI Enable Audience Targeting Sans Audience Tracking?
So how does the Protected Audience API allow audience targeting without audience tracking?
The answer is quite simple; when an entity calls joinAdInterestGroup(), the user stores on its device that interest group membership. Interest group membership could be many things, including interest in a product, interest in certain content, or offline data onboarded for logged-in users.
With this feature in use by GAM, publishers who wish to use PAAPI and continue to use GAM, have no current choice but to use GAM as the top-level seller.
When the PAAPI auction is initiated, rather than an indication of that group membership ever leaving the browser, the DSP bidding logic is downloaded to the device for an on-device auction to occur. This auction will be configured by JavaScript on the page that calls runAdAuction(). That javascript should be aware of the best available existing bid; often called the winner of the “contextual auction,” which is a bit of a misnomer for authenticated users.
For most publishers, 93% in the United States, the winner of the contextual auction will simply be the ad that GAM selects in the existing workflow. A feature was developed by the Chrome team, at the behest of the GAM team, to allow the ad server to nontransparently pass the contextual win price to its on-page javascript library. With this feature in use by GAM, publishers who wish to use PAAPI and continue to use GAM, have no current choice but to use GAM as the top-level seller.
By design, GAM uniquely knows how to identify the highest bid between its contextual auction choice and the PAAPI participants. So for now, a publisher looking to test PAAPI should test the PAAPI auction as initiated by GAM. Also, if a publisher is interested in AdWords participation in their PAAPI auction, they must choose GAM as a top-level seller. AdWords is responsible for the vast majority of current PAAPI transactions and restricts its PAAPI buying to AdX.
Describing an Entity as Top-level Seller
So what is it meant to describe an entity as top level seller? The top-level seller initiates many independent PAAPI auctions, compares each of those auction winners to the contextual winner, and chooses an ad to display.
In the case of GAM, its on-page gpt.js library will accept component seller configurations, via its API, for inclusion as one of the independent PAAPI sub-auctions. One of these component sellers will always be AdX. A publisher could submit their component selling auction configuration if they have relationships with DSPs or other PAAPI-targeting entities.
This auction configuration would include which DSPs to call and the location of a script that can initiate events to a special reporting API and assign each buyer bid a desirability score. The most accessible path today for a publisher to include additional component auction configuration is to submit the configuration via the Prebid fledgeForGPT module.
Several Prebid.js bidders, including Index Exchange, OpenX, Criteo, Unruly, Magnite, Pubmatic, Triplelift, RTBHouse, Axel Springer, and others, as well as the Prebid Server module, are capable of returning auction configuration to Prebid.js in conjunction with their existing bids. These bids are then conveyed to gpt.js by Prebid.js if the publisher has installed and configured the fledgeForGPT module and activated particular ad units and bidders for the PAAPI auction.
Keep Prebid.js Updated
For this workflow to execute, publishers should be on very recent versions of Prebid.js. New capabilities are continuing to be added, including parallel execution and support for interest group anti-targeting, also known as negative interest groups, so it will be important to keep up to date on Prebid versions to participate.
We also anticipate Amazon Publisher Services may one day enter the fray and provide its component seller auction configurations for GAM submission. Savvy publishers who haven’t opted out may have already noticed they are selling PAAPI impressions to AdX and these are reflected in their GAM reporting interface.
As noted, this workflow is in its infancy and is missing several key components that publishers may be accustomed to. For example, many publishers can determine their entire advertising revenue by a report in GAM, indicating how many impressions and revenue are associated with each header bidding channel, AdX, and direct reservation line items.
GAM does not currently provide this information to publishers for the portion of impressions and revenue won in the PAAPI auction by a non-AdX component seller, and therefore a publisher is incapable of discrepancy reconciliation with the entities acting as component sellers.
There is no on-page event to listen to where one could form their reporting. This may scare many publishers away from testing; however, I hope many others will consider it a call to action. We must work together to uncover the requirements we have for PAAPI workflows before we lose our existing ones.