Topics API

ユーザーがアクセスしたサイトを追跡せずに、インタレストベース広告を可能にします。

Published on Updated on

Translated to: English, Español, Português, 한국어, 中文, Pусский

実装状況

このドキュメントでは、インタレストベース広告の新しい提案である Topics API について概説します。


chrome://flags または機能フラグでテストする

Chrome Canary 102 を実行している単一のユーザーに対して Topics API を試すことができます。

  • コマンドラインから privacySandboxAdSapisOverride フラグを設定する
  • chrome://flags/#privacy-sandbox-ads-apis を有効にする

フラグを使用してChromiumを実行するでは、コマンド行から Chrome およびその他の Chromium ベースのブラウザーを実行するときにフラグを設定する方法を説明しています。

これは、初期テストに向けた開発中の API バージョンであるため、機能が完全である、または最終的な実装を示しているとは見なさないでください。

プライバシーサンドボックスのタイムラインには、FLEDGE とその他のプライバシーサンドボックス提案の実装時期に関する情報が提供されています。

機能サポートの検出

API を使用する前に、ページで使用できるかどうかを確認してください。 たとえば、次のようになります。

'browsingTopics' in document ?
console.log ('Document.browsingTopics() はこのページでサポートされています'):
console.log ('Document.browsingTopics() はこのページでサポートされていません');
Caution

現在のページでの機能のサポートは、API が使用可能であることを保証するものではありません。ユーザーがブラウザー設定で API を無効にしたり、API の使用が防止される他の設定が存在する可能性があります。 ユーザーのプライバシーを保護するために、これをプログラムで確認する方法はありません。


この API が必要な理由

Topics API は 、ユーザーがアクセスしたサイトを追跡せずに、インタレストベース広告を可能にするメカニズムのためのプライバシーサンドボックス の提案 です。

インタレストベース広告 (IBA) はパーソナライズド広告の一形態で、最近アクセスしたサイトから推測されるユーザーの興味/関心に基づいて広告が選択されます。 これは、ユーザーがアクセスしているページのコンテンツと照合することを目的としたコンテンツターゲット広告とは異なります。

IBA は、広告主が潜在的な顧客にリーチするのを支援し、コンテンツターゲット広告だけでサイトへのアクセスを簡単に収益化できない Web サイトに資金を提供するのに役立ちます。 IBA は、現在のページのコンテキスト情報を補足して、ユーザーにとって適切な広告を表示できるようにします。

Topics API は、ユーザーが現在関心を持っている可能性のあるトピックを、最近の閲覧アクティビティに基づいて提供する方法を提案します。 これらのトピックはコンテキスト情報を補足し、適切な広告を選択できるようにします。

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

  • Web サイトのホスト名を関心のあるトピックにマッピングする。 たとえば、ヨガの Web サイトは、「フィットネス」に関連する項目 に分類されることが考えられます。
  • 最近の閲覧アクティビティに基づいて、ユーザーの上位のトピックを計算する。
  • ユーザーが現在関心を持っているトピックを提供する JavaScript API を提供し、適切な広告を選択できるようにする。

Topics API は、人が認識可能かつハイレベルなトピックで構成されているため、堅牢なユーザー制御が容易に可能です。 Chrome では、個々のトピックを削除するオプションと、ブラウザーに保存されているトピックを表示するオプションを提供する予定です。

トピックの分類と選択の方法

トピックは分類体系から選択されます。これは、「カントリーミュージック」、「メークアップ & コスメ」、「ベジタリアン料理」などの項目のリストです。 これらのトピックは、当初、テスト用に Chrome で分類されますが、最終的には、トピックの分類は、エコシステムに貢献している信頼された組織によって管理されることを目指しています。 できる限り多くのブラウザーが各トピックに関連付けられるように、分類はに使用されるトピックの数はある程度絞る必要があります (現在の提案は約 350 ですが、最終的なトピックの数は数百から数千になると想定されています)。 センシティブなカテゴリを避けるには、これらのトピックを公開し、人間が分類し、 最新の状態に保つ必要があります。 Chrome のテスト用に提案された最初の分類は、民族性や性的指向など、一般的にセンシティブと考えられるのカテゴリを除外するために人間が分類しています。

Topics API では、機械学習を使用して、ホスト名からトピックを推測することを提案しています。 このための分類子モデルは、最初は、ブラウザーベンダー、または信頼できるサードパーティによって、人間が分類するホスト名とトピックを使用して学習されます。 モデルはブラウザーとともに配布されるため、オープンに開発され、自由に利用できます。 ユーザーのデバイスのブラウザーは、このモデルを使用して、最近アクセスしたサイトの のホスト名 に基づいて、ユーザーに最も関心のあるトピックを計算できます。 以下の図は、アドテクプラットフォームが適切な広告を選択する方法を Topics API がどうサポートするかを単純化した例として示しています。 この例では、ユーザーのブラウザーに、Web サイトのホスト名をトピックにマッピングするための モデルが既に存在していることを前提としています。

