增長黑客必看的11個AB測試問答

來自專欄 A/B測試那些事

AB測試是一種用數據驅動產品迭代的解決方案，使用AB測試驅動產品業績增長的方法，深受Google，Facebook，微軟，百度，騰訊，阿里等眾多公司青睞。Testin雲測是業界第一家提供全生命周期AB測試服務的企業，對應用發布前和發布後的產品實驗需求提供了完整的解決方案，已幫助數千家客戶有效提升了Web/H5、Android、iOS、小程序等應用的轉化率、留存率、點擊量、成交額等核心業務指標。

2017年12月28日，Testin 副總裁、AB 測試首席顧問陳冠誠在Gitchat上為大家分享了如何用 AB 測試驅動產品增長的心得體會。

以下為整理後的訪談內容——

問題1：AB 測試如何與版本管理結合，比如 Git？它是通過開啟多個分支來進行的嗎，能否同時灰度多個功能？只有一台伺服器能做灰度測試嗎，是否每進行一個 AB 測試就需要一台伺服器？

答：我將這個問題拆成幾個部分來回答。

一個基本的 AB 測試系統，有兩個核心模塊：分流系統和數據統計系統。AB 測試系統當然可以跟 Git 這樣的版本管理系統結合。

舉例，如果是原始版本頁面的後端介面基於 Http 協議，新版本的後端介面基於 Https 協議，兩個版本在不同的代碼分支里，分別進行部署之後，要利用 AB 測試系統的分流模塊，將一定比例的用戶分流到新介面進行灰度測試，同時其他用戶分流到老介面。

在此過程中通過分流系統完成新老介面的用戶流量分配以及灰度測試。

利用 AB 測試系統同時灰度多個功能也是可以的。如果要進行灰度測試的功能相互獨立，只需要同時為不同的功能進行用戶分流即可。

只有一台伺服器也能做灰度測試，例如需要灰度測試的新老介面可以同時部署在同一台伺服器上，再通過用戶分流進行灰度測試。

同樣，並不是每進行一個 AB 測試就需要一台伺服器，具體需要多少伺服器資源，取決於進行灰度測試的應用伺服器的負載壓力等其他情況。

問題2：自建 AB 測試工具在人力、資金、時間等方面大概需要多少成本，可以從哪些方面入手？

答：自建 AB 測試工具方面需要多少成本，給大家一個參考：BAT 這種量級的公司，從零開始做一個通用的 AB 測試系統，需要大概 8-10 位工程師做 0.5-1 年的時間才能出一個基本的、可用的系統。

當然，如果僅僅只是實現一個最基本的 AB 測試系統，例如最基本的分流功能和最基本的統計功能，耗費時間會短一些。

僅就分流這個功能模塊來說，最基本的分流方式（例如基於 client id、cooike 做隨機分流）在一些場景下其實是不太能滿足需求的，例如他們不能保證唯一性、相似性。

唯一性：在流量分配不變的情況下，同一個用戶每一次重新訪問這個 app 或者打開這個網頁被分配的版本應該前後一致。不能今天登陸 app 分到版本 A，明天登登錄的時候就跳到版本 B 了。版本前後不一致會導致實驗結果不可信，因為引入了額外的干擾因素。

相似性：分流後的不同用戶群體的整體特徵相似。例如不能 A 組人群中 iPhone7 用戶特別多，而 B 組人群中 iPhone8 用戶特別多，如果人群特徵不相似，也會干擾實驗結果的準確性。

統計模塊也是類似，除了最基本的轉化率、點擊量等指標之外，一個合格的 AB 測試系統最基本的指標還應該包括置信區間、p-value、統計功效等。

如果你對實現一個 AB 測試系統感興趣，可以參考 2 篇論文。分別是 Google 的《Overlapping Experiment Infrastructure: More, Better, Faster Experimentation》和 Facebook 的《Designing and Deploying Online Field Experiments》。

問題3：使用TestinData.AI提供的AB測試系統，在人力、資金、時間的成本是怎樣的？

答： TestinData.AI是一個第三方的工具，所提供的 AB 測試支持 SaaS 交付和私有化部署交付兩種方式。以 SaaS 交付為例，如果選擇直接使用 TestinData.AI 的 AB 測試系統，我們就不需要再去管分流、統計、可視化編輯等功能該怎麼實現，而且直接用就好了。

最簡單的情況下，只需要一個產品經理和一個開發，就可以每周跑幾十上百個 AB 測試了。

這也是像 TestinData.AI 這樣的第三方 AB 測試工具最大的價值：開箱即用，把注意力放在業務如何開展 AB 測試和如何提高轉化率上面，而不是費力氣搭建工具。

對我們產品感興趣的朋友，可以直接訪問 http://ab.testin.cn 申請試用。

