How Google Chrome’s Privacy Sandbox Will Work + Possible Solutions for AdTech

Since Google Chrome announced it’ll stop supporting third-party cookies, publishers, agencies, AdTech companies, and brands have questioned what it will mean for the future of the online advertising industry.

But to understand the impact this will have on digital advertising in Google Chrome, we first need to understand how Google Chrome’s Privacy Sandbox will work. 

Although not much is known about how it will work, there’s enough information out there to get a basic understanding. 

In this post we paint a picture of how the digital advertising industry works in Chrome now and how we believe it will work once third-party cookies disappear and Privacy Sandbox is introduced.

UPDATE: On Thursday June 24, 2021, Google Chrome announced that it would be extending its planned sunset of third-party cookies by 2 years. It’s currently expected that Chrome will shut off support for third-party cookies starting from the middle of 2023. 

Then, on Wednesday July 27, 2022, Google Chrome announced that it won’t start phasing out third-party cookies until the second half of 2024.

The Role of Third-Party Cookies in Digital Advertising

For close to two decades, third-party cookies have powered several key digital advertising processes. 

Within web browsers, AdTech companies create third-party cookies to:

• Identify users across different websites in the same web browser.
• Run behavioral advertising and retargeting campaigns.
• Target audiences created in a DMP via DSPs.
• Measure the performance of ad campaigns.

But simply creating third-party cookies isn’t going to help with most of the above processes.

To power identification, behavioral targeting, retargeting, and audience activation, they need to be shared between different AdTech vendors.

And this is where cookie syncing comes in.

What Is Cookie Syncing and What Roles Does It Play in Digital Advertising?

Despite the many advantages cookies offer, they have one big limitation; they are domain specific. 

This means they can only be read by the domain that created them. For example, dsp.com can’t read a cookie created by dmp.com. 

This presents a big challenge for AdTech companies wanting to identify users across different websites. 

So how can ssp1.com tell dsp1.com that a user on publisher.com matches their target audience?

The answer lies in cookie syncing. 

As the name suggests, cookie syncing matches cookies created by one AdTech platform with another one. But because the cookie IDs for each AdTech platform are different, the cookies are matched in a cookie-matching table.

AdTech vendors carry out cookie syncing via piggybacking, whereby one AdTech vendor (e.g. an DMP) loads another AdTech vendor’s pixel — essentially, one AdTech platform piggybacks off another one.

Now, dsp.com and dmp.com are able to talk about the same user, allowing advertisers to identify members of their target audience across different websites. 

Now that we know the role third-party cookies and cookie syncing play in online advertising, let’s look at their decline.

The Decline in Availability of Third-Party Cookies

The availability of third-party cookies has been declining for over a decade. 

The first phase started when ad blockers (browser plugins) were introduced in the mid-2000s.

Most ad blockers prevent AdTech tags (i.e. JavaScript snippets) from loading on a web page. And when AdTech tags don’t load on a page, then third-party cookies can’t be created. 

More recently, the decline of third-party cookies has been accelerated by privacy laws like the GDPR and privacy settings in web browsers — Safari and Firefox block third-party cookies by default. 

Both Apple’s Safari and Mozilla’s Firefox have killed off the very thing that keeps online display advertising together without offering publishers and advertisers an alternative. 

Google Chrome has also made some changes to how it handles third-party cookies with the introduction of the SameSite attribute that requires website developers and AdTech companies to mark their third-party cookies with SameSite=None. Doing so will make it easier for users to block and delete third-party cookies. 

Then on Tuesday the 14th of January, 2020, Google Chrome announced that it would stop supporting third-party cookies altogether within the next two years.  

But on Thursday June 24, 2021, Google Chrome announced that it would be extending its planned sunset of third-party cookies by 2 years. Chrome said it will shut off support for third-party cookies starting from the middle of 2023. Read about the main points here. 

Then, on Wednesday July 27, 2022, Google Chrome yet again announced that it will be delaying the phasing of third-party cookies by another year. Currently, Google Chrome plans to shut off third-party cookies in the second half of 2024.

Because a large portion of Alphabet’s (Google’s parent company) revenue derives from advertising, Google Chrome would never follow suit and block third-party cookies like Safari and Firefox have without offering up an alternative.

The alternative to third-party cookies that Chrome is proposing is called Privacy Sandbox.

What Is Google Chrome’s Privacy Sandbox?

Google Chrome’s Privacy Sandbox, which was first revealed on August 22, 2019, is a set of open standards aiming to improve user privacy and maintain an ad-supported web.

