Playing in the Sandbox: Google’s Role in the Cookieless World
With Google still responsible for almost a third of global digital advertising revenue, the tech giant will continue to play a significant role in the future of the digital advertising market, despite the deprecation of third-party cookies on its Chrome browser in 2023. And the most obvious way that Google will have a part to play is through its Privacy Sandbox framework.
What exactly is the Privacy Sandbox?
Put simply, once Google depreciates third-party cookies from Chrome, it would like to have a group of technologies (that the tech giant has developed with contributions from other stakeholders) to replace all the different functions of cookies - such as identification, targeting, attribution, and measurement - while still ensuring consumer privacy and protection.
Since the original announcement, a number of other ad tech players have contributed their own proposals, looking to strengthen areas where they feel the Google proposals have not gone far enough, or cover terrain where Google chose not to go at all.
At its heart, the Privacy Sandbox is made up of several application programming interfaces (APIs), operating in the user’s browser, which will each replace one or more of the functions that third-party cookies perform today.
Google Privacy Sandbox Proposals
Below are descriptions of some of the key proposals that Google has set forward for each of the third-party cookie functionality replacements.
Targeting (show relevant content) proposals
- FLoC: The most talked about component of the original Privacy Sandbox was the Federated Learning of Cohorts – commonly known as FLoC.
With FLoC, browsers track the content that users are consuming then, via an API, sort these users into large clusters (or “cohorts”) based on their interests using machine learning. Once a cohort had been built, advertisers would then have been able to use it to target the users within that group. As with all of the APIs, the aim was to preserve user privacy.
However, FLoC came under a lot of scrutiny, and was a controversial Privacy Sandbox solution (discussed below), resulting in its replacement with the Topics API in 2022. - Topics API: The most recent addition to the Sandbox, Topics uses browsing history to determine what a user’s top interests are from over a three-week period. The Topics API assigns every publisher website with an interest group from a pool of around 350 topics – broad in scope and curated by real people, meaning sensitive topics will be filtered out by default.
Google Chrome will collect ‘topics’ for each user based on the sites they’ve visited in the last week and make a decision on each user’s ‘top five’ topics. These ‘topics’ are selected at device level, rather than via external servers, and are deleted after three weeks, allowing the user interests to maintain recency and relevance.
When a user visits a site running the Topics API, three topics are selected to represent their interests (one topic from each of the past three weeks) and are shared with the site, and its advertising partners, in order to target that user with relevant ads. - TURTLEDOVE: Google’s TURTLEDOVE (Two Uncorrelated Requests, Then Locally-Executed Decision on Victory) proposal presents a vision for how advertisers could still retarget in the post-third-party cookie world.
Using this framework, users are placed into audience segments based on either their interests or actions. Advertisers would then be able to target these groups, but would not be able to combine these ‘interests’ with any other information about the user. The browser holds the information, and publishers and advertisers would not be able to learn anything about the interests of their users
- FLEDGE: The “First Locally Executed Decision over Groups Experiment” proposal, or FLEDGE, enables advertisers to build audiences, and target them without seeing anyone’s browsing history. It works by having the user’s browser hold information about the user’s interests. When somebody visits a site with ads, the browser then combines this data with buyer and seller data, and “business logic”, to run an auction to select the ads that make most sense to serve to the user. Here, the advertiser and publisher never find out anything about the user. This proposal uses concepts first outlined in TURTLEDOVE.
- Other targeting proposals have been submitted by technology platforms such as Criteo (SPARROW), Google Ads (Dovekey), Magnite (PARROT), and NextRoll (TERN) and are discussed below.
Cross-site identification proposal
- First-party sets is a privacy-focused proposal that would enable sites with multiple domains to utilize first-party data across their properties, without giving any third parties access to that data.
Websites will be able to declare that they belong to a certain group of domains by serving a JSON file to a “.well-known/first-party-set” address. The browser would then attempt to match this manifest file with a list of domains that have been filed by the owner to verify a valid link between the two.
Attribution proposal
- The Attribution Reporting API is very much self-explanatory; it makes it possible for advertisers to measure when a user has clicked or viewed an ad, and later converted following that action, but does so without any cross-site tracking. The API is made up of two types of report: event-level reports and aggregate reports.
Event-level reports link a particular ad click or view to a conversion, while aggregate reports look at the conversion data without linking it to a specific action.
Fighting spam and fraud proposal
- The Trust Token API is an alternative to the well-known CAPTCHA security measure, and designed to fight spam and fraud. Like CAPTCHA, the API will enable publishers to verify whether Chrome users are human or not. Websites will be able to do this by requesting that users fill out a CAPTCHA-like form, or by observing the account activity of a user.
Once a user has been confirmed as being human, they are given a cryptographic token – a ‘trust token’. These tokens are stored securely by the user’s browser, and then used to prove the authenticity of the person every time they access the site. Because these trust tokens are encrypted, the website is never able to identify the user and, therefore, unable to track them.
Non-Google Sandbox Contributions
As mentioned earlier, the Privacy Sandbox is made up of proposals developed based on contributions from Google and other digital advertising stakeholders.
Google announced its decision to work with these stakeholders to create web standards for the post-third-party cookie world when it first introduced us to its Privacy Sandbox initiative in 2019. Since then, players with a vested interest in the future of digital advertising have put forward their own solutions in areas they feel Google has fallen short.
Here are just a few of the notable external contributions to the Privacy Sandbox.
- SPARROW (Secure Private Advertising Remotely Run on Webserver) by Criteo. This proposal fits within the foundations of TURTLEDOVE, with the aim of providing more control and transparency, and maintaining user privacy.
SPARROW would enable advertisers to create upper-funnel and lookalike campaigns from interest groups. The proposal also includes a recommendation about having an independent gatekeeper executing real-time bidding, rather than the browser doing it. This gatekeeper would ensure that advertisers, publishers, and ad tech partners cannot access any personal information about users.
- PARAKEET (Private and Anonymised Requests for Ads that Keep Efficacy and Enhance Transparency) by Microsoft. Under Microsoft’s plans, a proxy server would hold unique user IDs. When a page requests an ad, the request will go through the proxy server, acting as a gatekeeper, which will then serve up a result that masks the user’s data with statistical noise.
- SWAN (Secure Web Addressability Network). Another notable contribution is a non-profit alternative created by a group of tech and legal experts.
The aim of this solution is to deliver an open-source consent mechanism for the open web. Under the solution, users who visit publishers signed up to the SWAN will only have to consent to personalized marketing once, and this choice will apply to all sites involved in the network. User preferences will be stored as a first-party cookie.
- SKAdNetwork by Apple. Apple’s answer to the Privacy Sandbox is the SKAdNetwork, though it’s not quite an alternative or a contributor, but more of an equivalent.
The SKAdnetwork is designed to enable measurement of mobile ad campaigns, without the need for user permission, following the changes made to the company’s IDFAs. The solution enables Apple to identify when a user has clicked an ad and downloaded the advertised app, then share this information with an ad network without compromising privacy. All the data is aggregated and anonymized, and any data that could be used to identify the user is removed.
What the FLoC?
There have been plenty of obstacles standing in the way of the Privacy Sandbox, and its targeting proposals in particular. FLoC faced several questions over user privacy, whether it violated competition rules, and the morality of grouping users based on interest categories.
Critics argued that the use of cohorts could lead to fingerprinting, which is a far more invasive form of tracking than cookies. Fingerprinting is when a company creates a unique profile about a user based on information such as their computer hardware, software, add-ons, and preferences.
Beyond the fingerprinting worries, there was a more general privacy-based concern: would FLoC be compliant with the GDPR? A question where the answer was likely to be “no”, because it could have been deemed that FLoC processes personal data and, therefore, would have required informed consent from the user.
Google also had issues with the UK’s Competitions and Markets Authority (CMA), US attorney generals, and EU antitrust regulators over whether FLoC violated competition rules around the world. In the UK, the tech giant has been working closely with the CMA to find solutions to the problem.
Finally, FLoC faced criticism over the fact that the door was open for it to create categories based on sensitive “interest-based” topics. And certain people may not have wished for those habits or interests to be targeted.
To address the majority of these concerns, Google decided to scrap FLoC, and take a different approach with the Topics API (more details on Topics can be found here).
A Combined Solution
The identity landscape is going to be a rollercoaster ride over the next few years, and a number of companies are going to have a say in the way we operate in a world after third-party cookies. Google may continue to have the biggest say, but the efforts of many tech businesses – alongside the mounting pressure of regulators – means that we could be heading toward a slightly more even playing field.
Whichever way you look at it, publishers, advertisers, and ad tech platforms are all going to have to use a variety of different solutions to succeed after the deprecation of cookies. And it is imperative that everybody in the industry keeps their eye on what’s going on around the Privacy Sandbox, and all other solutions in the market. For now, it’s time to choose a flexible technology partner that can help you build an identity testing strategy, and use third-party cookies as a point of comparison while they’re still around.