【干貨】AB實驗助力用戶體驗升級（含直播回放）-有解無憂

本文根據4月14日淘系技術前端團隊出品的「阿里淘系用戶體驗優化前端實戰系列直播」——《AB實驗助力用戶體驗升級》整理而成，

（直播回放）

為什么AB實驗能夠提升用戶體驗

我們先從一個例子說起，上圖中是一個購物頻道的首頁，產品經理在思考頁面上可能會影響到用戶體驗的因素，他想到這樣一個問題，頁面重復樣式的營銷模塊過多，導致底部的精選分類模塊無法在首屏透出，從而影響了用戶體驗，試想，如果用戶在首屏就能看到精選分類模塊，可能會幫助到他們更快的定位想要類目的商品，基于這個思考，產品經理和設計師一起設計了實驗組方案，即，將原來多個重復的營銷模塊合并為一個，這樣底部的精選分類模塊就可以在首屏展示了，我們設計了一個AB實驗來論證新方案的有效性，將頻道用戶均勻的分為兩組，各50%，分別對應兩個首頁，實驗上線后，我們對兩組的用戶行為資料進行對比分析，實驗組的各個指標的確都優于原首頁，我們在整個實驗周期內，對核心指標（如，點擊率）進行觀測，發現實驗組的優勢是穩定存在的，基于這個結論，產品經理選擇固化實驗組，

基于前面案例，我們了解了AB實驗的基本流程，從產品經理產生猜想，到設計實驗，再到實驗上線后，我們對資料進行采集分析，并最終做出決策，一個實驗的生命周期，實質上就是一個人從思考問題到論證問題的程序，回到本節最初的問題，為什么AB實驗可以提升用戶體驗，我認為有以下三點：

AB實驗是一種我們與用戶的溝通方式；它讓我們業務同學，技術同學都能夠站在用戶的角度去思考問題，通過實驗我們了解到用戶的真實需求，前端UI的迭代是用戶需求驅動的，而不再是“憑經驗拍板”；
AB實驗將用戶體驗具象化；用戶體驗是一個抽象的名詞，從前面的例子我們也看到，在實驗中我們將用戶體驗轉化為客觀可量化的資料指標，并根據資料結果更準確的衡量用戶體驗的提升或者下降；
AB實驗的科學性，可以極大程度的保證資料的準確性，即我們從資料中提煉出的用戶需求是可靠的，實驗的科學性體現在分流模型，及底層的決策模型等等，我們在下一章節進行詳細的介紹，

前端AB實驗技術原理

一條完整的AB實驗鏈路到底需要什么？創建實驗，工程接入，分流，實驗資料回流...恩，是的，我還可以列一大堆，但是它們沒有組織不成體系，就毫無意義，更談不上架構設計，所以，我們來把這些分散的元素嘗試歸類，

一條完整的AB實驗鏈路其實可以拆分成三部分，第一部分是實驗配置，顧名思義它包含了所有與實驗配置相關的操作，配置創建，分組，配置的推送或下發，第二部分，在前端工程運行時我們讀取實驗配置，并進行分流，并將分流結果進行埋點上報，第三部分是實驗資料，它包含實驗資料的計算，存盤及展示(實驗報表)，接下來我們就基于這三部分展開來聊一聊其底層設計原理，

? 實驗配置模型

它核心解決的問題是，如何將實驗配置按照合理維度進行組合并下發？我們線上運行著數千個實驗，如果簡單的把每一份實驗配置進行單獨存盤并下發，很快實驗配置會多到無法管理，且在多實驗并行的頁面上也會非常影響性能，如果把所有配置都放到同一個檔案里，那顯然更不可行，所以找到這樣一個合適的維度來對實驗配置進行組合非常關鍵，我們引入了前端應用的概念，前端應用我們可以理解為一個前端工程，一個小程式可以是一個應用，或手淘內某個頻道(比如淘金幣)也可以是一個應用，我們將實驗配置以應用為維度進行組合，然后推送到CDN，前端運行時則通過JSSDK讀取配置，完成分流并渲染相應的業務組件，

