1.公司數(shù)據(jù)有泄漏風險；

2.平臺功能并不完全符合公司業(yè)務(wù)發(fā)展和變動，后期改造成本較大；

3.選用服務(wù)成本不低，但是收效卻不盡人意等。

所以部分公司權(quán)衡后便決定組織人力著手搭建平臺，那么一個ab平臺究竟要如何搭建，搭建的ab平臺如何在業(yè)務(wù)中應(yīng)用，實驗過程中出現(xiàn)的異常如何應(yīng)對等一系列問題便會接踵而至。

下面我將從平臺的前期準備，業(yè)務(wù)場景、平臺建設(shè)以及異常處理四個方面來講述一下整個搭建的過程。

一、前期準備

所謂前期準備就是立項前的一個評估，評估在什么“前提”下公司可以開始投入人力搭建ab平臺。

這里的用戶量級不僅僅是指app本身、還包括具體功能使用的人數(shù)量級，再具體點來說就是進入實驗的用戶量級，ab測試之所以有科學性主要是引用了統(tǒng)計學的評估原理，根據(jù)z檢驗的公式：

可以很直觀的看出：如果樣本量很小，單個用戶的行為表現(xiàn)就具有極大的影響力，極易造成兩個版本的差異變大，無法客觀的評估實驗結(jié)論是具有統(tǒng)計學意義的。

ab實驗的原理上一章我也有所描述，整體流程類似于控制變量法，那既然是控制變量，就要通過對已知變量的控制來減少誤差對實驗的影響，即實驗過程中只對某一變量因素進行控制，因此需要在功能切分上做到相對精細化的控制，避免引入其他影響因素造成實驗結(jié)果不具備參考價值。

ab測試前期需要投入較大的研發(fā)成本，而實驗過程平均周期也需要2-3周，最終得到的結(jié)果卻不一定符合預(yù)期，甚至不一定是正向表現(xiàn)，需要反復(fù)的進行實驗探究。一次實驗從開始到最終結(jié)論產(chǎn)出的這個煎熬過程和”損失“需要我們能理性的接受。

ab測試并非是解決決策“分歧”的唯一依據(jù)，我們要以思辨的角度先去評估用戶反饋的功能是否是產(chǎn)品的主功能或者影響了主流程的使用，畢竟在實驗過程中要投入大量的人力和時間成本。

筆者在ab測試問題復(fù)盤的過程中，經(jīng)常發(fā)現(xiàn)很多無故的放大用戶需求的案例，最終的實驗結(jié)果達不到最初的預(yù)期。所以在實驗設(shè)計階段或?qū)嶒炘u審階段大家盡量做到”三思而后行“。

上述列舉的幾點是筆者認為幾個比較重要的因素，大家也可以結(jié)合自身業(yè)務(wù)特性進行其他角度的思考和補充。有了搭建ab平臺的一些前置要素。下面我們進入第二篇內(nèi)容，看一下公司中都有哪些業(yè)務(wù)場景需要進行ab測試：

列表中的是否發(fā)版用以判斷實驗變量控制位置，需要發(fā)版一般版本id要在客戶端進行版本判斷，不需要發(fā)版一般可通過服務(wù)端進行判斷，按需則根據(jù)具體功能實現(xiàn)方式來選擇。

數(shù)據(jù)來源是作為實驗效果評估的主要數(shù)據(jù)依據(jù)。例如客戶端實驗主要以sdk采集的用戶行為數(shù)據(jù)為主，服務(wù)端實驗若無法全面的獲取用戶數(shù)據(jù)，則以服務(wù)端日志為主要依據(jù)，例如push實驗，用戶不點擊push打開，則無法統(tǒng)計到用戶行為數(shù)據(jù)，只有服務(wù)端記錄的push下發(fā)相關(guān)的數(shù)據(jù)。

上面我們描述了一下平臺搭建的前期準備和適用的業(yè)務(wù)場景。本章我們拆解一下平臺如何進行建設(shè)，在開始這部分前，我選用上面一個流程優(yōu)化的場景，通過一段”日常“對話來描述一下平臺的需求都有哪些，方便大家進行理解：

業(yè)務(wù)產(chǎn)品經(jīng)理：最近收到一批忠實用戶的反饋，內(nèi)容創(chuàng)作的入口應(yīng)該從「我」中拿到主頁面，我們想調(diào)整一下看不同入口位置哪種效果最好，目前已經(jīng)設(shè)計了3個方案想搞個ab實驗，選一個最優(yōu)版本來代替當前版本上線。

平臺產(chǎn)品經(jīng)理：你們新版本大概什么時間開發(fā)好？實驗需要運行多久？

業(yè)務(wù)產(chǎn)品經(jīng)理：大概2021年1月1號能開發(fā)完，實驗周期的話預(yù)計2周時間