Just like with other sandboxes used in computer security, Chrome’s Privacy Sandbox will execute advertising processes in a restricted environment, which is in stark contrast to how these processes are carried out today.

There are three parts to Privacy Sandbox:

1. Replacing cross-site tracking processes — i.e. the ones currently powered by third-party cookies.
2. Phasing out third-party cookies by separating first-party and third-party cookies via the SameSite attribute and turning off support for third-party cookies.
3. Mitigating workarounds such as fingerprinting.

In the post, we’ll focus on the first part as it will have the biggest impact. 

The standards are being discussed and worked on between AdTech companies, agencies, publishers, Google Chrome and Google’s ad teams via the W3C Improving Web Advertising Business Group.

Although it’s still in development, Privacy Sandbox puts forward a completely new way of how online advertising works.

Below we illustrate how key advertising processes work now via independent AdTech companies and how they’ll likely work in Chrome’s Privacy Sandbox. The diagrams below aim to provide a general idea of Chrome’s proposed changes.

It’s also worth noting that many ideas and proposals have been put forward to the W3C business group. We listed the main ones below but a fill list can be found here.

How AdTech Works Now vs How Privacy Sandbox Will Work

The online advertising processes we’ll look at are:

• Identification.
• Ad targeting and media buying.
• Measurement and reporting.

Identification

AdTech now

As mentioned above, most user identification is done with third-party cookies. 

Here’s how it works:

When an AdTech vendor creates a third-party cookie in a user’s web browser, it can then read its cookie when the user visits a different site, provided the AdTech vendor’s code loads on the page, which has either been added directly by the publisher or by piggybacking off a different AdTech company’s code.  

When third-party cookies stop working, most AdTech companies will turn to other identifiers and web browser storage methods to identify users, but these solutions will be much more limited than third-party cookies. See the section titled “Possible Solutions” below for more information.

Privacy Sandbox

If you read the material published by Google Chrome about Privacy Sandbox, it’s clear that their goal is to provide an environment for advertising that doesn’t rely on 1:1 identification. For that reason, Privacy Sandbox won’t identify individual users.

This is the biggest change that the online advertising industry will have to get used to, as publishers, brands, agencies, and AdTech vendors have built their businesses around identifying individuals across the web. 

Although many AdTech vendors will turn to other identifiers such as first-party cookies, it’s impossible to rule out the possibility of Chrome limiting the use of first-party cookies and other techniques for identification, like what Safari has done with Intelligent Tracking Prevention (ITP).

Evidence of this is scattered throughout Chrome’s page about Privacy Sandbox (important text in bold):

The Privacy Sandbox project’s mission is to “Create a thriving web ecosystem that is respectful of users and private by default.” The main challenge to overcome in that mission is the pervasive cross-site tracking that has become the norm on the web and on top of which much of the web’s ability to deliver and monetize content has been built.

As that functionality becomes available we will place more and more restrictions on the use of third party cookies, which are the most common mechanism for cross-site tracking today and eventually deprecate them entirely. In parallel to that we will aggressively combat the current techniques for non-cookie based cross-site tracking, such as fingerprinting, cache inspection, link decoration, network tracking and Personally Identifying Information (PII) joins.

As we’re removing the ability to do cross-site tracking with cookies, we need to ensure that developers take the well-lit path of the new functionality rather than attempt to track users through some other means.

The last sentence suggests that any cross-site tracking alternatives (aka workarounds) that AdTech companies create will be restricted or blocked by Chrome.

Ad Targeting and Media Buying

Independent AdTech

AdTech companies offer different targeting methods, with the two most common methods being contextual and behavioral:

Contextual targeting uses the context about a page to determine which ads to show. This information is collected by web crawlers and via the user agent string in HTTP header requests. 

Most contextual ad campaigns are executed by ad networks via a media-buying process known as programmatic direct.

Behavioral targeting uses data known about users, such as which websites they visited and products they’ve purchased, to determine which ads to display. This data is collected by AdTech and data companies (e.g. DMPs) and is added to user profiles.

Advertisers then create audiences, which consist of multiple user profiles, and use them for ad targeting.

Retargeting also uses data known about users, but displays ads to users that have interacted with a brand, such as visited their website and viewed their products.

The main way advertisers run behavioral-targeted and retargeting campaigns is via real-time bidding (RTB).

Real-time bidding starts when an SSP’s code (JavaScript snippet) loads on a publisher’s website. The SSP then sends a bid request to multiple DSPs. 

