Google Privacy Sandbox: A Rallying Cry to Replace the Third-Party Cookie
Note: This post originally appeared on the SpotX website.
The practice of monitoring and storing user behavior, as it stands today, is rapidly deteriorating as the industry trends toward increased consumer privacy and transparency. Google announced last year that it would phase out support for third-party cookies on Chrome by 2022 and Apple began blocking third-party cookies by default nearly a year ago.
While significant measures are being taken to shift more control to the consumer, the industry’s intention is not to kill tracking and data collection altogether. Instead, web browsers and ad tech vendors are looking to educate consumers on how their data is used, and if granted permission, utilize their data in a way that does not jeopardize the user’s privacy.
As the window closes in on Google’s deprecation of the third-party cookie, a full-fledged arms race is taking place to find a safe and executable replacement. In this post, we will provide an overview of the potential alternatives to the third-party cookie being proposed in Google’s Privacy Sandbox. In subsequent posts, we will discuss the identity-based solutions being introduced by independent entities backed by industry experts like The Trade Desk and LiveRamp, as well as a new set of privacy standards available for public comment recently proposed by the IAB Tech Lab’s Project Rearc.
Google Privacy Sandbox
Google’s Privacy Sandbox is a working group that was created by Google in light of their announcement to eliminate third-party cookies. At this point, the Sandbox merely contains a set of proposals that aim to fill the void that will be left once third-party cookies are deprecated. The stated objective is to develop a privacy-centric solution that allows advertisers to maintain the quality and breadth of ad targeting options they have today: primarily retargeting, interest-based targeting, and contextual targeting.
Google first kicked off discussions with a proposal called Two Uncorrelated Requests, Then Locally-Executed Decision On Victory (TURTLEDOVE). TURTLEDOVE serves to address the retargeting use case and is reliant on first-party data collection. With this proposal, an advertiser has the ability to create interest groups for the purpose of retargeting based on the behavior of users visiting its website .
Per Google, this will work in the following way:
The browser sends multiple uncorrelated ad requests to the ad network:
- a contextual ad request, which is allowed to contain the URL of the page where the ad will appear, and
- a separate request indicating an advertiser-identified interest, but which cannot be tied to any browsing behavior, and which can happen at a time other than while loading the web page where the ad will appear.
The ad network must make the final decision of which ad “wins” via code which executes locally within the browser, and which cannot send information off-device. That is, we allow the ad network to run an on-device auction to choose among previously-served ads.
The creation of first-party interest groups is relatively straightforward. I browse a sneaker website looking for running shoes, and based on my behavior, I am placed into a “men’s running shoes – color red – abandoned cart” interest group. Chrome then stores the interest group directly in the browser, where the sneaker website can reference it at a later point to deliver me a targeted ad when I visit a second website.
Regarding the interest-based targeting use case, Google proposed a second initiative by the name of FLoC (Federated Learning of Cohorts). Currently, advertisers are reliant on personal data collected by third-party cookies to define their targeting and display ads that are relevant to the recipient’s interests. With FLoC, Google’s objective is to introduce an interest-based targeting alternative that eliminates the need to track individual user activity.
While many agree that Google’s intention to improve user privacy is good for the industry and consumers, these proposals have been met with their fair share of scrutiny from other ad tech leaders. TURTLEDOVE, for instance, has taken a lot of heat for essentially stripping ad tech companies of their decisioning power and moving the entire auction process into Google’s browser. A move such as this would greatly stifle the current workflow and “disable many common web advertiser tactics such as A/B testing, attribution, and optimization for metrics including click-through rates and conversions,” states AdExchanger.
FLoC, on the other hand, has several concerning attributes which Google addressed directly. These include:
- Revealing people’s interests to the web: Sites that collect personal data can record and potentially reveal someone’s cohort. This is an improvement over cookies revealing someone’s exact browsing history, but still not ideal.
- Tracking people via their cohort: It’s possible that a cohort can be combined with information like an IP address to directly identify a user.
- Longitudinal privacy: If a user changes FLoCs too frequently, more information about the user’s browsing history could be revealed over time.
- Sensitive categories: Although Google aims to remove sensitive information from its data collection, there is no uniform consensus on what is and is not sensitive. Therefore, Google would inevitably have access to data that some users would classify as sensitive.
To address the weaknesses of Google’s initial proposals, several large ad tech players, as well as Google itself, have submitted bird-themed counter proposals. We’ll discuss a selection of these proposals below:
Secure Private Advertising Remotely Run On Webserver (SPARROW) was proposed in May 2020 by Criteo, a company focused on retargeting, in response to TURTLEDOVE. SPARROW introduces several changes that allow the advertiser to retain control over the ad serving process.
- It proposes a way for advertisers to retrieve more advanced reporting, conduct A/B testing, and define their own attribution methods.
- It provides a compelling alternative to a Chrome-controlled auction by suggesting the auction moves away from the browser and over to a trusted independent “Gatekeeper,” thus minimizing Google’s attempted power grab.
- The proposal addresses shortcomings in TURTLEDOVE by prioritizing brand safety and fraud detection.
- SPARROW’s scope is not limited exclusively to retargeting and can theoretically support all targeting use cases.
- Many industry players are concerned with the security of a third-party Gatekeeper. There is fear that a centralized entity may be susceptible to a data breach. Additionally, there is skepticism surrounding providing real-time reporting in a way that meets privacy standards.
- DSPs and SSPs will be required to re-implement bidding models and auction logic in the Gatekeeper, a complex process that relies heavily on the Gatekeeper to protect confidential information and technologies.
The Google Ads team responded to SPARROW in September with DOVEKEY (a play on TURTLEDOVE and key-values). DOVEKEY aims to simplify auction aspects of TURTLEDOVE and modify SPARROW so that the Gatekeeper acts as a key-value (KV) server. Google explains their intent below.
Dovekey supports many of the same use cases as SPARROW while also mitigating these challenges:
- It alleviates the need for the ad tech industry to re-implement logic on an external server, the KV server will cache the results of existing control and bidding logic.
- It allows trustworthiness to be established via an open source auditing process, the KV server will only support limited and well-defined functionality.
- It can guarantee user privacy, the KV server can be implemented in a private or semi-private manner.
The key idea of Dovekey is that we can get most of the benefit of SPARROW bidding even if the Gatekeeper server just acts as a simple lookup table – a trusted Key-Value (KV) server which receives a Key (a contextual signal plus an interest group) and returns a Value (a bid).
- Ad tech companies will not be required to re-implement bidding models and auction logic into another server.
- The key-value server does not need to be run by Google, and can instead be operated by a third-party, shifting some control away from Google.
- It supports many of the improvements proposed in SPARROW, such as A/B testing and fraud detection.
- While DOVEKEY addresses auction and bidding dynamics, it does not address TURTLEDOVE’s measurement and reporting shortcomings.
- The auction still takes place in the Chrome browser, allowing Google to attain a major stake in the ad serving process.
- It is unclear who will host the key-value servers and how many servers will be needed.
Another proposal that builds off the SPARROW and DOVEKEY counter proposals is Magnite’s Publisher Auction Responsibility Retention Revision of TurtleDove (PARRROT). PARRROT adopts a lot of the privacy aspects of TURTLEDOVE, but instead aims to shift the power away from Google by recommending that all auction dynamics be moved back to the publisher side. Magnite suggests we accomplish this by using a Fenced Frames API. In short, Fenced Frames enable an ad to appear on a website without the web page gaining insight into the ad being displayed. This can be thought of in the same sense as header bidding. Magnite’s VP of Product Management, Garrett McGrath says that PARRROT should be seen as complementary to SPARROW and DOVEKEY. “PARRROT extends the key-value store component of DOVEKEY by allowing DSPs to directly and explicitly declare their bidding wishes; otherwise this is theoretically accomplished through Machine Learning in DOVEKEY. PARRROT and DOVEKEY simplify the Gatekeeper by removing any computation tasks thereby increasing trust among users. PARRROT addresses where the auction logic is run, not how audiences are handled.”
- Publishers and SSPs retain control over auction dynamics by using the Fenced Frames API.
- Chrome’s role in the auction is diminished to controlling what data is available.
- PARRROT’s most prevalent criticism is that aside from reducing Google’s control, it does not offer solutions to issues from prior proposals.
This is not a comprehensive list of proposals. Several other industry players have weighed in as well, and each counter proposal has been met with at least some criticism. The truth is that we likely won’t reach a solution that the entire ad tech industry supports. What is promising is that each new proposal takes previous proposals into consideration and attempts to make improvements. Even Google seems willing to compromise and work toward a solution where they are not the sole bearer of power.
That being said, Google did recently cause a stir by disavowing identity-based solutions entirely in their products. Outside of Google’s Privacy Sandbox, identity-based tracking solutions that will work without third-party cookies are being proposed by reputable ad tech players like The Trade Desk, LiveRamp, and Neustar. In our next post, we’ll dive into some of the identity solutions that the industry is rallying behind, explain how they differ from the Privacy Sandbox proposals, and provide some insight into Google’s reluctance to endorse or support them.