從設計到歸因 - AB Test 實戰心得
前言
這是大Fei分享工作過程中,關於資料增長的系列文章,筆者(大Fei)在國內知名出海App任職資料負責人,有多年的相關工作經驗,公眾號的主筆與我亦師亦友,經常一同深究一些資料背後的邏輯,此次旨在分享一些自己的實戰和分析經驗,供大家參考,並與大家一起交流成長。
作為資料增長實戰分享的第一篇,我先從個人認為最重要的AB Test實戰開始分享,而分享過程中涉及到重要且無法展開的,未來會慢慢再與大家討論和分享。甚至我會和大家講到一些資料平臺的使用玩法比如神策、Firebase等。
== 關於AB Test ==
說到AB Test 大家都不會陌生,也是增長黑客概念流行以來非常熱門的話題,我曾與業內經常做AB Test的朋友交流,也遇到過這類常見的問題
- 方案存在多變數,沒有控制唯一變數,實驗結果很難歸因和解釋
- 多組實驗同時跑,不知道實驗的變數相互干擾
- 不確定如何有效評估實驗,提升多少算有效?
- 實驗結果看起來有效果,上線後卻效果不明顯
- 實驗結果看起來有效果,但不知道為何,無法歸因出原因
我們最可怕的不是不知道要開展AB 實驗,而是明知道要開展,卻不知道如何科學開展或開展後面對資料結果一臉茫然。
== 如何科學開展實驗呢 ==
首先,實驗的過程可以簡單分為三步
- 實驗設計 - 包括實驗的想法,背景,假設,方案,指標等
- 實驗上線 - 包括實驗AB功能,資料採集,測試和上線
- 實驗評估 - 包括資料獲取,對比分析,轉化結果顯著度,實驗結果歸因,結論,建議和計劃
具體過程相信大家不會陌生,所以不會逐個介紹,下面我們重點聊聊整個過程可能常遇到的問題和經驗教訓,這也是我本次想分享的核心。
== 看似簡單的實驗設計,更需要重視 ==
1、實驗想法拿資料做支援
• 記住不要光拍腦袋不分析資料,這是提高實驗成功率的有效途徑,否則你將會承擔更高的實驗風險,要麼實驗沒有效果,要麼實驗效果下滑,這些都是浪費資源的做法
• 公司不會有那麼多時間和資源投入到一個又一個失敗的實驗方案中,因此想法很重要,但更重要的是參考、分析,為你的實驗想法提供資料依據,拿資料說話
• 真實的情況是,我們完全可以拿資料否掉很多不靠譜的想法
• 由於本次分享的內容側重點,這塊內容以後的機會再分享
2、實驗目標說清楚,寫下來
• 清晰的實驗目標能夠讓方案聚焦,也避免評估結果的相互扯皮
• 如果團隊有人想要收入,有人想要留存,這往往打架的實驗目標會造成後續的一系列麻煩
---
經歷:
我們曾遇到過一個實驗對於收入的效果非常顯著,但卻損害了使用者體驗,導致使用者認為應用收費性質過強而流失,但團隊一致認為當前收入最重要,且通過資料驗證了流失的使用者均是較為低質的活躍使用者,對長期留存來看並無意義,只是短期留存不好,DAU會下滑。
但團隊中有人則認為前期的活躍使用者更重要,不想流失使用者和DAU下滑,這個就團隊在前期沒有確定一個一致的目標造成,最後的結果則是非常不歡,方案也沒有上線,非常打擊團隊的信心。
我們不要總期待魚和熊掌兼得,那是可遇不可求的,我們也正是一直在方案的利弊中,學會權衡並決策前行,這才是可貴的成長和經驗,我們總要學會拋棄芝麻撿西瓜,把目標定下來,會更利於我們的決策。
---
3、實驗方案設計
• 清楚瞭解自己的實驗目標,設定測試中想要測試的變數
• 儘量避免要評估的方案存在多變數的情況,控制唯一變數,有利於得到更多實驗資訊
• 分組設計會是另一個重點,我們放在後面來講
---
經歷:
我們曾犯過這類錯誤,上線一個新的付費頁面,但我們實驗設計前期沒有想清楚可以評估和實驗的變數,導致我們只控制了展不展示該頁面,但該付費頁面我們換了新商品,更換了SKU組合,更換了商品的折扣屬性,頁面也放置在使用者完成關鍵動作後出現。
不難想象,我們最終只得到了一個大而全的策略結果,而不知道頁面裡面的變化能起到的關鍵作用,因此我們浪費了一次機會,丟失了本可以獲取的實驗資訊。
---
這個過程就好比如下,同時修改了顏色和文案那樣,我們無法知道顏色和文案分別的影響
儘量不要做出這樣的對比,在實驗前想清楚,再想清楚,把你要評估的變數梳理清楚,這樣再把變數拆開
如下:
實驗設計方案參考如下模板
關於資料採集這塊我就不做分享了,不是本次的重點,後續有機會我們再拿來分享
== AB實驗工具 ==
筆者使用過多個AB 工具,包括自研AB系統,Firebase等第三方支援AB 的工具,我總結了常見AB工具的幾個特性,供大家今後需要的時候參考
當我們建立一個AB Test時,需要有:
• 使用者圈選:一般要求系統能夠對目標實驗群體做圈選,滿足的使用者進入AB Test,建議支援系統已有的使用者屬性,行為資料,使用者標籤等作為可選擇維度,第三方工具則要求相關資料上報,需做好前期的實驗設計和資料採集工作
• 實驗灰度:假如你的實驗不想影響所有使用者,那麼這個正是你所需要的,可以實現逐步放量,相對完善的AB工具均有此類選項,如Firebase
• 配置項:一般指可以由後端自定義值的【遠端配置】,例如:是否展示免費試用商品,就是一個【遠端配置】
• 實驗分組:任意增加多個分組,併為各組選擇配置項,配置項的值,以及該組的樣本比例
• 實驗分組標記:每個建立的實驗都建議為每個實驗建立一個Track Tag,將分組名稱作為值,如Test1_Control,Test1_VarB,Test1_VarC,然後作為一個使用者的標籤標記上,同時要避免標籤資料被覆蓋導致歷史實驗資料丟失
如果大家是做出海的App,Firebase是我優先推薦的,它是谷歌的產品,而且免費,但唯一不好是對國內支援不好,所以可以根據實驗群體和場景選擇哦。
當然最靈活的還是自研AB系統,但是這個需要一個較有經驗的增長產品經理或增長資料分析師來參與比較好系統的設計和資料採集,這樣才能較好確保系統的可用,否則仍會出現很多坑,下面我來講一下我們團隊在實驗分組遇到過的問題。
== 實驗分組 ==
1、按照使用者ID等屬性計算隨機值
我們團隊一開始通過使用者ID來實現簡單的隨機分組,這個方式在我們跑多組實驗的時候遇到了問題
按使用者ID屬性計算分組值存在的潛在問題如下
假如一個使用者U3,基於該使用者ID通過某種隨機演算法計算得到59,按照隨機演算法被分配到50%~100%這個區間,此時如果Test1區分AB兩組,各50%,那麼使用者U3應該會被分配到Test1的B組;此時如果又有Test2 區分AB兩組,各50%,那麼該使用者仍會被分配到Test2的B組
最後當我們要對Test1的A組和B組做對比時,假設Test2也會或多或少影響Test1的目標轉化,那麼就會多了一個Test2的干擾因素,從而兩個實驗的變數會相互干擾結果,無法評估某個Test 變數的貢獻,如下圖所示:
因此這種情況下你只能同時跑一組實驗。
2、按照使用者ID等屬性和實驗ID計算隨機值
後來,我們採用另外一種分組方案,按照使用者ID和實驗ID共同決定隨機值,這樣起到在每個實驗中,兩組的使用者也分別均勻分佈在其他實驗的各組值中,如下圖所示原理,理論上兩個實驗均設定兩組各50%,則樣本預計將平衡貼近25%
理論上,Test1和Test2就相互不干擾了,因為在分組足夠均衡的情況下,Test1 AB各組受其他實驗的影響也被均衡了,可以忽略不同變數相互之間的影響
3、另外一種分組方案探索
我們團隊還嘗試過另外一種方案,這種方式就是把使用者按照一個個規定的桶,將使用者隨機分配好,然後為實驗具體組選擇某個(幾個)桶的使用者,會比較強隔離每個實驗,互不干擾,相對來說比較方便,但卻需要有專人管理和把控實驗資源的配置,且樣本量要足夠大,否則一旦篩選了條件導致樣本量不夠多,則會面臨分組不夠用的問題
我身邊也有朋友在這麼做,這只是分享給大家參考,大家可以結合自己的實際情況來決定
如果大家選擇一些AB 工具則可以不用太擔心,人家已經實現了合理的分組,按照說明設定就好了,但在自己實現分組的時候則需要特別留意這塊了。
== 實驗評估 ==
這裡我們關注一個重點,如何評估實驗結果是否有效,或者說如何評估提升多少才算有效?
關於如何選取評估指標,這個需要大家結合實際業務場景來確定,這個就不介紹了(注意,我們往往不會評估單一指標)。
對於出海來說,尤其是工具類產品,最不陌生的就是免費試用了,這個蘋果和谷歌為我們提供了很成熟的產品支援
我就拿這個舉例子,也是我們團隊親身經歷過的專案
先做個簡單假設:上線7天免費試用,能夠對收入有提升10%,提高使用者付費轉化率提高10%
核心評估指標:
• 使用者付費轉化率(7天內,0金額不計算)
• ARPU(7天內)
實驗分組:
A 控制組,預設不曝光
B 實驗組,曝光7天免費試用,顯示免費試用字樣
參考下面資料例子,
我們可以看到示例中
整個實驗週期中,A組有12100個樣本參與,B組有12200個樣本參與
A組的成功付費轉化率為1.65%,B組的成功付費轉化率為1.97%(為了簡單演示,沒有給出置信區間估計)
如果單靠看轉化率的變化,我們可以看到B組有些效果,但提升是否真的有顯著效果呢?
這就要求我們引入統計顯著的概念了,先來看示例中我們計算的結果是95%顯著,這個就能極大給我們信心說結果是顯著的。
當轉化率結果顯著,這個意味著實驗有勝出組了,然後看ARPU表現,即可大概率確認實驗的效果。
這裡只舉一個指標評估做為例子,實際評估還需要結合實際業務來看,包括評估方案的正向反向效果。
一個小技巧:當我們的運營團隊不知道如何分析結果的歸因時,採用轉化前後的使用者行為做差異分析,這樣就能大概率做到對結果的歸因分析了,關於歸因仍為一個大專題,不在這裡做詳述。
== 統計是否顯著概念 ==
如果有朋友學過統計學或者接觸過類似的概念,相信不會陌生,這裡只做下概念普及,為了通俗易懂,有些描述可能也不是特別的科學嚴謹
統計推斷的概念需要有一個【原假設】,這個【原假設】我們一般假設實驗的方案不如老方案效果好,然後想辦法推翻,以此來堅信我們的實驗是有效果
例如這個效果指付費轉化率,那麼就是說,實驗的B組的成功概率(用PB表示)不如實驗A組的成功概率(用PA表示)高,即PB <= PA
有了【原假設】,接下來只需要找證據推翻上述【原假設】就可以了
前面實驗中PB = 1.97%,而PA=1.65%,PB > PA,這個時候可以推翻原假設嗎?
不能確定,因此需要引入統計顯著的概念,一般顯著度達到95%以上,就可以有足夠的信心推翻原假設
這個95%你可以簡單理解為PB > PA發生的概率超過95%,這樣我們的信心就很足了。
關於顯著度的計算這裡不深入展開,只是提供大家一個判斷依據,對效果的評估要加上這個會比較科學,這樣能知道方案上線後有效果的把握程度。
注意:發生概率高,不代表一定會發生,所以要做好上線後隨時準備面臨結果不如意的心態。
== 別忘了細分實驗結果 ==
在我們多次跑實驗的經驗,尤其是對於出海應用,我們面臨了很多的國家市場,來自全球各地人付費文化和行為模式是存在差異的,因此我們前期實驗選擇的群體可能就包含了不同消費特性的人群,因此無論在總體結果是否顯著的情況下,我們都應該做更多維度的細分。
這樣我們能有效發現那些響應不足或響應後效果差的地區,對策略做出及時的調整。
== 巧妙利用AABB分組 ==
這個是我最後想補充的內容
想必大家都會遇到一些波動特別大的指標,類似一些收入指標,那實驗出現隨機的結果是很可能發生的,這個時候AABB分組策略能給我們提供一些資訊
假如我們實驗只是簡單的分為兩組,實際上我們還能夠將A組劃分成A1,A2,將B組劃分成B1,B2組
通過對比組間,如A組和B組的結果來衡量實驗效果
還能通過對比A1和A2,或對比B1和B2來確認組內的資料是否穩定,如果組內資料差異過大,而組間差異也表現差異很明顯的時候,這個時候就要小心我們前面提到的隨機發生的結果
因此AABB分組還夠給我們提供更多的實驗資訊,大家可以去嘗試一下。
== 後續 ==
由於篇幅問題很多內容無法開展討論,我們後續有機會再給大家分享。
本篇文章內容篇概念和理論層面多一些,後續系列文章將分享如何實戰分析的過程,會結合實際的分析工具,讓產品和運營人員也能上手做深入分析。
作者:大Fei
來源:九日論道
相關文章
- 從思路到工具 - 增長實驗資料歸因分析
- AB test 中的AA test有什麼作用?
- Python專案實戰(一)《Python程式設計 從入門到實踐》Python程式設計
- 廣告歸因-讓你徹底弄歸因架構實現架構
- Python多執行緒程式設計深度探索:從入門到實戰Python執行緒程式設計
- RocketMQ實戰系列從理論到實戰MQ
- 0503對比實驗歸因
- 【遊戲關卡設計集】從平面佈局到遭遇戰設計遊戲
- 實驗設計(DOE)學習心得
- AB test | 資料分析師面試必知 !面試
- Python程式設計從0到1(實戰篇:提取Word表格儲存到Excel)Python程式設計Excel
- 《Python程式設計:從入門到實踐》Python程式設計
- Redis 從入門到實戰Redis
- Locust 從入門到實戰
- UI 設計之AB測試UI
- 程式設計心得程式設計
- 如何設計奇幻戰場: 從《戰錘:全面戰爭》到《霍位元人:五軍之戰》
- 從2012到2021,從土木到程式設計師程式設計師
- Python 程式設計從入門到實踐5Python程式設計
- Docker從入門到實戰pdfDocker
- Docker實戰-從入門到跑路Docker
- springboot使用redis(從配置到實戰)Spring BootRedis
- Python專案案例開發從入門到實戰-1.3 Python物件導向設計Python物件
- 如何設計財務對賬系統 —— 從零到一搭建對賬中心實戰
- 從程式設計到養生程式設計程式設計
- 從0開始的數值設計實戰(一)
- 從不均勻性角度淺析AB實驗
- NOJ-演算法設計實驗-test3演算法
- 實踐心得:從讀論文到復現到為開源貢獻程式碼
- Uni-app從入門到實戰APP
- node專案從0到1實戰
- UI元件庫從0到1開發心得UI元件
- 0504邏輯歸因
- DDD研究十年心得:《複雜軟體設計之道:領域驅動設計全面解析與實戰》出版
- 反派角色的設計心得
- 7月程式設計心得程式設計
- 淺談從搜尋到動歸
- 從碼農到設計者,從單例模式入手設計程式碼單例模式