トピックが推測される仕組みや、トピックがユーザーのユーザーがトピックリストを管理する方法などについて解説しました。
実装ステータス
- The Topics API has completed the public discussion phase and is currently available to 99 percent of users, scaling up to 100 percent.
- To provide your feedback on the Topics API, create an Issue on the Topics explainer or participate in discussions in the Improving Web Advertising Business Group. The explainer has a number of open questions that still require further definition.
- The Privacy Sandbox timeline provides implementation timelines for the Topics API and other Privacy Sandbox proposals.
- Topics API: latest updates details changes and enhancements to the Topics API and implementations.
トピックとは
Topics API におけるトピックとは、ユーザーが関心を持っているテーマのことで、ユーザーがアクセスしたウェブサイトからわかります。
トピックは、広告テクノロジー プラットフォームが関連性の高い広告を選択するうえで役立つシグナルです。サードパーティ Cookie とは異なり、この情報は、ユーザー自身やユーザーの閲覧アクティビティに関する詳細情報を開示することなく共有されます。
Topics API を使用すると、広告テクノロジー プラットフォームなどのサードパーティが、ユーザーの関心のあるトピックを監視してアクセスできます。たとえば、API は「Fiber &テキスタイル アート」ウェブサイト knitting.example にアクセスしたユーザーに表示されます。
Topics API で使用されるトピックのリストは、人間がキュレートした一般公開のトピックのリストで、判読可能で、デリケートなカテゴリを避けるように設計されています。こちらは最新のリストであり、今後さらに拡充される予定です。このリストは分類として構造化されています。トピックは、おおまかな内容でも、より具体的な内容でも構いません。たとえば、Food & Drink は大まかなカテゴリで、サブカテゴリは Cooking & Recipes です。サブカテゴリはさらにサブカテゴリに分類される場合があります。
このようなトピックの分類は、有用性とプライバシーのトレードオフの関係にあります。トピックが限定的すぎる場合は、個々のユーザーを識別できる可能性があります。一般的すぎると、広告やその他のコンテンツの選択に役立ちません。
トピックの分類は、次の 2 つの基本的な要件を念頭に置いて構築されています。
- インタレスト ベース広告をサポートする
- ユーザーの安全を維持し、プライバシーを保護する
このことから、いくつかの質問が予想されます。例:
- ユーザーのプライバシーを保護しながら、閲覧アクティビティに基づいてユーザーの興味 / 関心のトピックを API で推測する最適な方法は何ですか。
- この分類法をどのように構造化すれば、さらに便利になるでしょうか。
- 分類には具体的にどのような項目を含める必要がありますか？
API がサイトのトピックを推測する方法
トピックは、ウェブサイトのホスト名を 0 個以上のトピックにマッピングする分類モデルから導出されます。 追加情報（完全な URL やページ コンテンツなど）を分析すると、広告の関連性が高まりますが、プライバシーが低下する可能性があります。
ホスト名をトピックにマッピングする分類モデルは一般公開されており、説明のとおり、ブラウザのデベロッパー ツールを使用してサイトのトピックを表示できます。このモデルは、時間の経過とともに進化、改善され、定期的に更新されることが期待されます。この頻度はまだ検討中です。
Topics API を呼び出すコードを含むサイトのみがトピックの表示頻度の計算対象となる閲覧履歴に含まれ、API 呼び出し元は確認したトピックのみを受け取ります。つまり、サイトまたは API を呼び出す埋め込みサービスがないと、サイトはトピックの頻度を計算できません。
また、呼び出し元は、コードが「見た」トピックのみを受信できます。そのため、別の呼び出し元のコードによってユーザーのブラウザにトピック（/Autos & Vehicles/Motor Vehicles (By Type)/Hatchbacks など）が登録され、そのトピックがそのユーザーのブラウザに登録されていない場合、埋め込みコードから API を呼び出すときに、そのユーザーのブラウザに関連するトピックを知ることはできません。API には観測された祖先が含まれるようになったため、上記の例の /Autos & Vehicles/Motor Vehicles (By Type)/Hatchbacks によって Autos & Vehicles と Motor Vehicles も観測されたことになります。
ユーザーに返されるトピックは、トップレベル サイトに応じて呼び出し元について再計算されます。たとえば、adtech.example が news-a.example、news-b.example、news-c.example でユーザーのトピックをリクエストした場合、ユーザーに返されたトピックは各サイトで再計算されます。つまり、ユーザーに返されるトピック（最大）の 3 つは、過去 3 回のエポックで上位 5 つからランダムに選択されるため（トピックはランダムに取得される確率は 5%）、トップ レベルのサイトによって、ユーザーが異なるトピックを受け取る可能性が高くなります。この場合、トピックによって呼び出し元がユーザーを識別するのが難しくなります。これは、トップレベル サイトによってトピックが異なる可能性があるためです（ユーザー、呼び出し元、エポックが同じであっても）。
分類モデル
50,000 の上位ドメインについてトピックを手動でキュレートし、このキュレーションを使用して分類器をトレーニングします。このリストは override_list.pb.gz にあります。chrome://topics-internals/ の [分類] タブで、現在のモデルから入手できます。リスト内のドメインとトピックの関連付けは、モデル自体の出力の代わりに API によって使用されます。
![[分類器] パネルが選択されている chrome://topics-internals ページ](https://developers-dot-devsite-v2-prod.appspot.com/static/privacy-sandbox/assets/images/chrometopics-internals-8d62cfff441e4.png?authuser=9&hl=ja)
chrome://topics-internals] ページの [分類器] パネルには、モデル バージョン、そのパス、一覧表示された各ホストに関連付けられたトピックが一覧表示されます。モデルを直接実行するには、TensorFlow のモデル実行ガイドをご覧ください。
override_list.pb.gz ファイルを調べるには、まずファイルを解凍します。
gunzip -c override_list.pb.gz > override_list.pb
protoc を使用して、これをテキストとして検査します。
protoc --decode_raw < override_list.pb > output.txt
GitHub では、トピックの ID による分類をすべて確認できます。
分類モデルに対するフィードバックまたは入力の提供
Topics API に関するフィードバックは、複数のチャネルから送信できます。分類モデルに関するフィードバックについては、GitHub の問題を送信するか、既存の問題に返信することをおすすめします。例:
ユーザーの上位 5 つのトピックが選択される仕組み
API はエポックごとに 1 つのトピック（最大 3 つ）を返します。3 つ返された場合は、現在のエポックと前の 2 つのエポックのトピックが含まれます。
- 各エポックの終了時に、ブラウザは次の条件を満たすページのリストを作成します。
<ph type="x-smartling-placeholder">
- </ph>
- このページは、エポック期間中にユーザーがアクセスしました。
- このページには、
document.browsingTopics()を呼び出すコードが含まれています。 - API が有効になっている（例: ユーザーまたはレスポンス ヘッダーによってブロックされていない）。
- ユーザーのデバイス上のブラウザは、Topics API が提供する分類モデルを使用して、各ページのホスト名をトピックのリストにマッピングします。
- ブラウザにトピックのリストが蓄積されます。
- ブラウザは、頻度別に上位 5 つのトピックのリストを生成します。
次に、document.browsingTopics() メソッドは、エポックごとに上位 5 つのトピックからランダムなトピックを返します。5% の確率で、これらのトピックはトピックの完全な分類からランダムに選択されます。Chrome では、ユーザーは個々のトピックを削除したり、閲覧履歴を消去したりして、API から返されるトピックの数を減らすこともできます。ユーザーは API をオプトアウトすることもできます。
現在のエポック中に観測されたトピックに関する情報は、chrome://topics-internals ページで確認できます。
どの呼び出し元にどのトピックを表示するかを API が決定する方法
API 呼び出し元は、最近確認されたトピックのみを受け取り、ユーザーのトピックはエポックごとに 1 回更新されます。つまり、API では、特定の呼び出し元が特定のトピックを受け取ることができるローリング ウィンドウが提供されます。
以下の表は、ある 1 回のエポックにおけるユーザーの仮の閲覧履歴の例（非現実的には小さいものの）を示したもので、ユーザーがアクセスしたサイトに関連するトピックと、各サイト（サイトに含まれる JavaScript コードで document.browsingTopics() を呼び出すエンティティ）の API 呼び出し元が表示されています。
| サイト | トピック | サイトでの API 呼び出し元 |
|---|---|---|
| yoga.example | フィットネス | adtech1.example、adtech2.example |
| knitting.example | 工芸品 | adtech1.example |
| deck-holiday.example | フィットネス、旅行、運輸 | adtech2.example |
| diy-clothing.example | 工芸、ファッションスタイル | [なし] |
エポックの終わり（現在は 1 週間）になると、Topics API により、その週のブラウザの上位のトピックが生成されます。
- adtech1.example が「Fitness」と「Crafts」yoga.example や knitting.example でも確認されているためです。
- adtech1.example が「Travel &交通トピックに関連するサイトにはこのユーザーが最近アクセスしたどのサイトにも存在しないためです。
- adtech2.example で「Fitness」が「旅行・交通検索したとします。しかし、「クラフト」のトピックは説明します。
このユーザーが diy-clothing.example にアクセスしています。スタイル」そのサイトでは Topics API の呼び出しがありませんでした。この時点では、これは「ファッションとスタイル」どの呼び出し元に対しても API からトピックは返されません。
2 週目、ユーザーが別のサイトにアクセスします。
| サイト | トピック | サイトでの API 呼び出し元 |
|---|---|---|
| sewing.example | 工芸品 | adtech2.example |
さらに、adtech2.example のコードが diy-clothing.example に追加されます。
| サイト | トピック | サイトでの API 呼び出し元 |
|---|---|---|
| diy-clothing.example | 工芸、ファッションスタイル | adtech2.example |
「フィットネス」は「旅行・交通つまり、adtech2.example が「Crafts」トークンを「ファッションとスタイル」ただし、次のエポック、第 3 週までです。これにより、サードパーティがユーザーの過去（この場合はファッションへの関心）について、Cookie よりも詳しく知ることができなくなります。
さらに 2 週間後には「旅行・交通adtech2.example のコードを含むこれらのトピックを扱うサイトにユーザーがアクセスしない場合、adtech2.example の対象トピックのリストから除外されることがあります。
ユーザー コントロール、透明性、オプトアウト
ユーザーが Topics API の目的を理解し、Topics API について言及されていることを認識して、API がいつ使用されているかを把握して、API を有効または無効にするコントロールを提供できるようにする必要があります。
人が読める形式のこの API の分類により、ユーザーはブラウザによって提案されるトピックについて把握し、制御できます。ユーザーは、Topics API で広告主やパブリッシャーと共有したくないトピックを削除できます。また、API についてユーザーに通知して、有効または無効にする方法を示すコントロールも用意されています。Chrome では、Topics API に関する情報と設定を chrome://settings/adPrivacy で提供しています。また、シークレット モードでは API 呼び出し元はトピックを利用できず、閲覧履歴を削除するとトピックも消去されます。
次の場合、返されるトピックのリストは空になります。
- ユーザーがブラウザの設定（
chrome://settings/adPrivacy）で Topics API をオプトアウトしています。 - ユーザーが（
chrome://settings/adPrivacyのブラウザ設定を介して）トピックを消去したか、Cookie を消去しました。 - ブラウザがシークレット モードになっています。
プライバシー目標について詳しく説明し、API が目標にどのように対処するのかを説明しています。
サイトのオプトアウト
ユーザーがオプトアウトできるだけでなく、サイトやページ上で Topics をオプトアウトすることもできます。方法については、デベロッパー ガイドをご覧ください。
prebid.js があるウェブサイトで Topics API を使用する
Prebid 7 のリリースでお知らせしたとおり、 新しいモジュールを通じて Topics API との統合を積極的に開発しました。 このモジュールは 2022 年 12 月に統合されました。
詳しくは以下をご覧ください。
- Prebid の Topics API モジュールのドキュメントをご覧ください。
- 詳しくは、Prebid.js が提供している標準のチャネルを通じてお問い合わせください。
次のステップ
- 広告テクノロジー デベロッパーの方は、Topics API をテストして参加してください。
- 詳しくは、デベロッパー ガイドをご覧ください。
- 特定の広告テクノロジーのユースケースについて詳しくは、Topics API 統合ガイドをご覧ください。
フィードバックを共有
- GitHub: Topics API の説明を読み、API リポジトリで問題の投稿とディスカッションのフォローを行います。
- W3C: 「ウェブ広告ビジネスの改善」グループで、業界のユースケースについてご確認ください。
- お知らせ: メーリング リストへの参加や表示を行います。
- プライバシー サンドボックスのデベロッパー サポート: プライバシー サンドボックス デベロッパー サポート リポジトリで質問したり、ディスカッションに参加したりできます。
- Chromium: 現在 Chrome でテストできる実装について質問がある場合は、Chromium のバグを報告してください。