最近學到的ABTest知識

Java3y發表於2019-10-30

前言

只有光頭才能變強。

文字已收錄至我的GitHub倉庫，歡迎Star：github.com/ZhongFuChen…

如果之前看過我文章的同學就知道我在工作中搞的是推送系統，之前寫過一篇帶你瞭解什麼是Push訊息推送，裡面也提到了我們或許可以做ABTest，最終提高推送訊息的點選率。

那什麼是ABTest呢？這篇文章帶你們入門一下。

一、ABTest的介紹

比如我寫了一篇關於ABTest的文章，我希望這篇文章的閱讀量能上2500，但是我沒想好標題叫什麼比較合適。一條推文的標題非常能影響到閱讀量，於是我想了幾個的標題：

最近我學到的AbTest知識
AbTest入門

而我不知道哪個標題效果會更好一些，於是我做了這麼一個嘗試：

《最近我學到的AbTest知識》這個標題推送給10%的使用者
《AbTest入門》這個標題推送給10%的使用者
過一段時間後，我看一下效果，哪個標題的閱讀量更高，我就將效果高的標題推送給剩餘80%的使用者

要注意的是：在推送的文章的時候，除了標題不同，其他因素都需要相同（不能被別的因素給干擾），這樣看資料的時候才有說服力。

1.1為什麼要做ABTest？

做ABTest的原因其實很簡單，我們在做業務的時候會有各種各樣的想法，比如說：

“我覺得在文案上加入emoji表情，這個推送的訊息的點選率肯定高”
“我覺得這個按鈕/圖片換成別的顏色，轉化率肯定會提高”
“我覺得首頁就應該設計成這樣，還有圖牆應該是這樣這樣..“
.....

但是，並不是所有的想法都是正確的，很可能因為你的想法把首頁的樣式改掉，使用者不喜歡，就影響到了GMV等等等....

一個好的產品都是迭代出來的，而我們很可能不清楚這次的迭代最終是好是壞（至少我們是覺得迭代對使用者是好的，是有幫助的，對公司的轉化也是好的），但是我們的使用者未必就買賬。

於是，為了降低試錯成本，我們就做ABTest。一個功能做出來，我們只放小流量看下效果，如果效果比原來的功能差，那很可能我們這個想法沒有達到預期。如果小流量效果比預期要好，再逐步加大流量，直至全量。

二、怎麼做ABTest？

從上面的案例，其實我們大概知道，ABTest最主要做的就是一個分流的事

將10%流量分給使用者群體A
將10%流量分給使用者群體A

我們需要保證的是：一個使用者再次請求進來，使用者看到的結果是一樣的

比如說，我訪問了Java3y，他的簡介是：“一個堅持原創的Java技術公眾號“。而一個小時後，我再訪問了他一次，他的簡介是：“一個乾貨滿滿的技術號“。而一個小時過後，我又訪問了他一次，他的簡介是：“一個堅持原創的Java技術公眾號“。

這是不合理的，理應上使用者在一段時間內，看到的內容是相同的，不然就給使用者帶來一種錯亂感。

OK，於是一般可以這樣做：

對使用者ID(裝置ID/CookieId/userId/openId)取hash值，每次Hash的結果都是相同的。
直接取使用者ID的某一位

現在看起來，ABTest好像就是一個分流的東西，只是取了個高大尚的名字叫做ABTest。

2.1 ABTest更多的內容

假如我做了一個UI層面上的ABTest，佔用全站的流量80%，現在我還想做搜尋結果的ABTest怎麼辦？只能用剩下的20%了？那我的流量不夠用啊（我可能要做各種實驗的呢）。UI層面上的ABTest和搜尋結果的ABTest能不能同時進行啊？

答案是可以的。因為UI層面和搜尋結果(演算法優化)的業務關聯性是很低的。如果要做“同一份流量同時做UI層面上和搜尋結果的ABTest”，那要保證“在UI層面做的ABTest不能影響到搜尋結果的ABTest”

業界應用最多的，是可重疊分層分桶方法
層與層之間的流量互不干擾，這就是很多文章所講的正交(流量在每一層都會被重新打散)

來源：https://www.infoq.cn/article/BuP18dsaPyAg-hflDxPf

我們就可以這樣幹：通過 Hash(userId, LayerId) % 1000 類似的辦法來實現

每一層的實驗不管有多少個，對其他層的影響都是均勻的

我的理解：

為了實現UI/演算法/廣告這些業務上沒什麼關聯的，能夠使用同一份流量做ABTest測試，所以分了層。流量經過每一層都需要將流量重新打散(正交)----每層實驗後，不會影響到下一層的實驗

如果業務關聯強的應該放在同一層，同一層多個實驗是互斥的（比如一個按鈕顏色改為綠色作為一個實驗，一個按鈕的樣式改成大拇指作為一個實驗。這兩個實驗的流量是要互斥的（不然你咋知道使用者是因為你的按鈕顏色還是樣式而點選）