本篇談一個大家十分熟悉的技術——AB測試。所有有實際產品或運營經驗的同學對它都不陌生，然而，在實際運用中卻常常存在意識或決策上的明顯錯誤。

有四個問題，常常會存在判斷上的困難：

1. 到底什么要做AB測試？什么不要做？
2. AB測試時，我們應該如何判定什么數據是正確的觀察對象？
3. A和B本身只是兩個平級的分支，那么如果想要同時測試多個因素，尤其是互相重疊的因素（無法對等分為A、B、C、D測試組），那該怎么辦？
4. AB測試的結果真的像看起來那么正確嗎？

這幾個問題看起來似乎很簡單，然而，實際工作中我們恰恰常在這幾點上做出錯誤決策。下面讓我結合實戰案例上做一些探討：

一、AB測試做與不做的具體情況

01

我最初接觸AB測試時認為：如果想精確評估一個功能帶來的效果，或者衡量對比兩個決策因素（或者兩個設計、兩個選項……）孰優孰劣如何選擇，我們可以通過AB測試來實際看一下到底哪個更優。如果采用某個方案已經非?？隙?，那么AB測試并沒有太大必要。

然而，在實際工作中，我還是看到了非常多的例子，似乎已經非?？隙ǖ氖虑?，AB測試的結果卻給出了完全相反的答案。

下面我們看一個實際的例子：

作為綜合性電商，如何在顯示面積有限的移動端向消費者高效率展示海量商品，是個普遍的難題。

大多數情況下，會根據一級分類設計類目頻道，點進去是二級分類頻道，再點進去是三級分類頻道……這樣的結果，需要用戶走很深的層級才能看見具體的商品，不但“酒香巷子深”，而且每一次跳轉，都會導致流量大比例跳失。所以近年來電商產品普遍嘗試的一個趨勢是“做淺”。

我的團隊曾經針對“做淺”做過一個產品改造，在移動端首頁的所有類目頻道入口直接增加展示單品，以驅動商品曝光，帶來更多的商詳頁瀏覽量，并通過個性化算法向不同用戶推薦不同的活動和單品，以提升轉化率。如下圖，

首頁流量非常大，這樣的首頁商品曝光+個性化算法選品，我們認為必然能帶來商詳頁流量的明顯提升。這個項目如果是我以前負責本地電商產品時，可能會直接安排上線，因為主觀預期非常明確。

但是，公司有嚴格的規定，所有新功能上線都必須要經過Weblab的數據驗證。Weblab系統實際上就是一個AB測試的系統，可以輸入觀察的目標數據項，系統會用一段時間跑出結果，對比有新功能的分組（Treatment Group，簡稱T）和沒有新功能的分組（Control Group，簡稱C），直接體現目標數據項的增減情況。

經過四周的Weblab測試，數據結果表明，T與C相對比，商詳頁流量下降了1.32%?。?！

這是一個非常意外的結果，產品和BA團隊隨后立即進行了深入的專題數據分析。

請仔細觀察上圖，圖中每個“Grid”對應的是首頁各品類頻道入口對商詳頁的導流數據，在Weblab測試結果中，C的數據為左邊橙色柱，T的數據為右邊褐色柱。從左到右的每組柱體，代表一個品類頻道入口數據，在首頁自上而下排序。

從圖中我們可以看到：在第二、第三個欄目中（Grid-18，Grid-19），新版本帶給商詳頁的流量確實超越了老版本；但從第四個欄目（Grid-20）開始出現逆轉；越深的欄目，貢獻給商詳頁的流量下跌越多；最后計算總體數據，發現老版本的商詳頁導流能力更強！

產品分析的結論是：新版設計加大了單個品類頻道的入口高度，雖然單個品類頻道的商詳導流能力增強了；但在同樣的移動端屏數里，得到曝光的品類頻道入口減少了。由于移動端流量隨著屏數加深而迅速衰減，導致向用戶曝光的品類頻道減少，所以全局上商詳流量出現了下降。根據這個結果，最后技術團隊回滾了這個功能。

這個案例表明，很多主觀上看似明顯更好的設計，在數據結果上往往出人意料。

