雖然AB實驗是一種很直接、公正又簡單的產品驗證方式，但在現實中無法做A/B Test的情況又蠻常見，這種情況下該如何做出合理的產品決策呢？本文作者整理了一些AB實驗之外的產品驗證方法或流程，希望能給你帶來一些幫助。

雖然AB實驗是一種很直接、公正又簡單的產品驗證方式，能夠協助 PM 們通過數據進行決策，但在現實中其實「無法做 A/B Test」的情況又蠻常見，在這些情況下我們該怎么依然有憑有據的做出合理產品決策呢？

我整理了一些AB實驗以外的產品驗證方法或流程，希望能幫助大家通過數據決策。

01 哪些狀況不適合AB實驗？遇到這些狀況該怎么辦？

除了公司沒資源沒有實驗架構、老板不給時間這些原因以外，這四種情況也不太適合做AB實驗，以下隨場景附上推薦的解決方案：

狀況一：流量太低

當產品每天只有千位甚至百位活躍用戶，A/B Test 分組下去一組只剩幾百甚至幾十人，這樣的情況通常不適合做那種改一點按鈕顏色、改一點文字翻譯的小步快跑 A/B Test，因為如同大家所知，樣本太少時并不容易達成統計上的顯著。

推薦方法：定性研究為根基的「大步跑」

一個 A/B Test 若樣本數多、產品改動的影響大、時間跑得長，就越容易達成統計上顯著。所以其實低流量也不是什么問題，只是那些線上樣本計算機會跟你說「你的實驗只要跑 5487 天就會有顯著結果哦！」。

現實中我們當然不可能乖乖等 5487 天，通常都希望在幾周內可以看到結果，才好做下一步的產品規劃，所以這個時候我們可以盡量把產品改動的規模擴大做大，放棄小步快跑來個大步跑，若帶來的影響夠大，自然也會更容易達成統計上的顯著。你可以試試這樣做：

• Step 1：為了降低大改帶來的風險，執行扎實徹底的用戶研究。
• Step 2：規劃大改動（例如整頁信息架構調整，前后流程調整等等）。
• Step 3：改動上線后通過其他反饋工具來做驗證，例如使用 NPS 工具，在產品內嵌入簡單的問卷表單，與客服協作獲得反饋等。還是可以試著跑跑看 A/B Test，如果效果不錯影響面夠大也是可以獲得統計上顯著的。
• Step 4：若還是想得到量化信息，可以考慮在未來產品流量提升之后，進行 Blackout Experiment 來觀測。所謂 Blackout，就是將某個已上線的改動或功能在實驗中暫時關掉，看看這些改動或功能是否真的有影響。

除了這種「扎實版大步跑」以外也有一些其他方法手段，我會在下一大段落中一并分享其他在低流量產品身上也能使用的產品實驗設計方法，有興趣的朋友可以滑動到底下閱讀。

狀況二：ToB 產品

當你的產品用戶非一般消費者、而是天天要用你的產品工作的「專業使用者」或企業，比如說用 POS 系統點餐的餐廳店員、用飯店管理工具后臺確認訂房付款狀況的飯店柜臺等等，他們已經習慣按鈕顏色、位置、功能，需要一致的體驗，可能也經不起你三天一小改五天一大改、無法預期的產品實驗。

推薦方法：利用 Beta program 進行快速回饋與溝通

可以試著和幾個關鍵用戶討論看看他們是否愿意加入「新功能搶先用的」 Beta program，以他們為主要用戶研究對象、訪談、規劃與開發產品，開發后的新功能與改動再先利用 Beta program 上線，以獲取早期回饋。

等到這些功能與改動比較成熟穩定，再開始對其他用戶做中大型規模的 A/B Test 來做最后的驗證。這樣的話就可以降低對用戶的干擾程度，也較好對 Beta program 用戶們做預期管理。

狀況三：新產品

新產品除了跟流量低的產品有相同問題以外，相較于成熟產品，MVP 和理想的商業模式通常差比較遠，產品本身體驗和用戶真正的需求落差也可能更大，在這個時候若還堅持每次只改動一個變量、慢慢用 A/B Test 當成唯一驗證手段，或許也不是最有效率的方式。

推薦方法：定性研究與規律用戶測試為王

在新產品的階段，基本上和狀況一的低流量一樣，需要更多市場研究、用戶研究、競品研究等信息來提供洞見，以及通過反饋工具與客服狀況來了解上線后的效果。

