是時候重新審視AB測試了
譯/貓貓喵喵
本文轉自遊戲網站Gamasutra.com的社群博主Viktor Gregor,原文地址在此,一段時間沒有更新了,考慮來一個硬一點的菜,就選中了本文。本來我不想翻譯與手遊有關的內容,但是考慮到遊戲運營這部分儘管更多運用於手遊,但並不是手遊的專利,另一方面也是因為這篇文章的確寫的很有水準,並且相信能對最直接的經營思維提供一些有價值的資訊。
由於文中涉及到不少有關統計學的知識,作者的主張是貝葉斯方法對遊戲版本更新提升氪金能力的影響進行AB測試,大家可以參考查閱相關梳理統計方面的知識。另,由於本人是學渣,統計相關的知識只是以前用SPSS的時候鑽研過,並沒有非常堅硬且系統性的知識體系,加上是從英文翻譯,部分知識點的確超出了我的知識範圍,我也是一邊查資料一邊翻譯的,所以如果有什麼低階錯誤希望大家指出,非常感謝!
前言
我想在本文中解釋一下為什麼我們Pixel Federation會決定徹底的改變使用A/B測試的方法,我們會比較對F2P類的手遊的不同版本進行AB測試的新舊辦法。
我們常常回去測試兩個版本的遊戲,(通常)版本A是現階段的遊戲版本,而版本B是加入了一些新特性的不同版本——調整了平衡或者其他什麼,以前,我們通常使用“虛無假設檢驗法”進行測試(NHST,null hypothesis significance testing),也就是大家熟知的頻率測試(frequentist testing)。具體說,就是我們首先使用卡方檢驗來測試轉化指標,然後對收費指標進行T檢驗,如ARPU(每使用者平均收入)或ARPPU(每位付費使用者的平均收入),而現在,我們使用貝葉斯檢驗。(譯者注:卡方檢驗和T檢驗都是統計學上的常用工具,簡單理解,假設你對遊戲中某些細節做了調整,運用卡方檢驗,可以確定新版本的改動,是否對於轉化率變化產生了符合預期的促進作用。T檢驗是可以分析出,不同版本有沒有對於客戶付費的心理產生影響(或者說吸引力更多願意付費的客戶)。而貝葉斯檢驗則(理論上)可以分析出,現在的這一版改動,對於各項指標的改進是否朝著預期的方向前進。)
我介紹一下我們為什麼要把測試方法換成貝葉斯檢驗:
(1)可以解釋結果
(2)樣本大小和測試設定
1、如何解釋結果?
由於頻率論和貝葉斯統計對機率和假設檢驗的處理方法是截然不同的, 因此我們從相同的資料中得出的結論也會大相徑庭。
解釋頻率測試方面
頻率測試會得出一個p值以及置信區間,透過將p值與預設的α水平(通常為5%)進行對比,我們可以判斷某個結果是否是“顯著的”。 這種方法已經用了100多年了,並且沒什麼問題。 但是求p值這個部分卻存在一個大問題,很多人以為自己理解了它,其實大部分是沒有的。 這就可能導致許多問題,比如無意是下的“p值駭客”(P-hacking)問題。(譯者注:p值駭客簡單的理解就是“應試教育”,一旦考試中規定了某個指標作為唯一的判別標準,就會誘導人有意無意的去僅僅只追求那個指標,例如其實啥知識都沒學到的“考試型選手”,以p值為唯一的判斷標準,就會誘發這個問題,我們把這種情況稱之為“p值駭客”。)
主要是因為p值並非一種直觀的指標——如果我們想測試A和B之間是否存在差異,我們就必須先形成設定一個“虛無假設”,就是假設一個“否定的結論”(例如A等於B),然後,我們收集資料並觀察他們,看他們與這個結論相比起來差異大不大,之後,我們才能從p值的結果中得出所觀察資料的機率與(之前所做的)虛無假設相差甚遠(然後反推出所觀察的資料與我們預設的資料之間沒有差異)。(譯者注:這裡有點拗口,簡單理解就是,p值假設來驗證一件事情的方式,並不是用“這件事真不真”這種直觀的表達,而是採用類似“這件事如果反過來說,這個反過來說的結論是否並不真實”這種多層否定的邏輯,如果不是用習慣了的話,非常容易把自己繞進去,而且當把這個結果帶入到更復雜的一套邏輯中後,就會導致那一整套邏輯特細變得特別複雜,難以方便的思考。)
換句話說,如果我們進行AB測試(注:原文這裡寫作“A/A test”,聯絡前後文應該是筆誤),p值告訴我們的是,我們所獲得的結果機率與實際觀察到的結果是一樣極端(或更極端)——這已經是我所知道的最簡單的p值描述了,但它似乎仍然讓人難以理解。
我並不是說複雜的事情就沒用,但在我們是需要在商業層面上讓我們的業務人員和遊戲設計師們能理解我們的結果的。
那我們該如何解釋我們的這些結果呢?如果我們得到p值小於alpha的結果,這就表明一切都很好。我們得出了A和B有所不同的結論,明確了商業上存在價值了,之後每個人都會因此很高興我們做了一個成功的A / B測試,不過,卻沒人關心他們並不明白的p值究竟意味著什麼。
但如果我們沒那麼幸運呢?當我們得到高於alpha的p值時,實際上是很難得出具有一定價值的結論的。我們可以看一下下面的例子:這是一次卡方檢驗的結果(由Evan的Awesome A/B Tools計算得出)。
我們不僅無法得出結論認為哪個版本更好,也無法認為(新版本)沒產生變化。現在,我們唯一知道的就是p值等於7.2%這個結論。我們也有置信區間,但在這裡沒什麼用,因為所存在差異的置信區間包括0。(注:理解這裡需要一點數學基礎,簡單理解就是,差異的置信區間如果包括0的話,可以認為“前面的這個p值的可信度是有問題的”)。現在,生產團隊的人很可能無法理解等於7.2%的p值是什麼意思,如果你試圖用某種方法向他們解釋,那可能會讓情況更糟。 因為我們假設了一個我們不希望發生的結論,那誰會願意去關心“我們得到的結果比我們假設的前提更極端”這件事?
在這種情況下,你(反而)可能很容易會說“嗯,7%非常接近5%,看起來有效果。那應該就是B版本更好啦”。但實際上你是不能這麼做的,因為(理論上來說)如果沒有實際效果,p值就會均勻分佈在0和1之間,也就是說,如果A和B之間確實沒有差異,那p值等於7%或者等於80%或任何其他數字的機率是相等的(譯者注:也就是說是均勻的分佈在整個機率區間上,如果有所確定,那麼就會集中分佈於某些機率區間上,舉個例子,你如果沒有證據表明明天你會不會被天上掉下來的石頭砸到,理論上就是不會砸到50%,會砸到50%,機率“均勻”的分不到“砸到”和“不會砸到”兩個結果上)。因此,你能維護身為一個統計學家的正直性的,就是宣告:在當前的測試中,當前沒有足夠的資料支撐任何判斷。
這讓人非常沮喪,因為A B測試是非常破費的。從管理者的角度來看,我們進行幾周的測試,然後分析師也得出了結論,但是我們看起來基本上都沒意識這樣做是在浪費時間和金錢。我看到大家很失望,導致以後也不願意進行AB測試了,這不是我想要的。
解釋貝葉斯檢驗
貝葉斯方法很好地解決了上述問題,因為它可以在任何情況下都能為我們提供有意義且易於理解的資訊,他在使用過程中不需要進行虛無假設,這就使得他在解釋的過程中簡單了許多。
貝葉斯檢驗的結果不是p值,而是下列三個數字:
•P(B> A) - 版本B優於A的機率
•E(loss| B) - 如果B版本有問題,那問題又多大
•E(uplift | B) - 如果B 版本很好,那究竟有多好
而且E(loss| B)和E(uplift | B)兩個結果在測試過程中所用的單位是一致的。 如果是轉換,如果(二者)需要換算對比,(結果)就是一個百分比,接下來讓我們看一下,之前的資料(在這種方法下)產生的結果。
結果告訴我們,如果我們選擇版本B,結果(一方面)可能會變得更糟(機率為3.6%),我們可以預測會產生0.026%的轉化率損失。另一方面,我們的選擇更可能是正確的(機率為96.4%),我們預期能在原本23%的轉換率基礎上有3.3%的提升。這是一個簡單的結論,遊戲設計師和管理者們都能很好地理解。
要確定使用版本A還是版本B,我們就需要在測試結果得出前先確定測試的規則。你可以根據P(B> A)來決定,但如果你僅僅只需要確定E(loss| B)的結果小於某個預定義的閾值,就可以宣佈B是更好的選擇,這種方法就無疑是更加明智的。
雖然這樣的決策機制並不如p值那麼明確,但我認為這是一件好事。 “p值<5%”在每個統計學家腦海中都是一個讓人緊張的東西,因為我們甚至常常難以確認這個結論在當下背景下是否具有意義。而在貝葉斯測試中,我們需要在測試之前就與遊戲設計師討論E(loss| B)的閾值,然後我們就可以將閾值設定為一個非常低的數字,低到我們不用去關心是否會出現(比閾值)更低的誤差錯誤出現。
但即使預先設定的決策規則無法在不同變數中區分出差別(例如我們沒有足夠的資料,或者我們將閾值設定得太低),但至少我們也還可以從對比在P(B > A)的機率下的預期收益及在1 – P(B > A)機率下的預期損失之後,做出一個明智的判斷。這就是貝葉斯測試在具體應用層面上最主要的優勢所在,總而言之,就是你總是能從中獲得好理解且有意義的資訊。
2.樣本規模和測試設定
到目前為止,我只提到了有關如何理解測試結果的問題。使用貝葉斯測試還有另一個關於樣本量的非常實際的原因。NHST最常提到的缺點就是需要在測試開始之前確定樣本規模的大小,而貝葉斯測試沒有這個要求,除此之外,它通常在樣本規模較小的測試中表現會更好。
頻率測試中的樣本規模
在NHST中需要確定樣本規模的原因在於我們如何去收集資料將會影響到p值,例如當我們設定的測試目標分別是來自10000名玩家的觀測(資料)與來自100名玩家的觀測(資料)時,我們就應該(用)不一樣的(方法)去計算P值。這聽起來有點違反直覺,而且常常被被忽視,這是由於,一方面是人們會認為(分析)資料本身就是足夠的,但是如果你想計算出正確的p值,你就不能如此。我不打算在這裡解釋它了,因為John K. Kruschke在其論文中(見圖10)已經進行了很好的分析,他在他自己的書《貝葉斯資料分析》(<Doing Bayesian Data Analysis>)中第11章裡進行了更詳細的解釋。確定樣本大小的另一個原因是我們需要對統計測試的效力進行一些估計。
這意味著我們必須在收集資料之前確定測試中會包含多少玩家,然後僅在達到預期的樣本規模後才能評估結果。但由於我們通常不知道效果的實際大小,因此很難正確且有效地設定測試。由於AB測試很昂貴,所以我們會希望儘可能高效地安排測試。Evan Miller在一篇文章中詳細介紹了這個課題。他清楚地展示了“窺探”(譯者注:對一個時間點上的資料進行切片分析定性,我們可以稱之為data peek,也就是資料窺探)是如何在達到預設的固定樣本量之前,引發測試結果中的第一類錯誤的比例大大的增加,導致結果變得完全無效的。
(譯者注:第一類錯誤是一個統計學概念,又稱Ⅰ型錯誤、拒真錯誤,是指拒絕了實際上成立的、正確的假設,簡單理解就是第一類錯誤:原假設是正確的,卻拒絕了原假設。也就是說我們如果預設P值,簡單理解就是我們預設了一個“我們容忍5%機率以下犯第一類錯誤的機率,認定目前的結論”)
他還提出了兩種可能的方法來解決這個“窺探問題”:序貫檢驗或貝葉斯檢驗。
(譯者注:peeking problem,也就是peek引發的問題,假設我們基於一個p值下進行一次peek,理論上我們所接受的內容中是存在5%的第一類錯誤的,基於接受上一次peek 的結論而進行的下一步假設檢驗就會把資料中攜帶的5%的第一類錯誤“遺傳”下去,如果測試不斷延續下去,就會造成第一類錯誤的“堆積”,另,序貫檢驗是一種測試之前不確定樣本量規模,而在測試過程中確定樣本量規模的假設檢驗方法)
貝葉斯測試中的樣本規模
貝葉斯測試並不需要鎖定樣本規模才能提供有效結果。你甚至可以反覆測試結果(這一點幾乎被認為是對NHST測試方法的侮辱),並且結果仍然有效。但是我必須給大家一個大大的警告!一些文章聲稱貝葉斯方法“對於Peek免疫”。這種表述可能會產生誤導,因為這種表述會讓我們以為,即便我們有條不紊的檢查結果並在出現顯著結果時停止檢測,第一類錯誤率可以保持(在可接受範圍)。其實並不是這樣,目前在統計學裡面,如果你有一個基於某些極值的觀測的測試停止機制(比如P<0.05),那你就不可能做到(維持第一類錯誤率在範圍內),事實上,貝葉斯檢測從一開始就沒有一個約束性的第一類錯誤率,它是一種不一樣的方法,但它卻存在一個作為約束的預期損失率。David Robinson在這篇文章中表明,貝葉斯檢測的預期損失在“窺探”(Peeking)的時候也是收到約束的。所以,這種觀點部分是對的,但是需要意識到所謂的“對窺探免疫”對於NHST方法來說意味什麼,在貝葉斯檢測中則是指別的東西(譯者注:貝葉斯測試不是對於peek免疫了,而是因為其問題不在第一類錯誤率上,而在預期損失率上,所以等於說貝葉斯方法是“避開”了第一類錯誤率,而不是消除了它)。
如果你需要特別關心第一類錯誤率方面的問題,那我需要警告你,在這類情況中,貝葉斯測試可能並不適宜。
但我總歸認為第一類錯誤率在我們的背景下並不是非常重要,儘管它很顯然在醫學等科學研究中非常重要,但AB測試是不一樣的,因為我們最後總是要選擇出A或者B的,如果確實沒有差異或者差異非常小的話,我們就並不需要關心我們是否犯了第一類錯誤,我們只關心所犯的錯誤是不是很大。基於此,在AB測試上,以預期損失作為約束條件而不是第一類類錯誤率將更有意義。
除此之外,貝葉斯測試還有另一個實際優勢,與NHST相比,它通常只需要很小的樣本規模就能實現相同的效力,這可以為我們節省很多錢,因此我們可以更快的做出決策。
下圖展示了對於轉化率檢測的模擬,我們進行了1000樣本量的卡方檢驗以及1000樣本量的貝葉斯檢驗,並測算出了兩個實驗中“B為最優解”的分別的預測機率,表現出了(兩種測試)在特定樣本規模基礎上展現出的近似的效力。
我們可以看到,貝葉斯測試在獲得80%測試效果上所需的樣本規模是顯著較低的,不到(NHST的)一半。另一方面,如果我們繪製出A和B兩種條件下達到相同轉化率時的圖形,則(會發現)NHST具有更好的結果(對於樣本規模下測試效力均為95%)。
對於卡方檢驗,我們使用等於5%的alpha值(第一類錯誤率),當(我們需要設定)預期損失低於0.1%時,(則可以用)貝葉斯測試得出B為更優。
如何在實踐中運用
在說完改變的原因後,我還想聊聊我們如何在實踐中使用它。目前,我們正在使用兩個獨立的貝葉斯模型進行兩種不同型別的測試,這裡就不做詳細的解釋了(需要單獨的文章),我只列出我們目前正在運用的部分。
我們使用的模型不是卡方檢驗,而是假定轉換率具有伯努利分佈。所有公式均來自下列來源:
Evan Miller的貝葉斯AB測試公式(Formulas for Bayesian A/B Testing)
Chris Stucchio在貝葉斯AB測試中簡便評估決策規則(Easy Evaluation of Decision Rules in Bayesian A/B testing)
對於收入資料,我們一個轉化率模型的擴充套件(模型),它使用指數分佈單獨估算轉換率與伯努利分佈,然後估算出支付金額。我是根據這篇論文實現的:
Chris Stucchio的VWO貝葉斯AB測試(Bayesian A/B Testing at VWO)
Kruschke的書中提供的程式碼對於理解貝葉斯統計資料也非常有用。 我用其中的一部分來計算最高密度區間(譯者注:最高密度區間是一個統計學定義,其中密度是指密度分佈,密度分佈等於一段區間的機率除以該段區間的長度,這段區間也就是事件的取值範圍):
執行貝葉斯資料分析程式
使用這些來源,我在R中實現了AB測試計算器(譯者注:R是一種用於統計分析、繪圖的語言和操作環境)。你可以在這裡嘗試一下:
轉化率的貝葉斯AB測試
ARPU的貝葉斯AB測試
總結
使用貝葉斯AB測試,現在我們可以更快地執行測試,並獲得更多可操作的結果。讓我一起總結一下,它的優點如下:
那麼這種方法還有什麼缺點呢?為什麼我們不經常使用呢?在我看來,主要原因是與傳統的NHST測試相比,這種測試方法實現起來要複雜許多,傳統的NHST測試可以只使用Excel中的一個函式就能計算。另外,有些人對使用貝葉斯方法猶豫不決的原因是先驗分佈(譯者注:先驗分佈,又譯為“驗前分佈”或“事前分佈”。是機率分佈的一種。與“後驗分佈”相對。與試驗結果無關,或與隨機抽樣無關,反映在進行統計試驗之前根據其他有關引數口的知識而得到的分佈,可以簡單理解為類似上天偶然給的一個事先的分佈)。先驗和後驗分佈是貝葉斯統計的關鍵要素,在進行任何計算之前,你必須確定這個先驗分佈。在Pixel Federation,我們目前是將無資訊先驗用在AB測試上(譯者注:無資訊先驗指的是在沒有任務資訊的情況下,認為各個點的機率或機率密度相等是合理的,我們沒有理由讓任意一點的機率大於其它點的機率。無資訊先驗試圖給出一個對後驗機率影響儘可能少的分佈,一切讓資料說話)。
總之,我想強調一點,我並不是說頻率統計都不如貝葉斯方法。對於不同的目標它們都是有用的。在本文中,我想表達的是貝葉斯方法更適合商業應用程式。
如果您碰巧遇到類似問題並以不同方式解決了問題,或者您使用貝葉斯統計資料並擁有一些你想分享的經驗,請告訴我們。
參考資料:
Bayesian estimation supersedes the t test
Doing Bayesian Data Analysis, A Tutorial with R, JAGS and Stan
How Not To Run an A/B Test
Is Bayesian A/B Testing Immune to Peeking? Not Exactly
Bayesian A/B Testing at VWO
Formulas for Bayesian A/B Testing
Easy Evaluation of Decision Rules in Bayesian A/B testing
來源:奶牛關
地址:https://cowlevel.net/article/2007883
相關文章
- 企業是時候重新審視資料安全與合規了
- 6 歲!是時候重新認識下 Serverless 了Server
- 6歲!是時候重新認識下Serverless了Server
- 9個月後再開測試,我們試著重新審視《原神》
- 是時候扔掉 Postman 了,試試 IntelliJ IDEA 自帶的高能神器!PostmanIntelliJIdea
- 美國公司年審時間是在什麼時候的?
- 在氣候災難的時代,這些遊戲正在用自己的方式去重新審視自然遊戲
- 2024, 是時候告別CentOS了CentOS
- 是時候扔掉 Postman 了,Apifox 真香!PostmanAPI
- 你的 ResNet 是時候更新了
- 解鎖 AB 測試的力量
- UI 設計之AB測試UI
- 是該重新思考一下網站綜合監測技術的時候啦網站
- 【Android Adapter】是時候開啟Adapter新時代了AndroidAPT
- 是時候放棄 el-form 元件了ORM元件
- ab 是如何壓測後臺的
- 剛做測試工作一年的時候,我是怎樣的?
- 是時候為Spring Boot 3.0做準備了Spring Boot
- 非智慧WAF,是時候轉身離場了
- 是時候學習真正的 spark 技術了Spark
- 等保測評機構每年都需要年審嗎?年審時候需提供哪些資料?
- 是時候談談JavaScript物件導向了!(我們什麼時候更需要它)JavaScript物件
- Linux基礎命令---ab測試apache效能LinuxApache
- apache-ab 壓力測試詳解Apache
- 介面測試的時候如何生成隨機資料進行測試隨機
- 無伺服器時代:是時候做 Cloud Right 了 - Wardley伺服器Cloud
- 功能測試之審批流測試
- 資料枯燥乏味?是時候用利用資料視覺化來講故事了!視覺化
- 德勤:是時候認真對待資料了
- 是時候優雅的和NullPointException說再見了NullException
- 《榮譽勳章》系列是時候重回戰場了
- 為什麼說是時候擁抱.NET CORE了?
- 還在學iOS?是時候學習Flutter了(二)iOSFlutter
- APK瘦身-是時候給App進行減負了APKAPP
- 是時候來了解下 HTTPS 網站的部署了HTTP網站
- 飆升暢銷榜TOP3後,是該重新審視一番這款“國乙癲遊”了
- apache ab壓力測試工具-批次壓測指令碼Apache指令碼
- 超實用壓力測試工具-ab工具