Topics API の概要

Topics API を使用すると、ユーザーがアクセスしたサイトをトラッキングすることなく、インタレスト ベース広告（IBA）を実施できます。

実装ステータス

Topics API とは

Topics API は、プライバシーを保護しつつ、ブラウザがユーザーの興味 / 関心に関する情報を第三者と共有できるようにするプライバシー サンドボックス メカニズムです。ユーザーがアクセスしたサイトをトラッキングすることなく、インタレスト ベース広告（IBA）を実施できる。

インタレスト ベース広告は、Topics API の重要なコンセプトです。パーソナライズド広告の 1 つで、ユーザーが最近アクセスしたサイトから推測され、興味 / 関心に基づいて広告が選択されます。コンテンツ ターゲット広告では、ユーザーがアクセスしているページ上のコンテンツに合わせて広告を配信します。

インタレスト ベース広告は、広告主（商品やサービスを宣伝したいサイト）とパブリッシャー（広告を使用してコンテンツを収益化するサイト）の両方に役立ちます。

  • IBA は広告主様が見込み顧客にリーチするうえで役立ちます。
  • IBA は、コンテキスト情報を補足するもので、パブリッシャー様は広告を利用してウェブサイトに資金を投じるのに役立ちます。

Topics API は、ユーザーの最近のアクティビティに基づいてブラウザに割り当てられたトピック（インタレスト カテゴリ）を使用した、新しい形式のインタレスト ベース広告を提供します。これらのトピックは、適切な広告を選択するためにコンテキスト情報を補足するものです。

仕組み

従来、複数のサイトをまたいでユーザーの閲覧行動をトラッキングし、関心のあるトピックを推測するために、サードパーティ Cookie やその他のメカニズムが使われていました。これらのメカニズムは段階的に廃止されています。

Topics API では、ブラウザはユーザーの閲覧アクティビティに基づいて、ユーザーが興味を持っていると思われるトピックを監視し、記録します。この情報はユーザーのデバイスに記録されます。Topics API により、ユーザーの閲覧アクティビティに関する追加情報を開示することなく、API の呼び出し元（広告テクノロジー プラットフォームなど）に、ユーザーの興味 / 関心のトピックへのアクセス権を付与できます。

祖先トピックの観察

Chrome 114 以降では、呼び出し元がページでユーザーのトピックを監視する際、ブラウザは呼び出し元もトピックのすべての祖先を確認したと見なします。

たとえば、呼び出し元がユーザーの Shopping/Apparel/Footwear/Boots を観測したことをブラウザが記録している場合、そのトピックの祖先（Shopping/Apparel/Footwear、Shopping/Apparel、Shopping）も観測されたものとみなされます。

以前は、呼び出し元がブラウザから Shopping/Apparel を観測したものとみなすには、API から該当するトピックが観測されたとおりに返される必要がありました。つまり、あるページでユーザーの呼び出し元に対して Shopping/Apparel が確認され、別のページでは Shopping/Apparel/Footwear/Boots が確認された場合、API は両方のページで Shopping/Apparel が確認されたと見なします。

エポック

当然ながら、Topics API は、提供する関心のあるトピックが最新の状態に保たれているようにする必要があります。ブラウザは、エポックと呼ばれる期間（現在は 1 週間）の閲覧アクティビティに基づいて、ユーザーのトピックを推測します。各ユーザーには独自のエポックがあり（エポックは「ユーザーごと」）、最初の開始時間はランダム化されます。エポックごとに選ばれるトピックは、その期間にユーザーが最も関心を持っている 5 つのトピックからランダムに抽出されます。プライバシーをさらに強化し、すべてのトピックが表示されるようにするため、興味 / 関心の分類からトピックがランダムに選択される確率は 5% です。

Topics API には、主に 3 つのタスクがあります。

  • ブラウザのアクティビティを関心のあるトピックにマッピングできます。Topics API の現在の設計では、トピックはユーザーがアクセスしたページのホスト名から推定されます。たとえば、水槽に関するウェブサイトの場合、トピックは「/ペット、動物/ペット/魚、水槽」となります。
  • ユーザーの最近の閲覧アクティビティに基づいて、ユーザーの上位のトピックを算出する。
  • ユーザーが現在関心を持っているトピックにアクセスして、適切な広告を選択できるメカニズムを提供する。

Topics API は、人が読んで理解しやすいトピックを提供するため、ユーザーが有意義なコントロールを提供することができます。

トピックが選定される仕組み