ユーザーが Web サイトにアクセスしてから広告 が表示されるまでの Topics API ライフサイクルのステージを示す図

Topics API ライフサイクル: 拡大バージョンを表示

Topics API の仕組み

Topics API の提案は、エコシステムからフィードバックを収集し、そのフィードバックに基づいて行動するための最初のディスカッションフェーズです。

API 設計は最終段階ではなく、検討が進むにつれて次の詳細内容が変更されます。

Topics APIなどのインタレストベース広告を容易にするメカニズムは、提供される興味/関心のトピックが最新の状態であることを保証する必要があります。

Topics API の提案では、ブラウザーは、「エポック」と呼ばれる期間(現在 1 週間と提案されている)の閲覧アクティビティに基づいて、ユーザーのトピックを推測します。 エポックごとに選択されたトピックは、その期間におけるユーザーの上位 5 つのトピックからランダムに選択されます。 プライバシーをさらに強化し、すべてのトピックが確実に表示されるようにするため、5% の確率で分類上のすべてのトピックからランダムに選択されます。

Topics JavaScriptAPI には、document.browsingTopics() という 1 つのメソッドがあります。 これは、最大 3 つのトピック (直近の 3 つのエポックごとに 1 つずつ) をランダムに含む配列に解決される Promise を返します。

Topics の Explainer では、document.browsingTopics () によって返される配列の各トピックオブジェクトに次の 3 つのプロパティを設定することを提案しています。

  • value: 分類体系のトピックを識別する数値
  • taxonomyVersion: ブラウザーで現在使用されているトピックの集合を識別する文字列
  • classifierVersion: ホスト名からサイトのトピックを推測するために使用される機械学習分類子を識別する文字列

現在、Topics API の設計は、Explainer として議論されています。これは標準化プロセスの最初のステップに過ぎません。 API は確定されていません。

この記事で説明するパラメーターと API の詳細 (分類サイズ、1 週間に計算されるトピック数、呼び出しごとに返されるトピック数など) は、エコシステムのフィードバックを取り入れ、API に反映させることを繰り返すため、変更される可能性があります。

API 呼び出し元は観測したトピックのみを受信する

Topics API の設計目標は、現在サードパーティ Cookie よりも少ない数のエンティティに情報を共有しながら、インタレスト ベース広告を実現することです。 Topics API では、制限された時間枠内で、すでにユーザーを観測した API 呼び出し元に対してのみ、そのユーザーのトピックを返すことを提案しています。

Key Term

トピック API の呼び出し元は、document.browsingTopics() JavaScript メソッドを「呼び出す」エンティティで、メソッドによって返されたトピックを使用して、関連する広告を選択できるようにします。 通常、 document.browsingTopics() の呼び出しは、アドテクプラットフォームなどのサードパーティのサイトに含まれているコードから実行されます。 ブラウザーが現在のドキュメントのサイトから呼び出し元を判定します。 そのため、ページのサードパーティである場合は、必ず自社サイトが所有する iframe から API を呼び出してください。

Document.browsingTopics () が 1 つ以上のトピックを返すには、それらのトピックが観測されたサイトのコードと同じオリジンのコードでこのメソッドが呼び出される必要があります。

API呼び出し元は、Topics API がそのトピックにマッピングしたサイトに含まれるコードで document.browsingTopics() メソッドを呼び出した場合に、ユーザーのトピックを「観測」したとされます。 たとえば、次のようになります。

  1. Topics API は、ホスト名 knitting.example を「布&織物製品」を含むトピックにマッピングします。
  2. adtech.example のコードは、knitting.example のページに含まれます。
  3. ユーザーが knitting.example にアクセスします。
  4. adtech.example のコードが document.browsingTopics () を呼び出します。
  5. ブラウザーが knitting.example で推測したトピックの 1 つは、「 布&織物製品」です。
  6. adtech.example は、そのユーザーの「布&織物製品」というトピックを観測したとされます。

API の document.browsingTopics() メソッドは、直近の 3 つのエポックで呼び出し元によってすでに観測されたトピックのみを提供します。 これにより、ユーザーに関する情報が、API が取って代わるテクノロジー (サードパーティ Cookie を含む) よりも多くのエンティティと共有されるのを防ぐことができます。

document.browsingTopics() によって返されるトピックの数は、API 呼び出し元が以前に観測したトピックの数と、ユーザーが利用できるトピックの数 (データが蓄積された週数など) によって異なります。 0 ~ 3 つのトピックが返される可能性があります。

Topics JavaScript API の記述例

