其他注意事項和測試

如要瞭解最佳做法及測試對話式商務代理程式介面，請考量其他事項。

實作最佳做法

導入對話式商務代理程式介面時，請考慮下列最佳做法：

  • 訪客 ID 一致性：確保系統會針對特定使用者，在每個要求中持續傳送專屬 visitor_id。這對準確提供個人化體驗和訓練模型至關重要。理想情況下，這個 ID 在不同工作階段和登入/登出狀態下，應保持一致。
  • 分店管理：雖然 default_branch 很常見，但如果產品目錄包含多個分店，請務必使用正確的分店 ID。
  • Search API 互動：如果是 SIMPLE_PRODUCT_SEARCH 和提供 refined_search 的任何情況，請記得使用 refined_search 欄位中的 query 或原始查詢，對核心 Search API (SearchService.Search) 進行個別呼叫，以取得實際的產品資訊。對話式 API 主要著重於對話體驗和瞭解使用者意圖，而非直接傳回產品結果。
  • 使用者介面設計：設計網頁介面，以直覺方式清楚呈現 conversational_text_response、followup_question 和 refined_search 選項，引導使用者操作。

規劃 A/B 測試

雖然關聯性是重要的輸入指標，但 Vertex AI Search 電子商務套件也會考量其他變數，以盡可能提升業務成果：

指標
單次造訪收益 (RPV) 每次造訪收益是評估搜尋成效最有效的指標，因為它會考量轉換率、平均訂單價值和關聯性。
轉換次數 - 平均訂單價值 (AOV) 轉換率和平均訂單價值都會影響每位訪客收益。
關聯性 - 可購買性 - 價格 系統會根據關聯性和其他輸入內容，產生成效良好的搜尋結果。

A/B 測試準備檢查清單

使用的成效指標如下：

項目 定義 階段
事件歸因配置 與 Google 合作，正確區隔用於評估的使用者事件。 實驗前
監控資料輸入 快速瞭解訓練資料是否含有可能影響成效的異常狀況。 實驗前
活動涵蓋範圍 我們是否會記錄與搜尋或建議 AI 工作階段相關的所有可能結果？ 實驗前
可評估的成功標準 以可評估的字詞定義完成的項目。 實驗前
評估使用者體驗偏誤的能力 確保各實驗組的使用者體驗一致。 實驗期間
VAIS 資料與用量之間的一致性 確認 API 是否將歸因權杖、篩選器、排序依據、位移等傳遞至 UserEvents。事件和 API 要求之間的訪客/使用者 ID 相符。 實驗期間
實驗期間的調整核准 規劃微調活動、記錄變更，並據此調整評估和解讀方式。 實驗期間

實作概念驗證或最簡可行產品

資料擷取 A/B 測試設計 效能指標 管理和程序

完整且最新的產品目錄擷取作業

遵循建議的事件擷取方法，確保 Google 與您之間的資料同步。
Google 建議您追蹤即時事件，包括曝光資料。

傳遞必要的屬性，例如實驗 ID、訪客 ID，並視情況正確導入搜尋權杖。

 採用實驗最佳做法，確保結果可靠：
  • 驗證整合。
  • 一次只能測試一項變更。
  • 避免積極快取。
  • 確保測試組和控制組的網頁介面公平性。
  • 使用訪客 ID 拆分流量，確保流量分配公平。
  • 確保產品資料一致性。
  • 在測試組和控制組中套用相同的業務規則。
 所有評估標準都應以實證為依據、客觀評估，並以指標為導向。

針對追蹤的指標明確定義，是準確評估成效的關鍵。

追蹤的標準指標包括：
  • 搜尋聯播網點閱率 (結果關聯性)
  • 空值搜尋率 (意圖理解)
  • 每位訪客的收益 / 每位使用者的收益
  • 要轉換的搜尋次數
 資料整合、測試、功能推出和最佳化是反覆的過程，需要資源。

實驗週期範例

滿足最低可行產品依附元件 校正測量結果 部署正式版深色模式 是否繼續進行的決定
  • 合約
  • 訓練好的模型和服務設定
  • 產品和事件資料擷取
  • 比較 (用戶端) 資料與 Commerce 搜尋遙測資料，並據此進行調整
  • 確認評估基準
  • 執行離線評估
  • 調整設定
  • A/A 測試，用於驗證流量分配
  • 取得 QA 簽核
  • 承諾繼續推動升級

A/B 實驗的節奏範例

持續測試 逐步增加流量至 X% 測量、調整並重複 將即時流量調升至 X%
  • 持續調整/最佳化
  • 測試增量功能
  • 分析各搜尋區隔的成效
  • 調整任何模型/規則
  • 交叉檢查成效
  • 找出並說明異常狀況
  • 展開實驗
  • 每天分享成效指標
  • 執行微調

成功的實驗應具備以下要素

校正評估結果並確立成功標準 維持實驗公平性 監控資料品質
  • 正式發布前，請預留時間驗證目錄、使用者事件和 API 消耗量是否一致。
  • 預先建立可量化的成功條件 (最好以每位訪客收益的變化表示)。
  • 主動找出並說明迴歸或異常狀況，然後修正問題。
  • 經常分享測量結果，並瞭解及記錄實驗組的指標定義。
  • 盡量縮小區隔間的使用者體驗差異 (常見的版面配置和視覺效果，只有資料不同)。
  • 請留意商品陳列 / 業務規則 (確保不會造成偏誤)。
  • 評估目錄變化。
  • 正確註解實驗結果 (透過使用者事件)。

角色和實驗擁有權

Google 您
品質評估 Commerce Search 成效 使用者體驗影響
測量數據 備份/驗證 權威
遙測/資料 平台量值 (驗證成效)
事件和索引異常		 歸因符記和重現步驟 (驗證問題)
搜尋平台 產品層級項目
  • 資料對應
  • 模型/訓練調整
  • 品質/放送異常
  • 平台配額/限制
  • 產品/用戶端程式庫有瑕疵
 查詢/放送項目
  • 要求擴增 (包括內容路徑、快取和意圖處理)
  • 供應設定 (調整)
  • 擴充來源資料
  • 用戶端效能 (例如 WC 執行緒)
  • UX/API/平台/程式庫缺陷
Go/No-go 推薦地點 核准

在控制台中進行實驗

  1. 前往 Search for commerce 控制台的「實驗」頁面。

    前往「實驗」頁面

  2. 使用控制台，套用 Google 的歸因方法，針對 Vertex AI Search for Commerce 導入和 A/B 測試進行進階自助式分析：

  • 監控流量區隔、商家指標，以及搜尋和瀏覽成效。

  • 在關鍵字搜尋和瀏覽中，套用個別搜尋造訪層級指標。

  • 以時間序列形式查看實驗成效，並取得統計顯著性指標。

  • 使用嵌入式 Looker 平台。