網頁版 Topics API 總覽

Topics API 不需要追蹤使用者造訪的網站，就能按照興趣顯示廣告 (IBA)。

導入狀態

什麼是 Topics API？

Topics API 是一種 Privacy Sandbox 機制，可保護隱私權，同時讓瀏覽器與第三方分享使用者興趣的相關資訊。不必另外追蹤使用者造訪的網站，就能按照興趣顯示廣告 (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 必須確保提供的興趣主題保持在最新狀態。瀏覽器會根據使用者在「訓練週期」(目前一週) 內的瀏覽活動，推測使用者的主題。每位使用者都有自己的訓練週期 (以「每位使用者」表示)，初始開始時間為隨機排序。系統會在每段訓練週期內推測出使用者的五大偏好，並從中隨機選出一項做為該週期的主題。為了進一步強化隱私權並確保所有主題的呈現，我們有 5% 的機率會從興趣的分類中，從所有可能的主題中隨機選出該主題。

Topics API 有三項主要工作：

  • 將瀏覽器活動對應到感興趣的主題。根據目前的 Topics API 設計，系統會從使用者造訪的網頁主機名稱推斷主題。舉例來說，關於水族館相關網站推斷出的主題可能是「/寵物與動物/寵物/魚與水族」。
  • 根據使用者的近期瀏覽活動計算熱門主題。
  • 提供機制來存取使用者目前感興趣的主題，協助選擇適當的廣告。

Topics API 提供人類可讀且容易理解的主題，所以能為使用者提供有意義的控制項。

系統如何收錄及選擇主題

系統會從分類中選取主題，其中包含/藝術與娛樂/音樂與音訊/靈魂與節奏藍調，以及/商業與工業/農業與林業。這些主題皆是由 Chrome 精心挑選，用於初步測試，但我們的目標是成為由值得信賴的生態系統貢獻者維護的資源。分類必須夠小，這樣許多使用者的瀏覽器才會與各個主題建立關聯。目前主題數量為 469 個，但最終主題數量預計為數百到數萬個。

為了避免敏感類別，主題必須設為公開、人工收錄，並隨時保持最新狀態。Chrome 最初提議用於測試的分類，已經經過人為調整，排除一般敏感的類別，例如族裔或性傾向。

針對 50,000 個熱門網站，Chrome 中的 Topics API 實作項目會使用手動收錄、開放大眾使用的覆寫清單，將主機名稱對應至主題。針對其他網站，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 呼叫端就會為使用者觀察到主題。

API 只會傳回最近三個週期內，呼叫端觀察到的主題。比起要替換的技術 (包括第三方 Cookie)，採用有助於防止系統共用使用者相關資訊。

傳回的主題數量取決於 API 呼叫端先前觀察到的主題數量，以及使用者可用的主題數量 (例如所累積的資料週數)。不論主題為何，系統可能會傳回 0 到 3 個主題，因為最近三個週期中代表一個主題

如要進一步瞭解如何使用及測試 Topics API，請參閱 Topics API 開發人員指南。

API 如何減少數位指紋採集

Topics API 提供多種機制，確保使用者難以只使用 Topics API「跨」網站重新識別大量使用者：

  • 由於主題分類提供概略的主題，因此每個主題可能會有大量使用者。事實上，每個主題都有最少使用者人數，因為傳回的主題有 5% 是隨機的。
  • 系統會隨機傳回使用者前五名的主題。
  • 如果使用者經常造訪同一個網站 (例如每週) 在網站上執行的程式碼，每週最多只會學習一個新主題。
  • 每個網站在同一週期內會針對同一使用者收到不同主題。使用者在某個網站上，傳回的主題與在其他網站上傳回的主題相符時，只有五分之一的機率。因而較難以判斷對方是否為同一名使用者。
  • 使用者每週都會更新一次主題，因此資訊分享的頻率受限。換句話說，這個 API 不會太常提供主題更新，有助於降低數位指紋採集的風險。
  • 只有 API 呼叫端最近觀察到同一使用者擁有相同主題時，才會傳回主題。這種做法有助於限制實體可能因為未曾觀察到的使用者興趣而學習或分享相關資訊。

API 如何解決 FLoC 的疑慮

2021 年 FLoC 的來源試用收到許多廣告技術和網路生態系統貢獻者的意見。具體而言，某些疑慮是 FLoC 同類群組可用來做為指紋識別介面來辨識使用者，或是揭露使用者與敏感類別的關係。同時，我們也希望讓 FLoC 對使用者提供更公開透明且易於理解的成果。

Topics API 的設計參考了這項意見回饋。旨在探索其他支援按照興趣顯示廣告的方式，像是提高資訊透明度、提供更強大的隱私權保證，以及對敏感類別採取不同的做法。

後續步驟

進一步瞭解主題的定義和運作原理。

如果您是廣告技術開發人員，請使用 Topics API 實驗並參與。如需更多資源，請參閱開發人員指南。

交流及分享意見回饋