商品推薦不準？別急著換模型，先檢查商品資料
站內推薦與搜尋推不準，團隊通常先調模型、版位與權重，很少打開被送進系統的商品資料。屬性空白、分類只服務後台、識別碼跨系統對不上，都會讓演算法失去可以比較的材料。這篇文章把「推不準」拆成可檢查的資料問題，說明公開研究能證明什麼、不能證明什麼，並給出先修資料還是先調模型的判斷條件與量測設計。
換了推薦模型，搜尋結果依然可能停在原地
品牌換了推薦模型、加上 AI，首頁猜你喜歡仍反覆出現同一批熱銷品；消費者在站內輸入「通勤防潑水外套」，結果卻混入厚重雪衣與一般風衣。團隊回頭調整版位、權重與推薦規則，畫面短暫換了一輪商品，顧客要找的款式依舊沒有出現。
這種落差會直接改變顧客是否繼續逛站。廠商自營的 Coveo 2025 年度商務相關性報告 調查美國與英國合計 4,000 位消費者，其中 72% 表示搜尋結果不符合需求時會離開網站。這項海外調查不能直接當成台灣品牌的流失率，卻清楚提示了一件事：當搜尋與推薦無法理解商品，顧客很少有耐心陪品牌慢慢修正。
在部分品牌的實務檢查中，團隊常先查看模型、版位、點擊率與轉換率，商品資料本身則可能較晚才被納入排查。演算法只能使用手上的材料。欄位若是空白、命名若互相衝突，AI 讀到的商品世界本來就模糊。
報表上的空白，倉庫貨架早已填滿
我們陪品牌看站內搜尋報表時，最常停在同一個畫面：熱門關鍵字的結果寥寥可數，倉庫貨架卻排滿符合需求的商品。會議室裡的人盯著那片空白，既擔心又好奇，商品明明存在，為什麼系統像是完全看不見？
推不準的資料問題，先分成三類來查
本文提出一個三類拆法，目的是把籠統的「推不準」改寫成可檢查的資料工作。這三類問題彼此可能重疊，也不是推薦失準的全部原因；流量不足、新品冷啟動、事件追蹤缺漏、庫存與價格更新延遲、模型設定與版位設計都可能產生相同症狀，需要平行排查。這個拆法只負責把「資料」這一塊講清楚。
| 表面症狀 | 這一類要查的資料 |
|---|---|
| 搜尋有結果，商品卻不相關 | 可比較的材質、功能、尺寸與情境屬性 |
| 同類商品散落各處 | 面向消費者需求的分類、同義詞與標籤 |
| 系統無法辨認跨通路的同一件商品 | 各系統之間可對應的商品識別碼 |
- 搜尋有結果卻不相關，多半是商品欄位缺漏，模型缺少比較依據。商品名稱可能只寫系列名與顏色，描述欄複製品牌文案，材質、版型、容量、適用季節與使用情境留白。此時系統看得到商品編號，卻無法理解兩件外觀相近的商品差在哪裡，也無法把「輕量」「親膚」等需求對回適合的品項。
- 同類商品散落各處，多半是分類與標籤只服務後台管理。採購、倉儲與財務習慣依部門、供應商、庫別或會計類別整理商品，消費者則用場合、困擾、風格與功能找東西。若前台搜尋沿用後台分類，顧客輸入「上班可穿」時，系統很可能只認得「女裝／上身類／襯衫」，自然漏掉針織外套、西裝背心與素色洋裝。
- 系統看不出跨通路的同一件商品，多半是識別碼無法對應。瀏覽紀錄只有商品編號，訂單資料使用另一組款式編號，門市交易又以規格品號保存。系統無法確認會員看過、買過與退過的是同一類商品，個人化只好退回全站熱銷排行。至於會員本人在門市與線上是不是同一筆檔案，屬於另一個要單獨檢查的問題，兩者容易被混為一談。
這個拆法的重點，是把「推不準」從抽象感受改成欄位、分類與識別碼的檢查工作。只要能指出系統缺少哪一項材料，團隊就知道該找商品、電商、資訊或會員營運夥伴一起處理。
公開證據能證明什麼，不能證明什麼
推薦與搜尋的錯誤很容易被歸到技術端。公開研究確實顯示商品內容與搜尋體驗值得治理，但這些研究都沒有比較各類技術與營運根因的發生比例，也就不能用來證明商品資料是推薦不準的主要原因。以下三組證據分別對應退貨、站內流失與資料標準。它們的市場、樣本與調查單位不同，適合用來辨認方向，不適合直接變成單一品牌的目標值。
商品內容出錯，退貨先反映資料落差
商品頁是消費者無法摸到實品時的判斷依據。圖片、尺寸、材質、顏色、用途與規格只要有一項含糊，購買當下的期待就可能和收到商品後的感受分開。推薦系統若又根據含糊內容把商品送到不適合的人面前，錯誤會一路延伸到訂單與退貨。
廠商自營的 Salsify 2025 消費者研究 於 2024 年 10 月透過 SurveyMonkey 調查美國與英國合計 1,910 位消費者，誤差率在 3% 以內。研究中，71% 受訪者曾因商品內容錯誤而退貨，54% 曾因不同通路的商品內容不一致而放棄購買。
Akeneo 在 2025 年委託 Dynata 進行的兩份美國消費者調查，每份各訪問 1,000 位消費者，分別顯示 59% 受訪者曾因線上商品描述誤導或不準確而退貨，以及在 假期購物情境 中，「商品與描述或照片不符」占退貨主因的 17%。
上述數字都來自美英樣本，也都帶有廠商自營或廠商委託調查的限制，台灣品牌不宜直接照抄成 KPI。它們的用途，是提醒團隊查看商品內容錯誤是否伴隨退貨原因出現。這組證據的判斷很清楚：推薦帶來一次點擊以前，商品資料已在決定顧客會不會買錯。
零結果讓顧客比品牌更早放棄
站內搜尋的零結果，可能來自確實無貨，也可能來自索引或庫存更新延遲、同義詞未覆蓋、屬性缺漏、拼字與語意處理不足，或搜尋設定本身。商品標題寫「機能防護系列」，顧客搜尋「雨天外套」；後台標籤寫「商務休閒」，顧客輸入「面試穿搭」。兩邊談的是相近需求，詞彙沒有對上，結果頁便呈現空白。這幾種成因需要先分類診斷，不能一律當成資料問題。
Baymard Institute 2019 年研究頁面 於 2025 年 2 月更新，研究發現接近 50% 的網站沒有提供有效方式，協助使用者離開零搜尋結果的狀態。到了 Baymard Institute 2026 年電商搜尋研究，在 170 個以上受測站台與 App、超過 10,000 項可用性評分中，搜尋體驗被評為「中等或更差」的比例，桌機為 46%、行動網頁為 58%、App 為 64%。
這些結果來自海外受測站台與研究情境，只能提示搜尋體驗的普遍風險，不能直接換算成台灣品牌的比例，也不能單獨判定問題源自商品資料。前述 Coveo 研究另外顯示，72% 受訪者會在搜尋結果不符需求時離開網站。不同研究方法不能直接合併推論，但共同指向同一個營運問題：零結果、弱相關結果與缺少替代路徑，都會縮短顧客留在站內繼續找商品的時間。
品牌可以把零結果關鍵字視為一份需求字典。它記錄顧客用哪些詞形容材質、場合、困擾與期待，也照出商品資料尚未收錄的同義詞。這組證據的判斷是：搜尋結果空白時，先分類成因，再決定要補資料、修索引，還是調整模型。
公開標準早已寫清楚商品要能被辨認
一件商品要被搜尋引擎、購物服務與資料交換系統正確理解，需要穩定而可辨識的欄位。這件事並沒有神祕門檻，公開標準早已列出基本結構。
Google Merchant Center 官方商品資料規格 列出 id、title、description、link、image_link、price、availability 等必要屬性，並依商品類型與銷售地區，增列 brand、condition、GTIN、MPN 等條件式必要屬性。schema.org 官方 Product 型別 提供 sku、gtin、brand、offers、additionalProperty 等標準屬性，讓商品資訊能用一致結構被機器讀取。GS1 Global Data Model 則定義全球一致的基礎商品屬性，支援上架、訂購、倉儲、配送與銷售等工作。
這些標準處理的範圍不同，卻都要求商品具備清楚識別、描述、交易條件與規格。品牌常見的落差，通常不在於缺少可參考的標準，而在欄位有沒有被填寫、同一屬性是否使用一致格式、各通路是否同步更新。這組證據的判斷是：商品資料能否被機器理解，先取決於結構與填答紀律，再輪到模型發揮。
不同推薦方法對商品資料的依賴程度並不一樣
站內搜尋與推薦可能使用商品內容、會員行為、共同瀏覽或購買紀錄、即時情境與排序規則。內容式方法高度依賴商品屬性；協同過濾與熱門排行即使在屬性不完整時也能運作，但在新品冷啟動、細緻需求匹配與結果解釋上會受限。商品資料是重要輸入之一，並不是所有模型的唯一前提。
這個區別很實用，因為它決定了症狀該怎麼讀。熱銷排行永遠推得動，卻永遠推得很粗；靠共同購買撐起來的推薦在暢銷品上表現尚可，一遇到新品或長尾就失去依據。屬性缺漏時，可用的材料會變窄：材質欄空白，便無法辨認棉、羊毛與聚酯纖維的差異；情境標籤缺少，便無法區分通勤、旅行與戶外活動；規格格式不一致，「五百毫升」「500ml」與「0.5L」可能被當成不同概念。
模型再好，讀到的商品資料是空的，推出來的東西也會是空的。這句話並非否定模型的價值，而是提醒團隊，模型表現有一部分來自輸入材料。若同一件商品在標題被稱為「輕羽衣」，分類放在「季節限定」，描述只有品牌故事，內容式方法很難知道它是一件可收納、抗風、適合旅行的外套。
判斷錯常常不是演算法笨，是它拿到的描述本來就分不出差別。當兩項商品共用相同文案，只替換顏色名稱，系統看不見版型、厚度與用途差異。行銷團隊再怎麼調整推薦版位，仍可能把相似外觀誤認為相似需求。
另一個常被忽略的問題，是識別碼與資料責任。商品資料住在一套系統、會員資料住在另一套，中間沒人負責對齊，瀏覽紀錄、訂單與商品屬性便難以穩定連接。今天改了款式編號，昨天的行為可能失去對應；門市與官網使用不同分類，會員偏好也會被拆開解讀。
有時候先調模型才是划算的
先修資料並不是永遠正確的順序。若抽樣檢查顯示關鍵欄位完整、識別碼可對應、代表性搜尋詞也能召回正確商品，問題卻集中在排序延遲、結果同質化、探索不足，或模型不支援目標情境，那麼調整排序邏輯或更換工具可能更划算。順序應該由小規模測試的錯誤歸因決定，而不是由「一定先修資料」或「一定先換模型」的成見決定。
市場上流傳許多「推薦系統貢獻某個比例營收」的說法，其中最常被轉述的數字，多半查不到方法論公開的原始出處。品牌若把這類比例直接設成目標，容易忽略站內流量、品類、會員規模、購買週期與版位定義的差異。比較可靠的方式，是在自己的站內建立對照觀測：比較有無完整屬性、不同推薦規則或不同搜尋詞處理下，點擊、加購、轉換、零結果與退貨原因如何變化。
個人化還要把會員行為接回商品屬性
商品資料修好後，系統終於能分辨商品之間的差異。個人化仍缺少另一半：同一位會員過去買過什麼、看過什麼、退過什麼，以及這些行為發生在門市或線上。只有把行為紀錄與商品屬性接起來，推薦才有機會離開全站熱銷排行，改用個人的需求與階段選擇內容。
這裡要區分行為的語意。退貨若源自尺寸、瑕疵或物流問題，不宜直接視為對該品類的負向偏好，否則個人化判斷反而會被污染；退貨原因、時間與通路應該一併納入判讀。
例如，會員在線上瀏覽輕量行李箱，門市購買旅行收納袋，之後又查看防潑水外套。若各通路紀錄分開，系統只看到幾個零散事件；資料歸到同一筆會員檔案後，團隊才可能辨認出旅行情境，再從容量、材質、重量與防護功能中找出相關商品。
同一個人在門市和線上沒有歸成一筆檔案，商品偏好就會被切成兩半。顧客資料平台負責整合跨通路會員識別與行為，再把這些行為和商品屬性交叉。91APP CDMP（Customer Data Management Platform）是 91APP 用來處理這項工作的產品，協助品牌把會員輪廓、交易與互動資料放回一致的辨識脈絡。
這段工作也需要商品端先有穩定欄位。若「防潑水」有時放在名稱、有時寫在描述、有時完全未填，平台即使整理好會員行為，也難以累積可靠偏好。品牌可依目前使用的 91APP 方案與後台權限，盤點手上可用的商品分類、標籤與會員資料整合功能，實際設定位置與支援範圍以產品文件及顧問確認為準。
CDMP 在此扮演的是資料連接角色。商品團隊負責定義可比較的屬性，電商團隊整理搜尋語言，會員營運團隊確認分眾與溝通情境，資料平台則維持識別與對應。分工清楚後，推薦結果才有可追查的理由，團隊也能知道某次偏差來自商品欄位、會員辨識或推薦規則。
先確認錯在哪一層，再決定補資料還是調模型
經濟部統計處民國 114 年，也就是 2025 年的統計 顯示，全年網路銷售額為 6,716 億元，年增 2.8%；零售業全年營業額為 4 兆 8,448 億元，年減 0.2%。本文以這兩項官方數字相除，得到約 13.9% 的粗略比值。這是本文換算，並非經濟部發布的官方電商滲透率，解讀時仍須留意兩項統計的涵蓋口徑。這個市場脈絡提醒品牌，線上體驗已是零售營運的一部分，商品資料也該由一次性上架素材，轉為持續維護的營運資產。
在動手之前，先為五項行動準備共通的量測設計：每項改善先記錄修改前一段固定期間的基準，再分批上線，並使用相同長度的觀察窗。欄位完整率與識別碼匹配率屬於資料指標，零結果率、搜尋後點擊率、加購率、轉換率與退貨原因屬於結果指標。只有在控制檔期、庫存與版位變化之後，結果指標仍然改善，才能暫時判斷資料修正有效。
- 先盤點必要欄位的填答率。
- 做法：依品類列出名稱、描述、材質、尺寸、顏色、規格、用途、適用情境與識別碼，檢查空白、預設值及格式差異。
- 預期：找出模型無法比較的區域，並得到欄位完整率的基準。
- 週期：每月檢查一次，新品上架前另設檢核關卡。欄位不用一次追求最多，先確保高搜尋、高銷售與高退貨品項具備穩定資料。
- 用消費者會說的詞整理分類與標籤。
- 做法：把站內搜尋詞、客服問法、商品評論與門市常見需求整理成同義詞，對回材質、場合、功能與困擾。
- 預期：降低「商品存在卻找不到」的情況，可用零結果率與搜尋後點擊率驗證。
- 週期：每月依熱門搜尋與新品變化調整。後台分類可繼續服務管理，前台標籤則補上顧客的語言。
- 把零結果搜尋當成選品與命名線索。
- 做法：每週查看零結果與低點擊查詢，逐筆判斷屬於真正缺貨、索引延遲、詞彙未對應、商品命名不清或排序失準。
- 預期：區分資料問題與真正的商品缺口，避免把所有零結果都當成資料問題處理。
- 週期：每週處理高頻詞，每月回看修正後的搜尋表現。退貨與棄購其實是資料在說話，兩者都能回頭補充屬性與說明。
- 把商品資料與會員資料對齊。
- 做法：確認瀏覽、收藏、訂單、退貨及門市交易能否對回相同商品識別碼，並透過 CDMP 或既有顧客資料平台整合會員身分。
- 預期：讓偏好從單次點擊累積成跨通路紀錄，可用識別碼匹配率追蹤。
- 週期：識別碼匹配率與資料流異常每週或每月監控，新品類、新系統或欄位異動上線時立即抽查，每季再做一次完整稽核。
- 建立能持續查看的商品資料健康度。本文為了說明持續管理而提出「商品資料健康度」這個說法。
- 做法：先為每項指標定義分母、合格門檻、資料來源與負責人，例如必要欄位完整率、格式合格率與識別碼匹配率。
- 預期：讓資料維護有固定的檢視對象，初期分開呈現各項指標，不急著合成單一總分。
- 週期：每月檢視趨勢，每季挑選品類改善。把商品資料修好之後，第一個受益的往往是既有的會員溝通管道，因為電子報與分眾內容也能使用更清楚的商品屬性。
搜尋框照見的，是品牌整理商品的方式
回到會議室裡那個畫面，搜尋報表仍停在熱門關鍵字，結果頁只有寥寥幾件商品，倉庫貨架卻排得滿滿。此時團隊該追的，不只是一個更靈巧的推薦規則，也包括那些空白欄位、混亂標籤與彼此對不上的識別碼。
商品能不能被推薦，先看它能不能被理解；會員能不能收到合適的商品，再看行為能不能回到同一筆商品資料。搜尋框裡的空白，往往照見品牌尚未說清楚的商品。
品牌最常問的商品資料與 AI 推薦問題
Q1：商品資料品質是什麼，和商品描述有什麼差別？
A1：商品描述只是商品資料的一部分。商品資料品質還包含欄位是否完整、格式是否一致、分類是否合理、識別碼能否對應，以及不同通路內容是否同步。描述寫得生動，若尺寸、材質或用途仍空白，搜尋與推薦依然缺少可比較的依據。
Q2：這和以前做商品分類有什麼不同？
A2：傳統分類常依採購、庫存或會計需求安排，方便內部管理。搜尋與推薦還需要消費者使用的詞、商品功能、適用場合及可比較屬性。原有分類不必全部重做，可保留管理架構，再補上前台標籤、同義詞與情境資料。
Q3：SKU 少、人力少的品牌該從哪裡開始？
A3：先從熱門搜尋、高銷售、高退貨或主推商品開始，挑出影響顧客選擇的必要欄位。每次新品上架固定補齊，舊品則依優先順序處理。SKU 少反而容易建立一致規則，重點是先選一個品類做完，再把可用格式延伸到其他品類。
Q4：補完商品資料後，多久可以看到成效？
A4：時間取決於網站流量、商品量、搜尋詞量與觀測方式。欄位補齊後可先看零結果、低點擊查詢與推薦內容是否改變，再觀察加購、轉換及退貨原因。建議保留修改前基準，分批更新商品，才能分辨變化來自資料、版位或活動檔期。
Q5：需要工程資源，或一定要更換系統嗎？
A5：欄位盤點、命名規則、分類調整與同義詞整理，通常可先由商品、電商與會員營運團隊進行。若要串接跨通路識別碼、顧客資料平台或自動同步，才需要資訊人員協作。是否換系統，應先看現有欄位與匯出能力能否支援目標。
Q6：什麼情況下該換推薦引擎，而不是繼續補資料？
A6：先用一組代表性搜尋詞與商品清單做小規模測試。若關鍵欄位完整、識別碼可對應、正確商品也召回得到，問題卻集中在排序延遲、結果同質化或模型不支援目標情境，換工具就可能比較划算。若測試顯示屬性空白、分類混亂或識別碼對不上，新工具仍會讀到同一批材料。