行動版 Topics API 總覽

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

瞭解 Android 上的 Topics API，以及導入該 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 會從使用者活動中找出感興趣的主題。系統會從預先定義的開放原始碼分類中選取主題。每個週期，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 透過 54 萬筆人工標籤和 1,700 萬個機器學習標記的公開應用程式資訊 (從 Google Play 商店等應用程式商店取得) 訓練 V5 模型。這個模型以應用程式名稱和套件名稱做為輸入信號，而且免費開放應用程式開發人員測試及瞭解其應用程式分類的主題。
• 應用程式可能會對應至多個主題或未對應至任何主題，也可能不會納入使用者的主題記錄。如果某個應用程式對應至分類中的多個主題，系統最多只會為該應用程式選擇使用者最感興趣的 3 個主題。

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

分類

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

Android 主題實務

假設使用者在裝置上安裝了 A、B、C、D、E、F 和 G 這 7 個應用程式，假設應用程式的主題分類和所含的廣告技術 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
女	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

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

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

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

傳回的主題加密

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

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

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

後續步驟

另請參閱

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

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