Growth Hacking：移動端 ABTest 在支付寶 App 內的落地與應用

| 導語

近年來，隨着互聯網的快速發展，Growth-Hacking 已是一個很廣泛的概念。Growth-Hacking 的目的就是使用更小更靈活的成本經過數據驅動來挖掘產品增加的奧祕。同時在 AARRR 這個模型中，打形成一個不斷優良循環的流程，須要從數據分析中發現產品功能、運營策略與轉化之間的相關性，思考他們之間因果關係。

One accurate measurement is worth more than a thousand expert opinions

– Admiral Grace Hopper

如何衡量思考、創新想法的正確性？數據是最好的衡量標準，這就所以要求咱們須要運用一些工具。而 AB 測試就是一個快速試錯，用戶影響儘量小，經過數據科學決策的工具，它是 Growth-Hacking 最基礎也是最重要的工具之一。

自 2000 年穀歌工程師將 ABTest 應用在互聯網產品以來，A/B 測試在國內外愈來愈普及，逐漸成爲互聯網數據驅動產品的重要體現，經過 A/B 測試來驅動產品設計迭代優化。

什麼是 ABTest

A/B 測試以數據驅動爲導向，能夠實現靈活的流量切分，使得同一產品的不一樣版本能同時在線，經過記錄和分析用戶對不一樣版本產生的行爲數據，獲得效果對比，最大程度地保證結果的科學性和準確性，從而幫助人們進行科學的產品決策。

ABTest 的主要組成部分

下圖是一個通用的架構設計：

整個架構包含如下部分：

• AB 測試管理平臺：實驗操做門戶，提供建立、修改、關閉實驗等，而且提供報表查看。
• 配置數據庫：實驗配置數據，不只僅侷限於普通的關係型數據庫，也可能有緩存數據庫等。
• 分流服務：根據實驗配置數據，實驗具體的分流邏輯，這個通常集成在各個業務平臺或者業務服務器。
• SDK：提供通用的解析分流邏輯，通常集成於客戶端，前端。
• 數據採集：分流結果日誌，用戶行爲日誌的實時採集。
• 數據分析：實時和離線數據分析，經過必定的數據分析算法作出科學決策。

ABTest 的統計學原理

從 A/B 測試的試驗原理來看，它是統計學上假設檢驗（顯著性檢驗）的一種形式：假設檢驗中的參數檢驗是先對整體的參數提出某種假設，而後利用樣本數據判斷假設是否成立的過程。

邏輯上運用反證法，統計上依據小几率思想：

• 小几率思想是指小几率事件（顯著性水平 p < 0.05）在一次試驗中基本上不會發生。
• 反證法是指先提出假設，再用適當的統計方法肯定假設成立的可能性大小；如可能性小，則認爲假設不成立。

具體到對比試驗，就是假設測試版本的整體參數（優化指標均值）等於對照版本的整體參數，而後利用這兩個版本的樣本數據來判斷這個假設是否成立。

檢驗假設的基礎概念

• 原假設：又稱零假設，H0，一般咱們都是假設對比實驗中的兩組統計量的統計值同樣，即實驗組的均值等於對照組的均值。
• 備擇假設：也做對立假設，即否認原假設;實驗組均值不等於對照組均值。
• 雙側檢驗與單側檢驗：若是備擇假設沒有肯定的方向即"≠",則爲雙側假設。若是有特定的方向，包含「>」 或 「<」的則爲單側檢驗。
• 檢驗統計量：在檢驗假設時所使用的統計量稱爲檢驗統計量，好比樣本組的均值。
• 接受域：使原假設接受的那些樣本 (X1,X2,...,Xn) 所在的區域。
• 否認域：使原假設被否認的樣本構成的區域。
• 簡單假設與複雜假設：不管是原假設或者備擇假設，只包含一個參數則爲簡單假設，不然爲複雜假設。

兩類型錯誤

• 第 I 類錯誤(棄真錯誤)：原假設爲真時拒絕原假設；第 I 類錯誤的機率記爲 α(alpha)。
• 第 II 類錯誤(取僞錯誤)：原假設爲假時未拒絕原假設。第 II 類錯誤的機率記爲 β(Beta)。

真實狀況\實際決策	接受 H0	拒絕H0
H0爲真	正確判決	第一類錯誤
H1爲真	第二類錯誤	正確判決

