部分 Privacy Sandbox 技術即將淘汰。

請參閱這篇文章，瞭解我們對 Privacy Sandbox 技術的計畫更新。

Privacy Sandbox 功能狀態提供個別 API 和平台功能的狀態資訊。

Topics API for Web

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.

Diagram showing that the Topics API only marks the topics as observed if the callers has presence in the context. — The Topics API marks the topics observed only by the callers that have presence in the context of these topics. The callers will only be able to access the topics they have observed.

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 網站推斷的主題可能是 /寵物與動物/寵物/狗。

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

這張圖表顯示 Topics API 生命週期的各個階段，從使用者造訪網站到顯示廣告。 — Topics API 生命週期圖表從高階角度說明 API 動作的各個階段。

瀏覽器會根據呼叫 Topics API 的程式碼環境，判斷呼叫端的來源。在實務上，這表示 Topics 使用者會從來源呼叫 iframe 中的 API，或在 fetch 中加入主題，傳送至來源。

舉例來說，供應端平台 (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`	[none]

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

adtech1.example 現在有資格接收 Running & Walking、Athletic Shoes 和 Dogs 主題，因為該廣告技術在 running.example 和 dogs.example 上觀察到這些主題。
adtech1.example 無法接收這位使用者的 Hotels & Accommodations 主題，因為使用者最近造訪的網站中，沒有任何與該主題相關聯的網站。
adtech2.example 看過 Running & Walking、Athletic Shoes 和 Hotels & Accommodations 主題，但未看過 Dogs 主題。

使用者造訪了 sunglasses.example，該網站有 Sunglasses 主題，但該網站上沒有對 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 的網站時，API 會執行的步驟。 — API 如何觀察及存取主題。

分類器模型

主題會使用分類器模型，將網站主機名稱對應至零或多個主題 (分析完整網址或網頁內容等額外資訊，可能有助於放送關聯性更高的廣告，但也可能降低隱私權)。

分類

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

為避免使用敏感類別，主題必須公開、經過人工收錄，且隨時保持最新狀態。Chrome 使用的分類架構經過人工收錄，排除一般認為的敏感類別，例如族裔或性傾向。

主題分類

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

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

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

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

API 會針對每個週期傳回一個主題，最多三個。如果傳回三個主題，則包括目前和前兩個時期的主題。

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

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

您可以在 chrome://topics-internals 頁面查看目前週期觀察到的主題相關資訊。

後續步驟

設定

準備好環境，以便使用 Topics API 測試及開發網頁應用程式。

實作主題

請查看實作詳細資料和程式碼範例，讓呼叫端可以觀察及存取主題。

另請參閱

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

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