因此，如果條件具備的話，所有的新功能迭代都應當進行AB測試，并保持一個合理的時長，來驗證預期效果是否達到；尤其要謹慎的是，局部優化，是否在全局上反而得不償失。

多提一句，也許有產品同學會有疑問，做淺既然是正確的大趨勢，那么這個改造為什么失敗了？

主要是因為這個方式考慮不夠全面，如何正確地“做淺”不在本文范圍，后面談首頁和頻道頁設計的時候我們再深入探討。這里主要是通過這個案例說明，AB測試常常會否決想當然的推測。

02

進行AB測試時，我們可以多注意以下的問題，避免踩雷。

1. 進行局部AB測試

有時一個新功能至關重要，或者來自領導層的明確要求，不適合在全局只上一半，此時可以考慮進行局部AB測試。

例如：

把A和B分組從50:50調整成90:10（如果流量足夠大，甚至可以99:1），然后用那10%的局部測試的結果數據乘以9，來和那90%進行對比，得到結論。

要特別說明的一個誤區是——目前很多App是采用灰度發布的模式，慢慢把上線流量從5%提升到100%，這和AB測試是完全不同的策略。

灰度發布的目的是防止未知的錯誤影響全局，往往先從新疆西藏等小流量地區上線，沒問題再擴大到陜西湖南湖北，再沒問題則延伸到江浙滬京廣深等大流量區域，直至全局上線。每步推進往往只間隔幾個小時，最多一天。

而切分部分流量進行AB測試，則需要十分科學、均衡、對等、隨機地選取流量，并進行相對更為長期的測試（至少在2～4周），以取得足夠的結果樣本，提高結果的正確性。

2.?在A和B樣本選取的時候，需要對影響因素盡量保持完全對等

例如：

平臺的50%流量來自北京，50%流量來自上海，在做對比分組的時候，就不宜把北京作為A分組，把上海作為B分組；因為北京和上海的用戶，本身很可能就存在較大的特性差異。

此時最好通過系統隨機抽取樣本，讓各種影響因素在兩個樣本里均勻分布（例如IP地址最后一位為奇數的為A組，偶數的為B組），通過精心設計的對等性屏蔽所有除被測因素以外的影響因子。

3.?要注意用戶對新功能新用法有一個習慣培養過程

例如：

出于不加大首頁長度、犧牲下方欄目流量，以及在首頁展示更多單品的理由下，我們曾經把秒殺頻道在首頁展示的單品，由縱向平鋪改成橫向劃動。

當時的全局的AB測試證明這是一個失敗的嘗試；但時隔一年再次嘗試，卻取得了相反的結果！

通過分析，我們發現是在做AB測試時，有一批老用戶習慣了縱向劃動瀏覽秒殺欄目，不習慣新的交互方式，帶來了較差的預期效果，影響了整體數據。然而，對于新用戶來說，橫劃瀏覽是一個非常高效的方式（注意對橫劃的引導設計），而老用戶隨著時間推移也會接受這個新交互方式，此時效果就會體現出來。因此，對于這種高度受使用習慣影響的功能，應當把測試數據集限定在不受固有習慣影響的新用戶中，或把測試周期拉到足夠長。

4.?戰略性的新功能并不適用于AB測試

戰略往往專注于未來，但AB測試只反應當前。新業務功能開發出來時，因為某些環境支持因素、用戶使用習慣、或配套條件還不完全具備，數據上可能居于劣勢。

例如：

在商詳頁商品圖首次使用視頻時，可能由于4G網絡還不夠普及，或者視頻素材制作水平還不夠規范，導致視頻商詳圖片帶來的效果并不理想。但只要相信這是正確的方向，就應該堅持下去。

5. 避免投入的浪費

有時大家可能會有這樣的矛盾：一個功能如果沒做，是沒法做AB測試的；如果做了，那么研發成本都付出了，不上線多可惜。再或者，兩個方案不知道哪個好，如果不都開發出來，是無法進行AB測試的；如果都開發了，那么付出了雙倍的成本，如何避免投入的浪費？

