Topics API for Web

Topics API 可讓您在不使用第三方 Cookie 的情況下，按照興趣顯示廣告。

Topics API 的運作方式

您可以使用 Topics API，根據使用者的活動，觀察並提供他們感興趣的主題。接著，Topics API 就能讓 API 呼叫端 (例如廣告技術平台) 存取使用者感興趣的主題，但不會揭露使用者活動的其他資訊。

核心概念

  • 「主題」是人類可讀形式的使用者興趣主題，並屬於 主題分類。
  • 呼叫端是指向 Topics API 發出要求，以觀察或存取使用者興趣的實體，例如應用程式、第三方 SDK、網站或服務。
  • 如果呼叫端在過去三個週期內，曾經從與某個主題相關聯的網頁或應用程式發出 Topics API 要求，即表示呼叫端「觀察」了該主題。
  • 「週期」是主題計算作業的時間長度，預設為一週。
  • 分類法是類別的階層清單，例如 /Arts & Entertainment/Music & Audio/Soul & R&B 和 /Business & Industrial/Business Services/Corporate Events 等類別。
  • 系統會使用分類器模型擷取主題，該模型會將使用者活動對應至零個或多個主題。

Topics API 流程核心步驟

Topics API 生命週期有三個主要步驟：

  • 觀察使用者活動，例如使用者造訪網頁 https://cats.example/tabby/index.html 或下載應用程式 cats 時。
  • 從使用者活動推導主題，例如 /Pets & Animals/Pets/Cats。
  • 存取使用者先前觀察到的主題，例如做為選取相關廣告 (例如貓食促銷活動) 的信號。

觀察主題

呼叫端只能存取「觀察」過的主題。當呼叫端從與該主題相關聯的內容發出 Topics API 要求時，即表示該呼叫端觀察了該主題。為了說明這個概念，請參考以下簡化的範例。

  • 假設有兩個 Topics API 呼叫端：A 和 B。
  • 有兩種情境：
    • Greenhouse，例如與主題 Home & Garden 相關聯的應用程式 Greenhouse 或網站 greenhouse.example。
    • 網球練習，例如與主題 Sports/Tennis 相關聯的應用程式「網球練習」或網站 tennis.example。
  • 呼叫端 A 和 B 都位於 Greenhouse 的內容中。
  • 在「網球練習」情境中，只有呼叫端 B 會出現。
  • 為了簡化說明，我們假設在第 1 個時段之前，系統並未觀察到任何使用者主題。
  • 使用者造訪 Greenhouse 應用程式，呼叫端 A 和 B 發出 Topics API 呼叫，記錄使用者造訪該網頁或應用程式 (如要瞭解如何呼叫 Topics API，請參閱「後續步驟」中建議的導入指南)。這項記錄 (主機名稱或應用程式資料) 稍後會用於衍生出感興趣的主題。Topics API 稍後會將主題 Home & Garden 標示為由呼叫端 A 和 B 觀察到。
  • 使用者造訪「網球練習」應用程式。只有呼叫端 B 會傳送 Topics API 要求。Topics API 稍後會將主題 Sports/Tennis 標示為呼叫端 B 觀察到的主題。
  • 在週期結束時，Topics API 會重新整理使用者最感興趣的主題，並根據使用者活動判斷觀察到這些主題的呼叫端。
  • 稍後，當呼叫端 B 發出另一個 Topics API 呼叫時，它可以在回應陣列中取得 Home & Garden 或 Sports/Tennis 主題 (或有 5% 機率取得隨機主題)，以便為此使用者提供服務。
  • 呼叫端 A 從未觀察到主題 Sports/Tennis，因此只能存取主題 Home & Garden。也就是說，第三方只能在特定情境 (應用程式或網站) 中瞭解使用者感興趣的主題。
圖表顯示，只有在呼叫端在情境中出現時，Topics API 才會將主題標示為觀察到。
Topics API 會標示出只有在這些主題內容中出現的呼叫端觀察到的話題。呼叫端只能存取觀察過的主題。

衍生主題