應用里面包含了場景，一個獨立的流量入口我們稱之為場景，比如某應用的首頁就是一個場景，導購頁也是一個場景，每個場景(頁面)下都運行著一個或多個實驗，實驗是在場景里完成分流的，換句話說，場景是我們底層的分流模型，

? 分流模型

實驗在場景內并不是無序放置的，場景里有很多層(layer)，大家可以將層簡單的理解為一個數學區間，比如[0，100)，這個區間代表著該場景下100%流量，在場景里，每個實驗都是放置在相同或者不同的層里的，比如上圖中，實驗一有AB兩組，各占50%的流量，且實驗一占據了一整個層，這意味著，A組占據了該層(區間)的前50%，即[0,49]，B組占據了后50%，也就是[50,100)，

穩定分流

當一個用戶進入該場景，我們會首先讀取他的唯一id，這可以是他的web設備id，也可以是userid，總之它可以唯一且穩定的標識一個用戶，然后我們會將這個唯一id作為入參，運行一個Hash演算法，該演算法的結果一定是落在層這個數學區間上的某一個位置的，以實驗一為例，如果Hash演算法的結果處于該層的前50%，那么該用戶命中了實驗一的A組，反之則是B組，由于唯一id是穩定的，這位用戶不管多少次訪問當前場景，他落在某個特定層(區間)上的位置也是穩定的，因此他也會穩定的被分流到實驗一的A組，

穩定分流保證了線上用戶體驗的連續性，從而大大提升了用戶行為資料的可靠性，

實驗的正交、互斥及推全

統一場景下常常運行著多個實驗，如何來處理不同實作之間的相互關系，來滿足復雜場景下的業務需求，還是以上圖為例，該場景下同時運行了三個AB實驗：

實驗一，紅包權益彈層有AB兩種樣式，觀測指標是兩個彈層的點擊率；
實驗二，頁面頭部商品模塊有AB兩種樣式，觀測指標是模塊點擊率；
實驗三，運營投放的營銷banner有AB兩種設計，透不同利益點，觀測指標是banner點擊率；

現在的問題是，實驗二和實驗三都是頁面上的模塊，我們希望這兩個實驗同時運行，但不希望它們互相影響，即進入實驗二和實驗三的流量必須互斥，如何做到呢？如上圖所示，實驗一獨占一層，它與下一層的實驗二和實驗三是正交關系，即進入實驗1的流量，同時也會進入實驗二或實驗三，我們把實驗二和實驗三放在同一層，因為我們希望進入實驗二的流量不要與進入實驗三的流量重疊，即他們各自占據了層(區間)上的一部分流量，通過這樣的方式我們實驗了，在一個場景里，層與層之間的實驗流量正交，層內的實驗流量互斥，

在上面的模型圖中我們還看到一個特殊的層，發布層(Launch Layer)，這個層用來放被推全的實驗分組，比如說，經過線上驗證實驗一的A組效果明顯優于B組，用戶在平臺側將A組推至全量，這時候場景內部結構會發生變化，即實驗一的A組會從原來的layer被放到這個特殊的發布層里，此時該場景內所有觸發實驗一的流量將不會再執行分流演算法，而是直接回傳組A所對應的前端組件，

? 實驗資料模型

每一個實驗所關注的資料是不同的，如何為不同的實驗產出其對應的資料報表？我們引入了業務域，它是資料指標的集合，同一業務域下的實驗可以創建并關聯這個業務域下的所有指標，形成實驗與指標的映射關系，在計算實驗資料時，我們會首先讀取該映射關系，確定要計算的指標有哪些，然后再進行計算，這樣也極大程度的節省了計算資源，

? 前端AB實驗架構設計

有了前面的知識基礎，我們來看看完整的前端AB實驗架構設計，首先綠色的部分，對于第一次入駐AB平臺的業務，我們需要進行相關作業空間的注冊，應用，業務，及場景，對應前面提到的三個模型，

