一、A/B測試是啥

隨著移動網際網路流量紅利、人口紅利的逐漸衰退，越來越多的產品運營開始關注資料驅動的精細化運營方法，期望透過精細化運營在一片紅海中繼續獲得確定的使用者增長，而A/B測試就是一種有效的精細化運營手段。

簡單來說，A/B測試是一種用於提升App/H5/小程式產品轉化率、最佳化獲客成本的資料決策方法。在對產品進行A/B測試時，我們可以為同一個最佳化目標（例如最佳化購買轉化率）制定兩個方案（比如兩個頁面），讓一部分使用者使用 A 方案，同時另一部分使用者使用 B 方案，統計並對比不同方案的轉化率、點選量、留存率等指標，以判斷不同方案的優劣並進行決策，從而提升轉化率。

如果不使用A/B測試，而是根據經驗，直接上一個落地頁呢？在回答這個問題之前，我們先來看看我們在做產品決策時，常面臨的一些挑戰：

產品最佳化依靠經驗主義，不能保證新的產品版本一定會有業績提升重大產品功能很難決策，不確定哪個方案效果最優“後驗”成本高，如果改版失敗，業績損失無法挽回

三、目前為何應用太少的原因

概念需要時間沉澱，才能轉成實踐。

「駭客增長」的精髓就是A/B測試，但經過調研，真正組建增長團隊的並不是特別多，目前還在研究概念階段。2011年，這一概念從矽谷發出，2015年國內第一本「駭客增長」圖書釋出，到現在才逐漸有落地的動作。這個時間週期，是需要考慮在內的。從概念到落地，需要沉澱吸收，也需要市場教育。

2. 團隊文化建設不足，過於追求快速發版，目前更側重於後驗。

一般A/B測試，建議開展2周左右，但目前一般公司App開發，以1個月（4~5周）為一個小版本週期，主要工作量聚焦在設計、開發，留給測試找Bug的時間本來不多。限於老闆們的發版需求，用於A/B測試的時間很少，始終過於追求發版的狀態。

我們經常開玩笑說，BDD而不是TDD，就是Boss Driven Development——老闆驅動的開發模式。老闆們經常說，「小步快跑」、「快速迭代」，但結果一般就是功能越堆越多，先做出來再說。

程式碼層面，後面重構都變得困難，產品更不用說早已痛不欲生，運營也苦不堪言！上了新功能不推吧會讓老闆覺得自己不行，但推吧也違心。比較好的情況是，功能用的少的模組，可能後續版本入口就慢慢隱藏直至砍掉，追溯整個過程，實際上浪費了嚴重人力物力心力。

3. 目前缺乏好用的工具。

隨著「增長駭客」概念的普及，大陸出現了一波資料驅動增長的公司，當然目前產品主要集中在後驗階段，但A/B測試則是處於前驗階段。如果透過A/B測試，某個版本能更加提升留存等資料指標，可直接釋出使用。

很多公司自研工具，但這涉及到統計、流量分配排程、後臺資料處理能力，搞一個新工具，陣勢和自己做一款新產品差不多，這並不誇張。買別人的，怎麼證明技術團隊的價值呢？——很多技術團隊輔助決策的時候，會抱著這樣的想法。在業務和技術本身做取捨，寧可吭哧一陣搞出不好用的工具，運營、產品體驗很差，大家痛苦地使用一兩遍，後面也會放棄。即使這樣，也很難痛下決心直接使用第三方SaaS服務。怎麼還能鼓勵更多人落地A/B測試呢？

不是很少做，而是其中很多誤區。

A/B 測試是一項很有趣的測試內容，使用者可以透過優質的工具去完成產品中的 A/B 測試。但其實，A/B 測試並不僅僅是建立一個測試，很多公司在使用 A/B 測試時都存在一定的誤區，都在不經意間浪費著時間和金錢且不自知。下面，本文將為大家梳理一些運用 A/B 測試時常見的誤區：

太早停止 A/B 測試

如果樣本量足夠大，統計顯著性是版本 A 優於版本 B 的最好證據，50% 的統計顯著性代表一種隨機的結果。如果你只要求有 50% 的統計顯著性，那麼你可能要考慮離職了，因為其實這個數字達到 75% 也不能說明什麼。任何一個經驗豐富的測試人員都有過這樣的經歷，你透過 A/B 測試去檢測你的產品功能，最終將一個置信度達到 80% 的產品推向各大市場，但最終發現，市場卻並不買賬。於是你想，那下次把數字達到 90% 怎麼樣？這樣就會很好了吧？其實比達到 90% 更重要的是，你要找到其中的真相。 真相>勝利 作為一個專業的職場人士，你的工作就是找出真相。你必須先把自我放在一邊，執著於你的假設或設計是人之常情，如果當你的假設沒有出現顯著的差異性時，這可能會對你造成很嚴重的打擊。真理高於一切，否則一切都失去了意義。

這裡有一個常見的場景，即使對於經常進行 A/B 測試的公司也是如此，公司進行一個又一個的測試，持續了 12 個月，好不容易挑選出“獲勝者”，然後將它們推出市場。結果一年後發現，他們網站的轉化率和剛開始時一樣……

