行動裝置適用的 Topics API：總覽

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

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 都會重新整理使用者最感興趣的五個主題，以及在該週期內觀察到這些主題的呼叫端。主題分類器模型會根據使用者活動推斷主題，包括網頁造訪的主機名稱，以及 Android 上的應用程式資訊。

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

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

訓練週期

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

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

實際執行 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 訓練 V5 模型時，使用了 54 萬筆人工標記的資料，以及 1,700 萬筆機器學習標記的資料，這些資料來自 Google Play 商店等應用程式商店的公開應用程式資訊。這個模型會使用應用程式名稱和套件名稱做為輸入信號，並免費提供給應用程式開發人員測試，以便瞭解應用程式所屬的主題分類。
• 應用程式可能會對應至多個主題或未對應至任何主題，也可能不會納入使用者的主題記錄。如果某個應用程式對應至分類中的多個主題，系統最多只會為該應用程式選擇使用者最感興趣的 3 個主題。

如要進一步瞭解分類器模型的運作方式，建議您透過 Android Topics Classifier Colab 測試不同應用程式資料對分類的影響。

分類

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

實際執行 Android 主題

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

應用程式	主題分類	廣告技術 SDK
A	T1、T5	ad-sdk1、ad-sdk2
B	T2	ad-sdk2
C	T3、T6	ad-sdk3、ad-sdk4
D	T1、T4	ad-sdk1
E	T5	ad-sdk4、ad-sdk5
F	T6	ad-sdk2、ad-sdk3、ad-sdk4
G	T7	ad-sdk2

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

最感興趣的主題	可瞭解該主題的呼叫端
T1	ad-sdk1、ad-sdk2
T2	ad-sdk2
T3	ad-sdk3、ad-sdk4
T4	ad-sdk1
T5	ad-sdk1、ad-sdk2、ad-sdk4、ad-sdk5

在第 2 週，如有任何應用程式的呼叫端呼叫 API，則在傳回的主題清單中，系統只會針對該週期、該應用程式和該主題，列出「可瞭解該主題的呼叫端」欄有該呼叫端的主題。

• 在計算每個呼叫端可用的主題時，所採用的歷史記錄期間為 3 個週期 (即 3 週)。
• 系統只會使用與透過廣告 SDK 叫用 Topics API 的應用程式相關聯的主題。這表示如果某個應用程式未包含呼叫 Topics API 的廣告 SDK，系統就不會以與該應用程式相關聯的主題為基礎，提供主題給廣告 SDK 可存取的主題集區。
• 應用程式也可以以宣告的方式選擇停用 Topics API。與選擇停用的應用程式相關聯的主題不會用於計算每週主題。我們日後會更新本文件，加入相關的實作詳細資料。

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

返回主題的加密

註冊的廣告技術平台在呼叫 Topics API 時，也必須提供加密金鑰，確保傳回的主題只能由呼叫端讀取。

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

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

Next steps

另請參閱

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

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