其實這類問題并沒有標準答案。本土互聯網公司講究“試錯”，講究速度，不管對錯，做了再說，總有碰對的。而亞馬遜這樣的國際巨頭，則極其嚴謹，寧可不做，也不做錯誤的。

以前我在1號店，一個迭代兩周就平均上線60多個功能，看到數據變化了，卻沒有準確地知道誰帶來了多少增長或導致了多少下跌，懵懵懂懂往前狂奔。

而亞馬遜則十分嚴謹，每個功能必須做AB測試，達到了確信的提升才允許上線；一個項目上線前會不斷被AB測試專家、用戶體驗專家、技術團隊、業務團隊所挑戰。

狂奔，有時候其實只是在兜圈子；而太謹慎，則可能輸了速度，win the battle lose the war。

在我看，沒什么對錯，要敢賭；但出手前要審慎地推敲，不打無把握的仗，事后則要想辦法清晰準確地知道每件事的成敗得失。

帶著這個思路回看前面的問題，我的觀點是：如果做了之后證明效果不佳或者平平，不上更好，止損好過進一步損失，也減少折騰用戶。付出的都是沉沒成本，不能因為舍不得而影響未來決策（是不是覺得心有點痛，做都做了，不上好可惜～）。

兩個方案做哪個好，仔細分析下，做更有信心的，賭一把。如果確實差不多又是重大功能，就都做，根據AB測試取好的，因為A和B的價值差異，可能都超過成本本身。但如果這個功能不太重要，那都別做了，把時間省下來做更重要但事。半重要不重要的，拋個硬幣吧。

二、AB測試時，如何判定正確觀察指標？

AB測試之前，大家都會選定若干關鍵指標作為核心被測指標，來對比兩個測試集之間的效果差異。這里常見的一個錯誤是，所選擇的判定指標較為片面，不能正確全面體現方案效果，得出錯誤結論。

下面我們來看一個實際案例：

在中國的電商應用中，大家可能習慣把購物車當做收藏夾，把有可能會購買的商品放進購物車，在最后結算時勾選本次要買的商品進入結算流程，剩下的則繼續收藏在購物車里，留在以后下單。真正的收藏夾反而使用較少，或用來收藏店鋪或重度復購商品。

某亞的購物車邏輯有所不同。它更類似用戶在超市中實際推的購物車；在最后結算時，必須要從購物車中移除所有本次不購買的商品，然后把購物車所有商品一起結算。如果不想直接刪除，可以移入收藏夾。

前者在中國用戶用得很好，而后者則在全世界用戶那里用得很好，除了中國。兩者可能沒有絕對的好壞之分，都是用戶習慣培養的問題，只是兩邊培養的用戶習慣不太一樣。

那么問題來了，某亞中國app該怎么辦？我看到很多用戶反饋，某亞購物車和大家習慣的不一樣，會買錯東西，很不方便，等等。

這個問題由來已久，兩年前某亞購物車團隊也曾上線過類似中國購物車的部分結算版本（稱為Partial Checkout）；但經過AB測試驗證，Partial Checkout版本以銷售額作為對比指標，在為期一個月的AB測試中輸給了原來的版本，因此該版本最終被回滾。

這是一個有些意外的結果，我們做了跟進分析，得到如下結論：

1. 用戶習慣尚未形成時，剛接觸全部結算版本購物車的新用戶，有可能把一些本來沒打算當次購買的商品納入訂單，也就是說，一不小心多買了。如果只是簡單地以銷售額來衡量，全部結算的老版本反而占到了優勢。

2. 一不小心多買了的用戶，事后發現時有一部分人會選擇退貨，由此造成了退貨率的提升。同時，用戶滿意度會受到影響。但因為不是所有人都會退貨，老版本銷售額顯得更高。

3. 部分結算版本購物車，用戶可以保留不立即結算的商品，因此這些在購物車中保留的商品具有未來潛在的銷售機會。而對于全部結算版本購物車，數據表明：大約有40%的用戶會把不結算商品移入收藏夾，其余用戶則會直接刪除。這一定程度地損失了這些商品的后續銷售機會。然而，后續銷售會有一個時間后置，未來的損失不會在為期一個月的AB測試階段被捕獲。