トピックは、/アート、エンターテインメント/音楽、オーディオ/ソウル、R&B や /ビジネス、産業/農業、林業など、階層的なカテゴリで構成される分類から選択されます。これらのトピックは、初期テストのために Chrome によって厳選されたものですが、この分類が、信頼できるエコシステムのコントリビューターが管理するリソースとなることを目標としています。多くのユーザーのブラウザが各トピックに関連付けられるまで、分類は小さくする必要があります。現在、トピックの数は 349 ですが、最終的なトピック数は数百から数千の間になる見込みです。

デリケートなカテゴリを避けるために、トピックは公開され、手作業でキュレートされた最新の情報であることが必要です。Chrome のテストで最初に提案された分類法は、民族性や性的指向など、一般にデリケートであると見なされるカテゴリを除外して人間がキュレートしたものです。

Chrome への Topics API の実装では、上位 10,000 件のサイトを対象に、手動でキュレートされた一般公開されているオーバーライド リストを使用して、ホスト名をトピックにマッピングします。その他のサイトでは、Topics API が機械学習モデルを使用して、ホスト名からトピックを推定します。

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

TensorFlow Lite モデルファイルと、ホスト名から推測されたトピックには chrome://topics-internals からアクセスできます。

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

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

API 呼び出し元は監視したトピックのみを受け取る

Topics API の設計目標は、サードパーティ Cookie で現在可能な以上の情報を共有することなく、インタレスト ベース広告を可能にすることです。Topics API は、API 呼び出し元がすでにトピックに対応しているものについてのみ、限られた期間内にトピックを返すことができるように設計されています。API 呼び出し元は、Topics API がトピックにマッピングしたサイトのコード内で document.browsingTopics() メソッドを呼び出した場合、ユーザーのトピックを監視したと言われます。

API は、直近の 3 エポック内に呼び出し元によって確認されたトピックのみを返します。これにより、ユーザーに関する情報が、API で置き換えられている技術（サードパーティ Cookie を含む）よりも多くのエンティティと共有されるのを防ぐことができます。

返されるトピックの数は、API 呼び出し元がこれまでに確認したトピックの数や、ユーザーが使用できるトピックの数（データの蓄積された週数など）によって異なります。最近の 3 つのエポックのそれぞれに対して 1 つのトピックを示すことができるため、0 ～ 3 つのトピックのいずれかが返されます。

Topics API の使用方法とテスト方法について詳しくは、Topics API デベロッパー ガイドをご覧ください。

API でフィンガープリントを削減する方法

Topics API には、Topics API のみを使用するサイト間で多数のユーザーを再識別しようとするメカニズムが複数用意されています。

  • Topics の分類ではトピックをおおまかに分けることができるため、各トピックのユーザー数は多くなることが予想されます。5% の確率でトピックがランダムに返されるため、トピックあたりの最低ユーザー数が保証されています。
  • トピックはユーザーの上位 5 つからランダムに返されます。
  • ユーザーが同じサイトを（たとえば毎週）頻繁に訪問する場合、サイトで実行中のコードは、多くても週に 1 つの新しいトピックを学習できます。
  • サイトが異なると、同じエポックでも同じユーザーに関する異なるトピックを受け取ります。あるサイトでユーザーに返されたトピックが、別のサイトでユーザーに返されたトピックと一致する可能性は、5 分の 1 のみです。同じユーザーであるかどうかを判別するのが難しくなります。
  • ユーザーのトピックは週に 1 回更新されるため、情報を共有できる頻度が制限されます。言い換えれば、この API はトピックの更新をあまり頻繁に提供しないことで、フィンガープリントの軽減につながります。
  • トピックは、以前に同じユーザーの同じトピックを最近確認した API 呼び出し元についてのみ返されます。このアプローチにより、エンティティが、直接確認していないユーザーの興味 / 関心に関する情報を把握（または共有）する可能性を制限できます。

API による FLoC の懸念への対処

2021 年の FLoC のオリジン トライアルでは、広告テクノロジーとウェブ エコシステムの貢献者から幅広いフィードバックが寄せられました。特に、FLoC のコホートをフィンガープリントのサーフェスとして使用し、ユーザーを識別したり、ユーザーがデリケートなカテゴリと関わっていることが明らかになったりする懸念があった。また、FLoC の透明性を高め、ユーザーにわかりやすくするための提案も行われました。

Topics API は、こうしたフィードバックを念頭に置いて設計されています。透明性の向上、プライバシーの確実性の向上、デリケートなカテゴリに対する異なるアプローチなど、インタレスト ベース広告をサポートする他の方法を模索することを目指しています。

次のステップ

詳しくは、トピックと仕組みについての記事をご覧ください。

広告テクノロジー デベロッパーの方は、Topics API をテストして参加してください。詳しくは、デベロッパー ガイドをご覧ください。

フィードバックを共有