Topics API for Web

The Topics API enables interest-based advertising, without using third-party cookies.

How the Topics API works

The Topics API can be used to observe and provide access to topics that appear to be of interest to the user, based on their activity. The Topics API can then give API callers (such as ad tech platforms) access to a user's topics of interest, but without revealing additional information about the user's activity.

Key concepts

• A topic is a human-readable topic of interest for the current user and is part of the Topics taxonomy.
• A caller is an entity, such as an app, a third-party SDK, a website, or service, that makes a request to the Topics API to observe or access a user's interests.
• A topic is observed by a caller, if the caller made a Topics API request from a web page or app associated with this topic during the past three epochs.
• An epoch is a period of topic computation, which defaults to one week.
• A taxonomy is a hierarchical list of categories, which includes, for example, such categories as /Arts & Entertainment/Music & Audio/Soul & R&B and /Business & Industrial/Business Services/Corporate Events.
• Topics are derived using a classifier model that maps user activity to zero or more topics.

Topics API flow core steps

The Topics API lifecycle has three main steps:

• Observe user activity, such as when they visit the web page https://cats.example/tabby/index.html or download the app cats.
• Derive topics from user activity, for example /Pets & Animals/Pets/Cats.
• Access topics previously observed for the user, for example as a signal to select relevant advertising (such as a cat food promotion).

Observe topics

Callers can only access topics of interest that they've observed. A caller observes a topic when they make a Topics API request from a context associated with this topic. To illustrate this concept, consider the following simplified example.

• Suppose there are two Topics API callers: A and B.
• There are two contexts:
  • Greenhouse, for example an app named Greenhouse or a website greenhouse.example, associated with the topic Home & Garden.
  • Tennis exercises, for example an app named Tennis Exercises or a website tennis.example, associated with the topic Sports/Tennis.
• Both caller A and B are present in the context of Greenhouse.
• Only the caller B is present in the context of Tennis exercises.
• Assume that no topics were observed for the user before epoch 1, for the sake of simplification.
• The user visits the Greenhouse app, and callers A and B make a Topics API call to record the user visit to the page or app (see the implementation guide suggested in Next steps to find out how to call the Topics API). This record (a hostname or app data) is later used to derive topics of interest. The Topics API will later mark the topic Home & Garden as observed by both callers A and B.
• The user visits the Tennis exercises app. Only the caller B sends a Topics API request. The Topics API will later mark the topic Sports/Tennis as observed by the caller B.
• By the end of the epoch, the Topics API refreshes the user's top topics and determines the callers that observed these topics based on user activity.
• Later, when the caller B makes another Topics API call, it can get either Home & Garden or Sports/Tennis topic (or, with a 5% chance, a random topic) for this user in the response array.
• Caller A can only access the topic Home & Garden, as it has never observed the topic Sports/Tennis. This means that a third-party will only learn about a user's topic of interest within the specific context (app or website) where it is present.

Derive topics

Topics derives topics of interest from user activity. The topics are selected from a predefined open-source taxonomy. Once per epoch, Topics refreshes the user's top five topics and the callers that observed them during the epoch. The Topics classifier model derives topics from user activity: hostname for a web page visit, app information on Android.

Caller accesses user's topics of interest

The API returns only topics that have been observed by the caller within the most recent three epochs. A maximum of three topics may be returned to a caller,one topic for each of the three recent epochs (if the caller observed topics for that epoch). The returned topics can be used by the caller to supplement any contextual information and can be combined to help find a more relevant ad for the user.

Epochs

The Topics API must ensure that the topics of interest it provides are kept up to date. The topics are inferred for a user based on their activity during a period of time known as an epoch, one week by default. Each user has their own epochs (epochs are "per user") and the initial start time is randomized.

Once each epoch, the Topics API computes the user's top five topics and determines which callers observed those topics using on-device information. The topic selected for each epoch is randomly selected from the user's top five topics for that time period. To further enhance privacy and ensure that all topics may be represented, there is a 5% chance the topic is randomly selected from all possible topics in the taxonomy of interests.

Topics on the Web in practice

On the web, topics are inferred from the hostnames of pages the user visits. For example, the topic inferred for the website dogs.example might be /Pets & Animals/Pets/Dogs.

The following diagram shows a simplified example to demonstrate how the Topics API might help an ad tech platform select an appropriate ad. The example assumes that the user's browser already has a model to map website hostnames to topics.

The browser determines the caller's origin from the context of the code that calls the Topics API. In practice, this means that Topics users call the API in an iframe from their origin or they include topics in a fetch to their origin.

For example, a supply-side platform (SSP) can be embedded on multiple publishers' sites. The SSP could then call the Topics API within an iframe from its origin, allowing it to observe topics associated with a user on those publisher's sites. These topics could then be shared with a demand-side platform (DSP) to help it select a relevant ad for the user.

How the API decides which callers see which topics