• 功效函數：設 R 表示一個檢驗的拒絕區域，

顯著性水平和統計功效

• 顯著性水平：顯著性水平是指在原假設爲真時而被拒絕的機率或者風險，也就是發生類型一錯誤的機率α。一般在 AB 測試中，咱們設置顯著性水平爲 0.05，當求得的 p-value 即 p<=0.05，那麼拒絕原假設；p>0.05，那麼不能拒絕原假設。
• 統計功效：統計功效，簡單說就是真理能被發現的可能性。就像胰島素能下降血糖這事是真實存在的，但人類能發現它的機率是多少？若是統計功效是 0.8，就是說人類有 80% 的機率能發現它。它的數學定義可用一個公式來歸納，統計功效=1-β。

p-value 計算

AB 測試中 p-value 的計算和區間估計的計算是相對應的，這個裏面咱們就利用雙樣本 Z 檢驗，簡單說明一下 p-value 的計算公式：

• 均值類指標：

• UV 點擊率/轉化率等比率類指標：

根據 Z 值求 p 值，其實就是求標準正態分佈的積分，求(z,∞)的N(0,1)的積分*2.

mPaaS ABTest

螞蟻金服內部也有濃厚的實驗文化，ABTest 實驗平臺已累計運行上萬個實驗：從支付寶客戶端樣式實驗、交互實驗到後端算法、策略實驗都有着豐富的案例積累，在此過程當中 ABTest 平臺也獲得了深度錘鍊和能力積累，愈來愈簡單易用、成熟穩定、權威可信。

目前，ABTest 平臺已完成產品化改造，併入駐到 mPaaS 產品體系中，爲 mPaaS 的智能化能力構建提供了有力的支撐。

實驗模型

在進一步介紹 ABTest 架構以前有必要討論一下 ABTest 的實驗模型：

流量的隔離和複用

同一批用戶若是同時參與多個實驗，實驗場景之間若是是相關的，兩個實驗之間的結果就可能相互影響，致使實驗結論不正確。所以咱們須要讓同一個用戶在同一段時間只能參與一個實驗，從而避免多個實驗致使的影響，稱之爲流量的隔離。

隨着線上實驗的增多，流量隔離避免不了流量不足以及流量飢餓的問題，這就對流量的複用提出了要求。

Google的層域架構

在 Google 2010 年發佈的《Overlapping Experiment Infrastructure: More, Better, Faster Experimentation》 這篇文章中，主要介紹了 Google 的交疊實驗架構，目的是可以提供一個 Better & More Faster 的實驗平臺。

關於 Google 提出的交疊實驗架構，其核心是層域模型：

經過上圖咱們能夠了解層域模型的基礎結構了，這類結構不只可以兼容單層實驗和多變量實驗，同時更具靈活性，能夠對系統參數進行多種組合劃分。

由於層域之間的複雜關係，這樣設計雖然增長了靈活性可是同時使得業務方使用成本也大大增高，實際業務中主要仍是基於單層實驗，當整個鏈路中，每一個分支都是相互獨立，而每一個分支的子集劃分也比較清晰，因此對域的需求並非很強。

ABTest 的領域模型

mPaaS ABTest 的領域模型：

mPaaS 上的 ABTest 經過「實驗室」實現了一個分層，即每一個「實驗室」都擁有獨立的 100% 流量。因爲實際業務的一個鏈路並無不少的參數而且參數間是否獨立也是比較明確的，因此 ABTest 弱化了域這個概念。

• 實驗室

100% 的流量入口。支持設置參數的默認值兜底。業務上相互獨立的每一個業務應該擁有一個獨立的實驗室。

• 實驗

每一個實驗室下能夠建立多個實驗，實驗間的流量是互斥的，達到流量隔離的目的。同時實驗級別支持圈人定向條件，支持定向實驗。

• 實驗版本

一個試驗下能夠建立多個實驗版本，實驗版本上綁定實驗參數的實驗值。每一個版本的的流量分配經過和 10000 個 bucket 間的映射關係來分配。

ABTest 架構

從架構上來說 ABTest 分爲接入層、核心能力層和底層依賴層，下面重點介紹下接入層和核心能力層。

接入層

