Topics API for Mobile overview

Learn about the Topics API on Android, and the steps involved in implementing it. You can also jump straight into implementing topics.

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.
Diagram showing tat the Topics API only marks the topics as observed if the callers has presence in the context.
The Topics API marks the topics observed only by the callers that have presence in the context of these topics. The callers will only be able to access the topics they have observed.

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 Android in practice

The Topics API on Android is designed to support third-party advertising SDKs that typically operate across multiple apps. Topics provides callers with coarse-grained advertising topics of interest based on the user's app usage, without relying on cross app identifiers. These topics can be used to supplement any contextual information related to the app that wants to display an ad, and can be combined to help select an appropriate ad for the user.

In the context of the Topics API, buyers and advertisers depend on the sell-side. It is the seller side that has a broad presence on the publisher's apps and observes user's topics, and then shares the topics with the buyers to help them select more relevant ads. To get topics, sell-side apps and SDKs must establish a footprint by being an observer of the Topics API for at least one epoch.

Refer to the Topics API implementation guide ) for code samples that demonstrate how to set up the ability to fetch topics for interest-based advertising.

Topics integration by business type

Enable for IBA (interest-based-advertising) with the Topics API. Follow the steps based on your ad tech business type to integrate the Topics API and get ready for the launch.

For all ad techs

  • Review the Topics taxonomy and provide feedback.
  • Experiment with the Topics API sample apps to see what topics data is returned from the on-device classifier.
  • Update app and SDK flows to start calling the Topics API.
  • Update protocols to start sending topics in ad requests.
  • Enroll your ad tech with the Privacy Sandbox.

For sell-side ad techs

  • Become an observer to establish a Topics API footprint. The Topics API provides a new signal, so you will need to update your SDK to start calling the Topics API. To consistently retrieve topics, your SDK must call the API from publisher apps at least once per epoch. It takes up to four epochs to get the maximum amount of topics (three topics) to send with your ad requests.
  • Include Topics API information in your ad requests. For each ad request, start sharing your Topics API data with buy-side partners. The Topics API plans to supplement other signals (such as contextual signals) to help find an appropriate advertisement for a given visitor.
  • Collaborate on a protocol for sharing topics with your buy-side partners. The Topics API needs each SDK to work with downstream partners to agree on how Topics API data is shared.

For buy-side ad techs

  • Connect with sell-side partners to confirm their plans to observe topics and establish footprint. To receive topics, sell-side providers must call the Topics API at least once per epoch.
  • Collaborate on a protocol for receiving topics from your sell-side partners. Topics is a new signal that will be shared by sell-side partners as part of the ad request. Buy-side consumers will need to ensure they work with their upstream partners on how topics will be shared.
  • Incorporate topics in bidding and optimization models. The Topics API is expected to supplement other signals like contextual to help find an appropriate advertisement for the visitor.

How the API infers topics for an app

On Android, Topics API infers topics for an app based on app information, using a classifier model. In the current implementation, Topics uses app and package names to assign topics of interest to an app, but this may later be extended to include other information such as app description.

Topic classifier

Topics of interest are derived from a classifier model that is trained on publicly available app information.

  • When the classifier model is used for inference to compute the topics for a given epoch, the set of signals used remain on the device. This set of signals may include apps installed or recently used, and it may later be expanded to include other signals.
  • The V5 model was trained by Google on 540,000 human-labeled and 17 million ML-labeled publicly available app information from app stores like the Google Play Store. The model uses app names and package names as input signals and is freely available for app developers to test and see what topics their app classifies to.
  • It's possible that an app maps to more than one topic, or to no topics, or that it isn't added to the user's topic history. In the event that an app maps to more than one topic in the taxonomy, the number of topics chosen for this app will be limited to the top three.

To get a better understanding of how the classifier model works, you can test how different app data affects classification by using the Android Topics Classifier Colab

Taxonomy

Topics are selected from a predefined open-source taxonomy. The taxonomy is publicly available, and subject to change. Suggestions can be filed using the feedback button at the top of this page. This taxonomy is human-curated so that sensitive topics are not part of the taxonomy. It will be tailored to the categories of ads that can be shown on mobile apps on Android.

Topics on Android in practice

Suppose a user has seven apps installed on the device: A, B, C, D, E, F and G. Assume that the topic classification for the app and the ad tech SDKs in these apps are as follows:

App Topic classification Ad tech SDK
A T1, T5 ad-sdk1, ad-sdk2
B T2 ad-sdk2
C T3, T6 ad-sdk3, ad-sdk4
D T1, T4 ad-sdk1
E T5 ad-sdk4, ad-sdk5
F T6 ad-sdk2, ad-sdk3, ad-sdk4
G T7 ad-sdk2

End of week one: The Topics API generates the user's top 5 topics for this epoch.

Top Topic Callers that can learn about the topic
T1 ad-sdk1, ad-sdk2
T2 ad-sdk2
T3 ad-sdk3, ad-sdk4
T4 ad-sdk1
T5 ad-sdk1, ad-sdk2, ad-sdk4, ad-sdk5

In week two, if a caller on any app calls the API, then the returned topic list will only include topics for which the caller is in the "Callers that can learn about the topic" column for that topic for that app for that epoch.

  • The history window included in the calculation of topics available to each caller is three epochs (or three weeks).
  • Only topics associated with apps that invoke the Topics API through ad SDKs are used. This means that if an app doesn't include any ad SDKs that call the Topics API, the topics associated with that app don't contribute to the pool of topics accessible by ad SDKs.
  • An app can also declaratively opt out of the Topics API. Topics associated with opted-out apps won't contribute to the weekly topic computation. This document will be updated to include related implementation details.

If there's not enough app usage for the platform to infer five topics, the platform may consider options like randomly generating remaining topics.

Encryption of returned topics

Enrolled ad tech platforms that call the Topics API are also required to provide encryption keys to ensure that the returned topics are readable only to the caller.

Privacy Sandbox will fetch these keys from the endpoint provided by the ad tech . We recommend as best practice that the keys are updated regularly, but no at least every six months.

Privacy Sandbox will ask ad techs to confirm the availability of the endpoint they provide during the enrollment process. For more details on action required by current and newly enrolled ad techs, see the enrollment guide

Next steps

Check out implementation details and code samples for callers to observe and access topics.
Learn how users and developers can manage and customize the Topics API to suit user's preferences and needs.

See also

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