API callers only receive topics they've recently observed, and the topics for a user are refreshed once each epoch: a period of time, set to one week in Chrome's implementation. That means the API provides a rolling window in which a given caller may receive observed topics.

The following table outlines an example (though unrealistically small) of a hypothetical browsing history for a user during a single epoch, showing topics associated with the sites they've visited, and the API callers present on each site (the entities that call document.browsingTopics() in JavaScript code included on the site).

Site	Topics	API callers on site
running.example	Running & Walking Athletic Shoes	adtech1.example adtech2.example
dogs.example	Dogs	adtech1.example
holiday.example	Hotels & Accommodations	adtech2.example
sunglasses.example	Sunglasses	[none]

At the end of the epoch (by default one week) the Topics API generates the browser's top topics for the week.

• adtech1.example is now eligible to receive the Running & Walking, Athletic Shoes and Dogs topics, since it observed them on running.example and also on dogs.example.
• adtech1.example is not eligible to receive the Hotels & Accommodations topic for this user as it is not present on any sites the user visited recently that are associated with that topic.
• adtech2.example has seen the Running & Walking, Athletic Shoes and Hotels & Accommodations topics, but has not seen the Dogs topic.

The user visited sunglasses.example, which has the Sunglasses topic, but there were no calls to the Topics API on that site. At this point, this means the Sunglasses topic wouldn't be returned by the API for any caller.

In week two, the user visits another site:

Site	Topics	API callers on site
cameras.example	Camera & Photo Equipment	adtech2.example

In addition, code from adtech2.example is added to sunglasses.example:

Site	Topics	API callers on site
sunglasses.example	Sunglasses	adtech2.example

As well as Running & Walking, Athletic Shoes and Hotels & Accommodations from week 1, this means that adtech2.example will now be able to receive the Camera & Photo Equipment and Sunglasses topics — but not until the following epoch, week 3. This ensures that third parties can't learn more about a user's past (in this case, an interest in fashion) than they could with cookies.

After another two weeks, Running & Walking, Athletic Shoes and Hotels & Accommodations may drop out of adtech2.example's list of eligible topics if the user doesn't visit any sites with those topics that include code from adtech2.example.

Classifier model

Topics uses a classifier model that maps website hostnames to zero or more topics (analyzing additional information, such as full URLs or page content, might allow for more relevant ads, but could also reduce privacy).

Taxonomy

Topics are selected from a taxonomy. These topics have been curated by Chrome, with the goal that the taxonomy becomes a resource maintained by trusted ecosystem contributors. The taxonomy needs to be small enough that many users' browsers will be associated with each topic. The eventual goal is for the taxonomy to be sourced from an external party that incorporates feedback and ideas from across the industry.

To avoid sensitive categories, topics must be public, human-curated, and remain up to date. The taxonomy used by Chrome has been human-curated to exclude categories generally considered sensitive, such as ethnicity or sexual orientation.

Topics classification

Topics are manually curated for 50,000 top sites, and this curated override list of hostnames and topics is used to train the classifier model. For the top sites, topics are accessed from the override list rather than by using the classifier model. You can view the override list locally on your computer.

Chrome's implementation of the Topics API downloads a TensorFlow Lite file representing the model so it can be used locally on the user's device.

How the user's top five topics are selected

The API returns one topic for each epoch, up to a maximum of three. If three are returned, this includes topics for the current epoch and the previous two.

1. At the end of each epoch, the browser compiles a list of pages that meet the following criteria:
   • The page was visited by the user during the epoch.
   • The page includes code that calls document.browsingTopics().
   • The API was enabled (for example, not blocked by the user or by a response header).
2. The browser, on the user's device, uses the classifier model provided by the Topics API to map the hostname for each page to a list of topics.

3. The browser generates a list of the top five topics.

   • Each of the 22 root topics in the taxonomy is assigned to either a "high utility" or "standard utility" bucket based on feedback from the advertising ecosystem. The browser first sorts topics by their bucket assignment. All descendant topics inherit the bucket assignment of their parent root topic. "High utility" topics are prioritized.
   • The browser then sorts topics by frequency within each bucket.
   • The top five topics from this sorted list are selected as the user's top topics for that epoch.

The document.browsingTopics() method then returns a random topic from the top five for each epoch, with a 5% chance that any of these may be randomly chosen from the full taxonomy of topics. In Chrome, users are also able to remove individual topics, or clear their browsing history to reduce the number of topics returned by the API. Users may also opt out of the API.

You can view information about topics observed during the current epoch from the chrome://topics-internals page.

Next steps

See also

Check out our resources to better understand the Topics API on the Web.

• Check out Topics demos, collab and walkthrough videos.
• See the list of Chrome flags that allow developers to customize the Topics API for testing.
• See how users and developers can control the API.
• Check out the resources for technical explainers and support. Ask questions, engage and share feedback.