Topics API for Web

Topics API を使用すると、サードパーティ Cookie を使用せずにインタレスト ベースの広告を掲載できます。

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.

ウェブに関するトピックの実践

ウェブでは、ユーザーがアクセスしたページのホスト名からトピックが推測されます。たとえば、ウェブサイト dogs.example から推定されるトピックは /ペット、動物/ペット/犬 などです。

次の図は、Topics API が広告テクノロジー プラットフォームの適切な広告選択にどのように役立つかをわかりやすく示したものです。この例では、ウェブサイトのホスト名をトピックにマッピングするモデルがユーザーのブラウザに組み込み済みであることを前提としています。

ユーザーがウェブサイトにアクセスしてから広告が表示されるまでの、Topics API ライフサイクルの各ステージを示す図。
Topics API のライフサイクル図は、API アクションの各ステージを概要として示しています。

ブラウザは、Topics API を呼び出すコードのコンテキストから呼び出し元のオリジンを判断します。実際には、Topics ユーザーがオリジンから iframe 内の API を呼び出すか、オリジンへのフェッチにトピックを含めます。

たとえば、サプライサイド プラットフォーム(SSP)は複数のパブリッシャーのサイトに埋め込むことができます。SSP は、オリジンから iframe 内の Topics API を呼び出して、パブリッシャーのサイトでユーザーに関連付けられたトピックを検出できます。これらのトピックは、デマンドサイド プラットフォーム(DSP)と共有して、ユーザーに関連性の高い広告を選択できるようにできます。

API がどの呼び出し元にどのトピックを表示するかを決定する仕組み

API 呼び出し元は最近確認したトピックのみを受け取り、ユーザーのトピックはエポックごとに 1 回更新されます。エポックとは、Chrome の実装では 1 週間に設定されている一定期間です。つまり、Topics API には、特定の呼び出し元が確認済みのトピックを受け取ることができるローリング ウィンドウが存在します。

次の表は、1 つのエポックにおけるユーザーの仮想的なブラウジング履歴の例を示しています(ただし、現実的な規模ではありません)。訪問したサイトに関連付けられたトピックと、各サイトに存在する API 呼び出し元(サイトに含まれる JavaScript コードで document.browsingTopics() を呼び出すエンティティ)を示しています。

サイト トピック サイトの API 呼び出し元
running.example Running & Walking
Athletic Shoes
adtech1.example
adtech2.example
dogs.example Dogs adtech1.example
holiday.example Hotels & Accommodations adtech2.example
sunglasses.example Sunglasses [なし]

エポック(デフォルトは 1 週間)の最後に、Topics API はその週について、ブラウザの上位のトピックを生成します。

  • adtech1.example は、Running & WalkingAthletic ShoesDogs のトピックを受け取ることができます(running.example と dogs.example で確認したため)。
  • adtech1.example は、このユーザーについて Hotels & Accommodations トピックを受け取ることができません(このトピックに関連する、ユーザーが最近アクセスしたどのサイトにも存在しないため)。
  • adtech2.example は Running & WalkingAthletic ShoesHotels & Accommodations のトピックを確認していますが、Dogs トピックは確認していません。

ユーザーは Sunglasses トピックがある sunglasses.example にアクセスしましたが、そのサイトに Topics API の呼び出しはありませんでした。つまりこの時点では、どの呼び出し元に対しても API が Sunglasses トピックを返すことはありません。

第 2 週に、ユーザーが別のサイトにアクセスします。

サイト トピック サイトの API 呼び出し元
cameras.example Camera & Photo Equipment adtech2.example

また、adtech2.example のコードが sunglasses.example に追加されます。

サイト トピック サイトの API 呼び出し元
sunglasses.example Sunglasses adtech2.example

第 1 週の Running & WalkingAthletic ShoesHotels & Accommodations と同様に、adtech2.example は後続のエポック(第 3 週)から Camera & Photo EquipmentSunglasses のトピックを受け取れるようになります。これにより、第三者がユーザーの過去(この場合、ファッションに興味があること)について、Cookie を使用した場合よりも詳細に把握することはできなくなります。