創建完作業空間以后，我們開始核心的實驗創建鏈路，這里包含了實驗的基本資訊的讀取，分桶設定(流量分配)，接下來是創建指標并將指標與實驗關聯的程序，然后是實驗發布，正式發布前，有一個beta發布環節，beta發布可以理解為實驗上線前的一次“非正式”下發，開發者和業務方可以在beta發布后對實驗分流、資料及相關業務邏輯進行充分驗證后，再正式發布，當然，實驗是支持多次發布的，即實驗中期業務方可以回到流量分配這一步，重新調控流量比例，并重新發布實驗，

然后是藍色部分AB實驗的JSSDK，先從前端工程說起，我們在工程里引入了一個業務AB實驗組件，該組件是AB平臺根據用戶的配置動態生成的，作為(AB實驗相關的)業務組件與頁面(或父容器)的銜接器，其核心作業就是讀取AB實驗所需的引數并傳入SDK，以此觸發SDK的整個AB實驗邏輯，

首先從全域來看，我們把JSSDK拆成了兩個包：

一個是核心(Core)包，封裝了通用的核心邏輯如實驗配置讀取及快取策略，實驗周期控制及分流演算法；
另一個是接入具體DSL工程的銜接器包(Coupler)，如圖所示，它就像是一個AB實驗流程的中轉站，它實作了一套介面函式，即在特定DSL環境下(如React)的請求、快取及cookie決議(分流因子)，并將這些介面函式和實驗引數一起透傳給Core，我們這么設計的目的是實作Core與前端DSL的徹底解耦，這樣極大的增加了JSSDK的可擴展性，

在拿到實驗引數，及所需的介面函式以后，Core要做的作業就是先獲取實驗配置，此時Core不會直接去請求實驗配置，而是觸發版本控制策略，該策略主要是檢查遠程實驗配置的版本號是否更新，若有更新才會去請求配置，否則會讀取本地快取的配置，這份本地快取的配置是用戶第一次觸發實驗時從CDN請求并快取下來的，之后每次版本更新，才會重新請求并更新快取，拿到實驗配置后，Core會確認當前事前是否處于實驗周期(AB平臺側配置)內，校驗通過后才會正式觸發分流演算法(見下一章節)，然后將分流結果回傳給Coupler，

Coupler接著會根據分流結果來判斷應該展示哪個對應的業務組件，同時它會將分流結果上報給平臺，用戶此時已經可以在實驗的實時資料報表看到分流資料了，技術同學可以通過實時資料來確認實驗是否正常觸發，另外，埋點組件會對命中的業務組件做一層封裝，這里會傳入可供業務組件呼叫的埋點上報方法，具體的呼叫我們在AB平臺創建實驗時，就已經生成好了，前端同學是需要將這些上報實驗指標的代碼部署到相應的業務即可，這一部分埋點資料是T+1的，業務方可以在平臺側看到相應的實驗報表，并分析實驗結果，

為了快速覆寫所有的前端場景，我們在設計上慎重的考慮了JSSDK的易擴展性，這也是為什么我們在上一節的Rax 1.0方案中，將JSSDK拆成了Core和Coupler兩個包，我們的思路是Core封裝AB實驗的核心邏輯，不依賴任何前端DSL，在Core與前端工程之間引入一個"銜接器"包，來串聯起整條鏈路，這樣如下圖所示，我們可以通過這樣的架構，非常低成本的擴展到React，小程式，Node FaaS等等，同時也具備良好的可維護性，

我們是如何做到將核心包(Core)與這些DSL徹底解耦的？我們定義了一套介面規范，然后在"銜接器(Coupler)"包中根據這個規范實作一系列的介面函式，當Core在執行某段邏輯呼叫這些函式時，根本無需關心其底層用的是哪一個DSL的API，比如對localStorage的操作，React和小程式的API是完全不一樣的，所以我們在React和小程式的"銜接器"中按照介面規范各自實作了這樣一套對localStorage的處理函式，并透傳給Core，

? 前端AB實驗資料鏈路