Topics 會從使用者活動中找出感興趣的主題。系統會從預先定義的開放原始碼分類中選取主題。每個週期，Topics 都會重新整理使用者最感興趣的五個主題，以及在該週期內觀察到這些主題的呼叫端。主題分類器模型會根據使用者活動推斷主題，包括網頁造訪的網域名稱，以及 Android 上的應用程式資訊。

呼叫端存取使用者感興趣的主題

API 只會傳回呼叫端在最近三個週期內觀察到的主題。系統最多會向呼叫端傳回三個主題，每個最近的三個週期各一個 (如果呼叫端觀察到該週期的主題)。呼叫端可使用傳回的主題補充任何脈絡資訊，也可以將這些主題結合，為使用者尋找更相關的廣告。

訓練週期

Topics API 必須確保提供的興趣主題保持最新狀態。系統會根據使用者在「訓練週期」內 (目前建議長度為一週) 的活動，推測使用者的偏好主題。每位使用者都有自己的 epoch (epoch 為「每位使用者」)，且初始開始時間為隨機。

在每個週期中，Topics API 會計算使用者最感興趣的五個主題，並判斷哪些呼叫端使用裝置端資訊觀察這些主題。系統會在每個訓練週期內推測出使用者的五大偏好，並從中隨機選出一項做為該週期的主題。為進一步強化隱私權，並確保所有主題都能呈現，系統會從興趣分類中隨機選取主題，機率為 5%。

網路主題實作

在網頁上，系統會根據使用者造訪的網頁主機名稱推測主題。舉例來說，系統可能會為網站 dogs.example 推斷的主題為 /Pets & Animals/Pets/Dogs。

下圖簡要說明瞭 Topics API 如何協助廣告技術平台選取合適的廣告。這個範例假設使用者的瀏覽器已設有將網站主機名稱對應至主題的模型。

圖表顯示 Topics API 生命週期中的各個階段，從使用者造訪網站到顯示廣告。
Topics API 生命週期圖表從高層面向您介紹 API 動作的各個階段。

瀏覽器會根據呼叫 Topics API 的程式碼內容，判斷呼叫端的來源。實際上，這表示 Topics 使用者會從來源呼叫 iframe 中的 API，或是在來源的擷取中加入主題。

舉例來說，供給方平台 (SSP) 可嵌入多個發布商網站。接著，供應端平台就能從原始來源呼叫 iframe 中的 Topics API，觀察使用者在這些發布商網站上的相關主題。這些主題可與需求端平台 (DSP) 共用，協助對方為使用者選取相關廣告。

API 如何決定哪些呼叫端可查看哪些主題

API 呼叫端只會收到最近觀察到的主題，而使用者的主題會在每個週期中更新一次：在 Chrome 實作中，週期為一週。也就是說，API 會提供一個滾動視窗，讓特定呼叫端接收觀察到的主題。

下表列出使用者在單一時間範圍內的假設瀏覽記錄 (雖然不太實際)，其中顯示與使用者造訪的網站相關的主題，以及各個網站上的 API 呼叫端 (在網站上包含的 JavaScript 程式碼中呼叫 document.browsingTopics() 的實體)。

網站 主題 網站上的 API 呼叫端
running.example Running & Walking
Athletic Shoes		 adtech1.example
adtech2.example
dogs.example Dogs adtech1.example
holiday.example Hotels & Accommodations adtech2.example
sunglasses.example Sunglasses [無]

在週期結束時 (預設為一週)，Topics API 會產生瀏覽器當週最感興趣的主題。

  • 由於 adtech1.example 在 running.example 和 dogs.example 中觀察到 Running & Walking、Athletic Shoes 和 Dogs 主題，因此現在有資格接收這些主題。
  • adtech1.example 不符合取得此使用者 Hotels & Accommodations 主題的資格，因為使用者最近造訪的任何網站都沒有與該主題相關聯的內容。
  • adtech2.example 已看到 Running & Walking、Athletic Shoes 和 Hotels & Accommodations 主題，但未看到 Dogs 主題。

使用者造訪了包含 Sunglasses 主題的 sunglasses.example，但該網站並未呼叫 Topics API。這表示 API 不會為任何呼叫端傳回 Sunglasses 主題。

在第二週，使用者造訪其他網站：