さらに 2 週間後、Running & WalkingAthletic ShoesHotels & Accommodations は、adtech2.example のコードが含まれる、これらのトピックを持つサイトにユーザーがアクセスしなかった場合、adtech2.example の対象トピックのリストから外れる可能性があります。

ユーザーが API を使用するサイトにアクセスしたときに Topics API が行う処理の流れ。
API がトピックをモニタリングしてアクセスする方法。

分類モデル

Topics は、ウェブサイトのホスト名を 0 個以上のトピックにマッピングする分類モデルを使用します(完全な URL やページ コンテンツなどの追加情報を分析することで、広告の関連性が高まる可能性はありますが、プライバシーが損なわれるおそれもあります)。

分類

トピックは分類から選択されます。これらのトピックは、信頼できるエコシステムの協力者による分類の維持管理を目標に、Chrome によって選定されています。分類においては、各トピックにより多くのユーザーのブラウザが関連付けられるよう、トピック数を必要最小限にする必要があります。最終的な目標は、業界全体からのフィードバックやアイデアを組み込んだ外部パーティから分類を取得することです。

デリケートなカテゴリが含まれないよう、トピックは公開され、判読可能で、常に更新される必要があります。Chrome で使用される分類は、一般的にデリケートと考えられるカテゴリ(民族や性的指向など)を除外するように手動で選定されています。

トピックの分類

トピックは、上位 5 万サイトについて手動でキュレートされています。このキュレートされたホスト名とトピックのオーバーライド リストが、分類モデルのトレーニングに使用されます。上位サイトの場合、トピックには分類器モデルではなくオーバーライド リストからアクセスされます。オーバーライド リストをローカルのパソコンで確認できます。

[分類システム] パネルが選択された chrome://topics-internals ページ。
[chrome://topics-internals] ページの [分類システム] パネルには、モデルのバージョン、パス、リスト内の各ホストに関連付けられているトピックが表示されます。

Chrome の実装では、Topics API を使用してモデルを表す TensorFlow Lite ファイルをダウンロードし、ユーザーのデバイスでローカルに使用できるようにします。

ユーザーの上位 5 つのトピックが選ばれる仕組み

API はエポックごとにトピックを 1 つ返します(最大 3 つ)。3 つ返される場合は、現在のエポックのトピックと、前 2 つのエポックのトピックが返されます。

  1. 各エポックの最後に、ブラウザは次の基準を満たすページのリストをコンパイルします。
    • 対象エポック中にユーザーによってアクセスされたページ。
    • このページには、document.browsingTopics() を呼び出すコードが含まれています。
    • API が有効になっている(たとえばユーザーまたはレスポンス ヘッダーによってブロックされていない)。
  2. ユーザーのデバイスで、ブラウザは Topics API が提供する分類モデルを使用して、各ページのホスト名をトピックのリストにマッピングします。
    • 分類の 22 個のルートトピックはそれぞれ、広告エコシステムからのフィードバックに基づいて「高ユーティリティ」または「標準ユーティリティ」のバケットに割り当てられます。ブラウザはまず、トピックをバケットの割り当て順に並べ替えます。すべての子トピックは、親ルートトピックのバケット割り当てを継承します。「有用性が高い」トピックが優先されます。
    • 次に、ブラウザは各バケット内でトピックを頻度順に並べ替えます。
    • この並べ替えられたリストの上位 5 つのトピックが、そのエポックのユーザーの上位トピックとして選択されます。

document.browsingTopics() メソッドは、エポックごとに上位 5 つの中からランダムにトピックを返します(トピックの全分類からランダムに選ばれる確率は 5%)。Chrome では、ユーザーが個々のトピックを削除したり、閲覧履歴を消去したりすることで、API から返されるトピックの数を減らすこともできます。ユーザーは API をオプトアウトすることもできます。

現在のエポックで検出されたトピックに関する情報は、chrome://topics-internals ページで確認できます。

Next steps

Get your environment ready to test and develop web applications with the Topics API.
Check out implementation details and code samples for callers to observe and access topics.

関連情報

ウェブ上の Topics API について理解を深めるには、Google のリソースをご覧ください。