行動版 Topics API 總覽

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

瞭解 Android 上的 Topics API，以及導入該 API 的步驟。您也可以直接開始實作主題。

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.

實際執行 Android 主題

Android 上的 Topics API 支援通常用於多個應用程式的第三方廣告 SDK。Topics 不必仰賴跨應用程式 ID，而是根據使用者的應用程式使用情形，為呼叫端提供概略的興趣廣告主題。這些主題可在要顯示廣告的應用程式中補充相關的脈絡資訊，也可以彼此結合使用，為使用者選擇適當的廣告。

在 Topics API 的情況下，買方和廣告主取決於賣方。賣方在發布商應用程式中擁有廣泛的曝光率，並觀察使用者的主題，然後與買方分享這些主題，協助他們選擇更相關的廣告。如要取得主題，賣方應用程式和 SDK 必須至少在 1 個訓練週期中成為 Topics API 的觀察者，藉此建立足跡。

請參閱 Topics API 導入指南中的程式碼範例，瞭解如何針對按照興趣顯示的廣告主題設定擷取功能。

依業務類型整合主題

使用 Topics API 啟用 IBA (按照興趣顯示廣告) 功能。請根據廣告技術業務類型，按照步驟整合 Topics API，並準備好推出服務。

針對所有廣告技術

• 查看主題分類，並提供意見回饋。
• 試用 Topics API 範例應用程式，瞭解裝置端分類器傳回哪些主題資料。
• 更新應用程式和 SDK 流程以開始呼叫 Topics API。
• 更新通訊協定，開始在廣告請求中傳送主題。
• 透過 Privacy Sandbox 註冊廣告技術。

針對賣家廣告技術

• 成為觀察器以建立 Topics API 足跡。Topics API 提供新的信號，因此您必須更新 SDK 才能開始呼叫 Topics API。如要持續擷取主題，SDK 必須在每週期至少從發布商應用程式呼叫 API 一次。廣告請求最多需要四個週期 (三個主題) 才能隨著廣告請求傳送。
• 在廣告請求中加入 Topics API 資訊。針對每個廣告請求，開始與買方合作夥伴共用 Topics API 資料。Topics API 計劃補充其他信號 (例如比對內容訊號)，協助找出適合特定訪客的廣告。
• 透過通訊協定與您與買方合作夥伴分享主題。Topics API 需要每個 SDK 與下游合作夥伴合作，彼此同意 Topics API 資料的共用方式。

針對買方廣告技術

• 與賣方合作夥伴聯絡，確認他們觀察主題及建立足跡的計畫。如要接收主題，賣方供應商必須至少在每個週期中呼叫 Topics API 一次。
• 透過通訊協定接收來自賣方合作夥伴的主題。「主題」是新的信號，會在廣告請求中由賣方合作夥伴分享。買方消費者必須確保與上游合作夥伴合作，說明主題的分享方式。
• 將出價和最佳化模型納入主題。Topics API 應該補充其他信號 (例如比對內容)，協助找出適當的訪客廣告。

API 如何推斷應用程式的主題

在 Android 裝置上，Topics API 會使用分類器模型，根據應用程式資訊來推斷應用程式的主題。在目前的實作中，Topics 會使用應用程式和套件名稱，將感興趣的主題指派給應用程式，但日後可能會擴充至包含應用程式說明等其他資訊。

主題分類器

感興趣主題是由分類器模型推斷而來，該模型已根據應用程式公開資訊經過訓練。

• 使用分類器模型進行推斷，針對特定週期計算主題時，所用的信號組合會保留在裝置上。這組信號可能包括已安裝或最近使用的應用程式，但我們日後可能會進一步加入其他信號。
• Google 透過 54 萬筆人工標籤和 1,700 萬個機器學習標記的公開應用程式資訊 (從 Google Play 商店等應用程式商店取得) 訓練 V5 模型。這個模型以應用程式名稱和套件名稱做為輸入信號，而且免費開放應用程式開發人員測試及瞭解其應用程式分類的主題。
• 應用程式可能會對應至多個主題或未對應至任何主題，也可能不會納入使用者的主題記錄。如果某個應用程式對應至分類中的多個主題，系統最多只會為該應用程式選擇使用者最感興趣的 3 個主題。

如要進一步瞭解分類器模型的運作方式，可以使用 Android Topics Classifier Colab 測試不同應用程式資料對分類的影響

分類

系統會從預先定義的開放原始碼分類中選取主題。分類是公開的，因此可能會有變動。您可以使用本頁頂端的意見回饋按鈕提交建議。這個分類會以人工方式進行收錄，確保當中不含敏感主題。這個分類會根據可在 Android 版行動應用程式中顯示的廣告類別進行調整。

Android 主題實務

假設使用者在裝置上安裝了 A、B、C、D、E、F 和 G 這 7 個應用程式，假設應用程式的主題分類和所含的廣告技術 SDK 如下：

第 1 週結束時，Topics API 會為這個週期產生使用者最感興趣的 5 個主題。

在第二週，如有任何應用程式的呼叫端呼叫 API，則傳回的主題清單只會包含呼叫端位於「可瞭解該主題的呼叫端」中的主題下方顯示該週期的該應用程式版本。

• 在計算每個呼叫端可用的主題時，所採用的歷史記錄期間為 3 個週期 (即 3 週)。
• 系統只會使用與透過廣告 SDK 叫用 Topics API 的應用程式相關聯的主題。換句話說，如果應用程式不含任何呼叫 Topics API 的廣告 SDK，與該應用程式相關聯的主題並不會納入廣告 SDK 可存取的主題集區。
• 應用程式也可以以宣告的方式選擇停用 Topics API。如果主題與選擇停用的應用程式有關，則不會計入每週主題計算結果。我們日後會更新本文件，加入相關的實作詳細資料。

如果應用程式使用資訊不足以讓平台推斷出五個主題，平台可能會考慮其他選項，例如隨機產生剩餘的主題。

傳回的主題加密

已註冊、呼叫 Topics API 的廣告技術平台也必須提供 確保傳回的主題只能讀取 呼叫。

Privacy Sandbox 會從廣告技術提供的端點擷取這些金鑰。建議的最佳做法是定期更新金鑰，但至少每六個月更新一次。

Privacy Sandbox 會要求廣告技術確認在註冊過程中提供的端點是否可用。如要進一步瞭解現有和新註冊的廣告技術需要採取哪些行動，請參閱註冊指南

後續步驟

另請參閱

請參閱我們的資源，進一步瞭解 Android 上的 Topics API。

• 或是觀看 Topics 的範例應用程式、合作影片及逐步操作說明影片。
• 瞭解使用者和開發人員如何「控管」 API。
• 歡迎查看支援資源，提出問題、互動及分享意見回饋。