推薦模組顯示「帶來多少營收」，通常只代表顧客看過或點過推薦後購買，無法證明推薦造成交易。熱賣品本來就有高購買機率，把所有訂單歸給演算法會高估效果。評估要同時看增量商業結果、顧客任務與推薦品質。
先定義推薦類型和版位。替代、互補、升級、補貨與探索的成功標準不同，不能用同一個 CTR 排名。
建立完整曝光漏斗
事件包含 eligible、request、response、render、view、select、add_to_cart、remove、purchase、refund。每筆帶 placement、page、source item、recommended item、rank、model/rule version、experiment ID、market 和 session/user key。
只把進入 viewport 且可互動的卡片算 view。Provider 回傳但前端未渲染需另記，否則載入失敗會被當成低點擊。Ecommerce outcome 沿用 GA4 items schema，追蹤設計可參考 Shopify 實驗事件追蹤。
用 holdout 量增量
流量足夠時隨機保留一組不顯示推薦，或顯示既有規則作 control。事先固定 assignment、主要指標、觀察期、排除與停止規則。主要結果可用 contribution margin per visitor/order，並看 conversion、AOV、units 和回訪。
顧客跨裝置與多次 session 可能同時看到不同版本，分析單位需和分流一致。樣本不足時可做受控 pilot、任務研究和離線評測，但報告不能把前後變化寫成因果。
收入要扣掉後續成本
推薦高折扣、低毛利或高退貨商品，短期 revenue 可能上升，實際價值下降。把商品成本、折扣、運費、取消、退貨、客服與 provider 費用納入。觀察期需涵蓋主要退貨窗口，至少在早期報告標明尚未成熟。
若推薦讓 cart 更重、配送跳級或主商品 conversion 下滑，也要算入。詳細 UX 護欄可參考 Shopify 加購推薦 UX。
衡量多樣性與覆蓋
Coverage 看有多少合格商品和顧客能得到結果；catalog concentration 看曝光是否集中少數熱賣品；diversity 看同一推薦列是否重複；novelty 則觀察是否幫人發現原本沒接觸的合理商品。
這些不是越高越好。過度追求新穎可能降低相關性，平均多樣性也可能掩蓋某些顧客只看到單一品牌。依品類和任務設目標，並抽查長尾、冷啟動和新商品。
監看硬規則與傷害
相容性、年齡、過敏原、庫存、market、配送與法規限制屬於硬條件。計算 violation rate，任何嚴重違反都可觸發停止。顧客主動隱藏、回報不相關、快速移除和客服投訴也是重要訊號。
模型不應推回顧客已退貨且明確不喜歡的商品，也需避免敏感屬性被不當推論。資料使用和個人化提供退出方式。
離線與線上評測分工
離線用歷史資料測 precision、recall、ranking 和規則，適合快速篩選版本；歷史互動本身受舊版位和熱門度影響，不能預測完整增量。線上實驗驗證真實行為，人工任務測試則檢查理由和顧客理解。
每次發布保存資料範圍、feature、模型、規則、供應商與日期。結果下降時能回退前版，資料或商品變更後也知道是否需重訓或重建 index。
依決策週期做報告
每日監控可用性、延遲、空結果與規則違反；每週看版位漏斗和品質抽樣；每月或實驗期滿才判斷增量毛利、退貨和顧客影響。不要每天依波動換模型。
報表標出樣本、信賴區間、資料成熟度與同期間促銷。新品、缺貨與 campaign 會改變可推薦集合，需要在版本註記。團隊也要能從總覽下鑽到 query、商品、規則與單次 trace，才能把異常變成修正工作。
設定 owner 與決策節奏：工程負責事件和穩定，商品團隊看關係品質，CRO 分析增量，客服回報傷害。單一 CTR dashboard 無法支援這些角色。
一個好的 AI 推薦系統能幫顧客完成任務，並在扣除成本後創造增量。報表若同時保留 control、品質與護欄，團隊才不會把演算法最會取得的點擊誤認成商業成果。