Android Privacy Sandbox 開發人員預覽版隆重登場!瞭解如何開始使用,並繼續提供意見回饋

使用 Topics API 按照興趣顯示廣告

Stay organized with collections Save and categorize content based on your preferences.

提供意見

關於 Topics API

在行動廣告方面,廣告客戶會想根據使用者的興趣放送相關廣告。舉例來說,如果某位使用者對烹飪相關資訊有興趣,則相較於與其興趣無關的廣告,該使用者可能會覺得烹飪相關廣告更符合自身需求。

「按照興趣顯示的廣告」(IBA) 是一種個人化廣告,即系統透過使用者過去曾互動過的應用程式推斷其興趣,再據此向使用者放送相關廣告,這點與「內容相關廣告」不同。在「內容相關廣告」模式下,系統只會透過使用者目前瀏覽的內容推斷其興趣,並據此顯示廣告。相較於內容相關廣告,IBA 的一項優點在於可讓應用程式向使用者顯示更符合個人需求、更具吸引力的廣告。

Topics API 會根據使用者的應用程式使用情形,在裝置上推斷出概略的興趣信號。這些稱為「主題」的信號會提供給廣告客戶,並可支援 IBA 使用情境,因此廣告客戶不用在各個應用程式中追蹤個別使用者。

核心概念

  • 「主題」是人類可讀形式的使用者興趣主題,並屬於 Topics 分類
  • 如果呼叫端 (應用程式或應用程式中使用的第三方 SDK) 在過去三個週期內,曾經從與某個主題相關聯的應用程式發出 Topics API 要求,即表示呼叫端「觀察」了該主題。
  • 「週期」是主題計算作業的時間長度,例如一週。

運作方式

我們提議採用的 Topics API 旨在根據使用者的應用程式使用情形,向呼叫端提供概略的感興趣廣告主題。這些主題可在要顯示廣告的應用程式中補充相關的脈絡資訊,也可以彼此結合使用,為使用者尋找適當的廣告。

請參閱 Topics API 開發人員指南中的程式碼範例,瞭解如何針對按照興趣顯示的廣告主題設定擷取功能。注意:API 尚未完成。

系統會從預先定義的開放原始碼分類中選取主題。

平台會使用分類器模型來推斷主題。Topics API 的實作流程與其使用分類器的方式為 Android 開放原始碼計畫的一部分,並會隨著時間持續改進。

為廣告技術平台進行註冊

所有廣告技術平台 (包括 Google 的平台) 都必須完成簡易註冊程序才能使用 Topics API。這項程序仍在開發階段,鼓勵您提供寶貴意見。

假如有正當業務需求 (例如經營多個獨立產品線),企業還是可以註冊多次,但前提是不得合併透過不同註冊身分取得的資料,藉此規避隱私權限制。

應用程式開發人員可在應用程式資訊清單中加入廣告技術開發人員註冊 ID,以管理哪些廣告技術開發人員可以存取 Topics API。

