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.

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 ユーザーは参照元から iframe 内で API を呼び出すか、参照元への fetch にトピックを含めます。

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

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

API 呼び出し元は最近確認したトピックのみを受け取り、ユーザーのトピックはエポック（Chrome の実装では 1 週間に設定されている期間）ごとに 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.example と dogs.example で確認したため、Running & Walking、Athletic Shoes、Dogs のトピックを受け取ることができます。
• adtech1.example は、このユーザーについて Hotels & Accommodations トピックを受け取ることができません（このトピックに関連する、ユーザーが最近アクセスしたどのサイトにも存在しないため）。
• adtech2.example は Running & Walking、Athletic Shoes、Hotels & 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 & Walking、Athletic Shoes、Hotels & Accommodations と同様に、adtech2.example は後続のエポック（第 3 週）から Camera & Photo Equipment と Sunglasses のトピックを受け取れるようになります。これにより、第三者がユーザーの過去（この場合、ファッションに興味があること）について、Cookie を使用した場合よりも詳細に把握することはできなくなります。

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

分類モデル

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

分類

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

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

トピックの分類

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

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

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

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

1. 各エポックの最後に、ブラウザは次の基準を満たすページのリストをコンパイルします。
   • 対象エポック中にユーザーによってアクセスされたページ。
   • このページには、document.browsingTopics() を呼び出すコードが含まれています。
   • API が有効になっている（たとえばユーザーまたはレスポンス ヘッダーによってブロックされていない）。
2. ユーザーのデバイスで、ブラウザは Topics API が提供する分類モデルを使用して、各ページのホスト名をトピックのリストにマッピングします。

3. ブラウザが上位 5 つのトピックのリストを生成します。

   • 分類の 22 個のルートトピックはそれぞれ、広告エコシステムのフィードバックに基づいて「高ユーティリティ」または「標準ユーティリティ」のバケットに割り当てられます。ブラウザはまず、トピックをバケットの割り当てで並べ替えます。すべての子孫トピックは、親ルートトピックのバケット割り当てを継承します。「有用性の高い」トピックが優先されます。
   • 次に、ブラウザは各バケット内のトピックを頻度順に並べ替えます。
   • この並べ替えられたリストの上位 5 つのトピックが、そのエポックのユーザーの上位トピックとして選択されます。

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

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

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.