按一下檢查清單中的每個項目，即可查看如何進行的詳細資訊。完成每個啟用步驟後，請勾選核取方塊。按照這些步驟操作，即可提升建議的整體採用成效。
屬性資料
屬性篩選限制：屬性篩選限制為 10 個，請優先選取最重要的屬性。分析所選自訂屬性的模式，並將類似的相關屬性新增至目錄。確保目錄中的屬性篩選鍵涵蓋範圍廣泛，以便有效篩選及調整建議。
盡量發揮屬性的影響力：請勿刪除或停用屬性，否則可能會影響模型。為更多產品填寫這些欄位，即可提升自動選取屬性的涵蓋範圍。
檢查屬性設定：建議會使用可篩選的屬性設定，這些設定可用於建議篩選運算式。這項控制項僅適用於文字屬性。
類別
監控類別分布情形，並處理代表性過高的類別。高品質的產品類別可讓以規則為基礎的多樣性功能，推薦各種類別的產品。
缺貨比率
維持低缺貨率 (理想情況是低於 90%)，避免建議結果失真，確保結果關聯性。如果大部分產品都OUT_OF_STOCK (缺貨)，預測回應就會有很多缺貨產品，新增篩選條件後，召回數量就會減少。使用 patchProduct API 或匯入 API (附有 readMask)，盡可能讓 Product.availability 欄位保持最新狀態。
變體和主要詳細資料
請確認主要產品和子類產品的詳細資料完整且正確。請考量產品的 SKU 結構，並視需要將產品指定為主要或子類。請優先確保主要和子類產品的 product.categories、product.title、product.attributes 和 product.prices 屬性準確無誤。
決定哪些產品或產品群組是主要產品，哪些是子類時，請務必謹慎思考。
主要項目和變體有時也稱為父項和子項。
主要和子類產品的價格
請正確填入主要產品和子類產品的價格資訊，確保系統提供準確的建議和篩選功能。如果產品沒有產品層級的價格，且所有價格一律與店面商品目錄資料相關聯，請在產品層級價格資訊中填寫所有店面商品目錄資料層級價格的中位數價格資訊。
資料上傳頻率
請注意，模型大約每六小時會擷取一次新的產品資訊。
建議您定期匯入型錄 (每小時或每天，最好是即時)，以更新型錄，避免模型品質隨時間下降。
在 BFCM 等尖峰活動期間，請確保資料擷取管道可處理整個目錄的快速價格變更。
各分支機構的上傳次數不一致
請確保各分店上傳的產品一致，以免部分查詢缺少產品資訊，導致模型品質下降。
將資料匯入不同分支，即可暫存及預覽建議，或預測結果。
篩選器和多元性設定之間的平衡
請盡量平衡套用的篩選器數量和多元性設定。使用資料驅動的多樣化功能，產生兼顧關聯性與多元性的推薦結果。以資料為準的多樣性功能會從產品目錄中繼資料 (例如名稱或類別) 學習。
將 diversityLevel 設為 RULE_BASED_DIVERSITY、DATA_DRIVEN_DIVERSITY、no-diversity、low-diversity、medium-diversity、high-diversity 或 auto-diversity 等值，即可根據產品類別調整預測結果。
RULE_BASED_DIVERSITY根據產品類別，提供更多元的推薦結果。DATA_DRIVEN_DIVERSITY會根據產品中繼資料的學習結果，提供多元的建議，在關聯性和類別多元性之間取得平衡。
價格重新排序參數
使用 priceRerankLevel 參數，根據產品價格調整預測結果，並選擇不重新排序、低、中或最高價格重新排序。
允許的值為 no-price-reranking (如未設定，則為預設值)、low-price-reranking、medium-price-reranking 和 high-price-reranking。
使用者事件中的篩選資料有誤
請確保使用者事件中的多字篩選器與目錄完全相符，包括大小寫 (OnePiece 與 One-Piece)。
如要讓動態層面發揮最佳成效，請務必正確使用篩選器。模型會根據預測要求中的篩選條件，推斷構面熱門程度。
活動規定
針對所有事件類型 (依模型類型)，請確保有足夠的事件數量。
請確認擷取的事件可歸因，也就是時間戳記、訪客 ID 和產品 ID 詳細資料必須正確，模型才能訓練。也就是說，模型應能根據事件建構使用者歷程。
建立模型時，請參閱說明文件或 Gemini Enterprise for Customer Experience 的 AI Commerce Search，瞭解各模型類型的事件需求。
每個產品的平均曝光次數
就所有事件類型 (依型號類型)，每項產品 ID 的平均曝光次數應超過 10 次。只要一到兩週的詳細網頁瀏覽次數，就足以開始訓練「你可能也喜歡」和「為你推薦」模型。
購買訂單平均商品數
請確保購買訂單平均商品數大於 1 (不含商品數量)，但須視情況而定。請勿將多項商品購物車攤平為多個購買事件。請將這些事件視為包含多項產品的單一購買事件。
請確認部分購買事件包含多項產品，這有助於模型瞭解共同購買模式，尤其是「經常一起購買」等模型。
API 回應：搜尋和建議內容的差異
AI Commerce Search 的主要區別在於 Search 和 Recommendations API 如何處理回應中的產品子類。瞭解這項差異對導入作業至關重要。
搜尋回覆會包含特定產品子類，建議回覆則不會。
- 搜尋：使用者提交查詢 (例如「紅色跑步鞋，尺寸 10 號」) 時，API 會傳回主要產品清單，以及前五個相符子類的詳細資料。使用者查詢內容會提供必要脈絡，以找出最相關的變體並排序。
- 建議：對於「經常一起購買」或「為你推薦」等模型，回應中只會刻意傳回主要產品 ID。這些建議範圍廣泛，且缺少特定使用者查詢，無法引導選擇變體。
開發人員可彈性實作自己的變體選取邏輯。由於沒有引導查詢，你可以根據自己的業務規則控制顯示的變化版本，例如顯示暢銷商品、庫存量最高的變化版本，或是正在促銷的變化版本。這項設計可確保最終建議符合您的特定電子商務策略。
個人化模型 (例如「為你推薦」或「你可能喜歡的其他內容」) 會根據使用者的即時動作調整，因此效果最佳。這項回應能力取決於使用者互動資料或事件的處理方式。
- 即時個人化：這種做法會運用持續不斷的使用者事件串流，例如點擊或加入購物車。即時擷取這些事件後，推薦模型就能立即根據使用者最近的興趣調整輸出內容。確保建議內容一律是最新且高度相關的內容。
- 模型訓練與個人化：請務必區分核心模型和個人化層。
- 模型訓練：AI Commerce Search 的基礎建議模型通常每天都會重新訓練，並從所有歷來資料中學習。
- 即時個人化：這項功能會以訓練好的模型為基礎運作。每次呼叫 API 時，系統都會重新計算個人化推薦內容，並納入過去幾分鐘內發生的使用者事件。
- 擷取方法很重要：個人化速度與擷取使用者事件的方式直接相關。
- 即時擷取：這對即時個人化至關重要。如果貴商家需要把握當下的使用者意圖，就必須優先處理即時事件串流。
- 批次擷取：使用批次程序會導致個人化延遲，延遲時間等同於批次排程的頻率。雖然這並非壞事，但根據業務需求，這項取捨至關重要。
AI 輔助產品推薦的成效取決於策略性位置。在正確的網頁上顯示正確的模型，是盡量提高使用者參與度和達成重要業務指標的關鍵。本指南提供經過驗證的策略，協助您放置 AI Commerce Search 模型，同時強調滿足獨特業務目標所需的彈性。
核心建議模型和顯示位置
AI 購物搜尋提供適用於不同購物情境的專用模型。下表彙整了主要模型，以及建議的刊登位置，可發揮最大影響力。
| 電子商務頁面 | 主要目標 | 網頁的最佳模型 | 替代模型 1 | 替代模型 2 |
|---|---|---|---|---|
| 產品詳細資料頁面 | 顯示類似或替代商品 | 你可能會喜歡的其他項目 | 經常同時購買的產品 | 類似商品 |
| 首頁 / 類別頁面 | 個人化探索 | 為您推薦 | 再次購買 | 特價 |
| 購物車頁面 | 提高平均訂單價值 | 經常同時購買的商品 | 為您推薦 | 特價 |
- 為你推薦：運用使用者的歷來資料打造個人化體驗。在首頁或類別頁面上顯示，立即以量身打造的建議吸引回訪顧客。
- 你可能也會喜歡：這個模型適合用於產品詳細資料頁面，會顯示與目前查看產品類似或可替代的項目。這項工具可帶動產品探索，並針對點閱率或收益進行最佳化。
- 經常一起購買：建議互補產品，提高平均訂單價值。在產品詳細資料頁面和購物車或結帳程序中，系統會提示消費者加購相關產品，因此最能發揮效益。
進行 A/B 測試，根據資料做出決策
這些指南提供穩固的基礎，但您仍須進行 A/B 測試，驗證最適合特定目標對象的策略。舉例來說，您可以向不同使用者同類群組放送「你可能也喜歡」或「經常一起購買」模型，測試哪一個在產品詳細資料頁面上的成效較佳。
追蹤每個群組的轉換率和收益等主要成效指標，即可根據資料決定要部署哪個模型。這種實證方法可避免臆測，確保刊登位置策略能配合業務目標進行微調。
兼顧規範與業務需求
建議您從這些建議著手。AI 商業搜尋的彈性可讓您進行自訂，以達成特定策略目標。不過，如果商家沒有預先建立的刊登位置策略，這些經過驗證的指南可提供可靠的成功途徑。只要妥善放置模型，並透過測試持續調整做法，就能打造更具吸引力且有利可圖的電子商務體驗。