動態搜尋

現代電子商務搜尋列不僅僅是輸入欄位，這項互動式動態助理功能可引導使用者找到合適的產品，甚至在他們輸入完文字前就能提供建議。這項「邊輸入邊搜尋」(SAYE) 體驗會即時顯示查詢建議、熱門品牌、相關類別，甚至是熱門產品結果，有助於提高使用者參與度，並增加轉換的可能性。

Vertex AI Search for commerce 提供不同的 API，用於查詢自動完成和產品搜尋，但有意將 SAYE 使用者體驗的最終實作方式保留為開放式。

這份 Vertex AI Search for Commerce 建構指南探討了兩種主要設計模式，說明如何使用 Vertex AI Search for Commerce API 導入穩健的 SAYE 小工具，並詳細說明每種做法的取捨考量。

瞭解核心元件

如要建構完善的「你說即所得」功能，您必須瞭解 Vertex AI Search for commerce 提供的兩項基本 API：

  1. CompleteQuery API：這是自動完成建議背後的智慧技術。

    • 函式：針對指定的輸入字串 (例如「lipst」)，傳回建議查詢完成清單，包括「lipstick」和「lip gloss」、相關熱門品牌和相關類別。
    • 費用：這項 API 包含在 Vertex AI Search for commerce 套裝組合的定價中。
    • 效能：這項高處理量 API 專為快速、低延遲的回應而設計，可提供逐字元輸入的體驗。這項功能會運用自動學習功能 (包括拼字修正和建議)，根據商店每日搜尋事件訓練，找出最合適的結果。

  2. Search API：這是核心產品探索引擎。

    • 函式：針對指定查詢，傳回相關產品結果的排名清單。
    • 費用：這是付費 API，用量會直接影響營運成本。
    • 事件：為進行模型訓練和分析，每個 Search API 呼叫都應搭配搜尋事件，以便追蹤使用者行為，並隨著時間推移改善關聯性模型。

如要建立 SAYE 體驗，您必須編寫包裝函式 API 或前端邏輯，同時呼叫這兩個 API，並將結果合併到單一連貫的使用者介面。

實作模式 1：直接但成本較高的方法

這是最簡單的導入方式。這項邏輯是指每次按鍵時，您都會平行呼叫 CompleteQuery 和 Search API。

心流狀態

流程會依序執行下列步驟：

  1. 使用者輸入字元，例如 l。
  2. 應用程式會將 l 傳送至 CompleteQuery API。
  3. 同時，應用程式會將 l 傳送至 Search API。
  4. 系統會合併並顯示結果。
  5. 使用者輸入另一個字元 (l)，使查詢變成 li。
  6. 新查詢 li. 會重複執行這個程序。

優點

優點包括實作速度快，可讓您快速編寫及部署記錄。

缺點

  • Search API 呼叫量過高：這種做法會大幅增加 Search API 呼叫次數。如果查詢「口紅」，系統會觸發八個個別搜尋要求，導致查詢量大幅增加。
  • 成本增加：Search API 是付費服務，因此大量要求會直接導致營運成本增加，難以實現正投資報酬率 (ROI)。
  • 活動管理複雜度：每次 Search API 呼叫都應記錄對應的搜尋事件，以利準確訓練模型和評估成效。大量呼叫會導致難以確保擷取每個事件，可能造成資料遺失和分析結果有偏差。
  • 可能傳回品質較低的結果：搜尋一或兩個字元 (例如 l、li) 可能會傳回雜亂或過於廣泛的結果，導致初始體驗不夠相關。

這個模式會使用 CompleteQuery API 智慧地決定呼叫 Search API 的時機，進而提升成本效益、效能和關聯性。

心流狀態

流程會依序執行下列步驟：

  1. 使用者輸入部分文字查詢，例如「lip.」。
  2. 應用程式會將 lip 傳送至 CompleteQuery API。
  3. API 會傳回建議清單，其中 lipstick 可能是第一個結果。
  4. 應用程式會採用第一個建議 (lipstick)，並使用該字詞對 Search API 進行單一呼叫。
  5. 系統會顯示「口紅」的自動完成建議和產品結果。
  6. 當使用者繼續輸入 lips、lipst... 時，您可以新增邏輯，只在第一個自動完成建議變更時發出新的搜尋呼叫。

優點

  • 大幅降低成本：大幅減少 Search API 呼叫次數，有助於控管成本。
  • 控管 API 和事件量：API 和事件量可管理及預測，確保模型訓練和分析的資料更可靠。
  • 關聯性更高：您搜尋的字詞更完整且更可能符合需求，因此 SAYE 小工具會提供品質更高的產品結果。
  • 投資報酬率更高：降低成本並提升使用者體驗，有助於提高投資報酬率。

處理極端案例

這種做法較為優異，但需要處理一些特殊情況：

  • 沒有建議：如果 CompleteQuery API 未傳回任何建議，您的邏輯應改為使用使用者的原始輸入內容呼叫 Search API。
  • 部分查詢與建議查詢：在少數情況下，使用者可能想查看部分字詞的結果，例如「眼」，而不是熱門建議「眼影」。雖然這項取捨微不足道，但最佳化方法會優先考量最可能的使用者意圖。

使用實驗 ID 評估成效

無論選擇哪種實作方式，請務必獨立評估 SAYE 小工具的成效，不要與主要搜尋結果網頁混為一談。如果兩者使用相同的追蹤方式，您就無法判斷 SAYE 功能是否確實提升了點擊率和轉換次數。

如要評估 SAYE 小工具的點閱率和對話率，請在搜尋事件中使用不同的 experimentIds，將這些指標與主要搜尋事件的指標區分開來。

  • SAYE 事件：為所有源自「搜尋時輸入」功能的搜尋事件指派特定 ID，例如 "experimentId": "saye-widget"。
  • 主要搜尋事件：使用者按下 Enter 鍵或點選「搜尋」前往主要搜尋結果頁面時，請使用不同的 ID (或不使用 ID) 啟動搜尋。

這樣區隔事件後，您就能在 Vertex AI 控制台的 Analytics 資訊主頁中，篩選及比較 SAYE 小工具與標準搜尋體驗的成效，取得明確且實用的洞察資料。

結論

商家適用的 Vertex AI Search 提供可建立「邊輸入邊搜尋」體驗的元件。您可以擔任架構師，設計 CompleteQuery 和 Search API 之間的互動，建構搜尋功能，在使用者體驗和成效之間搭起橋樑。在大多數情況下，最佳化方法可提供與使用者相關的體驗，同時避免耗用大量運算資源。