在前端工程運行時，分流之后展示相應組件，并觸發相關的埋點，如下圖所示在埋點引數中，我們會帶上實驗引數，即實驗發布id和分組id，實驗發布id是什么呢？前文提到在實驗運行中，我們允許業務重新調控流量比例，并發布實驗，也就是說一個實驗是可以多次發布的，所以實驗發布id可以標識采集到的資料是當前實驗的某一次發布；這也就是所謂的資料染色程序，

資料上報后，在日志系統形成實時資料流，在資料庫會存盤到T+1的離線表，我們前面多次聊到了創建資料指標并將其指標與實驗系結，建立實驗與指標的映射關系；在平臺側，我們會讀取這個映射關系，并以此為依據進行對應資料指標的計算，計算結果會以KV形式存盤在非關系型資料庫中，便于快速讀取，最終我們在平臺產出資料報表供用戶分析決策，

資料積累到什么程度可以進行進一步決策呢？AB實驗平臺底層的統計學模型會對我們當前搜集到的資料進行進一步的計算，幫助業務同學進行風險評估，目前業界運用比較廣泛的兩種方式，一種是頻率學派，對各個指標進行顯著性檢驗(計算p值)，另一種是今天要給大家介紹的貝葉斯模型，

基于貝葉斯演算法的風險決策模型，主要計算的是轉化率的概率分布，公式中，θ代表的是我們關注的轉化率指標，比如，點擊率，成交轉化率等等；X代表當前已經采集到的資料，p代表概率，那么貝葉斯公式計算的結果 p(θ|X) 代表的意義就是基于當前資料X，轉化率指標θ的概率分布，

我們模擬一個簡單的實驗來進一步說明，假設現在有A、B兩個按鈕，我們關注的指標是它們的點擊率，那么套用貝葉斯公式，我們要計算的，就是基于已采集到的資料X，兩個按鈕點擊率的概率分布情況，

上圖中，我們繪制了隨著X的增加，兩個按鈕點擊率的分布曲線(概率密度函式，PDF)，藍色曲線代表按鈕A，黃色代表按鈕B，x軸代表點擊率，x周與曲線之間的面積代表概率密度，當采集到的資料極少的時候(圖1)，我們隊兩個按鈕的點擊率的分布估計是很不"自信"的，它們的PDF在0到1之間都有取值，且兩條曲線有大面積的重合，這樣我們也很難判斷它們哪個是更好的模型，

但是隨著采集資料的增加，兩條曲線發生了變化，它們在x周上的取值區間越來越狹窄，這意味著我們隊兩個按鈕點擊率的估計越來越準確，直到最后一張圖，我們看到代表按鈕A的藍色曲線，點擊率集中分布在0.6到0.7之間，而代表按鈕B的黃色曲線，點擊率集中分布在0.35到0.45之間，到這個程度已經很明顯，A的點擊率分布是優于B的，這是否意味著可以推薦用戶固化A組了呢？其實還不夠，我們繼續看看下面的風險評估流程，

我們不斷收集資料，并對A、B的點擊率的概率分布進行建模，然后比較兩個模型的優劣，并得出A是更好的模型，這時候我們會進一步計算基于A的損失函式，我們會最終得到一個值，這個值代表選擇A而這個選擇是錯誤的概率密度，我們會預先設定一個閾值，如果計算出選擇A的損失是高于這個閾值的，我們會進一步采集更多的資料，并重復上面的流程，如果低于這個閾值，那么可以認為當前決策的風險是可接受的，我們這時候才會推薦用戶去做進一步決策，

案例分享

? 花唄分期小程式

這個實驗中，兩個模塊樣式完全一致，唯一變化的是其利益點，一個是展示日均價格，另一個是展示分期價格，業務方的猜想是日均價格利益點能帶來更好的體驗，因為它幫助用戶做了更進一步的計算，所以預期展示“日均xx元”利益點的點擊率要優于“￥xxx/期”利益點，

而實驗上線后，我們發現結果與我們的預期完全相反，從累計資料以及每日趨勢資料得出，在曝光一致的前提下，￥xxx/期利益點比日均xx元利益點點擊率穩定高出了20%，可見用戶想要的跟我們的認知其實有著很大的出入，這引起了我們想要進一步探索頻道利益點的想法，于是設計了下面的組合實驗，

