我們的 A/B 測試失敗了——失敗的測試教了我們什麼

產品團隊很愛講成功的 A/B 測試。這篇講一個失敗的——更準確地說，是一個「贏了表面指標、卻讓我們差點做錯決定」的測試。它教我們的東西，比任何一個成功案例都多。

假設：降低摩擦，會帶來更多紀錄

背景：在 Apexhone 記一筆決策，新增決策 的流程有幾個欄位——你在考慮的選項、各自的理由、你的把握度、預定的回顧時間。有些用戶反映「欄位有點多」。於是我們有了一個很標準的產品假設：摩擦是留存的敵人，把流程砍短，記錄的人會變多，留下來的人也會變多。

我們做了一個 B 版：「快速記錄」，只留兩個欄位——決定是什麼、一句話理由。把握度和回顧時間都拿掉。然後 A/B 對跑。

B 版「贏了」——表面上

結果一如預期：B 版的單筆記錄完成率明顯高於 A 版。記錄的決策筆數也漲了。如果我們只看這兩個指標，結論很清楚：B 版勝出，砍短流程，上線。

我們差一點就這樣做了。攔住我們的是第三個指標。

第三個指標：回顧完成率

B 版用戶記了更多決策，但他們回去 回顧那些決策 的比例，遠低於 A 版。差距大到不可能是雜訊。

我們去讀了資料，原因其實很清楚。被我們當成「摩擦」砍掉的那兩個欄位——把握度、回顧時間——根本不是摩擦，它們是這個產品運作的引擎。

「把握度」是事後回顧時的對帳基準：沒有當初的把握度，回顧就只剩「結果好不好」，沒什麼好對的。「回顧時間」是把你帶回來的鉤子：沒有它，這筆決策記完就沉入海底，不會有人提醒你回來看。B 版砍掉的不是摩擦，是「讓一筆紀錄之後還有意義」的那兩根支柱。

B 版讓人更容易「記下」一個決策，也讓那筆紀錄更不可能「被回頭看」。我們優化了入口，卻拆掉了出口。

真正的教訓：先確認你優化的指標是對的

這個失敗的測試，教訓不是「不要降低摩擦」。教訓是：在你優化任何一個指標之前，先確認那個指標真的代表你要的東西。我們一開始盯著「記錄完成率」，把它當成成功。但這個產品的成功從來不是「記了幾筆」，是「記了之後有沒有回去回顧、有沒有因此校準」。盯錯指標，你會非常有效率地往錯的方向跑。這跟我們 〈刪掉一個用戶很愛的功能〉 的教訓是同一個——參與度數字會騙人。

還有一個更細的點：有些「摩擦」是功能，不是缺陷。要求你寫下把握度，確實讓記錄變慢了一點，但那個慢是有產出的——它逼你把模糊的感覺變成一個數字，這正是 〈我們開始幫你算 Brier 分數〉 講的校準基礎。一個工具如果它的價值來自「逼你多想一步」，那「多想的那一步」就不能當摩擦砍掉。

所以最後我們沒有上線 B 版。我們做的是另一件事：保留全部欄位，但把它們的引導寫得更好、順序排得更順——降低「體感摩擦」，但不拿掉「有功能的摩擦」。這也是我們一貫的產品立場，寫在 〈設計一個不讓你感覺良好的 App〉。如果你還沒體驗完整的記錄流程，可以從 Pro 的決策回顧 看看那兩個「被我們留下來」的欄位，後來長出了什麼。