測試、部署及擴大採用以主題為基礎的解決方案

本頁面說明如何使用 Topics API 建構、測試及擴充正式版導入作業。

主題後端實作

後端實作方式取決於您要使用瀏覽器計算的主題。我們建議廣告技術解決方案使用主題做為額外的 IBA 信號。

// Use the language/framework/stack of your preference
function processTopicsBackendAPI(topics) {
 // If the list is not empty, continue
 // Use topics as an additional signal
}

使用「主題」做為其他信號

您可以將主題資料與其他信號 (例如網址、關鍵字或其他中繼資料) 一併考量，做為目標對象的額外信號。

如「在使用第三方 Cookie 盡可能提高廣告關聯性」一文所述，您可以透過多種方法利用 Topics 放送相關廣告。其中部分做法包括使用 Topics 建立目標對象，而其他做法也建議採用 Topics 做為信號來訓練機器學習模型，藉此推斷目標對象的其他興趣，甚至改善出價邏輯。

建構及部署

  1. 在實際工作環境中觀察使用者 (預估導入時間：大約一週) 來收集主題：
    • 瞭解可用選項：如何使用 HTTP 標頭或 iframe 和 JavaScript 呼叫 Topics。
    • 定義將呼叫 Topics API 的 iframe 網域。
    • 以標頭示範或 JavaScript 示範程式碼建構解決方案。
    • 將 Topics 整合至發布商網站 (例如廣告 iframe) 嵌入的程式碼。請務必從嵌入項目呼叫主題。
    • 如要開始觀察使用者主題，請在實際執行網站中嵌入最新版本的指令碼。建議您先在每月造訪數不多的自家網站上測試導入作業。在這個階段，建議您至少在五個網站上嵌入新的主題式解決方案。
    • 此時，API 會預期傳回空陣列。這是因為系統尚未觀察到使用者有任何主題。系統最多可能需要三週的時間，才會開始取得使用者主題。
    • 執行功能測試和驗證。您可以手動或自動測試解決方案。例如：
      • 開啟瀏覽器 (有旗標)，並將週期設定為 15 秒，讓瀏覽器更快重新計算 Topics。
      • 造訪嵌入指令碼的網站。
      • 檢查 chrome://topics-internals/ 上的指令碼是否觀察到主題。
      • 查看你可望獲得哪些結果。
  2. 搭配使用 Topic 資料和其他情境訊號 (例如網址、中繼資料等) (預估時間：約 3 天)。
    • 在實際工作環境中運作三週後，您的指令碼應會觀察到一些使用者的主題。此時，您應該能使用 Topics 資料做為額外的信號。
    • 開始收到非空的話題清單後，您可以將其與其他內容信號一起傳送至後端。

部署至目標網站

將 Topics 呼叫整合至指令碼後，請確認這幾則程式碼已嵌入部分生產網站以進行第一次測試。確認導入作業能正常運作：

  • 呼叫 Topics API。
  • 您可以在這個受控環境中觀察主題。
  • 您可以存取主題 (API 會傳回使用者觀察的主題)。

選擇指定網站

將解決方案部署至發布商之前建議在控管的環境中測試您擁有的網站建議您按照下列方式選擇目標網站：

  • 網站每月造訪量不多 (每月少於一百萬次造訪)：建議您先向少數目標對象部署 API。
  • 您擁有並控管網站：如有需要，您可以快速停用導入作業，不必經過複雜的核准程序。
  • 網站對業務的影響不大：請從風險較低的目標網站著手。
  • 總共不超過五個網站：你目前不需要那麼多流量或曝光。
  • 指定網站代表不同的主題：選擇代表不同類別的網站 (例如一個是體育網站、一個是新聞網站，另一個是飲食網站)。您可以使用 Chrome 內部主題工具驗證網域，以及主題機器學習分類器如何將網域分類。

功能測試和驗證

在這個受限的環境中呼叫 Topics API 時，可能會產生下列結果：

  • 如果這是裝置首次針對這個網站和呼叫端在過去七天內呼叫，則為空的話題陣列 []。

  • 清單內含零到三個主題，代表此使用者的興趣。觀察七天後，您應該會收到以下內容：

    • 從前五名的使用者中選取一個主題，並根據呼叫端在當週觀察到的主題網頁主機名稱來計算。

  • 與先前所有 Topics API 呼叫相同的 API 回應。對於相同的呼叫端、使用者和頂層網站，API 會針對整個週期傳回相同的主題。避免對使用者的興趣過多。如要進一步瞭解詳情，請前往 GitHub。

  • 如果您在觀察四週後呼叫 Topics，系統會以新主題取代三個舊主題中的一個。

  • 如果您過去三週或更久以來未觀察到使用者的任何主題，Topics API 就會再次傳回空白陣列 []。

收集效能指標，評估使用者體驗：

  • 您應該評估在跨來源 iframe 中對 Topics API 發出的 JavaScript 呼叫執行時間，以用於日後的成效分析。
  • 收到主題後，建立 iframe 和 postMessage() 主題所需的時間。

如需疑難排解，請參閱 支援一節。

擴大規模並發布正式版

目前，您應該已在受控管的環境中 (也就是您擁有的部分網站上) 測試 Topics。如果一切運作正常，就該擴大導入規模了。將相同的程式碼部署至更多目標網站。這樣一來，您就能觀察更多使用者、收集更多主題資料，並進一步瞭解目標對象。

以下逐步說明如何擴充至實際工作環境：

  1. 針對更多流量測試以主題為準的解決方案。
    • 將您 iframe 加入更多自有網站，並加入更多造訪次數，並按照下方操作說明進行負載測試。
  2. 將解決方案部署至。
    • 當您的解決方案在自有測試環境中正常運作後，請與發布商合作，將 iframe 整合至他們的網站。舉例來說，他們可能需要更新包含 iframe 的程式庫。
  3. 處理及使用主題資料 (預估時間：約四週)。
    • 將主題資料納入其他資料，做為額外信號。
    • 來源即時出價測試合作夥伴。
    • 執行實用性測試，將主題做為其他資料的加成信號。

負載測試

為確保您的系統能處理流量，建議您先執行負載測試，再為發布商部署以主題為基礎的解決方案。

  1. 針對您擁有的更多目標網站逐步部署，尤其是流量較大的網站。
  2. 根據預期流量，對主題資料執行負載測試。
    • 您需要從 iframe 將主題資訊傳送至您的後端。進一步處理 Topics API 結果，並將這些結果做為額外信號，有助於選擇與使用者更相關的廣告。隨著更多網站加入您的嵌入功能，對後端的呼叫次數將大幅增加。確認後端可以處理 iframe 發出的大量呼叫。
    • 設定分析用的指標收集與記錄檔。
  3. 部署 Topics API 後，請立即檢查指標，找出任何嚴重的使用者問題。請持續定期查看指標。
  4. 如果系統出現中斷或非預期的行為，請復原部署作業並分析記錄檔，藉此瞭解並修正問題。

另請參閱

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