Recommendations For Implementing Retargeting In The Google Privacy Sandbox

Learn more about Lineate’s custom solutions for AdTech

Recently Google introduced their set of Chrome APIs named the Google Privacy Sandbox in an effort to support the AdTech industry as third-party cookies are deprecated. Since this introduction Lineate, alongside one of our long-term clients in the AdTech industry, had the opportunity to implement retargeting using the Protected Audience API of the Google Privacy Sandbox. The newness of the system, combined with downstream impacts on data sharing and reporting, made such an implementation a significant challenge. Based on our experience, we make three recommendations for companies to consider when embarking on such a project.

How It Works

The Protected Audience API allows precise retargeting for DSPs without the need to track users on the server. Instead of an identifier such as a cookie being passed down the stack to various bidders, users are assigned to interest groups (analogous to audiences targeting on the server side) within the browser itself, based on page visits and actions they perform. During an auction, a DSP can receive information from the browser if a given user is a member of a configured interest group.

To illustrate this, let’s first review the traditional process of displaying an ad on a publisher's website. It consists of four high-level steps:

1. A buyer defines a targeting audience. In the case of retargeting this audience consists of users who previously performed some actions on the buyer's website. This is generally done by capturing the user IDs with cookies.

2. A user visits a publisher’s site and an ad selection auction happens. During the auction, a DSP matches the ID to an internal database to determine if they are interacting with the targeted user.

3. The winning ad is chosen by the auction process inside SSP or a header-bidding system like prebid.js and then displayed on the publisher's site.

4. Further communication is shared for win notification, impression tracking, and click tracking. These are used for appropriate reporting and billing.

With the Protected Audience API, the process is very similar but most of the steps happen in the browser. The user’s data such as visits and identifiers are not shared with other companies. The buyer initiates a call (joinAdInterestGroup) which tells the browser a user should be placed in a given interest group. For example, “mark this user as having visited the mybrand.com page”. The browser memorizes and analyzes user visits and knows if a user is a member of the given interest group.

Auctions happen in the browser itself. When the browser calls a DSPs bidding logic, it will add interest group data from corresponding DSPs for each interest group that a user is associated with, assuming that the user has given their consent in their browser settings. Next, the browser will run the configured auction logic and notify the winner. 

The crucial difference is that the DSP and SSP are not able to do cross-site tracking or audience assignment during the request. These happen in the browser. This has far-reaching implications not just for bidding, but for downstream reporting and analysis, vastly reducing the amount of information exchanged, and affecting which information can be made available to whom and how. 

The relatively simple act of moving the auction into the browser has far-reaching consequences that need to be worked through and tested. The three main takeaways we have had on the development side are to fully investigate not just the Privacy Sandbox documentation but the historical proposals and discussions, allocate the time and resources to properly set up end-to-end test harnesses to ensure the flow of information, and to plan from the start the insights and reporting needs and what the Privacy Sandbox can share.

Understand The Historical Context In Addition To The Current Documentation

When we started the integration, the documentation of the Google Privacy Sandbox was insufficient to get the Protected Audience API (PAAPI) to work as expected. Since the Protected Audience API lives in the browser, our integration needed to occur in the prebid.js plugin. A key challenge we faced was in transferring PAAPI Auction Config objects back and forth between the DSPs and prebid.js. Several companies have done similar things and, looking at their solutions, we could confidently say that there was no standard for doing this. For example, the prebid.js PAAPI documentation suggested modeling a solution after OpenX or RTB house bid adapters. Following this advice, we found a proposal for bid request/response changes, but it was last updated three years ago. In short, there were no standard libraries or even standard answers, but reading through these older discussions proved invaluable during our implementation.

Set Up Test Harness Pages Early To Support End-To-End Testing

Moving interest groups and auctions into the browser necessitated changes to the rest of our client’s AdTech infrastructure in order to propagate interest group information to DSPs. This chain of dependencies impacts many players,  is not easy to test, and needs to be planned for early on.

End-to-end testing was one of the most challenging parts of the integration process. The Protected Audience API required changes in many system components because interest group signals need to be propagated from the publisher to the DSPs. The Privacy Sandbox had functionality to support this, but there were additional complexities that needed to be worked out and verified with partners. For example, in our case segment creation first needed to be initiated by DSPs before interest groups were propagated from the Privacy Sandbox.

We recommend setting up a test harness page for publisher simulation and another test harness page for the advertiser page. Also to save time, start looking early for AdTech partners (publishers, DSPs, SSPs) who are willing to test the new feature. Real end-to-end testing will take some time since partners also will need to make changes on their side. It requires coordination and roadmap synchronization.

Explore Insights And Reporting APIs

To test the performance of interest groups, as the next step, we recommend integrating your system with the Attribution Reporting API, which allows you to measure views, clicks, and conversions in a cookieless fashion, including the audiences targeted by the Protected Audience API. Attribution Reporting is a standalone API that focuses on multiple, but connected events that happen at different times, like ad view and ad click or conversion. This enables you to get individual attribution signals. You can ask the Aggregation Service to generate a summary report with the dimensions you need. 

The Privacy Sandbox has another reporting API tightly connected with the Protected Audience API: The Private Aggregation API. It was added in conjunction with Protected Audience and Shared Storage features and design to do cross-site measurements like “Approximately how many users have seen Content ID 123 at least 3 times?” or “What is the distribution of my auction bids?” So if you want to test individual conversion-related events look at the Attribution Reporting, if you want to do cross-site measurements, then it will be useful to explore the Private Aggregation API.

Conclusion

The deprecation of third-party cookies introduces major challenges for the existing implementation of AdTech systems. Google has released an initial version of its Privacy Sandbox for the Chrome Browser to address the large financial impact that this deprecation will have on the AdTech industry. Lineate recently integrated the Protected Audience API in order to handle user retargeting. We found this integration to be challenging due to the “early adopter” state of documentation and example code that is currently available and due to the need to simulate complex interactions between publishers and advertisers to ensure that appropriate testing can take place. Adding complexity were the challenges it posed for reporting and attribution (a problem that has particularly raised alarms on the publishing side). These factors combined mean the barrier to integration with the Google Privacy Sandbox is higher than most organizations might initially estimate. However, by looking at the reporting upfront, planning end-to-end testing from the start, and being willing to come through discussions on the evolution of the proposals, these complexities can be overcome.

Learn more about Lineate’s custom solutions for AdTech