問題4：做 AB 測試是否有建議的時長？假如一個選擇必須在 3 天內做出，是不是意味著沒時間做 AB 測試了？如果強行做測試，是否會因為測試時間太短而造成結果有偏向？

答：一般來說，建議一個實驗最少運行一周，這樣能覆蓋工作日和周末的場景。一個實驗周期從一周到一個月是比較常見的。

如果一個選擇必須在 3 天內做出，其實也可以做 AB 測試。這個時候，需要注意的就是：

1. 參與測試的樣本量是否夠；

2. 得出的統計結果的置信區間、統計功效、統計顯著性等指標是否證明新版本跟老版本之間存在顯著的統計學差異；

3. 因為這個結論是 3 天之內得出的，它在放到其他時間段時，是否會因為時間因素（例如假期等）而產生干擾？

例如電商秒殺活動，要做兩個不同的廣告物料，不確定哪個版本效果好，所以做了一個 AB 測試，但是必須一天就出結論，因為這個活動本身只持續 3 天，就是類似你說的情況。

此外，遇到這種情況，我們推薦使用TestinData.AI的智能優化功能，放棄傳統AB測試，直接優化這3天的整體轉化率。該功能基於強化學習的智能優化引擎，實時持續動態分析不同產品版本轉化率數據，並進行智能流量調節，無需人工干預，即可自動提升轉化率。

問題5：微軟 Bing 搜索引擎從 08 年的每周 20-30 個到 15 年之後的每周 400 多個，很明顯他們很看重 AB 測試的重要性，請問 AB 測試數量增長的過程中，有沒有什麼是需要額外注意的問題？如何平穩過渡？

答：這個問題，我需要拿出一個數據和大家分享：

這張圖裡面的 4 個階段，就是一個企業內部 AB 測試系統從起步到成熟所經歷的階段。簡單來說，從組織架構、AB測試系統的技術架構、實驗評價體系都會經歷很多發展和變化，具體細節大家可以參考截圖裡提到的點。

還是一句話，羅馬不是一天建成的，像 Bing 這樣從 08 年到 15 年，7 年的時間，又有足夠的資源，業務也在穩定發展，才完整實現了從 0 到 100 的過程。

其實我們在跟很多企業合作的過程中發現，很多公司的產品運營同學都聽過 AB 測試，但是沒有實際動手做過，不過他們又很清楚 AB 測試的價值，所以選擇跟 Testin 合作，快速地將 AB 測試在公司內部推進起來。

問題6：對同樣兩個頁面做 AB 測試，運行 1 次就能得出結果，還是需要運行 10 次甚至 100 次，這取決於什麼？如果運行 100 次中只有 1 次說明 A 是最佳選擇，99 次都說明 B 是最佳選擇，這時是否說明 B 是當下的最佳選擇？

答：一般來說，如果你有一個靠譜的 AB 測試系統的話，只要運行一次 AB 測試就能對兩個頁面的轉化率優劣做一個結論了。

兩個頁面的轉化率的優劣取決於 AB 測試的數據。這裡面需要牽涉到一些統計學的概念，我給大家舉一個例子。

假設我們對兩個頁面進行 AB 測試，頁面 A 用了 5% 的真實用戶流量參與了實驗，它的轉化率是 6.9%，頁面 B 也用了 5% 的真實用戶流量參與了實驗，測試出的轉化率是 7.2%，那麼我們知道頁面 B 的轉化率比頁面 A 的轉化率提升了 4.17%。

但是，這百分之 4 點幾的提升，只是在兩個版本各 5%、共 10% 的用戶測試流量下得出的結論，它是否足夠可信呢？這就需要我們拿到 95% 置信區間、統計功效、統計顯著性等數據了。

這些數據的概念我就不在這裡詳細解釋了，我還是拿一個樣例數據來給大家解釋下。

例如，還是在前面那個例子中，頁面 B 在 5% 測試人群中轉化率是 7.2%，它的 95% 置信區間是 [+1.7%, 6.6%]，那麼說明頁面 B 如果推廣給全部用戶之後，95% 的概率下，至少會比頁面 A 提升 1.7%，至多會比頁面 A 提升 6.6%。

基於這個統計數據，我們有理由相信，頁面 B 如果真的全量上線後，確實大概率下會比頁面 A 的轉化率更好，這也是 AB 測試基於統計演算法去做決策的理論依據所在。

相反，如果頁面 B 的 95% 置信區間是 [-10.4%, 24.8%]，那說明頁面 B 如果推廣給全體用戶，不一定會比頁面 A 的轉化率更高，因為他可能出現轉化率下降 10.4%。

同樣，一個靠譜的 AB 測試系統，除了 95% 置信區間之外，還會提供 p-value、power 等統計相關的數據結果，它們都是用來幫助使用者分析實驗結論是否 「靠譜」 用的。

