A-B-test-平臺架構設計

1、A/B test 平臺架構設計本文以一次性設計好A/B test功能架構為目的，對A/B test的使用場景與功能模塊進行了分析。 最近在考慮一個產(chǎn)品的小功能改進，目前我們的產(chǎn)品列表按照產(chǎn)品帶來的收益排序，如果用戶點擊了產(chǎn)品之后，那再點擊這個產(chǎn)品可能就無法帶來很大的收益，于是我們想到，那把用戶點過的產(chǎn)品放在產(chǎn)品列表底部怎么樣呢？ 當然團隊內(nèi)部也有不同的聲音，用戶點擊產(chǎn)品之后，可能由于網(wǎng)速、或者手滑，并沒有實際上注冊到第三方產(chǎn)品中去，那么放在產(chǎn)品列表底部可能會給用戶造成困惑，也失去了用戶第二次點擊的機會。 內(nèi)部討論過后，我們認為這是個值得做的嘗試，但應該以A/B test的方式去實現(xiàn)。根據(jù)數(shù)據(jù)，

2、來決定是否要全量覆蓋該功能。 A/B test的概念大家并不陌生，被廣泛應用于快速迭代的互聯(lián)網(wǎng)產(chǎn)品中。同時在以前的迭代過程中，我們也以其他方式進行過A/B test。 但是A/B test帶來的問題是，單個功能的A/B test是很容易做的，但與此帶來的數(shù)據(jù)統(tǒng)計拆分，每次都會帶來重復的工作量。因此比較節(jié)約的方式是，一次性設計好A/B test功能架構，支持未來的持續(xù)A/B test，降低單次測試帶來的邊際成本。一、A/B test的使用場景 從技術上講，AB測試存在兩種場景：純頁面交互A/B和功能A/B。這兩種場景的區(qū)別僅在于是否需要向后端申請不同的服務。二、功能模塊 A/B test功能模塊

3、大概有以下三個：用戶分流服務、A/B test 配置、數(shù)據(jù)統(tǒng)計。整個流程如下： 用戶訪問后，根據(jù)用戶屬性，調(diào)取用戶分流服務，根據(jù)用戶分流服務返回結果調(diào)取相應 AB/TEST 配置。 前端業(yè)務側做數(shù)據(jù)埋點，在用戶訪問時，前端做數(shù)據(jù)上報。同時自動生成數(shù)據(jù)報表，處理原始數(shù)據(jù)后給出是否采信方案的結論。2.1 用戶分流服務 用戶分流服務用于將訪問用戶分流進入對應客群。 這里我做設計的時候有一個部分很后悔，就是我曾經(jīng)做了一個版本是將用戶分類展示不同產(chǎn)品列表的功能。本質(zhì)上就是一種設定客群然后分流的服務，當時沒有考慮到后來這個功能有這樣的拓展，所以與產(chǎn)品列表與運營位配置耦合度很高。在做 A/B test 的分

4、流服務時，只能獨立再做一套。 事實上不僅用戶分流服務是一個應該與各功能模塊解耦的部分，客群服務（包括用戶信息、用戶畫像建設）也應該解耦。這兩個服務結合起來可用于：為不同用戶做定制化展示、A/B test、黑白名單等功能應用。 2.1.1 分層分流 說回用戶分流服務來，大型系統(tǒng)會遇到一個問題，我們總是希望以小范圍的測試來驗證足夠多的的假設。可如果多個部門多實驗并行，實驗之間又相互互斥的話，流量會不足。這里我們產(chǎn)生一個“域”的概念，不同域之間互斥，同一個域的不同層正交，正如下圖所示（圖片引用，具體見文末參考文章，之后不再贅述）： 不同域之間共享100%流量，例如域1分流了30%，那域2就分流70%

