トピック分類

トピックがどのように推測されるか、ユーザーのブラウザにどのように割り当てられるか、ユーザーがトピックリストを管理する方法を確認します。

実装ステータス

トピックとは

Topics API において、トピックとは、ユーザーがアクセスしたウェブサイトによって裏付けられる、ユーザーが関心を持っているテーマのことです。

トピックは、広告テクノロジー プラットフォームが関連性の高い広告を選択するためのシグナルです。サードパーティ Cookie とは異なり、この情報は、ユーザー自身やユーザーの閲覧アクティビティに関する詳細情報を開示することなく共有されます。

Topics API により、広告テクノロジー プラットフォームなどのサードパーティは、ユーザーが関心のあるトピックを監視してアクセスできます。たとえば、ウェブサイト 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/ の [Classifier] タブの現在のモデルで確認できます。リスト内のドメインとトピックの関連付けは、モデル自体の出力の代わりに API によって使用されます。

[分類器] パネルが選択された chrome://topics-internals ページ。
[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

ID を含むトピックの分類全体は GitHub で確認できます。

分類器モデルに関するフィードバックまたは入力を提供する

Topics API に関するフィードバックは、複数のチャネルで提供しています。分類器モデルに関するフィードバックについては、GitHub の問題を送信するか、既存の問題に返信することをおすすめします。次に例を示します。

ユーザーが最も関心を持っている 5 つのトピックが選ばれる仕組み

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

  1. ブラウザは各エポックの最後に、次の条件を満たすページのリストを作成します。
    • エポック中にユーザーがページにアクセスした。
    • このページには、document.browsingTopics() を呼び出すコードが含まれています。
    • API が有効になっている（例: ユーザーまたはレスポンス ヘッダーを介してブロックされていない）。
  2. ユーザーのデバイス上のブラウザは、Topics API が提供する分類モデルを使用して、各ページのホスト名をトピックのリストにマッピングします。
  3. ブラウザではトピックのリストが蓄積されます。
  4. ブラウザは、頻度別に上位 5 つのトピックのリストを生成します。

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

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

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

API 呼び出し元は最近確認したトピックのみを受け取り、ユーザーのトピックはエポックごとに 1 回更新されます。つまり、API は特定の呼び出し元が特定のトピックを受信できるローリング ウィンドウを提供します。

以下の表は、1 エポックにおけるユーザーの仮の閲覧履歴の例の概要を示しています。これは、ユーザーがアクセスしたサイトに関連するトピックと、各サイトに存在する API 呼び出し元（サイトに含まれる JavaScript コードで document.browsingTopics() を呼び出すエンティティ）を示しています。

サイト トピック サイト上の API 呼び出し元
yoga.example フィットネス adtech1.example、adtech2.example
knitting.example 工芸品 adtech1.example
ハイキング休日.example フィットネス、旅行、交通 adtech2.example
DIY 衣類.example クラフト、ファッション、スタイル [なし]

エポック（現在は 1 週間）の終わりに、Topics API により、その週のブラウザでの上位のトピックが生成されます。

  • adtech1.example は、yoga.example と knitting.example で観察されたため、「フィットネス」と「クラフト」のトピックを受信できるようになりました。
  • adtech1.example は、このユーザーの「旅行、交通」トピックを受信できません。このトピックに関連する、ユーザーが最近アクセスしたサイトにないためです。
  • adtech2.example には、「フィットネス」と「旅行、交通」のトピックが表示されましたが、「クラフト」のトピックは確認されていません。

ユーザーが「Fashion & Style」トピックを含む diy-clothing.example にアクセスしましたが、このサイトでは Topics API の呼び出しはありませんでした。この時点では、どの呼び出し元に対しても、API から「Fashion & Style」トピックは返されません。

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

サイト トピック サイト上の API 呼び出し元
sewing.example 工芸品 adtech2.example

さらに、adtech2.example のコードが diy-clothing.example に追加されます。

サイト トピック サイト上の API 呼び出し元
DIY 衣類.example クラフト、ファッション、スタイル adtech2.example

つまり、第 1 週の「フィットネス」と「旅行、交通」に加えて、adtech2.example は「工芸」と「ファッションとスタイル」のトピックを受け取れるようになりますが、次のエポックである第 3 週までは受信できません。これにより、第三者がユーザーの過去（この場合はファッションへの興味）について Cookie を使用する場合よりも多くの情報を得ることはできなくなります。

さらに 2 週間後、adtech2.example のコードを含むトピックのサイトにユーザーがアクセスしない場合、adtech2.example の対象トピックリストから「フィットネス」と「旅行、交通」が除外される可能性があります。

ユーザー コントロール、透明性、オプトアウト

ユーザーが Topics API の目的を理解し、Topics API について何の説明かを認識し、API がいつ使用されているかを把握し、API を有効または無効にするコントロールが提供される必要があります。

この API の人間が読める形式の分類により、ユーザーはブラウザから提案されるトピックについて確認し、管理することができます。Topics API で広告主やパブリッシャーと共有したくないトピックを削除できます。また、Topics 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 月にマージされました。

詳しくは以下をご覧ください。

次のステップ

フィードバックを共有