Last Updated on: 25th May 2024, 09:26 pm
Six months ago, during IETF 111, Google engineers made it clear that they were approaching a new iteration of FLoC, which was related to site topics. Yesterday, they finally announced Topics API. The ad topics concept has also been explored by Meta engineers in their Ad Topic Hints proposal, which builds on user feedback to displayed ads. Also, the PAURAQUE proposal from NextRoll was proposed in such a way that users could define topics which are interesting for them and can be used for personalization.
In this article you will learn about:
- Specification of Topics API in the Privacy Sandbox
- The impact it has on the way ads are served to the users
- 3 perspectives we analyze – privacy, advertising efficiency, and marketing competition
Table of Contents:
- The Privacy Perspective
- The Advertising Efficiency Perspective
- The Market Competition Perspective
- The Challenges Ahead
- What We Think
The idea behind Google’s proposal, explained in a high-level technical overview instead of a full specification, is that each website’s hostname using Topics API will be mapped to a specific topic, like “Tennis” or “Finance”, out of ~350 available in the initial taxonomy. It is unclear whether publishers will decide on their own which topics their sites represent or an algorithm built within the browser will do so, or a combination of both. The user history of the browsed websites participating in Topics API over the last three weeks will be stored privately on its device. Based on this, the user’s top 5 topics will be calculated for each week, with one random topic added for privacy protection. Upon the user’s visit to the website using Topics API, the site can call the API to receive up to three topics for the user to use for interest-based advertising.
We believe that the analysis of the Topics API concept should cover three different perspectives: privacy, advertising efficiency, and marketing competition.
The Privacy Perspective
From the privacy perspective, it is a move in the right direction from the original FLoC. The Chrome team integrated a lot of community feedback into this new proposal, making it clear that it’s now based on an opt-in mechanism for websites instead of the widely criticized opt-out. It allows websites to decide whether they see value in the concept and whether they want to participate in it. It also provides controls for users, as they can opt-out of Topics API at any time.
The Advertising Efficiency Perspective
From the advertising efficiency perspective, it is unclear what its utility will be compared to the FLoC proposal. In the original idea, the user was assigned to one cohort out of +30,000 possibilities. In this case, the user gets 5 topics from a set of ~350, increasing the number of potential combinations significantly. From the use cases perspective, just like FLoC, Topics API aims to satisfy the following conditions for upper funnel marketing:
- Classic interest-based advertising – allowing brands to reach new audiences based on the topics they are interested in, supplemented with contextual targeting.
- Lookalike advertising – allowing brands to understand the most popular topics among their existing customers and translate it to new user acquisition strategies.
- First-party recommendation engines – helping websites to personalize the experience for new users based on the archetype of an existing user interested in specific topics.
The scale of the initial FLoC Origin Trials was too limited to clearly assess its utility. To avoid this situation in the case of Topics API in the Privacy Sandbox, the Origin Trials must provide much more testing potential, which will help extract relevant insights. The Trials must also be available globally to compare the results across markets.
The Market Competition Perspective
From the market competition perspective, this proposal seems to favor large entities at the expense of SMEs. Google acknowledges this, but does not list it as an issue. The concept says that the more sites a company (reading Topics API) is present on, the more likely it is to get topics to target, which would especially favor large social networks, supply-side platforms, and ad networks. The explainer also states that the topic will be mapped to the website hostname, rather than the full url. It means that while the topic for hostname “tennis.example.com” could be “Tennis”, the topic for “example.com/tennis” will be related to the whole example.com website. Without at least looking at the section level, some large websites may provide very limited help for personalization purposes (example: YouTube.com,Google.com or Facebook.com), while getting all the insights from smaller sites. In markets dominated by media conglomerates and/or a few large publishers without adequately constructed sites, the value of this concept will be limited.
The Challenges Ahead
Google acknowledges that there are many open questions and lists them in the GitHub page. Just the first one question alone – regarding who will be responsible for mapping topics to a page, an algorithm or the publishers themselves – is critical before launching the testing phase. We believe there are many more challenges, which should be addressed before the introduction of this proposal for wide use:
- Why is the Topics API signal available in the traditional iframe, leaving room for its combination with other signals, such as contextual? Wouldn’t a fenced frame be a more privacy-preserving option?
- How do you avoid competitive issues resulting from the current design preferring big players with connections to many sites in the internet ecosystem?
- What will incentivize large multi-topic publishers to construct their website’s hostnames in such a way that they generate topics relevant from the perspective of other open web publishers? For example, if a user enters a website specialized in cars, the website will only learn that the user is interested in cars. It will not receive other user interests due to the limitations in the proposal. In such a case, the API is useless for this publisher. On the other hand, information that the user visited websites about cars is invaluable from the perspective of large, multi-topic publishers, who can then recommend relevant articles or serve relevant advertising according to the user’s interests.
- How will the most popular topics for users be selected? Bias towards a few of the most popular topics will significantly reduce the proposal’s utility for advertising.
What We Think
RTB House has taken part in creating, testing, and implementing many solutions in accordance with the official Chrome procedure, one of the main stages of which are Origin Trials. Our experience clearly shows that the successful implementation of a new solution requires the cooperation of the entire supply chain.
Today’s advertising ecosystem is so complex that ensuring such cooperation requires time. It also requires the full specification of Topics API in the Privacy Sandbox to be published. Looking at the official Privacy Sandbox Timeline, the tests might start just this quarter. Moreover, we can see that Google has started implementing the API in Chromium just a day after publishing the proposal.
We are treating the Google Chrome publication as a discussion starter, the challenges of which we should constructively form as market participants and collectively consider improvements on fields of privacy, advertising efficacy, and the competitiveness of this proposed solution.
At RTB House we have been closely involved in the development of Privacy Sandbox since it was announced. We are fully prepared for the FLEDGE Origin Trials, and we’re waiting for the Google team to publish the final specification for these tests. We expect Google to share more details in the next few days.
If you have any questions, comments or issues, or you’re interested in meeting with us, please get in touch.