Here’s just some of the information that can be contained in a bid request:

• Impression type, size, and placement.
• IAB content categories, such as ‘automotive’ and ‘fashion’.
• Device information, such as device type, operation system, device make and model, and device version.
• Cookie ID, which is used to identify users across different websites, allowing advertisers to identify members of their target audience.

If the information contained in the bid request matches their target criteria, then they’ll send back a bid response. The DSP with the highest bid wins the auction and the advertiser’s ad is displayed to the user. 

RTB heavily relies on third-party cookies and cookie syncing to identify and track users across different websites. For RTB to continue to work without third-party cookies, AdTech companies will need to use a different identifier. See the section below about possible solutions for more information.

So to recap, contextual advertising can be done without knowing anything about the user — e.g. an advertiser can display an ad for a mountain bike on a web page about mountain biking — whereas behavioral targeting and retargeting use data about a user’s interests and behavior, such as which websites they’ve visited and products they’ve purchased.

But does behavioral targeting result in more ad revenue for publishers compared to contextual targeting?

This is a question many folks have tried to answer, with varying answers.

A 2019 study by Veronica Marotta, Vibhanshu Abhishek, and Alessandro Acquisti found that the presence of cookies on a large publisher’s website contributed to 4% higher CPMs for publishers.

This report suggests that behavioral ad targeting isn’t a big revenue booster for publishers as many AdTech companies claim it is, however, the devil is in the detail and in this case many key factors may have been overlooked.

More recently, a team at Google Ad Manager ran an experiment where it disabled access to cookies for a small fraction of users to see whether publisher ad revenues would fall when cookies weren’t available.

The team at Google found that when cookies were disabled, ad revenues fell by 52% for the top 500 global publishers, with a median per-publisher decline of 64%.

The experiment highlights the value of personalized and targeted advertising.

Privacy Sandbox

The ad-targeting options in Chrome’s Privacy Sandbox will be fairly similar to the ones available today, with a few slight differences. 

Ad Targeting Method #1: Contextual and First-Party-Data Targeting

Although this isn’t a standard within Privacy Sandbox, Google has stated that companies can use contextual and first-party data in conjunction with the other Privacy Sandbox standards.

An example would be using contextual data alongside Topics API to compare the context of a webpage with a given user’s topic to help companies identify connections between them and build affinity audiences. 

For example, if a publisher identifies that users who have been assigned the topic “Beauty & Fitness” are visiting a lot of pages connected with hair care, then AdTech companies can assume that this group of users would also be a fit for the topic “Beauty & Fitness/Hair Care”, even when they haven’t been assigned that particular topic. 

To automate and optimize this process, AdTech companies can use machine-learning algorithms to create models that identify the connections between the topics from the Topics API and a publisher’s contextual data.

Ad Targeting Method #2: Interest-Based Targeting via FLoCs

Google’s original concept for interest-based targeting, known as Federated Learning of Cohorts (FLoC), involved adding users to a group (aka cohort) based on the websites they visit. Advertisers would then be able to target them based on the cohorts they belong to, rather than on an individual level.

Here’s an overview of how FLoC was supposed to work:

UPDATE: On January 25, 2022, Google announced that it would be sunsetting FLoC and replacing it with a new initiative — Topics API (more information about that below).

The targeting would be done on a cohort level and data would be processed on-device, meaning no user data would be passed to AdTech platforms, just the name of the interest group they belong to. This new way of running targeted ad campaigns was in stark contrast to how it’s done currently via third-party cookies.

Special report

We published a report about FLoC in ExchangeWire’s Industry Review: Reframing the Future. You can read it here on page 9.

Google Chrome announced on January 25, 2021, that it would make the FLoC API publicly available for testing in March 2021, and begin testing FLoC in Google Ads in Q2 2021. 

Based on the tests Google’s ad teams have conducted using FLoC, it claims that advertisers could expect to see at least 95% of the conversions per dollar spent when compared to cookie-based advertising for reaching in-market and affinity Google Audiences.

But not everyone was convinced that FLoC was the privacy-preserving solution Google was making it out to be.

The Electronic Frontier Foundation (EFF) expressed a number of concerns about the true effectiveness of FLoC in strengthening user privacy.

For the most part, the EFF stated that the cohorts themselves would make it easier for companies to create device fingerprints and companies would be able to identify individuals and learn information about them based on the cohorts they belong to.

While there is some truth in that, Google had taken steps to address and stamp out device fingerprinting and would only increase its efforts to do so in the future. 

