網站有流量，營收卻沒跟著動時，團隊很容易跳到解法：首頁換版、按鈕改色、再加一個折扣彈窗。這些動作都可能有效，但在沒有診斷的情況下，它們只是猜測。
CRO 的工作順序應該反過來。先找出漏斗在哪裡損失，再理解使用者為什麼停下來，接著選一個能被驗證的改動。每月重複同一套流程，價值不只來自贏的版本，也來自團隊逐漸知道哪些主張不成立。
先決定這個月要解哪一段漏斗
不要用全站轉換率當唯一入口。把流程拆成商品瀏覽、加入購物車、開始結帳、完成付款，再依裝置、來源與新舊客分開看。Google Analytics 的 Funnel exploration可以設定開放或封閉漏斗、最多 10 個步驟，並套用最多 4 個區隔。假設整體轉換率下降，可能只是本月行動廣告流量增加；若沒有分群，很容易把流量組成的變化誤判成網站故障。
Baymard Institute 彙整多份研究的 購物車放棄率資料顯示，平均值接近七成。不過這個平均值不能直接當成你的目標。商品單價、購買週期、裝置與市場都會改變基準。它真正提醒我們的是：從購物車到付款之間，有足夠大的損失值得逐段檢查。
漏斗只能指出「哪裡掉了」。要理解原因，還要看客服紀錄、站內搜尋、表單錯誤、使用者訪談與行為錄影。熱圖可以顯示點擊集中在哪裡，卻不能替使用者說明他為什麼猶豫。
把觀察寫成可能被推翻的假設
「結帳頁需要更清楚」無法測試。可執行的寫法應交代對象、改動與衡量方式，例如：「行動裝置使用者在看到運費前離開；若在購物車提前顯示免運門檻，開始結帳率應提高，而且客單價不能下降。」
最後那個限制很重要。只看轉換率，可能得到一個讓更多人下單、同時拉低毛利或提高退貨的版本。每個實驗至少要設定一個主要指標與一到兩個護欄指標。商品頁實驗可以看加入購物車率，同時監控客單價與退貨；結帳實驗則可看完成付款率，同時監控折扣成本。
假設清單不要排成「大家最喜歡的點子」。優先處理影響範圍大、證據較多、實作成本可控的項目。若客服每週都收到同一個尺寸問題，這比會議上有人覺得主視覺不夠吸睛更值得先查。
排程時也要避開無法解讀的時段。大型促銷、價格調整、網站改版與廣告受眾更換若同時發生，測試結果很難歸因。無法延後時，就在實驗紀錄標出干擾事件，不要事後把所有變化都算在版本差異上。
流量不足時，不要硬跑 A/B 測試
A/B 測試需要足夠樣本與合理的執行時間。測試跑三天、看到版本 B 領先就關掉，很可能把週末效應或隨機波動當成答案。開始前應根據基準轉換率、希望偵測的最小變化與流量估算樣本，執行期間也要涵蓋完整的商業週期。
低流量網站不代表不能做 CRO。此時更適合先處理明顯錯誤，或用可用性測試、客服訪談與結帳逐步檢查建立證據。這些方法回答的是「哪裡讓人困惑」，不應被包裝成轉換率提升的統計證明。
需要技術與內容一起調整時，可以先檢查 成長營運服務的工作範圍；若問題其實來自前端效能與架構，再回頭看 Headless Shopify 的決策框架。不要因為 CRO 是當前專案名稱，就假設所有問題都能靠文案解決。
實驗紀錄才是月度循環的核心
每次測試至少留下日期、假設、受影響頁面、版本差異、主要與護欄指標、樣本條件、結果及下一步。失敗的實驗也要保留。三個月後再有人提出相同點子，團隊才能看到當時測了什麼，而不是重跑一次。
贏的版本也不應立刻變成全站真理。它可能只對某個流量來源、裝置或促銷期有效。把適用條件一併寫入設計與內容規範，比留一句「版本 B 勝出」更有用。
月底回顧時，把本月投入的設計與工程時間也寫進紀錄。提升幅度相同的兩個方案，若一個需要長期人工維護，另一個能直接納入元件，後者通常更值得保留。CRO 的成本不只在測試工具，也包括團隊為每個版本付出的製作與維護時間。
下一個月不必重新腦力激盪。先回看未解決的漏斗問題、失敗實驗留下的新線索，以及已上線版本是否影響護欄指標。這樣才是一條連續的研究路徑，而不是每月換一個人猜首頁該改什麼。
一個可維持的月度節奏通常只需要完成一件事：選定一段漏斗，形成一個有證據的假設，採用符合流量規模的方法，然後把結果寫清楚。若目前連問題發生在哪一頁都說不準，可以先從免費轉換健檢開始。