次のコードは、考えられる API の使用方法の基本的な例を示しています (簡潔にするために、エラー 処理はありません)。

Warning

このコードスニペットは Topics JavaScript API の記述例です。 API の設計は変更される可能性があり、このコードは現在どのブラウザでも動作しません。

// このユーザーの上位トピックの配列を取得する。
const topics = await document.browsingTopics();

// 広告クリエイティブを要求する。
const response = await fetch('https://ads.example/get-creative', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
},
body: JSON.stringify(topics)
})

// 応答から JSON を取得する。
const creative = await response.json();

// 広告を表示する。

Topics API でどの呼び出し元がどのトピックを表示できるのかを決定する方法

API 呼び出し元は最近観測されたトピックのみを受信します。ユーザーのトピックはエポックごとに 1 回更新されます。 つまり、API は定期的に繰り返される時間枠を提供し、その時間枠内では特定の呼び出し元が特定のトピックを受信できます。 次の表は、1 つのエポックにおけるユーザーの仮説的な閲覧履歴の例 (確率的に非常に小さい) の概要を示します。ユーザーがアクセスしたサイトに関連付けられたトピックと、API 呼び出し元 が各サイト (サイトに含まれる JavaScript コードで document.browsingTopics () を呼び出すエンティティ) に提示するトピックを示します。

サイトトピックサイトの API 呼び出し元
yoga.exampleフィットネスadtech1.example adtech2.example
knitting.example手工芸adtech1.example
hiking-holiday.exampleフィットネス、旅行 & 交通adtech2.example
diy-clothing.example手工芸、ファッション & スタイル[none]

エポックの終わり (現在の提案では 1 週間) に、Topics API はブラウザーの 1 週間の上位トピック を生成します。

  • adtech1.example は、yoga.example と knitting.example で観測されたため、「フィットネス」トピックと「手工芸」のトピックを受信する資格があります。
  • adtech1.example には、このユーザーの「旅行 & 交通」トピックを受信する資格がありません。理由は、ユーザーが最近アクセスした「旅行 & 交通」トピックに関連付けられたサイトに、adtech1.example が存在しないためです。
  • adtech2.example では「フィットネス」と「旅行 & 交通」のトピックは見ていますが、「手工芸」のトピックは見ていません。

ユーザーは「ファッション & スタイル」というトピックを持つ diy-clothing.example にアクセスしましたが、そのサイトで Topics API への呼び出しはありませんでした。 この時点で、どの呼び出し元に対する「ファッション & スタイル」トピックも API によって返されません。

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

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

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

サイトトピックサイトの API 呼び出し元
diy-clothing.example手工芸、ファッション & スタイルadtech2.example

これは、第 1 週の「フィットネス」と「旅行 & 交通」に加えて、adtech2.example は「手工芸」と「ファッション & スタイル」のトピックを受信できることを意味します。ただし、次のエポックである第 3 週目までは受信しません。 これにより、サードパーティが Cookie を使用する場合よりもユーザーの過去 (この場合はファッションへの関心) について得られる情報が限定的になることが担保されます。

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

API がサイトのトピックを推測する方法

Topics API Explainer は、トピックが分類子 モデルから派生し、Web サイトホスト名を 0 個以上のトピックにマッピングすることを提案しています。 追加情報 (完全な URL やページコンテンツなど) を分析すると、関連性の高い広告が有効になりますが、プライバシーが低下する可能性もあります。 ホスト名をトピックにマッピングするための分類子モデルは公開され、Explainer ではブラウザー開発者ツールを使用してサイトのトピックを表示できると提案しています。 マッピングモデルは定期的に更新されます。更新の頻度は現在検討中です。

ユーザーの上位 5 つのトピックが選ばれる方法

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

  1. 各エポックの終わりに、ブラウザーは以下の条件を満たすページのリストをコンパイルします。

    • エポック中にユーザーがこのページにアクセスした。
    • このページに document.browsingTopics() を呼び出すコードが含まれている。
    • API が有効になっている (例: ユーザーまたは応答ヘッダーによってブロックされていない)。
  2. ユーザーのデバイスのブラウザーは、Topics API によって提供される分類子モデルを使用して、各ページのホスト名としてトピックのリストにマッピングします。

  3. ブラウザーにはトピックのリストが蓄積されます。

  4. ブラウザーは、上位 5 つのトピックのリストを頻度に応じて生成します。

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

FLoC に関する懸案事項に Topics API がどう対処するのか

2021 年の FLoC のオリジントライアルでは、アドテクおよび Web エコシステムのコントリビューターから幅広いフィードバックを受け取りました。 特に、ユーザーを識別するために FLoC コホートがフィンガープリント面として使用されたり、ユーザーとセンシティブなカテゴリとの関連付けが明らかにされたりする可能性があるという懸念がありました。 FLoC をユーザーにとってより透過的で理解しやすいものにするための喚起もありました。

