Topics API for Web

bookmark_border 透過集合功能整理內容 你可以依據偏好儲存及分類內容。

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

How the Topics API works

The Topics API can be used to observe and provide access to topics that appear to be of interest to the user, based on their activity. The Topics API can then give API callers (such as ad tech platforms) access to a user's topics of interest, but without revealing additional information about the user's activity.

Key concepts

• A topic is a human-readable topic of interest for the current user and is part of the Topics taxonomy.
• A caller is an entity, such as an app, a third-party SDK, a website, or service, that makes a request to the Topics API to observe or access a user's interests.
• A topic is observed by a caller, if the caller made a Topics API request from a web page or app associated with this topic during the past three epochs.
• An epoch is a period of topic computation, which defaults to one week.
• A taxonomy is a hierarchical list of categories, which includes, for example, such categories as /Arts & Entertainment/Music & Audio/Soul & R&B and /Business & Industrial/Business Services/Corporate Events.
• Topics are derived using a classifier model that maps user activity to zero or more topics.

Topics API flow core steps

The Topics API lifecycle has three main steps:

• Observe user activity, such as when they visit the web page https://cats.example/tabby/index.html or download the app cats.
• Derive topics from user activity, for example /Pets & Animals/Pets/Cats.
• Access topics previously observed for the user, for example as a signal to select relevant advertising (such as a cat food promotion).

Observe topics

Callers can only access topics of interest that they've observed. A caller observes a topic when they make a Topics API request from a context associated with this topic. To illustrate this concept, consider the following simplified example.

• Suppose there are two Topics API callers: A and B.
• There are two contexts:
  • Greenhouse, for example an app named Greenhouse or a website greenhouse.example, associated with the topic Home & Garden.
  • Tennis exercises, for example an app named Tennis Exercises or a website tennis.example, associated with the topic Sports/Tennis.
• Both caller A and B are present in the context of Greenhouse.
• Only the caller B is present in the context of Tennis exercises.
• Assume that no topics were observed for the user before epoch 1, for the sake of simplification.
• The user visits the Greenhouse app, and callers A and B make a Topics API call to record the user visit to the page or app (see the implementation guide suggested in Next steps to find out how to call the Topics API). This record (a hostname or app data) is later used to derive topics of interest. The Topics API will later mark the topic Home & Garden as observed by both callers A and B.
• The user visits the Tennis exercises app. Only the caller B sends a Topics API request. The Topics API will later mark the topic Sports/Tennis as observed by the caller B.
• By the end of the epoch, the Topics API refreshes the user's top topics and determines the callers that observed these topics based on user activity.
• Later, when the caller B makes another Topics API call, it can get either Home & Garden or Sports/Tennis topic (or, with a 5% chance, a random topic) for this user in the response array.
• Caller A can only access the topic Home & Garden, as it has never observed the topic Sports/Tennis. This means that a third-party will only learn about a user's topic of interest within the specific context (app or website) where it is present.

Derive topics

Topics derives topics of interest from user activity. The topics are selected from a predefined open-source taxonomy. Once per epoch, Topics refreshes the user's top five topics and the callers that observed them during the epoch. The Topics classifier model derives topics from user activity: hostname for a web page visit, app information on Android.

Caller accesses user's topics of interest

The API returns only topics that have been observed by the caller within the most recent three epochs. A maximum of three topics may be returned to a caller,one topic for each of the three recent epochs (if the caller observed topics for that epoch). The returned topics can be used by the caller to supplement any contextual information and can be combined to help find a more relevant ad for the user.

Epochs

The Topics API must ensure that the topics of interest it provides are kept up to date. The topics are inferred for a user based on their activity during a period of time known as an epoch, one week by default. Each user has their own epochs (epochs are "per user") and the initial start time is randomized.

Once each epoch, the Topics API computes the user's top five topics and determines which callers observed those topics using on-device information. The topic selected for each epoch is randomly selected from the user's top five topics for that time period. To further enhance privacy and ensure that all topics may be represented, there is a 5% chance the topic is randomly selected from all possible topics in the taxonomy of interests.

網路主題實作

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

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

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

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

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

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

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

在週期結束時 (預設為一週)，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 主題。

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

此外，adtech2.example 中的程式碼會新增至 sunglasses.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 會使用分類器模型，將網站主機名稱對應至零個或多個主題 (分析其他資訊 (例如完整網址或網頁內容) 可能會顯示更相關的廣告，但也可能會降低隱私權)。

分類

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

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

主題分類

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

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

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

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

1. 在每個 epoch 結束時，瀏覽器會編譯符合下列條件的網頁清單：
   • 使用者在該時間範圍內造訪該網頁。
   • 這個頁面包含呼叫 document.browsingTopics() 的程式碼。
   • API 已啟用 (例如未遭使用者或回應標頭封鎖)。
2. 使用者裝置上的瀏覽器會使用 Topics API 提供的分類器模型，將每個網頁的主機名稱對應至主題清單。

3. 瀏覽器會產生前五個主題的清單。

   • 根據廣告生態系統的意見回饋，分類法中的 22 個根主題都會指派至「高效用性」或「標準效用性」值區。瀏覽器會先依主題的桶分配結果進行排序。所有子主題都會繼承其父項根主題的值區指派。系統會優先處理「高實用性」主題。
   • 然後，瀏覽器會依據各個類別中的頻率排序主題。
   • 系統會從這份排序清單中選出前五個主題，做為使用者在該週期內的偏好主題。

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

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

後續步驟

另請參閱

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

• 請參閱主題的示範、合作和操作說明影片。
• 請參閱 Chrome 旗標清單，瞭解開發人員如何自訂 Topics API 以進行測試。
• 瞭解使用者和開發人員如何「控管」 API。
• 請參閱資源，瞭解技術說明和支援資訊。提出問題、互動並提供意見。