動態搜尋

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

AI Commerce Search 提供查詢自動完成和產品搜尋的專屬 API，但有意讓 SAYE 使用者體驗的最終實作方式保持開放。

這份 AI Commerce Search 建構指南探討了兩種主要設計模式，可使用 AI Commerce Search API 實作強大的 SAYE 小工具，並詳細說明每種做法的優缺點。

瞭解核心元件

如要建構完整的「搜尋即時生成」功能，您需要瞭解 AI Commerce Search 提供的兩項基本 API：

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

    • 函式：針對指定的輸入字串 (例如「lipst」)，傳回建議的查詢完成清單，包括「lipstick」和「lip gloss」、相關熱銷品牌和相關類別。
    • 費用：這項 API 包含在 AI Commerce Search 套裝方案價格中。
    • 效能：這項高處理量 API 專為快速、低延遲的回應而設計，可滿足逐字元輸入體驗的需求。這項功能會運用自動學習功能 (包括拼字修正和建議)，根據商店每日的搜尋事件訓練模型，以產生搜尋結果。詳情請參閱拼字修正 API 規格。

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

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

輸入時搜尋

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

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

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

Flow

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

  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，進而將成本、效能和關聯性最佳化。

Flow

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

  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 小工具與標準搜尋體驗的效能，取得明確且可做為行動依據的洞察資料。

結論

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