通過以上分析我們看到，這個購物車的改動直接影響到四個因素：直接銷售、未來潛在銷售、退貨率、用戶滿意度。

此外，由于操作步驟更加復雜（必須刪除不結算商品），導致結算步驟可能有更高的跳失率。在前次的AB測試中，測試指標只考慮了直接銷售因素，由此得出了可能比較片面的結論。

不過想要全面衡量上述指標，難點在于：

1. 未來潛在銷售無法拉取未來數據，除非做一個歷時較長的AB測試，但即使時長覆蓋多個用戶平均下單周期，也無法準確衡量全部未來銷售影響。下篇文章我會介紹一個非常有價值的方法，來計算未來價值。

2. 用戶滿意度是一個綜合性指標，同時受到非常多因素的影響，此外它的獲取方式也很不同于AB測試的功能投放，較難直接剝離出來納入AB測試結果的綜合分析。

在綜合考量后，產品團隊再次推動部分結算版本的購物車，并在新一輪的考量更全面的指標后，該版本贏得了AB測試，獲得了0.34%的綜合銷售提升和0.66%的下單頻度提升，最終得以成功上線。

以上案例說明，在進行AB測試時應當根據被測功能的綜合價值，對考量指標做一個全面分析，考慮多維度價值以及中長期影響，做出一個更為全面和長遠的決策。

在后續的實戰中，我們也把觀測指標做出了更為復雜的定義，分為核心判定指標，輔助觀察指標，以及否決指標。

例如：導購功能做AB測試時，以商詳頁瀏覽數作為核心判定指標，以轉化率、用戶獲取能力作為輔助觀察指標，以銷售額作為否決指標。只要商詳頁瀏覽數有明顯的增長，或者轉化率、用戶獲取數有較好增長但商詳頁瀏覽數不為負，就可以作為上線候選，最后校驗銷售額；如果銷售額下降，就一票否決，否則可以全面上線。

三、如何同時測試多個相互疊加的因素？

有時我們想要同時測試多個因素，或者測試本身受到很多因素的同時影響，比如，我曾有一篇文章想要測試一下“標題黨”玩兒法帶來的閱讀量波動。閱讀量雖然與標題強相關，但也與我的發文日期在工作日還是周末、發文時間點是早晨還是傍晚都有較大關系。最終那篇“標題黨”文章是在周日早上8點左右發出，最后我觀察到有較大的閱讀量提升。

那么問題來了，這個提升，到底是因為標題吸引人帶來的？還是因為周日大家有閑暇時間閱讀帶來的？還是因為早上是個黃金時間帶來的？

在這個例子里，上述三個主要因素共同構成影響，因此如果想要做最客觀的測試，就應該對任何一個因素選兩個差異最大的情況，進行排列組合，3^2=8，因此把測試集8等分，做等量的投放，由此可以看到每個因素帶來的影響量。

人工做這樣的流量切分和差異化投放比較難，最好能夠有系統層面的支持，把多個要做AB測試的功能獨立疊加上去，并且制定每個AB測試的時間段，讓系統在時間范圍內自動對流量做隨機切分和功能投放，以獲取相對準確對結果。

有些大型公司的系統很好地支持多參數AB測試，但如果沒有這樣的自動測試平臺，那么通過人工方式選取流量和投放也是可行的，但一定要垂直正交地做流量拆分，讓除被測因素以外的其它因素都互不干擾。

換句話說，在兩個被測分支A和B上，除單一的測試因素外，所有其它因素都完全對等。

四、AB測試結果真的正確嗎？

假設我們在做一個轉化效果的功能測試，當歷時四周的AB測試終于完成了，對比兩邊數據，發現投放了設計一的A分支比投放了設計二的B分支多銷售了1%。那么，我們可以結論設計一的轉化會更優于設計二嗎？

您猜對了，不能！很多原因都會造成AB測試的錯誤。

上述案例我們很容易作出結論——設計一更好。