5、；同一個域的不同層之間，會重復使用這個域中的流量，但不同層之間，每次進入流量會重新打散，保證互相不影響；同一個層之間配置 A/B test 的實驗 A/B/N，共同分享這個域中的流量，不同實驗組之間相互互斥共享100%該域流量； 2.1.2 如何對用戶分流 用戶分流方式有三種，一般使用的是以用戶維度分流，這樣可以保證單一用戶每次進來看到的是相同實驗，不會造成體驗上的不一致：以用戶維度；以分類維度；完全隨機； 哈希因子：實驗的 Hash 因子有設備 ID、策略 ID、流量層 ID，根據(jù)具體需求，可以選擇其中的幾個因子組合后 Hash，。HashID=Hash(設備 ID，策略 ID，流量層 ID

6、)%100+1 這樣每個用戶會得到唯一的 HashID，同時會落在1，100的范圍內(nèi)，讓用戶隨機均勻散落在這個范圍內(nèi)。如果需要將流量控制的更精準，可以對1000甚至10000取余，這個根據(jù)實際情況靈活做選擇就好。 在配置實驗時，根據(jù)實際需求，為各個版本均勻切分流量。譬如A版本劃分10%的流量，則 HashID 從 0-10 的用戶被劃分到 A 版本，以此類推。2.2 A/B test 設置 AB/TEST 設置用于配置實驗，做實驗的增刪查改，同時對線上的實驗做管理，及時上下線。 管理員在 AB/TEST 配置系統(tǒng)中，新建實驗，并設置分流規(guī)則。完成后實驗配置入庫，當用戶訪問產(chǎn)品時，根據(jù)分流規(guī)則調(diào)

7、取 AB/TEST 實驗版本。 2.2.1 新建/編輯實驗step1：新建實驗step2：輸入實驗信息（實驗的基本信息、生效時間）等step3：選擇分流服務step4：選擇后端服務step4：選擇數(shù)據(jù)指標 2.2.2 管理實驗 管理實驗模塊主要用于上下架實驗。2.3 數(shù)據(jù)統(tǒng)計 A/B test 最重要的一部分是統(tǒng)計和分析數(shù)據(jù)。在建立實驗時，同步選擇需要關注的數(shù)據(jù)指標。以實時或T+1的方式，展示數(shù)據(jù)報表。在新建實驗時，可以在現(xiàn)有的埋點指標中做選擇，選擇出用于分析實驗效果的關鍵漏斗指標，生成報表。在技術實現(xiàn)上，埋點的數(shù)據(jù)上報，需增加分流服務ID。2.4 數(shù)據(jù)分析 在數(shù)據(jù)統(tǒng)計完成后，更重要的部分是我

8、們?nèi)绾胃鶕?jù)數(shù)據(jù)報表來判斷各個版本的優(yōu)劣。由于其他因素的擾動，譬如流量質(zhì)量、級別等因素，同一個實驗的多個版本會有微小數(shù)據(jù)差別，在一定程度內(nèi)的數(shù)據(jù)差別是正常波動，并不能說明某個版本更優(yōu)。因此大部分的 A/B test 系統(tǒng)采用了 T 檢驗。 為什么要 T 檢驗或者其他檢驗呢，是因為 *樣本參數(shù)=總體參數(shù)+機會誤差+偏差*，現(xiàn)在我們手里有樣本，可以計算樣本參數(shù)，但是我們想知道的是總體參數(shù)，但是這個樣本參數(shù)能不能代表總體參數(shù)呢？T 檢驗在這里就是用來判斷是否是機會誤差這個因素造成，通俗點說就是樣本得到的參數(shù)值可不可能由于是抽取的時候的隨機造成的。 2.4.1 P 值（P value） P 值檢驗用于驗

9、證假設。在 A/B test 里，原先的版本可以稱它為H0（原假設），新的版本稱為H1（備擇假設），假設就是我們認為H1版本是優(yōu)于H0的。若 P 值落在置信區(qū)間里，那我們的假設成立，若 P 值沒有落在置信區(qū)間，就認為 P 值推翻了我們的假設。 P 值越小，我們認為H1這個備擇假設越靠譜。P 值越大，H1越不靠譜。置信區(qū)間是我們自行定義的“靠譜區(qū)間”。 以上我們計算出了 T 值，通過查詢界值表，可以獲取到 P 值。 2.4.2 置信區(qū)間 剛才說置信區(qū)間是人工定義的，值你可以定義為0.05、0.1，這個根據(jù)實際情況去做選擇，1-就是置信區(qū)間，除此以外的就是拒絕域。若 p ，那么拒絕原假設；若 p ，那么不能拒絕原假設。推薦閱讀（即參考文獻） 1.【ABtest在OpenSearch上的設計與實現(xiàn)】 type=2 2.【推薦系統(tǒng)衡量：ABtest框架】 3.【馬蜂窩