平臺產(chǎn)品經(jīng)理：你需要提前想一下實驗的名字，不然這么多實驗列表里不好找你的實驗。哦對了，你們這次實驗大概要用多少用戶？

業(yè)務(wù)產(chǎn)品經(jīng)理：3個方案的話加上當前對照組，怎么也得用至少總體的20%的用戶去驗證效果

平臺產(chǎn)品經(jīng)理：那下次發(fā)版時間大概什么時候？

業(yè)務(wù)產(chǎn)品經(jīng)理：預(yù)計過完年后，2月底了，這個版本功能比較多，所以如果數(shù)據(jù)效果好，看能不能通過平臺直接全量到線上，過年大家是大家分享的黃金時間，所以來不及等下次發(fā)版功能代碼開發(fā)了

平臺產(chǎn)品經(jīng)理：好滴!我們平臺馬上也要上線了，到時候可以直接在平臺操作，不會耽誤你們進度的。

從對話中我們提取幾個關(guān)鍵詞（紅字標記）：

通過簡單的一個場景描述，我們可以看到，一個ab系統(tǒng)的核心模塊至少包括以下四個：

01、實驗信息管理

該模塊主要是記錄實驗業(yè)務(wù)信息方便方便解讀和查詢，最少需要記錄以下信息：

該模塊用以確定變量版本，方便邏輯控制。同樣，需要的字段和每個字段的意義我以表格形式進行了整理：

該模塊下需要提供版本個數(shù)的增刪操作，方便用戶進行臨時版本的增加和刪除操作

實驗流量管理模塊應(yīng)該是ab平臺的核心功能之一，承載著確定變量流量，保證各版本分配的用戶成分相似。但在互聯(lián)網(wǎng)行業(yè)每天可能進行眾多的實驗，為了解決實驗流量不夠的問題，現(xiàn)通過引入流量層的方式來解決，所以實驗流量就會出現(xiàn)正交&互斥的特性，那我在這里再簡單描述一下相關(guān)知識點：

互斥

所謂互斥是指同層同時運行多個實驗，彼此占用的用戶不會被其他實驗所占用，詳見下圖：

正交  

正交是指，相同的用戶在不同層都會被隨機打散，以便以足夠離散的支持不同的實驗，詳見下圖：

那我們?nèi)绾螌崿F(xiàn)的流量的控制（離散和圈定），主要有三個方面：哈希算法、哈希因子以及流量確認。

哈希算法

業(yè)界比較常用的算法是murmurhash，共有三個版本（murmurhash、murmurhash2、murmurhash3），這種算法是一種非加密型哈希函數(shù)，適用于一般的哈希檢索操作，其優(yōu)點如下：

1）簡單（就生成的匯編指令而言）。

2）良好的分布（通過幾乎所有鍵集和存儲桶大小的卡方檢驗）

3）良好的雪崩行為（最大偏差為0.5％）。

4）良好的抗碰撞能力（通過了鮑勃·詹金的frog.c**測試。4字節(jié)密鑰不可能發(fā)生沖突，差異不大（1至7位）。

5）在Intel / AMD硬件上具有出色的性能，在哈希質(zhì)量和CPU消耗之間進行了很好的權(quán)衡。

當然還可以根據(jù)設(shè)備id的尾號進行分流，常用的分流算法有 crc_32、sha_256等，但是使用場景具有一定局限性：需要用戶量足夠大、設(shè)備id分布足夠均勻、實驗組數(shù)量不宜過多。

哈希因子

所謂的哈希因子，通俗的來講就是被哈希的對象，一般情況下設(shè)備id（deviceid）、流量層id（layerid）就夠了、還有一些統(tǒng)一測試平臺還會涉及應(yīng)用key或應(yīng)用id（appid）、美團的業(yè)務(wù)場景下還會引入?yún)^(qū)域的id（areaid），所以一個哈希因子就變成了appid_areaid_layerid_deviceid。

流量確認

通過哈希算法和哈希因子可以最終確定一個1-n的位置，假設(shè)是1-100，則某一層的總流量就是1-100，業(yè)務(wù)方通過平臺上操作的實驗版本個數(shù)和版本流量，來確定這個實驗1-100的位置如何分配，就完成了一次實驗的流量確認的過程，下圖就展示了正交&互斥的完整流量確認的流程。

實驗效果評估

通過實驗信息配置、版本和流量分配、實驗周期的控制，最后一步就是通過實驗數(shù)據(jù)來驗證版本效果好壞，那我們要關(guān)注哪些數(shù)據(jù)呢？

1）北極星指標

所謂北極星指標就是業(yè)務(wù)核心發(fā)展的重點指標，換句話說今年kpi就全靠他了，所以實驗版本的效果提升，都是采用對北極星指標正向的影響