Also, it wasn’t known what kinds of cohorts would be created. It was unlikely that Google would allow certain cohorts to be created, such as ones related to a person’s race, sexuality, or even political views. But the main challenge here was that the cohorts would be created by a machine rather than a person, which would have made it hard to identify and block these sensitive categories. 

Ad Targeting Method #3: Topics API (aka FLoC 2.0)

On January 25, 2022, Google announced that it would be sunsetting FLoC and replacing it with a new initiative — Topics API.

This announcement didn’t come as a complete surprise as Google had floated the idea of changing FLoC from interests-based targeting to topics-based targeting in July 2021. 

Google said that one of the main reasons for their decision to move away from interest-based targeting to topics-based targeting was because of feedback received about the privacy concerns about FLoC, even though it was designed to be a privacy friendly alternative to user tracking via third-party cookies. 

Here are the main things you need to know about the Topics API and how it differs from FLoC:

• Instead of using a FLoC ID and placing people into cohorts, the Topics API will generate up to 5 topics that represent a user’s interests based on the websites they visit.
• These topics will be given names that can be read and understood by humans, e.g. sport, luxury cars, punk rock music etc. With FLoC, each cohort would have been represented by an ID, which wouldn’t give companies any idea about what users were interested in but would allow the FLoC algorithm to show personalized ads.
• Just like with FLoC, only websites that have implemented the Topics API will collect a user’s interests and make them available to advertisers and AdTech companies.
• The Topics API will select 3 topics that can be used for targeting each time a user visits a participating website.
• The topics associated with a user will only remain active for 3 weeks, after which new topics will be generated.
• It’s possible to combine topics together, e.g. target a user who is interested in sport and luxury cars.
• Similarly to FLoC, the Topics API will run on a user’s device (i.e. on-device processing) and the information and data collected to run the Topics API won’t be passed to Google’s servers.
• No information about which websites a user has visited will be shared.
• In the future, users will be able to see which topics they’re associated with and allow them to disable the Topics API.
• Google would eventually like the Topics API to be managed by a third-party organization, such as the IAB.
• Unlike FLoC that was pulled out of testing in Europe due to issues surrounding GDPR compliance, the Topics API is planned to be rolled out globally.

Topics API entered a broad release phase with the launch of Google Chrome version 115.

Prior to this broader release that took place in July 2023, Topics had been accessible for experimentation through Google’s ‘Origin’ trials, which involve testing various Sandbox APIs with a limited number of Chrome users. 

During these trials, Topics had been deployed to a smaller audience for testing and evaluation. However, with the widespread rollout of Chrome 115 to Google’s user base, Topics will now be available to a much larger audience and can be utilized as a legitimate and effective means to target ads specifically on Chrome devices.

Ad Targeting Method #4: Remarketing (aka Retargeting)

The remarketing (aka retargeting) method is similar to the Topics API standard mentioned above, with the main difference being how the ad-decisioning process works. 

With Topics API, advertisers can show ads to users based on the topic groups they belong to. 

With the remarketing method, the browser will send two ad requests to the AdTech platform — one containing contextual information and one referencing the interest group that the user belongs to.

TURTLEDOVE

The process Chrome’s Privacy Sandbox will use for remarketing is known as Two Uncorrelated Requests, Then Locally-Executed Decision On Victory (TURTLEDOVE).

The AdTech platform won’t know that these two ad requests are coming from the same user, hence the name ‘two uncorrelated requests’. The reason for this is to make it hard for AdTech platforms to identify users by connecting the time the two requests are sent.  

The interesting thing about this proposed approach is that many of the key ad-decisioning and even auction mechanics will be conducted in the browser (aka on device) instead of by AdTech platforms.

Criteo’s SPARROW Proposal

In May 2020, French AdTech company Criteo released a proposal in response to Chrome’s TURTLEDOVE. 

Continuing on with the bird theme, Criteo named its proposal SPARROW, which stands for Secure Private Advertising Remotely Run On Webserver. 

While TURTLEDOVE proposes that all interested-based targeting via groups would happen in the browser and won’t allow for frequency capping, A/B testing, and optimization, the concept behind SPARROW is to move those processes to a dedicated, third-party server, known as the gatekeeper.

AdTech companies like DSPs and SSPs would be able to add bidding models and auction logic to the gatekeeper.

Although SPARROW is a move in the right direction, it would have to overcome a number of key challenges before it could even be considered for adoption:

1. Which company/companies would act as the gatekeeper?