接入層解決業務系統如何接入 ABTest 組件的問題，互聯網業務的 ABTest 一般分爲兩類：客戶端實驗和服務端實驗，接入層對這兩類型實驗都提供了支持。

客戶端實驗

客戶端實驗一般是針對客戶端的樣式、交互流程進行實驗，從而幫助產品和研發團隊進行更好的迭代和優化。

實驗配置經過客戶端動態配置服務（Remote Config）觸達到客戶端，客戶端業務經過從本地 local cache 中取變量的方式，拿到分流結果對應的實驗變量及值，作對應的差別化渲染，達到對不一樣的用戶提供不一樣服務、體驗的目地，同時動態配置（Remote Config）服務會記錄分流日誌，回傳服務端。

H5 容器、小程序框架集成 Remote Config，經過 Hybrid API 暴露服務給 H五、小程序，這樣客戶端 Native、H五、小程序三大開發框架都具有了 ABTest 的能力。

服務端實驗

服務端實驗一般是對服務端策略、算法作實驗，是 AI 能力迭代的基礎。

性能、接入難度是服務端業務系統接入 ABTest 比較關心的問題。ABTest 將分流服務抽離出獨立SDK，將實驗配置信息保存在內存中，集成進宿主系統後能夠提供本地的分流服務，避免了網絡開銷。同時SDK提供了簡單易用的接口，下降了使用的難度。

下圖是分流SDK和ABTest Console、宿主系統之間的關係：

集成分流 SDK 有必定的開發成本，須要業務系統接入。mPaaS 平臺在各個流量入口組件中預置了分流 SDK 提供分流服務，簡化了 ABTest 的接入工做：

網關服務 MGS 將分流參數在請求上下文中透傳到業務系統中，業務系統能夠直接使用 ； 發佈服務 MDS 的 H5 離線包管理平臺能夠直接對一個 H5 應用的不一樣版本作 ABTest； 智能投放 MCDP 能夠支持對不一樣廣告投放效果作 ABTest。

核心能力

關於 mPaaS ABTest 的核心能力，它已經達到了一個通用 ABTest 系統所應有的標準，主要分爲兩部分：

實驗能力

實驗能力主要包括實驗管理、指標定義、圈人定向、分流服務、灰度推全。咱們圍繞「實驗生命週期 & 科學流量分隔」着重展開：

• 一次實驗的生命週期包含「建立實驗、功能和鏈路驗證、正式運行、逐步放量、全量推全」五個階段。而在實驗狀態轉換過程當中，流量的分配是否科學很是重要。
• 在一個實驗室下，每一個用戶經過 Hash 算法被綁定到 0~9999 號桶上，而實驗版本保存對桶號的映射
• ABTest 經過將流量劃分爲空閒桶、回收桶、使用桶三種狀態，在流量分配過程當中優先使用空閒桶，其次使用回收桶。在回收桶也分配完以後，整個實驗室的流量已經使用完畢，須要同實驗室下其餘實驗推全或者下線後，使用桶被回收後才能新建實驗。ABTest系統在實驗生命週期流轉過程當中科學的分配、回收流量（即改變桶的狀態）保證了流量分配的科學性，下降了對用戶的打擾。

分析能力

分析能力包括實時的分流 PV/UV 統計，T+1 的實驗顯著性報表以及多維分析和對比分析。

實驗分流數據分爲客戶端分流埋點和服務端 ABTest SDK 分流日誌兩種，分別經過日誌網關和 flume 收集到 HDFS 中。實驗效果統計經過 mPaaS 客戶端 SDK 自帶的自定義事件埋點經過日誌網關和 flume 迴流到 HDFS。

• 實時計算鏈路

數據經過 Kafka 導入 Kepler，kepler 任務進行分流日誌和業務轉化日誌的雙流 join，和實驗 PUV 統計，最終將計算結果轉儲至 HBase，ABTest Console 展示結果。

• 離線計算鏈路

數據經過 flume 導入 HDFS，由離線計算平臺進行離線指標的計算和 ABTest 元數據和結果的同步，數據迴流Hbase, ABTest console 展示結果。離線鏈路用於計算利己顯著性報表、自定義指標已經留存等計算量較大的場景。

• 即時分析鏈路

離線鏈路還會將預處理的部分數據迴流到 LDAP 系統 Explorer，ABTest Console 利用 Explorer 作更爲靈活的多維分析和漏斗分析