詳細資訊

  • 在每個週期中,系統都會使用裝置上的資訊計算使用者最感興趣的 5 個主題一次 (例如每週一次)。

    • 當 Topics API 受到呼叫時,平台會檢查叫用 API 的應用程式是否已獲派主題。如果未獲指派,系統會依照以下方式選擇主題,並將所選主題指派給這個應用程式,直到這個週期結束為止。
      • 有 95% 的機率會從該週期計算出的 5 大感興趣主題清單中,隨機選擇一個主題,
      • 有 5% 的機率會從分類中隨機選擇一個主題。
    • 之所以要從多個主題中選擇一個主題指派給每個應用程式,是為了確保各個應用程式獲得不同的主題,讓應用程式較難與同一使用者產生互相關。
      • 舉例來說,針對某位使用者,應用程式 A 獲派的主題可能是 T1,但應用程式 B 獲派的主題則可能是 T2。這會讓這兩個應用程式較難判斷該資訊是否與同一使用者相關聯。
  • Topics API 會傳回最多包含 3 個主題 (過去 3 個週期各 1 個) 的清單。

    • 藉由提供最多 3 個主題,不常用的應用程式將有足夠的主題來尋找相關廣告,但常用應用程式每週最多只會瞭解到 1 個新主題。
    • 傳回的主題資訊包含主題 ID (與分類中的項目對應)、分類版本和分類器模型版本。
    • 如要接收特定主題,呼叫端必須在過去 3 個週期內,針對與該主題相關聯的應用程式觀察使用者使用情形。
    • 所有傳回的主題都代表使用者的興趣,您可以在廣告請求中為指定廣告個人化選取任一或所有主題。
  • 叫用 Topics API 的應用程式獲派某個主題後,平台會判斷呼叫端是否能接收該主題。

    • 如要接收特定主題,呼叫端必須在過去 3 個週期內,針對與該主題相關聯的應用程式觀察使用者互動情形。
    • 如果呼叫端過去並未針對該使用者,在與該主題相關聯的應用程式中呼叫 API,API 傳回的清單就不會包含該主題。
    • 如果呼叫端在過去 3 個週期內未接收任何主題,Topics API 就會傳回空白清單。

    舉例來說,假設使用者在裝置上安裝了 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
    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 週)。
    • 系統只會使用與叫用 Topics API 的應用程式相關聯 (直接相關或透過廣告 SDK 產生關聯) 的主題。這表示如果某個應用程式未包含呼叫 Topics API 的廣告 SDK,本身也並未叫用 API,系統就不會以與該應用程式相關聯的主題為基礎,提供主題給其他應用程式或廣告 SDK。
    • 應用程式也可以透過新的資訊清單和 XML 元素,以宣告的方式選擇停用 Topics API,禁止廣告 SDK 針對該應用程式使用 Topics API。與選擇停用的應用程式相關聯的主題不會用於計算每週主題。我們日後會更新本文件,加入與相關的實作詳細資料。
  • 如果應用程式使用資訊不足以讓平台推斷出 5 個主題,平台可能會考慮其他選項,例如隨機產生剩餘的主題。

分類

  • 在目前的提案中,初始分類包含幾百至幾千個主題。我們日後會更新本文件,提供初始分類提案。
  • 這個分類會以人工方式進行收錄,確保當中不含敏感主題。
  • 這個分類將針對可在 Android 版行動應用程式中顯示的廣告類別經過調整。

主題分類器

感興趣主題是由分類器模型推斷而來,該模型已根據應用程式名稱、說明和套件名稱等公開應用程式資訊經過訓練。

  • 使用分類器模型進行推斷,以針對特定週期計算主題時,所用的信號組合會保留在裝置上。這組信號可能包括已安裝或最近使用的應用程式,但我們日後可能會進一步加入其他信號。
  • Google 將利用各種訓練資料 (包括公開應用程式資訊的人工收錄標籤) 訓練初始模型,並且會免費提供這個模型,用來測試應用程式所屬的主題分類。
  • 訓練初始模型時,Google 會使用來自少數幾個應用程式商店 (例如 Google Play 商店) 的應用程式公開資訊。
  • 單一應用程式可能會對應至多個主題或未對應至任何主題,也可能不會納入使用者的主題記錄。如果某個應用程式對應至分類中的多個主題,系統最多只會為該應用程式選擇使用者最感興趣的 3 個主題。

使用者控制項

  • 這項設計的宗旨,是要讓使用者能夠查看和移除與自己的應用程式使用情形相關聯的主題。這項使用者控制功能的實作方式仍在開發階段,相關資訊將於日後更新時提供。
  • 如果使用者解除安裝某個應用程式,但系統在過去 3 個週期中因為該應用程式而選取了某個推斷出的主題,則該主題不會從針對過去 3 個週期傳回的主題清單中移除,這是為了避免揭露與解除安裝事件相關的資訊。