但當產品經理深入觀察數據時，比如拆分到具體每一天去看數據趨勢，也許會發現大部分的日子里，版本二表現更加優異；只是有少數日子，版本一的樣本中出現了大訂單（偶然事件），極大影響了總體數據，最后造成了版本一勝出。這樣我們不難推測，如果除去這類偶然事件，版本二實際上更好。

此類偶然因素本身不可避免，但它會對結果造成致命的影響，導致AB測試的結果出現偏差。消除的方法有多種：

1. 取更大的數據樣本，或者把測試運行更長的時間。通過數據結果樣本的大幅增加來減少偶然因素帶來的影響。

2. 設置置信閾值，除去超出置信閾值的數據。例如，一個生鮮電商平臺的訂單通常在幾十到幾百元，那么萬元以上的大單，往往十分偶然和蹊蹺，或者不出自普通消費者，甚至是刷單結果，應當從結果中除去。

3.? 對測試結果數據進行對數處理（取log）。這是一種消除隨機結果中的“毛刺”，把結果波動變得平滑，但又可以保留結果的波動特性的有效數學手段。對該方法感興趣對朋友可以進一步看一下相關數學或者信號處理理論。

除了對上述偶然性的理解和處理，另外有一個因素也是在做AB測試的流量投放測試中必須要慎重考慮的，那就是投放對象和被測因素的相關性。

例如：運營測“排行榜”頻道的入口文案效果，如果投放的人群是純精準型人群（典型行為是，絕大多數瀏覽的商品是通過搜索到達的），由于這些人群基本不會瀏覽和使用“排行榜”頻道，那測試結果其實都是隨機噪聲，并沒有實際意義。

在亞馬遜的系統中有一個非常實用的概念，就是對于每一個AB測試結果，系統都會給出一個置信度數值，稱之為P-Value。這個值代表著結果的不確定性。

例如，如果P-Value=0.05，意味著如果系統說A比B好，那么只有5%的情況會出現相反的結果。對于P-Value產生影響的主要是：

1. 數據樣本不足；
2. 結果中的大偶然因素；
3. A和B的對比因素（即被測因素）對于目標指標的影響差異過于微小。

雖然大家所使用的平臺未必有類似的功能，但帶著統計學觀點進行AB測試的設計和結果觀察，會對透徹理解測試結果和作出正確決策非常有幫助。

最后要說的一點是，數據是用來驗證猜想，反映客觀事實的。但數據只是工具，也會被人斷章取義。我們有時會看到為了讓結果看起來很美而做AB測試造假的項目。

例如：某功能對10%的用戶有正向結果，對90%的用戶有負面影響，于是這10%的用戶被刻意選擇作為測試范圍，然后用測試數據歡呼該功能具有“高價值”（當然也有在測試指標的選取、測試時長定義上玩兒花樣）。這背后，也需要職業操守，領導者最好能具備一定的AB測試知識，才不容易被蒙蔽。

到這里，我對AB測試的實戰經驗分享告一段落。做一個簡單總結：

1. 對產品或運營方案的優劣不要想當然，有條件的話盡量用AB測試做客觀的驗證。
2. 充分考慮用戶習慣有個變化過程，對升級優化的功能，盡量在還沒有形成習慣的新用戶身上進行投放測試。
3. 要充分意識到AB測試的偶然性，盡量保證用足夠大的數據樣本和合理時長的測試來取得客觀的結果。同時要帶著“置信度”概念看待測試結果。
4. 在測試變量的投放中，要做到除了單一被測變量，在AB數據集的所有其它因素都完全對等。
5. 可以使用閾值篩查，取對數做平滑處理等方法消除測試結果“毛刺”。
6. 充分考慮對被測指標可能存在多個主要影響因素，盡量做最全面的測試來作出全局正確的判定。也可以把多個數據指標按主、輔、否決器組合使用。

作者：徐霄鵬，微信公眾號：產品遇上運營。亞馬遜高級總監，產品、中央運營及增長團隊負責人，前京東、攜程高級產品總監。精通前臺產品、運營及用戶增長等領域。

本文由@產品遇上運營 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自@Unsplash, 基于CC0協議