網站 主題 網站上的 API 呼叫端
cameras.example Camera & Photo Equipment adtech2.example

此外，adtech2.example 中的程式碼會新增至 sunglasses.example：

網站 主題 網站上的 API 呼叫端
sunglasses.example Sunglasses adtech2.example

除了第 1 週的 Running & Walking、Athletic Shoes 和 Hotels & Accommodations 外，這也表示 adtech2.example 現可接收 Camera & Photo Equipment 和 Sunglasses 主題，但必須等到下一個週期 (第 3 週) 才會開始。這樣一來，第三方就無法透過 Cookie 瞭解使用者的過往 (在本例中為對時尚的興趣)。

如果使用者沒有造訪任何含有 adtech2.example 程式碼的網站，Running & Walking、Athletic Shoes 和 Hotels & Accommodations 可能會在兩週後從 adtech2.example 的適用主題清單中移除。

使用者造訪使用 Topics API 的網站時，Topics API 會採取的步驟。
API 如何觀察及存取主題。

分類器模型

Topics 會使用分類器模型，將網站主機名稱對應至零個或多個主題 (分析其他資訊 (例如完整網址或網頁內容) 可能會顯示更相關的廣告，但也可能會降低隱私權)。

分類

系統會從分類中選出主題。這些主題是由 Chrome 策劃，目標是讓分類法成為可由信任的生態系統貢獻者維護的資源。分類項目必須夠小，才能讓許多使用者的瀏覽器與每個主題建立關聯。最終目標是讓分類項目來自外部來源，納入業界的意見回饋和構想。

為避免使用敏感類別，主題必須公開、經過人工挑選，且保持最新狀態。Chrome 使用的分類法是經過人工審核的排除一般認為敏感的類別，例如種族或性傾向。

主題分類

我們會手動為 50,000 個熱門網站編輯主題，並使用這份主機名稱和主題的編輯覆寫清單來訓練分類器模型。對於熱門網站，系統會從覆寫清單存取主題，而非使用分類器模型。您可以在電腦上查看覆寫清單。

chrome://topics-internals 頁面，已選取「Classifier」面板。
「chrome://topics-internals」頁面「分類器」面板會列出模型版本、路徑，以及與每個主機相關聯的主題。

Chrome 實作 Topics API 時會下載代表模型的 TensorFlow Lite 檔案，以便在使用者的裝置上本機使用。

如何選出使用者的前五大主題

API 會為每個週期傳回一個主題，最多可傳回三個。如果傳回三個主題，則包含目前和前兩個週期的主題。

  1. 在每個 epoch 結束時，瀏覽器會編譯符合下列條件的網頁清單：
    • 使用者在該時間範圍內造訪該網頁。
    • 這個頁面包含呼叫 document.browsingTopics() 的程式碼。
    • API 已啟用 (例如未遭使用者或回應標頭封鎖)。
  2. 使用者裝置上的瀏覽器會使用 Topics API 提供的分類器模型，將每個網頁的主機名稱對應至主題清單。
    • 根據廣告生態系統的意見回饋，分類法中的 22 個根主題都會指派至「高效用性」或「標準效用性」值區。瀏覽器會先依主題的桶分配結果進行排序。所有子主題都會繼承其父項根主題的值區指派。系統會優先處理「高實用性」主題。
    • 然後，瀏覽器會依據各個類別中的頻率排序主題。
    • 系統會從這份排序清單中選出前五個主題，做為使用者在該週期內的偏好主題。

document.browsingTopics() 方法隨後會從每個週期的前五大主題中隨機傳回一個主題，且有 5% 的機率會從完整的主題分類中隨機選擇任何主題。在 Chrome 中，使用者也可以移除個別主題，或清除瀏覽記錄，以減少 API 傳回的主題數量。使用者也可以選擇停用 API。

您可以在 chrome://topics-internals 頁面中查看目前時間範圍內觀察到的主題相關資訊。

後續步驟

備妥使用 Topics API 測試及開發網頁應用程式的環境。
查看實作詳細資料和程式碼範例，方便呼叫端觀察及存取主題。

另請參閱

請參閱我們的資源，進一步瞭解 Topics API 在網路上的運作方式。