mPaas指標計算體系

針對 mPaaS 的客戶端用戶行爲採起自定義事件進行埋點，用戶只須要經過關聯特定的自定義事件便可自動產生 T+1 的實驗統計效果數據。以每一個用戶爲獨立的實驗個體，這裏面咱們認爲兩個用戶之間的行爲是獨立的，而用戶在實驗期間的每次行爲是有相關性的，經過實驗期間全部的用戶行爲進行統計分析。

對於除 sum 和 count 類指標咱們都會進行區間估計(計算指標統計的置信區間，實驗方案間對比的絕對差置信區間和相對差置信區間),以及基於檢驗假設計算 p-value 給出顯著性統計結論。

• 全局指標

實驗期間進入各個方案的人數(累計 UV)和次數(累計 PV)做爲基礎的實驗分流指標；另一部分全局指標爲留存類指標，以用戶第一次進入實驗開始，在次日活躍則記爲第二天留存，依次類推，咱們能夠計算 2，3，...,7 日留存等。

• 簡單型指標

簡單型指標由單個自定義事件構成，在用戶配置一個自定義事件以後，會自動生成對應的實驗指標：包括 PV 總數(事件觸發次數)，UV 總數(事件觸發總用戶數)，UV 轉化率(實驗用戶中觸發了該自定義事件的用戶佔比)，均值(觸發總次數/進入實驗方案的用戶數)。

• 複合型指標

複合型指標是爲了計算多個自定義事件組成的相關統計效果，在基礎的集合運算中包含交併差除，那麼咱們在複合型指標中也支持這四種運算。這裏面咱們以兩個自定義事件 E1,E2 爲例：

並（E1+E2）：表示用戶只要發生了 E1 或者 E2 即認爲該用戶觸發了(E1+E2)事件，那麼事件總觸發次數即爲觸發E1總次數+觸發E2總次數，其他相關指標計算就能夠看作是一個簡單型指標來進行處理。

交（E1*E2）：表示用戶既觸發了 E1，也觸發了 E2，這個裏面咱們能夠基於單個 session 來看，這樣事件觸發總次數就是同時觸發了E1和E2的總會話數也能夠默認爲 1(目前 mPaaS 直接認爲 1，即相交的計算咱們主要查看 UV 的轉化),其餘相關指標計算就能夠看作是一個簡單性指標來進行處理。

差（E1-E2）：表示用戶觸發了 E1 沒有觸發 E2，事件總觸發次數則是知足該條件的用戶觸發 E1 的總次數，其他相關指標計算就能夠看作是一個簡單型指標來處理。

除（E1/E2）：這個咱們成爲轉化類事件，最簡單的例子就是 E1 事件表示某個按鈕的點擊，E2 事件表示某個按鈕的曝光，那麼 pv 轉化率就是 sum(E1)/sum(E2) 即 pv-ctr，一樣的 UV 轉化率均值等口徑也就清晰了。一樣以曝光點擊爲例，在實際 pv-ctr 的方差計算時咱們發現一個用戶屢次曝光之間實際上是有相關性的，那麼在計算實際方差的時候咱們利用泰勒展開和 E1,E2 的協相關係數，對方差公式進行了優化：

假設 x1,x2,...xn 爲每一個用戶點擊次數，y1,y2,...,yn 爲每一個用戶曝光次數，則

以上，是移動端 ABTest 的具體技術架構解析以及在支付寶內如何落地實踐的總結。若是對 ABTest 感興趣，你們能夠進一步關注 mPaaS 後續文章及產品迭代更新。

往期閱讀

《開篇 | 螞蟻金服 mPaaS 服務端核心組件體系概述》

《螞蟻金服 mPaaS 服務端核心組件：億級併發下的移動端到端網絡接入架構解析》

《mPaaS 核心組件：支付寶如何爲移動端產品構建輿情分析體系？》

《mPaaS 服務端核心組件：移動分析服務 MAS 架構解析》

《螞蟻金服面對億級併發場景的組件體系設計》

《自動化日誌收集及分析在支付寶 App 內的演進》

關注咱們公衆號，得到第一手 mPaaS 技術實踐乾貨

釘釘羣：經過釘釘搜索羣號「23124039」

期待你的加入～