問題7：就落地頁而言，如果一個頁面在原版本的基礎上改動了多處，既改了顏色又改了文案，改了位置還改了背景圖，變得大相徑庭，這隻叫做兩個方案 PK 而不是 AB 測試了嗎？

答：這也是 AB 測試，叫做多變數測試。所謂多變數測試，是相對於單變數測試而言的。單變數測試的情況下，不同版本之間只有一個變數，例如按鈕的顏色。

如果不同版本直接有多處變數不同，就像你說的（一個頁面在原版本的基礎上改動了多處，既改了顏色又改了文案，改了位置還改了背景圖，變得大相徑庭），那就是多變數測試。

單變數測試最大的好處是可以做歸因分析。因為不同版本之間，只有一個變數是變化的，那麼不同版本轉化率等指標的優劣，可以歸因到這個變數上去。

而多變數的情況下，雖然可以比較出不同版本的優劣，但是不能直接將版本的優劣歸因到某個單一變數上去，因為可能是多個變數綜合影響才導致指標的變化。

在實際應用中，之所以會要做多變數測試，是因為大家想儘快實現產品的優化、以提升轉化率等核心業績指標。

因為多變數雖然不能歸因到具體是因為哪個改動造成了轉化率的提升，但是因為在一個測試周期里，就對多個變數進行了對比測試，所以可以達到儘快實現轉化率提升的目的。

問題8：多變數測試中，如果想確定是改了哪個真正起效了，是否需要進行更多的 AB 測試？

答：是的，如果你需要確定到底是哪個變數造成了轉化率的變化，那麼就需要再做更多的測試。

當然，實際場景中，可能沒必要去做，因為時間永遠是有限的。如果一個新版本已經提升了 15% 的轉化率，下一次迭代就會基於這個版本再去做優化了。

問題9：一個電商類型的互聯網項目，大概用戶量到什麼樣的規模之上適合用 AB 測試？

答：一般來說，如果每個實驗版本的用戶量可以在 1000 人以上，就可以嘗試 AB 測試了。具體每個實驗需要多少樣本量，Testin 專門有樣本量計算器來幫大家進行計算。

問題10：同一個站點有多個 AB 測試時，一個用戶是否會同時分流到多個功能點上？

答：這取決於分流機制是怎麼設計的。如果是簡單的基於用戶 id 進行分流的話，不同功能點的 AB 測試分別佔用了不同的用戶 id 群，那麼就不會出現一個用戶同時分流到多個功能的 test 的情況。

如果是像 Testin 這樣擁有分層分流機制的 AB 測試系統，如果兩個功能點的實驗分別處在不同的用戶流量層，是有可能出現一個用戶同時分到不同功能點的 AB 測試的情況的。

問題11：挑選分流用戶的邏輯和維度一般有哪些？

答：常見的設備標籤、用戶的業務標籤都可以拿來做分流。例如，機型、操作系統、語言、版本號等等。

如果做定向分流實驗，例如只對 iPhone8 的一線城市的 VIP 用戶做實驗，那就同時需要手機的設備標籤和用戶的業務標籤了。

AB測試本質上是個分離式組間實驗，以前進行AB測試的技術成本和資源成本相對較高，但現在一系列專業的實驗工具的出現，AB測試已越來越成為網站、App優化常用的方法。你可以將你設計的諸多版本都丟到TestinData.AI的AB測試系統上去，一個個測試他們的轉化能力。

不過，除了傳統AB測試之外，還有一個更高效的辦法：用TestinData.AI的智能流量調節引擎，根據轉化率自動變更流量分配、高效執行智能選優。

TestinData.AI 簡介

TestinData.AI致力於應用智能，成為產品經理的外腦，讓閱讀、資訊、知識、工具類App具備個性化智能，讓金融、電商、學習、旅行類等商業App具備商業智能，通過機器學習專利引擎對應用(HTML5、移動頁面、小程序、快應用、原生App、物聯網二維碼應用)實時自動優化，使產品、運營和市場人員能夠持續、高效提升轉化率、ROI和關鍵經營指標，預測客戶的潛意識需求、並即時傳遞給他們，從而推動可持續進化的商業效益及品牌忠誠度。

TestinData.AI具備實時、持續、智能提升轉化率的能力，驅動用戶增長，在支持智能優化的同時、也支持傳統的AB測試，並提供可視化編輯、科學流量分割和專業統計等功能，可以進行私有化部署。

還在苦於無法為落地頁的轉化帶來增長嗎？

還在對banner的優化迭代束手無策嗎？

還在尋找一個可靠的增長工具嗎？

你需要TestinData.AI 智能優化&AB測試：

TestinData.AI,轉化率優化,AB測試,智能優化,數據分析-雲測數據-國內領先的應用智能優化引擎?

ab.testin.cn
推薦閱讀：