為什麼？基本是因為測試停止得太早或樣本量太小。這裡有一個關於何時停止 A/B 測試解釋，簡而言之需要滿足這三個條件，才能說明測試已經完成：

1. 足夠的樣本大小。實驗要有足夠的被試參與，你需要為你的 A/B 測試預先估算出足夠的樣本量。

2. 要執行多個銷售週期(通常為 2-4 周)。如果你只是在幾天內就停止測試（或者在達到所需的樣本量之後就停止），那麼你獲得的這個樣本結果，並不具有代表性。

3. 統計學的顯著性至少要達到 95%（p≤0.05）。值得注意的是，p 值沒有辦法告訴我們 B 比 A 的方案好。

這裡有一個經典的例子來說明我的觀點，下表為開始測試兩天後的結果：

我構建的新版本損失慘重，我構建的版本並沒有太大的優勢，而我的客戶也已經開始準備停用這個方案。但是，由於樣本量太小（每次變化只有 100 多次訪問），透過我的堅持不懈，這是 10 天后的結果：

你沒看錯，我製造的版本現在以 95％ 的置信率獲勝。

有些A / B測試結束得過早，這就需要我們仔細檢查各種資料。而最糟糕的事情就是，因為不準確的資料，讓你損失了大量的時間與金錢。 需要多大的樣本量？

透過上面的介紹，我們都不希望根據較小的樣本量得出結論。理想的狀態下，一個好的測試版本最好能發生至少 350-400 次轉換資料。但是，這個數字不是定值。我們不要被一個號碼困住，因為我們手中的是科學，而不是魔術。所以，你一定要提前估算出測試所需要的樣本量。那麼即使這樣做了，但置信度還是低於 95％ 怎麼辦？那麼可以從細分領域下手，但你仍需要為每個測試的細節提供足夠的樣本量。無論如何，你都需要不斷修改你的假設並進行新的測試。

測試的單位不是“周”

假設你有一個高流量網站。你在三天內實現了 98％ 的置信度並且每次都發生了至少 350 次的轉換資料。這樣能算完成了測試嗎？不。我們需要排除週期性因素並測試整整一週。如果你從上週一開始測試，那麼這個測試需要在下週一停止。為什麼？因為你的轉化率可能會因“今天是星期幾”而有很大差異。如果你一次不測試整整一週，那麼你的結果就會出現偏差。 所以，你需要以“周”為單位，在你的網站上執行“ 每日轉化次數”的報告，觀察到底能產生多少波動。下面是一個例子：

你看到上表中的內容了嗎？星期四的收入比星期六和星期日的總和還多出 2 倍，星期四的轉換率幾乎是星期六的 2 倍。如果我們沒有以“周”為單位進行測試，那麼結果將是不準確的，所以，必須開始一次執行七天的測試。如果在這七天內沒有出現差異顯著的結果，則再執行七天。如果 14 天都沒有達到，那麼就執行到第 21 天。多數情況下，你需要至少執行兩週的測試（我的個人最低時間是四周，因為兩週通常是不準確的），然後，如果你需要延長測試時間，則應用七天規則逐步疊加。 注意外部因素 如果你在雙十一等一些購物季獲得了良好的測試結果，那麼你一定要在購物季結束後再次進行重複的測試。另外，如果你的公司鋪設了一些電視廣告或者其他大型活動，都可能會影響你的測試結果。你必須要了解你的公司正在做什麼，因為外部因素會影響到你的測試結果。

沒有足夠的流量也進行 A/B 測試

如果你每月只能完成一次或兩次銷售，然後進行測試，結果顯示 B 方案比 A 方案的轉化率高 15%，這樣的結果準確嗎？當然不。 許多人都喜歡用 A / B 測試來驗證假設，但流量較小的情況下，即使版本 B 的效果再好，也可能需要數月才能達到統計顯著性。

不基於假設就進行測試

我喜歡義大利麵，但我對義大利麵條柔韌度的測試卻沒多大興趣，比如將它扔在牆上，看它是否粘住牆壁？這其實是一種隨意的測試想法，而測試這種隨機想法需要付出巨大代價，它會浪費你寶貴的時間和流量，所以永遠不要那樣做。你需要有一個假設。假設的提出要根據有限的證據，這個證據可以透過實驗去被證明，並且作為一個新的研究起點。如果你在沒有明確假設的情況下進行 A/B 測試，然後發現 B 方案的轉化率高了 15％，可是你從中學到了什麼？什麼沒有。我們需要了解我們的受眾，獲得合理的假設，這將有助於我們更好地改進貼合實際的測試。

不利用大資料分析平臺

測試的平均值往往包含著謊言。如果 A 方案比 B 方案的轉化率高出 10％，但也並不能代表全部。你需要將其中的指標再次進行分割測試，去分析其中的各項細分指標。你可以使用一些優質的大資料分析工具，利用各種分析模型，對資料進行細緻地分析和處理。

為了不值得的問題進行測試

你測試過使用者喜歡什麼顏色，對嗎？請趕快停止吧。世界上哪裡有最好的顏色，因為顏色始終與視覺層次結構有關。當然，你可以在網上找到有人透過測試顏色從而獲得收益，但這些結果很多都是顯而易見的，所以，不要把時間浪費在這些測試上。

編譯過程有所刪減