Criteo suggests that this could be an AdTech company that is already involved in the ad-serving process, such as an SSP, but the gatekeeper would need to be independent and have no commercial interests in the auctions. 

This would rule out every single AdTech company out there. 

An organization like the IAB would be a more suitable choice, but nothing has been said about this being a possible option.

2. How would the privacy issues be handled?

Chrome’s TURTLEDOVE proposal is heavily focused on not collecting any kind of user-level data and preventing companies from identifying individuals, giving it a 5-star rating on the privacy front.

Although Criteo’s SPARROW would provide similar privacy measures, there’s a bigger chance that the data collected by the gatekeeper could be used to identify individuals and potentially lead to companies selling the data. 

To meet these privacy requirements, Criteo suggests that the gatekeeper undergo a periodic audit from Data Protection Authorities (DPAs), specify data management practices like data retention, and provide public APIs to allow others to ensure the data is not being mistreated.

But these suggestions still won’t satisfy Chrome’s privacy requirements. 

Criteo’s SPARROW is still being considered and discussed by members of the W3C business group. 

Dovekey

In September 2020, various teams from Google released a follow-up proposal to Criteo’s SPARROW, rightly called Dovekey. 

Dovekey is designed to be an improvement on SPARROW that addresses some of its shortcomings. The main feature of Dovekey is the introduction of a third-party KEY-value (KV) server, which will be used to handle the bidding and auction processes of TURTLEDOVE.

Here is Google’s explanation of Dovekey:

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).

Explanation (as provided by Google)

And here’s the proposed workflow:

• The browser sends a regular contextual ad request as described in TURTLEDOVE.
• The SSP returns the winning contextual ads, along with derived contextual signals (from SSP and DSP separately.) The final contextual signal is formed as the concatenation of those from a DSP and an SSP.
• The browser constructs the key by combining the contextual signal and the interest-group ID (ig_id), and sends those keys in a request to a KV server.
• The KV server returns all the bids associated with the requested keys. (*)
• The browser runs a simple auction between interest-group candidates fetched from the KV server and the winning contextual ad. (*)

• If a contextual ad wins, then the browser can proceed with rendering the ads.
• If interest-group ad wins, the browser can send another request to the KV server to get the creative or creatives can be pre-fetched ahead of time via the interest group request, as discussed in the TURTLEDOVE proposal

(*) Steps 4 and 5 are needed assuming the KV server can only perform lookup. It may also be possible for the KV server to run the final auction, in which case only the winning bids and creatives need to be returned.

Google suggests that Dovekey can support the following use cases:

• Budget management
• Incorporating browser-side signals (e.g. adding more information to interstate groups, such as recency).
• Adding new inventory
• A/B testing
• Fraud and security
• Product-level ads

Dovekey certainly seems like an improvement and the fact that it could include processes like budgement management, A/B testing, and fraud detection could mean that it will be well received by W3C members. 

However, there is still a number of questions that still need to be answered, such as:

1. Who will host the KV server?
2. Will any AdTech company be able to set up a KV server or will this be restricted in some way?
3. How will the KV server/s be policed so that they don’t expand their capabilities and start collecting user-level data? Some possible solutions to this include using cryptographic protocols and a single-server private information retrieval (PIR) system.

Regardless, it’s good to see progress in this area.

Magnite’s PARROT

AdTech company Magnite (formerly Rubicon Project) recently released a proposal called the Publisher Auction Responsibility Retention Revision of TurtleDove (PARROT). 

It is designed to maintain the privacy aspects of TURTLEDOVE but put control of the auction decisioning in hands of publishers by utilizing Fenced Frames (another proposal from the Google Chrome team). 

TERN

TURTLEDOVE Enhancements with Reduced Networking (TERN) is a proposal from AdTech company NextRoll. 

The goal of TERN is to propose improvements to TURTLEDOVE based on information collected from GitHub issues and repos. 

Fenced Frames

Fenced Frames is an API proposal created by Google engineers that would allow ads on a web page to load without the rest of the page knowing what ad is being displayed. The goal here is to prevent companies being able to identify users on websites and then perform cross-site recognition (aka cross-site tracking).

The Fenced Frames API would be used to communicate with other Privacy Sandbox standards, like TURTLEDOVE (now known as Protected Audience API), to show interest-based ads. 

Protected Audience API — Formerly Known as First “Locally-Executed Decision over Groups” Experiment (FLEDGE)