2）業(yè)務(wù)相關(guān)指標

是指業(yè)務(wù)人員關(guān)注對策略改版本身有所影響的指標以及其他輔助指標的波動情況，從時效性上可分天級、小時級、分鐘級

3）統(tǒng)計相關(guān)信息

每個指標的p值、置信區(qū)間、統(tǒng)計功效

除了以上指標，還可以觀測ab測試版本中功能后續(xù)使用的留存情況，進一步去評估本次實驗效果是真的好，還是偶然的好

上面根據(jù)業(yè)務(wù)場景和需求講述了ab平臺搭建需要的一些基本模塊，下面我們就來將這些模塊開始有機的組裝和流轉(zhuǎn)：

頁面參考：

1）創(chuàng)建實驗

2）指標查看

除了上述頁面還應(yīng)該提供一些管理頁面，包括：用戶管理、角色管理、應(yīng)用管理（如果有多app的話）、元數(shù)據(jù)管理、流量層管理、指標管理等，這些頁面這里就不作樣例展示了，大家可根據(jù)自身業(yè)務(wù)特性來發(fā)揮想象。以上頁面展示僅為參考，為方便大家便于理解上述所描述的內(nèi)容。

業(yè)務(wù)處理流程：

上圖中藍色線代表了以客戶端為邏輯判斷的主要流程，紅色線代表以服務(wù)端為邏輯判斷的主要流程，不同的邏輯判斷位置即代表了業(yè)務(wù)架構(gòu)的差異性也影響數(shù)據(jù)獲取的方式。

除了abtestsdk請求策略層獲取版本id用以app端邏輯判斷或傳遞給服務(wù)端進行邏輯判斷外，還有通過業(yè)務(wù)服務(wù)端直接請求策略層進行邏輯判斷的方式，如push實驗，本身特性是無論是否有用戶點擊app，都需要根據(jù)push平臺進行策略下發(fā)。第二節(jié)業(yè)務(wù)場景中所描述的是否發(fā)版和數(shù)據(jù)獲取來源直接決定了ab的接入方式和效果評估的數(shù)據(jù)來源

功能框架參考：

通過前期評估、業(yè)務(wù)場景、系統(tǒng)流轉(zhuǎn)以及平臺功能的框架，基本一套完整的ab平臺就已經(jīng)初具雛形，下面我們就可以按照以下的操作流程開始進行ab實驗，對每次策略進行效果評估：

在本文的第一章節(jié)有提及，我們要理性的接受ab測試過程中得出的結(jié)論可能無效甚至與預(yù)期相悖的，不過這些也不一定是實驗本身策略的問題，那么有哪些因素會導致實驗“無效”并且怎么去解決呢？

很多童鞋在做實驗時特別著急的想去看結(jié)果，甚至迫不及待的實驗開啟幾天就已經(jīng)開始決定要上線，這樣的做法顯然是不可取的，實驗周期的長短影響主要有以下幾個方面：

a.影響樣本量的大小；樣本量決定了樣本的代表性和實驗的可參考性；

b.用戶行為習慣影響數(shù)據(jù)指標，比如節(jié)日效應(yīng)，或者例如有些工具類app工作日使用會較頻繁，周末會下降；

c.影響進入實驗的用戶情況，因每天用戶活躍情況不同，若觀測時期較短，可能會因一天的數(shù)據(jù)問題導致整體數(shù)據(jù)指標很大或者很小

d.科學的實驗周期應(yīng)該在2-4周范圍內(nèi)。盡量涵蓋到目標樣本量以及所有時間維度上（工作日、節(jié)假日）

辛普森悖論是指當人們嘗試探究兩種變量（比如新生錄取率與性別）是否具有相關(guān)性的時候，會分別對之進行分組研究。然而，在分組比較中都占優(yōu)勢的一方，在總評中有時反而是失勢的一方，我們可以通過下面的例子簡單理解一下：

目標：男生的錄取率高于女生

方式：各學院提高男生的招聘率

上面可以直觀的看到，單看商學院和法學院都是男生錄取率比較高。但是總體情況確實女生錄取率（42%）是男生錄取率（21%）的兩倍。映射到ab實驗上，實驗版本和對照版本其實分別就對應(yīng)的是女生和男生的錄取率，辛普森現(xiàn)象的本質(zhì)是通過加權(quán)平均引起的，而且樣本量越大越容易出現(xiàn)這種情況。

所以如果要規(guī)避這個問題主要采用：

1）策略上線前，要盡可能的進行多維度分析，找出可能會影響的因素；

2）實驗分流前盡量選取合適的樣本量，避免因樣本量過大造成的反結(jié)果；

