The cookieless future is fast approaching. This decision by Google, sparked by very real privacy concerns, removes a key personalization capability for advertisers: third-party cookies. To counteract this, Google has been building a series of tools to replicate their functionality, and today we’re going to dive into one of them: Google Topics API.
In this article, you will learn:
- What Google Topics API is in practice.
- How it differs from the Federated Learning of Cohorts (FLoC).
- What Google Topics API means for different market players.
- How it relates to the Privacy Sandbox and the cookieless future, more generally.
Table of Contents:
- What is Google Topics API
- What about FLoC?
- What does the topics API mean for different market players?
- What does the cookieless future hold?
- Businesses need to prepare for the cookieless future today
What is Google Topics API
The Topics API proposal in Chrome’s Privacy Sandbox is designed to protect user privacy while enabling advertisers to show relevant content and ads. It will allow the Chrome browser to infer a selection of recognizable interest categories based on recent browsing history to enable sites to serve relevant ads. The big difference between Topics API and third-party cookies is the type of data shared. Third-party cookies track users across multiple websites and share this information with third parties. In contrast, TopicsAPI will only share your general interests, rather than granular behavior, across multiple sites.
The ultimate purpose of the Topics API and the Privacy Sandbox, more generally, is to allow digital ad personalization as it is beneficial to users, publishers, and advertisers.
How are Topics Selected?
Before diving into how the Topics API works, it makes sense to cover how topics are actually selected. The basis of the Topics API system is a taxonomy that consists of hierarchical categories, for example /Pets & Animals/Pets/Reptiles & Amphibians, or /Shopping/Consumer Resources/Coupons & Discount Offers. These categories are the formation of the entire Topics labeling system and are how categories are assigned to sites and eventually to users’ interests.
The initial taxonomy was curated by Chrome, but in the long term, it will be maintained by a trusted ecosystem of contributors like IAB Tech Lab or Prebid. The shape of the taxonomy has been recently revolutionized by subtracting categories which aren’t commercially relevant (i.e. “Civil Engineering”) and adding those that are (“Athletic Apparel). The currently proposed version consists of 469 topics.
It’s important to note that the taxonomy focuses on interests rather than demographic segmentation, so no information, such as ethnicity, can be defined by it. Chrome is keen to avoid harmful topics. So, all topics are public and human-curated in order to exclude categories that may be sensitive, such as ethnicity or sexual orientation.
How does the Topics API work?
To begin, Topics API’s automated classifier assigns websites with a contextual label based on their domain. For example, a travel website (travel.com) would have the label “travel,” or a sports news site (sportnews.com) would be assigned a “sports” label.
Next, users are assigned a topic based on their browsing history for a specific period of time, called an epoch, which is currently one week. For each epoch, the five most popular topics are derived from a user’s browsing history. When a bid request is made, three epochs and five topics from each epoch are taken into account. Then, three topics in total are chosen before being passed along to determine what advert type to display to this user. These topics are randomly selected from five topics stored in the user’s browser. As an additional layer of privacy, there is a 5% chance that a user’s topic is completely random. It’s also important to keep in mind that in any given bid, it will only be possible to see topics from the last three epochs for any given user.
How is the Topics API different from third-party cookies?
This is where we get into the tricky stuff. Many users, particularly those unfamiliar with how API calls work, will look at the fact that browsing data is still being selected and ask how this is any better than what we had before.
In the old, cookie-based system, browsers shared a lot of information with MarTech providers, only some of which was really relevant to the process in the first place. This increased the risk of personally identifiable data being leaked to advertisers and led to users feeling disempowered about how their data was being used. Additionally, third-party cookies allow tracking of an individual user across a number of different, unrelated websites.
In contrast, the Topics API has two key advantages over third-party tracking cookies. The first big one is anonymity. The Topics API segments users into topics of their interests and passes along only that information to third parties in order to make a decision. This helps to eliminate the need to produce an individual profile to effectively deliver personalized ads.
Secondly, the Google Topics API is designed to provide the maximum amount of control to users. They are able to see what Topics might be assigned to them and remove those topics if they aren’t interested in them. This is good for users, as they have more control over how they are advertised to, and good for advertisers, as they will still be able to deliver personalized ads in their upper-funnel campaigns.
What about FLoC?
Those who have been following the cookieless future for some time will probably be familiar with the Federated Learning of Cohorts proposal, more commonly called FLoC. This proposal was tested in 2021. FLoC was designed to infer user interests based on their browsing and group them together with people who had similar browsing habits. The theory was that MarTech companies could then understand the behavior of users at scale without being able to identify individual users.
However, during testing, it became apparent that FLoC could act as a surface for fingerprinting. Specifically, that the information shared with advertisers could be combined with other information sources, such as IP addresses, in order to track an individual user. Additionally, its taxonomy was deemed far too granular, with over 30,000 segments included. There were also concerns that updates to a user’s FloC group over time could create a historical trail of data that would provide exponentially more information about a user until they could be specifically identified.
Topics API, however, puts emphasis on user control and transparency while providing his/her interest profile—generic enough not to be intrusive and specific enough to be commercially relevant.
What does the topics API mean for different market players?
The Topics API in Privacy Sandbox won’t impact all types of stakeholders equally, however, the proposal is designed to resolve the concerns of three key groups: Users, Advertisers, and Publishers. Let’s take a look at how it impacts each group:
Users—enhanced privacy with personalized ads
Compared to FLoC, the Topics API is a major step forward in just about every direction. The Chrome team has eliminated many of the potential surfaces for fingerprinting. For example, topics are updated for a user once a week, which significantly slows the amount of information about a user which is being shared, and topics will only be returned for an API caller that has previously observed the same topic for the same user in the last three epochs.
Additionally, users will have more options to control their topics than they had under either FLoC or third-party cookies, and users are able to entirely opt out of the Topics API if they don’t see the value in it. In that case, their topics won’t be defined and passed to external parties, disabling this targeting mechanism, and it may result in users seeing less relevant ads, but that would be their choice.
Topics API is widely discussed in terms of acting for the benefit of publishers. It has been mentioned in the press that the mechanism of Google’s Topic API favors large publishers with domains across a wide variety of subjects over niche publishers. For example, a user who visits a niche website, such as disealenthusiasts.com, may get the Disease Vehicle label attached. This is valuable information that a large website like Yahoo.com could use to sell inventory in its portfolio of sites. This, unfortunately, doesn’t work the other way around, as tags from large domains like Google or Yahoo may be irrelevant to niche domains.
At the time of writing, Google has yet to explain how they plan to mitigate this challenge; however, it is possible for publishers to opt out of the Topics API without impacting their SEO. In general, this challenge is likely to be more robustly addressed after the depreciation of third-party cookies is in place and the true impact of the change becomes more apparent.
Utility for advertisers has been enhanced with the introduction of new Topics API taxonomy, which was a result of Chrome listening to the industry’s feedback. What is clear is that advertisers will be able to serve personalized ads based on Topics API signals in the upper funnel channel or use the signal to personalize ads for retargeting. However, the full utility of this solution for advertisers will largely depend on the participation rate of publishers and users.
What does the cookieless future hold?
The Topics API is just one part of a much larger puzzle called the Privacy Sandbox. This initiative is designed to provide a selection of solutions that maintain the features of third-party cookies without jeopardizing users’ privacy online. While nothing is written in stone, and those tools might be subject to many changes, we have already entered the General Availability stage, which means that APIs included in the Privacy Sandbox (including Topics API) are enabled for the vast majority of Chrome users. The next milestone declared by Chrome is depreciating third-party cookies for 1% of its users, with full depreciation slated for the second half of 2024.
As the cookieless depreciation timeline advances, we should expect to see the industry test and review solutions, including the Topics API and Protected Audience API. This feedback will be used to refine the solutions over time.
As usual in the MarTech industry, the situation is dynamic, and if you want to stay informed, you should keep a close eye on Google’s newsfeeds (or subscribe to our newsletter) to keep on top of the various changes as they’re rolled out.
Businesses need to prepare for the cookieless future today
Cookieless advertising is a huge challenge for the industry as a whole. From the perspective of users and publishers, personalized advertising is the foundation of the open internet, and without it, we will undoubtedly see more payment walls cropping up, limiting access to the internet to those who can afford to pay subscriptions. For advertisers, adapting to these new solutions is necessary to keep reaching relevant users. Chrome users make up over 60% of the total browser market share. If Google has made the decision to drop support for third-party cookies, the rest of us have no choice but to adapt.
Your first step is to make sure you’re prepared, to help you get started, we’ve created a checklist:
That’s why RTB House has been working so closely with Google and other major MarTech players to ensure that these solutions work. Our feedback was instrumental in the creation of multiple Privacy Sandbox proposals, such as the Protected Audience API (previously known as FLEDGE), and we are already using and testing a wide array of cookieless advertising methods.
Our approach puts Deep Learning at the center, which is of even higher value now as sources of granular data become more scarce. This enables us to build products that are tailor-made for the cookieless future and that will ensure your company is able to retain the same advertising effectiveness even after third-party cookies are retired.
If you want to learn how RTB House can help your business prepare, reach out to the team today.