如上圖所示，我們將首頁的各個模塊，通過不同利益點組合，并強化某一利益點的方式呈現，希望尋找不同組合方式下的最優方案，我們將頁面拆分成兩個實驗，實驗一，將首屏的一拖三模塊均分為三組，將日均，分期及期數三個利益點組合，并強化其中一個利益點；實驗二，將底部商品feeds流模塊分為四組，分組策略與實驗一相似，結合前文提到的溫流模型，這兩個實驗屬于正交關系，也就是說我們將首頁流量排列組合成12(3x4)組，我們期望根據實驗資料，最終得到最優的組合，

兩個實驗在線時間兩周，從資料報表看出，實驗一的第三組的表現要優于其它組，其中全引導寶貝訂單UV及直接引導寶貝訂單UV與另外兩組的差別僅為1%，可以認為是持平，但其中全引導寶貝及訂單數均有10%左右的增量，當然我們也觀測了每項指標的在兩周內的變化趨勢，此處以直接引導寶貝UV為例，第三組強化期數在實驗周期內的確穩定優于其它組，同樣的方式我們分析實驗二的資料，通過觀測多項指標在實驗周期內的均值，及其變化趨勢，第四組相對表現更好，通過實驗資料，業務最終決定固化實驗一的第3組，和實驗二的第4組，這是我們從兩個實驗正交，排列組合形成的12個分組中，得到的最優解決方案，

? 虛擬充值

虛擬充值業務，10元20元的小面額有一定概率缺貨，給用戶帶來不好的體驗，我們認為，如果能優化這一點，會讓更多的用戶使用該頻道的充值服務，從而提升頻道的GMV，和充值UV，于是我們設計了實驗組1，也就是把常缺貨的小面額折疊起來，將其它供貨穩定的面額提前，實驗上先后，相較于對照組，實驗組1的GMV的確有提升，但支付UV下降了，我們分析這是由于頻道有一部分用戶是傾向于充值小面額的，但實驗組1將小面額折疊起來，導致這部分用戶放棄了充值，這顯然不是一個理想的方案，于是我們設計了實驗組2，將所有面額展示給用戶，實驗組2的確帶來了GMV和支付UV的提升，這是一個滿足我們預期的方案，但產品經理認為，這種方式的一個問題是，充值模塊占用首屏過多的空間，

進一步思考，實驗組1方案之所以不可行，是因為我們認為它犧牲了一部分喜歡充值小面額的用戶的使用體驗，那如果我們圈選出一部分本來就喜歡充值高面額的人，在這個特定的人群下進行實驗，效果會是如何呢？實驗結果是，在這個特定人群下，實驗組1實作了GMV和支付UV的提升，于是在這個特定人群下，我們固化了實驗組1，

總結

本次分享為大家深入介紹了AB實驗的底層原理，以及前端AB實驗的架構設計，我們也提供了豐富的案例，為大家介紹了如何運用AB實驗技術提升用戶體驗，希望大家有所識訓，AB實驗在前端的應用我們還在持續探索，如何進一步降低UI實驗的成本，進一步提升實驗性能，是我們接下來希望能回答的問題，如果你也感興趣，歡迎加我的微信MrMarc隨時與我交流，謝謝大家，

直播疑問權威回應

大寶貝詹姆斯段哈哈

分析和決策可以自動化嗎？

黃昱

黃鈺2.jpg

是有這個能力的，但我們目前采用的是智能提醒的方式，如果當前實驗下某個分組優化率已經達到預期，那么我們會通過釘釘秘書提醒這個實驗者去根據實驗報表做出決策，但這個最終的決策權還是交給用戶的，

我們認為實驗和演算法還是有著本質的區別，他們有各自擅長的領域，實驗是輔助人去對一個假設做出科學論證，基于這一點我們希望用戶在這個實驗的程序中完成一個完整的思考，而不是我們代替他去決策，所以可以自動化，但是它目前是以智能提醒的方式存在的，去做分析決策的依然是實驗者，