モバイル向け Topics API: 概要

Android の Topics API と、その実装手順について学びます。トピックの実装に直接進むこともできます。

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.

Android の実践に関するトピック

Android の Topics API は、通常複数のアプリで動作するサードパーティ広告 SDK をサポートするように設計されています。Topics は、クロスアプリ識別子に依存することなく、ユーザーのアプリ使用状況に基づいて、興味に関する大まかな広告トピックを呼び出し元に提供します。これらのトピックを使用すると、広告を表示するアプリに関連するコンテキスト情報を補完でき、組み合わせることでユーザーに適した広告を選択できます。

Topics API のコンテキストでは、購入者と広告主はセルサイドに依存します。パブリッシャーのアプリに幅広く存在し、ユーザーのトピックを観察し、トピックを購入者と共有して、より関連性の高い広告を選択できるようにするのは販売者側です。トピックを取得するには、セルサイドのアプリと SDK が少なくとも 1 つのエポックの間 Topics API のオブザーバーとなって、フットプリントを確立する必要があります。

インタレスト ベース広告のトピック取得機能をセットアップする方法を示すコードサンプルについては、Topics API 実装ガイドをご覧ください。

ビジネスの種類によるトピックの統合

Topics API で IBA(インタレスト ベース広告)を有効にします。広告テクノロジー ビジネスの種類に応じて手順に沿って Topics API を統合し、リリースに向けて準備を整えます。

すべての広告テクノロジー

  • Topics の分類を確認し、フィードバックを提供します。
  • Topics API のサンプルアプリを試して、デバイス上の分類器から返されるトピックデータを確認します。
  • Topics API の呼び出しを開始するようアプリと SDK のフローを更新します。
  • プロトコルを更新して、広告リクエストでトピックの送信を開始します。
  • プライバシー サンドボックスに広告テクノロジーを登録します。

セルサイド広告テクノロジー

  • オブザーバーになって Topics API のフットプリントを確立します。Topics API は新しいシグナルを提供するため、Topics API の呼び出しを開始するには SDK を更新する必要があります。トピックを一貫して取得するには、SDK がパブリッシャー アプリからエポックごとに少なくとも 1 回 API を呼び出す必要があります。広告リクエストで送信するトピックの最大数(3 つのトピック)を取得するには、最大 4 エポックを要します。
  • 広告リクエストに Topics API の情報を含めます。広告リクエストごとに、バイサイド パートナーとの Topics API データの共有を開始します。Topics API では、特定の訪問者に適した広告を見つけやすくするために他のシグナル(コンテキスト シグナルなど)を補完することも予定されています。
  • バイサイド パートナーとトピックを共有するためのプロトコルに共同で取り組みます。Topics API では、各 SDK がダウンストリームのパートナーと連携して Topics API のデータの共有方法に同意する必要があります。

バイサイド広告テクノロジー

  • セルサイド パートナーに連絡し、トピックをモニタリングしてフットプリントを確立する計画について確認します。トピックを受信するには、セルサイド プロバイダはエポックごとに少なくとも 1 回 Topics API を呼び出す必要があります。
  • セルサイド パートナーからトピックを受け取るためのプロトコルに共同で取り組みます。トピックは、広告リクエストの一部としてセルサイド パートナーが共有する新しいシグナルです。バイサイドの消費者は、トピックの共有方法についてアップストリームのパートナーと連携するようにする必要があります。
  • 入札や最適化のモデルにトピックを組み込みます。Topics API は、コンテキストに合ったものなど、その他のシグナルを補完して訪問者に適した広告を見つけやすくすることが期待されています。

API がアプリのトピックを推測する仕組み

Android では、Topics API は分類モデルを使用して、アプリ情報に基づいてアプリのトピックを推測します。現在の実装では、Topics はアプリ名とパッケージ名を使用して興味のあるトピックをアプリに割り当てますが、今後、アプリの説明などの他の情報を含めるように拡張される可能性があります。

トピック分類器

