Topics API for Web の概要

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

実装ステータス

Topics API とは

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

インタレスト ベース広告は Topics API の重要なコンセプトです。パーソナライズド広告の一種で、ユーザーが最近アクセスしたサイトから推測された興味 / 関心に基づいて広告が選択される。これは、ユーザーがアクセスしているページの内容に合わせて広告をマッチングすることを目的としたコンテンツ ターゲット広告とは異なります。

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

  • 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 によって厳選されたものですが、この分類が信頼できるエコシステムのコントリビューターが管理するリソースとなることを目標としています。この分類は、多くのユーザーのブラウザが各トピックに関連付けられるのに十分な大きさである必要があります。現在、トピック数は 469 ですが、最終的なトピック数は数百から数千になる見込みです。

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

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

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

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

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

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

API 呼び出し元はモニタリングしたトピックのみを受け取る

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

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

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

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 をテストして参加してください。詳細なリソースについては、デベロッパー ガイドをご覧ください。

フィードバックを共有