怎麼樣在AB測試中盡量排除兩批樣本使用者的屬性干擾？

1樓：王曄

@劉澤軍感謝小夥伴們對我們信任，乙個勁兒的丟問題到我這裡，感覺知識被掏空了~

這是乙個基礎性的問題，即便不是技術人員，也會有這樣的擔心。但是，請大家確定乙個基本的認知，A/B測試不是隨隨便便的拉兩組人做測試，而是每一步都有邏輯和演算法的支撐，實際上，是最科學，干擾最少的方式。

下面，我從原理上證明一下剛才的這個說法：

從統計學角度考慮，要得到可信的資料結論需要滿足一定的樣本量，通常我們認為產品日活達到1000左右即可，日活越高統計結果收斂的速度越快。根據吆喝科技服務過的客戶經驗，如果日活能夠達到一萬，那麼5天之內就能完成一次樣本量充足、統計結果充分可信的A/B測試。

A/B測試應用控制變數的思想，除了要對照的產品方案之外，要求其他的環境因素完全一致，也就是說對於樣本間的分流，要盡可能使使用者的組成成分完全一樣，例如所使用的裝置型別、新老使用者佔比等等。

橫向去看，需要保證兩批樣本中，各種特徵使用者所佔總使用者比一致。

縱向去看，需要保證兩批樣本不會出現交叉——對於某個使用者，如果在首次啟動時進入了A版本，那麼之後再次啟動時依然要確保展示A版本。這說起來理所當然，卻是很多開發者經常忽略的一件事。

同樣，某個渠道的使用者不能代表所有使用者，有可能在單個渠道上獲得資料提公升，推廣到全渠道上卻沒有效果，甚至會產生反效果。

然而要達到令人滿意的效果，就不得不考慮自建服務端控制分流的系統，通過自己的服務端指令碼來控制每台裝置要展示哪一種試驗版本。可想而知實現成本頗高，除了開發量之外，還要消耗大量的api請求。

除此之外，能否保證同一臺裝置每次都能夠展示同乙個版本、如何判斷使用者到底有沒有受到試驗方案的影響、如何靈活的隨時調整樣本數量等等，越是考慮到這些細節問題，就越會發現實現成本幾乎高到不可行。

然而這並不是說科學的A/B測試無路可走，目前市場上已經出現了一批專為產品迭代中的A/B測試服務的企業，例如吆喝科技，完美解決了樣本分流的痛點：核心的分流演算法可以保證樣本間的一致性，並且規避了自建分流系統的成本，只需要整合SDK呼叫若干api即可。之

2樓：付顏

ABTest的目的在於判斷方案A和方案B那個更有效。

2）如何確保公平：

進入到首頁獲取到了A方案的使用者數為M，由A方案的頁面進入詳情頁的使用者數為N,

進入到首頁獲取到了B方案的使用者數為M1，由A方案的頁面進入詳情頁的使用者數為N1.

兩者相除（N/M和N1/M1）進行比較。誰的概率大則說明更優。

此方案從控制變數法的角度考慮，則是控制了概率是不變的。

3樓：

先說個「抽樣方式」上面的問題，「抽使用者」和「抽session」兩種方式適用的場景是不同的，用錯了的話會得出錯誤結論，但某些情況也可以相互代替。

不知道題主具體是用在什麼實驗上，所以先預設「抽使用者」是唯一且合理的抽樣方式。

看問題描述，問題是隨機抽出來的結果讓題主感覺實驗組和對照組屬性差別太大。

解決問題的根本方法是加大樣本容量，抽到全集的各50%的情況下，你描述的這種差異就會變少了。

如果出於成本和技術約束，樣本容量抽不大，那就多隨機抽幾次，選乙個你看著覺得看得過去兩組做實驗。

但本質上還是看樣本容量，如果實驗對照只抽得出10個人出來的話，就算肉眼可見的屬性很「均衡」，置信區間也沒法看，建議放棄A/B test。

4樓：

前提是你已經有歷史的資料做參考，然後再用AB測試去尋找更正確的優化方向。

有這個前提的話，接下來就很簡單了。你只要把原有資料調出來，看一下哪些維度對資料是沒有顯著影響的，然後再根據結果去選測試樣本就好。

如果是新功能上線，不建議直接做AB測試。一方面你的結果說明不了什麼問題，另一方面也會拖上線的進度。