尤其在 MVP 開發階段，由于產品根本還沒上線也毫無 A/B Test 的可能性，建議安排規律的（每個月或甚至每周）User Testing，利用手邊的原型去獲得早期回饋再來做產品調整，就不用等到上線之后才崩潰的發現都做得不對。

另外以早期產品來說，除了易用性與功能，也建議要持續驗證整個產品的商業模式，打好基礎，同時收集能夠應用在未來產品路途上的信息。

狀況四：難以測量的體驗或易用性提升

在大部分情況下，提升易用性、增加便利性還是可以被測量的，但我之前曾遇過一個我真的不知如何測量的狀況：我們想改善照片編輯 App 的操作手勢，我和設計師在長按、雙點擊、一長一短點擊這種常見手勢該搭配什么對應功能之間糾結，長按該把照片往底部推？還是編輯照片？還是拉到最上層？這個其實我到現在還沒想到可以跑 A/B Test 的方法（有想法的朋友歡迎跟我分享），因為這件事的驗證牽涉到用戶手勢意圖，是數據很難告訴我們的信息。

推薦方法：大樣本定性研究

一般的用戶研究會測試五位用戶左右，因為根據研究計算，只要測試五位用戶就可以看出行為模式、涵蓋大部分的痛點。這里我所謂的大樣本是指比平常用戶研究數量還多兩三倍的d研究，之前的經驗是我們從咖啡廳、路上、辦公室等地對 10–20 位用戶做了易用性測試，確實記錄每個動作、手勢、使用流程與背后的動機和意圖，再畫成表格比較優缺點。

在做這件事情的時候一定要很小心，確保：

1. 受測者涵蓋你的目標用戶區隔
2. 詢問的方式不帶引導性
3. 詳細記錄比較用戶的意圖以獲得最公正的信息。

02 六招低流量產品也適用的產品實驗設計方法

如果你的產品整體其實有些流量，但你只負責一部分的產品或注重某個國家或區域，這里提供六個步驟幫助你設計一個「測得出結果」的 A/B Test：

1. 找流量

哪里有流量就往哪里實驗！可以合并不同的用戶區隔增加樣本數，或者選擇在產品流量較大的頁面做實驗。（以電商為例，可以盡量在流量較多的如落地頁、搜索結果頁驗證你的產品假設，避開那些結算流程的末端）

2. 將統計功效（Statistical Power）納入優先級的考量

在排優先級時，選擇樣本數多、Base conversion 低、預估影響力大這些「能夠被 A/B Test 驗證的」功能?？梢岳镁€上的統計樣本計算機，先設定自己「最多可以接受實驗跑多久」的目標再反過來計算需要的樣本數。記得在做這件事情之前，要先向伙伴說明為何實驗很重要、為何統計顯著很重要等等，讓團隊都可以理解排序背后的意義。

3. 以創造更大效益為目標擴大改動規模

停止那些改一點按鈕顏色、改一點文字翻譯的小步快跑 A/B Test，以創造更大效益為目標，花時間去研究怎么開發中大型但有意義的改動。但同樣的這個做法風險也比較高，記得搭配扎實的事前準備與研究來使用。

4. 把時間和資源移到開發前的研究與早期驗證

既然數據還無法提供證據，那就用定性研究與反饋來了解用戶行為與動機，這些洞見同時也可以成為產品長大后很好的實驗素材。

5. 延長實驗時間

如果可以接受，也可以將實驗時間設定比較長，一樣可以用上面提過的樣本計算機得出合理 Runtime。但記得跑多久這件事一定要在實驗開跑前就規劃好，一旦確定，就算提早看到成效也不要把實驗提早結束，也不要為了看到結果就無限延長，因為那都很有可能是錯誤的結果。

6. 重新思考目標指標

如果 A/B Test 中的主指標一直不見效，有可能是因為指標本身很難撼動，可以試著找找其他較容易觀察成效的先行指標。但這件事情跟方法五一樣，也最好在實驗前就先規劃好，不然如果只是到處翻找顯著改善的數據指標，一樣很有可能是錯誤的。

03 結語

其實在不能做 A/B Test 的情況下，許多的替代方案都是結合定性研究、反饋收集來獲得決策需要的「證據」。

一個有品質的產品決策，最重要的就是有清晰的脈絡與有說服力的原因來告訴你的團隊、你的主管和你的用戶「為什么」這是個正確的決定，而這些原因都必須要被某種公正證據支撐著。PM 或設計師所要做的，其實也就是因應不同狀況、找到對的工具、收集足夠的信息來做合理決策。

就說這么多。