3）實驗方案設(shè)計時，要在相同量級的維度下進行實驗。例如為了節(jié)省成本，將一個策略同時在雙端進行實驗，但本身android的用戶量會大于ios，實驗結(jié)論從整體看效果是正向的，但實際ios可能完全與其相悖

“幸存者偏差”是指，當信息來源，僅來自于幸存者時（因為死人不會說話），這個信息可能會存在與實際情況不同的偏差。所以大家在實驗結(jié)果分析過程中，不僅僅要看用戶行為數(shù)據(jù)與有版本id用戶（即進入實驗的用戶）產(chǎn)生的指標情況，還應(yīng)看有版本id的用戶中具體觸發(fā)這些用戶數(shù)據(jù)的表現(xiàn)情況，綜合來評判版本實驗效果。

為了保證實驗?zāi)茉诳蛻舳朔€(wěn)定運行，避免造成實驗組和對照組來回波動的情況，一般會采用緩存策略。但在實際進行ab實驗時，存在對已經(jīng)結(jié)束的實驗進行重新開啟的情況，此時這個”新實驗“會受到之前實驗分桶流量的影響；同時還要考慮每次啟動app時請求分桶流量的時機，盡量保證實驗組和對照組在沒有波動的情況下獲取到最新的分流策略。

樣本量的大小影響顯著性水平、統(tǒng)計功效等。樣本量太小，不具代表性，得出的結(jié)論不可信；樣本量太大，容易導致辛普森悖論，需要的實驗周期長，同時流量有限又不能無限擴大，那多少樣本量合適，我們可以根據(jù)公式進行反推，也可以用樣本量測算工具（https://www.evanmiller.org/ab-testing/sample-size.html）計算。

在實際測試操作中，很多童鞋也會有這樣的問題就是，既然我們統(tǒng)計的都是轉(zhuǎn)化率這種相對指標，是不是我們實驗組和對照組的樣本量可以不相等，比如對照組1000人，實驗組5000人，針對于這種問題，我們可以進行個假設(shè)：若實驗組的流量是最小樣本量，那證明對照組樣本不夠，極容易導致實驗不可科學；

若對照組是最小樣本量，那”過載“的用戶樣本，會導致用戶數(shù)據(jù)偏移、樣本數(shù)據(jù)“浪費”以及辛普森等問題。所以大家在實驗過程中要盡量保證不同版本的樣本量一致。

業(yè)務(wù)童鞋在使用我們搭建好的平臺，無論實驗做的如何：可能是實驗結(jié)果不符合他們預(yù)期，也可能是因業(yè)務(wù)接入問題導致實驗失敗，即使ab平臺沒問題也會先被質(zhì)疑一番。

而分流是否合理便是第一個被質(zhì)疑的對象，所以作為平臺方我們即使用了當前最牛的分流算法，在平臺功能上也要提供：分流數(shù)據(jù)實時、小時的進入流量的情況以及不同畫像特征維度下實驗組和對照組的數(shù)據(jù)分布情況，如果十分有必要甚至可以讓業(yè)務(wù)每次實驗都應(yīng)該進行aab實驗，用aa實驗結(jié)果的準確性來保障平臺的可信度。

雖然aa實驗是驗證ab平臺數(shù)據(jù)準確性的有效手段，原則上aa實驗（實驗組和對照組的策略一模一樣）的數(shù)據(jù)表現(xiàn)應(yīng)該是一致的，但是有時候卻發(fā)現(xiàn)兩組指標竟然出現(xiàn)了差別，即使反復(fù)驗證也會出現(xiàn)這種情況，這種情況就是aa實驗的波動性。

導致這個問題的主要原因就是抽樣的隨機性，舉個簡單的例子：即使同樣性別的雙胞胎，經(jīng)過相同條件下培訓，最終答題的分數(shù)也不一定是一模一樣的。所以如果要解決這個問題，可以考慮適當提升aa實驗樣本量的大小，在一定程度上可以抵消這種波動性。

五、總結(jié)

A/B測試作為當前互聯(lián)網(wǎng)領(lǐng)域用戶增長、精細化決策的核心技能，越來越多的被各家公司作為基礎(chǔ)能力所要求。

本文我們簡單總結(jié)了一下ab平臺系統(tǒng)搭建以及大家在平臺使用過程中會遇到的一些問題，如果是此時你正需要搭建一個ab平臺，希望讀完后能起到一定的啟發(fā)作用。

如果是平臺的使用方，希望可以讓大家加深對ab測試的理解。通過異常處理章節(jié)中的內(nèi)容我們也可以看到，想做好一個科學的ab實驗并非一件容易的事，需要大家積極拆解業(yè)務(wù)，理解ab測試原理和流程，以及統(tǒng)計學的相關(guān)知識。

希望大家可以在工作中靈活運用這一技能，為企業(yè)帶來更大的增長效益。

-END-