Topics API は、このフィードバックを念頭に置いて設計されており、透明性の向上、プライバシー保護の強化、センシティブなカテゴリに対するさまざまなアプローチによって、インタレストベース広告をサポートする他の方法を模索しています。

フィンガープリントの削減

Topics API では、Topics API だけを使用してサイト全体でかなりの数のユーザーの再識別を確実に防止するために、複数のメカニズムが提案されています。

  • Topics 分類は粒度の粗いトピックの集合を提供します (最初の分類の合計は約 350)。つまり、(特定のブラウザーの合計ユーザー数によりますが) 各トピックに多数のユーザーが存在する可能性を高めます。 実際、返されるトピックは 5% の確率でランダムであるため、トピックごとのユーザーの最小数が保証されています。
  • トピックは、ユーザーの上位 5 つからランダムに返されます。
  • 5% の確率で、ランダムなトピックが (全てのトピックセットから選択され) 提供されます。
  • ユーザーが同じサイトに頻繁に (毎週など) アクセスする場合、サイトで実行されているコードは、1 週間に最大 1 つの新しいトピックしか学習しません。
  • サイトが異なると、同じエポック内の同じユーザーでも受信するトピックが異なります。 あるサイトのユーザーに対して返されたトピックが別のサイトのユーザーに対して返されたトピックと一致する確率はわずか 5 分の 1 です。 このため、同じユーザーであるかどうかを判断するのがさらに難しくなります。
  • ユーザーのトピックは週に 1 回更新されるため、情報を共有できる確率が制限されます。
  • トピックは、最近同じユーザーに対して同じトピックを観察した API 呼び出し元に対してのみ返されます。 このモデルは、エンティティが最初に観測していなかったユーザーの興味/関心に関する情報を知る (または共有する) 可能性を制限するのに役立ちます。

注意が必要なトピック

Topics 分類はセンシティブなカテゴリを避けるために人間が分類します。

さらに、サイトとユーザーの両方が、Topics API をオプトアウトできます。

Topics API の提案の Explainer では次のように説明されています。 「サードパーティ Cookie を使用して、ユーザーがアクセスした正確な URL から、それらのページの正確なページコンテンツまで、ユーザーに関するあらゆる情報を追跡できます。 これには、センシティブな資料が無限に含まれる可能性があります。 一方、Topics API は、人間が管理するトピックの分類法に制限されています。 他の項目がその分類のトピックと統計的に相関することができないわけではありません。 これは可能です。 しかし、2 つを比較すると、Topics は Cookie よりも明らかに改善されているようです。」

ユーザー制御と透明性

ユーザーは、Topics API の目的を理解し、ユーザーについて何が言われているのかを認識し、API がいつ使用されているかを把握し、それを有効または無効にするための制御方法が提供されている必要があります。

API の人間が認識できる分類により、人々はブラウザーによって関連付けられる可能性のあるトピックについて学習、管理できます。 ユーザーは、Topics API で広告主やパブリッシャーと共有したくない具体的なトピックを削除できます。また、API と API を有効または無効にする方法についてユーザーに通知するための UX も考えられます。 Chrome は chrome: //settings/privacySandbox で Topics API の情報と設定を提供します。 また、シークレットモードにある API 呼び出し元はトピックを使用できず、閲覧履歴がクリアされるとトピックもクリアされます。

サイトオプトアウト

Topics API を呼び出すコードを含むサイトのみが閲覧履歴に含まれ、トピック頻度計算の対象になります。API 呼び出し元は観測したトピックのみを受信します。 つまり、サイトまたは組み込まれたコードが API を呼び出すアクションを実行しないかぎり、サイトはトピック頻度計算の対象にはなりません。

Topics API の Explainer では、次の Permissions-Policy ヘッダーを使用して、サイトが訪問者のトピック計算をブロックできるようにすることも提案されています。

Permissions-Policy: browsing-topics=()

FLOC の既存の Permissions-Policy interest-cohort=() もトピック計算を禁止します。

ユーザーオプトアウト

Topics API の Explainer では、次の場合に返されるトピックのリストが空になることが提案されています。

  • ユーザーが chrome: //settings/privacySandbox のブラウザー設定を使用して Topics API をオプトアウトする。
  • ユーザーが (chrome://settings/privacySandbox のブラウザー設定を使用して) トピックをクリアしたか、Cookie をクリアした。
  • ブラウザーがシークレットモードである。

Explainer では、プライバシー目標と、API がどのようにプラバシー目標に対処しているのかについて、詳細を提供しています。


議論への参加とフィードバックの共有

詳細

Last updated: Improve article

We serve cookies on this site to analyze traffic, remember your preferences, and optimize your experience.