興味に関するトピックは、一般公開されているアプリ情報でトレーニングされた分類器モデルから得られます。

  • 推論に分類器モデルを使用して所定のエポックのトピックを算出すると、使用されたシグナルのセットがデバイスに残ります。このシグナルのセットには、インストール済みのアプリまたは最近使用されたアプリを含めることができ、後で他のシグナルを含むように拡張される場合があります。
  • V5 モデルは、Google Play ストアなどのアプリストアから入手した、人間がラベル付けした 54 万件と ML がラベル付けした 1,700 万件の公開アプリ情報を使用してトレーニングされています。このモデルは、アプリ名とパッケージ名を入力シグナルとして使用します。アプリ デベロッパーは、このモデルを自由に利用して、アプリがどのトピックに分類されるかをテストできます。
  • アプリが複数のトピックにマッピングされる、トピックにマッピングされない、またはユーザーのトピック履歴に追加されない可能性があります。分類の際にアプリが複数のトピックにマッピングされる場合、アプリに対して選択されるトピックの数が上位 3 つに制限されます。

分類器モデルの仕組みをより深く理解するために、Android Topics Classifier Colab を使用して、さまざまなアプリデータが分類にどのように影響するかをテストしてみてください。

分類

トピックは事前に定義されたオープンソースの分類から選択されます。分類は一般公開されていますが、変更される可能性があります。ページ上部のフィードバック ボタンを使用して提案を提出できます。この分類は、プライベートなトピックが含まれないように、人の手を経てキュレートされます。この分類は、Android のモバイルアプリでの表示が可能な広告のカテゴリに合わせてカスタマイズされます。

Android の実践に関するトピック

ユーザーがデバイスに 7 つのアプリ(A、B、C、D、E、F、G)をインストールしているとします。アプリのトピック分類とアプリの広告テクノロジー SDK が、次のようになっているとします。

アプリ トピック分類 広告テクノロジー 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

第 1 週の終わりに、Topics API がこのエポックの上位 5 つのトピックを生成します。

上位のトピック トピックの学習が可能な呼び出し元
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

第 2 週にいずれかのアプリの呼び出し元が API を呼び出すと、該当するエポック、トピック、アプリについて、呼び出し元が「トピックの学習が可能な呼び出し元」の列にあるトピックのみを含んだリストが返されます。

  • トピックの算出に際し、各呼び出し元が利用できる履歴ウィンドウは、3 エポック(3 週間)です。
  • 使用できるトピックは、広告 SDK を通じて Topics API を呼び出しているアプリに関連付けられたもののみです。つまり、アプリに Topics API を呼び出す広告 SDK が含まれない場合、そのアプリに関連付けられたトピックは、広告 SDK がアクセスできるトピックのプールに貢献しません。
  • アプリで Topics API を宣言的にオプトアウトすることもできます。オプトアウトしたアプリに関連付けられたトピックは、週ごとのトピックの算出には影響を及ぼしません。このドキュメントは、関連する実装の詳細を含むように更新される予定です。

プラットフォームで 5 つのトピックを推測できるほどアプリが使用されていない場合は、残りのトピックをランダムに生成するなどのオプションが検討される可能性があります。

返されたトピックの暗号化

Topics API を呼び出す登録済みの広告テクノロジー プラットフォームは、返されたトピックを呼び出し元のみが読み取れるように、暗号鍵も提供する必要があります。

プライバシー サンドボックスは、広告テクノロジーによって提供されるエンドポイントからこれらの鍵を取得します。キーは少なくとも 6 か月ごとに定期的に更新することをおすすめします。

プライバシー サンドボックスでは、登録プロセス中に提供したエンドポイントの可用性を確認するよう広告テクノロジー企業に求めるメッセージが表示されます。現在登録されている広告テクノロジーと新規登録される広告テクノロジーで必要な対応について詳しくは、登録ガイドをご覧ください。

次のステップ

呼び出し元がトピックをオブザーバブルにしてアクセスするための実装の詳細とコードサンプルを確認します。
ユーザーとデベロッパーが、ユーザーの好みやニーズに合わせて Topics API を管理、カスタマイズする方法について学びます。

See also

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