Back in 2021, the Google Chrome team proposed a new proposal called First “Locally-Executed Decision over Groups” Experiment (FLEDGE), which was an early prototype of ad-serving processes in TURTLEDOVE.

FLEDGE also incorporates components of the proposals made by independent AdTech FLEDGE also incorporates components of the proposals made by independent AdTech companies (i.e. the ones listed above). 

Google Chrome started running tests in 2021 and stated that “we need a robust API to take flight before Chrome’s expected removal of third-party cookies in 2022”. 

An announcement made on April 17, 2023 by Tristram Southey, a product manager on Privacy Sandbox, introduced a new name for the proposed alternative to ad auctions within Google Chrome. The previously known FLEDGE API has been rebranded as the “Protected Audience API.”

Southey stated in his blog post that the name change reflects the primary goals of the project — to enhance user privacy, ensure ad relevance, and provide better protection for advertiser and publisher audience data. 

The Protected Audience API aims to strike a balance between these key objectives, emphasizing its commitment to improving user experiences while safeguarding data integrity for all parties involved.

Ad Measurement and Reporting

AdTech now

AdTech companies measure and report on the performance of ad campaigns by impression and click trackers, and pixels (e.g. conversion tags). 

Below is an example of how impression tracking works in real-time bidding:

Privacy Sandbox

Chrome’s Privacy Sandbox puts forward APIs for measuring and reporting on ad campaigns, all designed to strengthen user privacy by avoiding cross-site tracking. 

To make it hard for AdTech companies to tie a click or conversion to an individual user, reports will be sent in aggregate from a server-side aggregation service. 

Below is an example of how reporting will likely work in Chrome’s Privacy Sandbox.

Possible Solutions

Since Google Chrome announced they’ll be killing off third-party cookies, AdTech companies have proposed several solutions. Most of them revolve around using a publisher’s first-party data for identification, which can then power ad targeting and measurement. 

Here are the main ways a publisher can use their first-party data for identification:

1. Use Email Addresses as an ID

This solution is one that gets talked about a lot. 

It involves a publisher asking users to create an account or provide an email address to access their content (e.g. read a news article).

Once a publisher has obtained a user’s email address, they can hash it and use the hash as an ID. This ID can then be used to identify returning visitors and power audience targeting. 

Email IDs created by publishers can also be matched with hashed email addresses from advertisers with an ID solution like the one The Trade Desk has proposed (i.e. Unified ID 2.0) or from companies like LiveRamp, Tapad, and Neustar. 

The main drawback of this solution is scale and reach as not every website asks its visitors to log in. These logged-in audiences will make up a small percentage (possibly 20%) of Internet users, meaning there will still be a large percentage of website visitors that will be unaddressable (i.e. unidentifiable and therefore can’t be shown targeted ads).  

Also, because Chrome’s goal is to move to an advertising model that doesn’t identify individuals, it’ll likely restrict this identification method, just as they’re doing with other user identification methods like device fingerprinting.

2. Use Other Browser Storage Methods

Cookies aren’t the only way web browsers can store data. 

Another web browser storage method that’s gaining popularity is local storage. 

Similarly to cookies, local storage can store IDs, which can be used to identify users. 

But again, the main drawback with this option is that it’s limited to the publisher’s domain, meaning there’s no easy way for AdTech companies to identify users across different websites.

3. Create a New Subdomain for AdTech Companies

Creating a new subdomain for the sole purpose of hosting a piece of software is nothing new; many MarTech platforms use this option. 

Publishers could create a subdomain (aka a CNAME record) for their AdTech partners (e.g. ssp.publisher.com), which would allow them to create a first-party cookie. This cookie could then be used for user identification.

The Main Problem With These Solutions

The above solutions present somewhat viable replacements to third-party cookies, but they should be viewed as short-term solutions. 

The reason we say that is because most are not privacy friendly.

Even with the appropriate consent and opt-out features, these solutions are still based on identifying individual users. And as we mentioned earlier, this goes against the very ideals of Chrome and the other major web browsers, especially Firefox and Safari.

So What Should AdTech Companies Do Now?

AdTech companies should be planning for the future, participating in discussions around Chrome’s Privacy Sandbox, making changes to their tech to make it privacy-friendly, and staying up to date with new announcements. 

With all that’s been happening in digital advertising over the past 5 years regarding privacy (the GDPR, ITP, etc.), it’s clear that the future of digital advertising lies in privacy-friendly tech and processes.

Until Chrome shuts off third-party cookies, it will be business as usual but AdTech companies should have one eye on the present and one eye on the future.