作者在《推薦系統評估》和《推薦系統的商業價值》這兩篇文章中提到了AB測試的重要性，新的推薦算法在上線到現網時需要做AB測試，對比新算法和老算法在關鍵指標上的差異，只有當新算法明顯優於老算法時纔會完全取代老算法。其實，AB測試的價值不止體現在推薦系統中，它在整個互聯網產品迭代週期中得到了廣泛深入的應用。
本文試圖對AB測試做一個比較全面的介紹，會從什麼是AB測試、AB測試的價值、什麼時候需要AB測試、AB測試的應用場景、AB測試平臺核心模塊、業界AB測試的架構實現方案、推薦系統業務AB測試實現方案、構建AB測試需要的資源及支持、構建AB測試需要關注的問題等9個方面來講解AB測試技術。
希望本文能夠幫助讀者更好地理解AB測試的價值和應用場景，並結合本文提供的實現方案，可以在具體業務中快速落地AB測試技術，應用到真實業務場景中，真正用AB測試工具驅動公司業務增長。
1.什麼是AB測試
AB測試的本質是分離式組間試驗，也叫對照試驗，在科研領域中已被廣泛應用（它是藥物測試的最高標準）。自2000年穀歌工程師將這一方法應用在互聯網產品以來，AB測試越來越普及，已逐漸成爲衡量互聯網產品運營精細度的重要體現。
簡單來說，AB測試在產品優化中的應用方法是：在產品正式迭代發版之前，爲同一個目標制定兩個（或以上）可行方案，將用戶流量分成幾組，在保證每組流量在控制特徵不同而其他特徵相同的前提下，讓用戶分別看到不同的方案設計，根據幾組用戶的真實數據反饋，科學地幫助產品進行決策(比如你想優化某個位置的文案顏色，覺得藍色比紅色好，就可以保持這個位置一組流量的文案紅色，一組藍色，其他都相同，進行AB測試)。AB測試原理如下面圖1。
圖1：AB測試原理
AB測試是一種科學的評估手段，具備概率統計學理論的支撐。這裏我簡單解釋一下原因。 概率論中有一箇中心極限定理，意思是獨立同分布的隨機變量的和服從正態分佈。對於AB測試，我們比較的是兩組樣本的平均表現，AB測試保證AB兩組某個因素不一樣(這個就是我們要驗證的優化點)，AB兩組其他很多未知影響因素一樣(這些因素是獨立同分布的隨機變量)，當AB兩組樣本足夠多時，這些其他因素產生的效果是滿足同一正態分佈的，因此可以認爲對要驗證的變量的作用是相互抵消的，這樣待驗證因素(即我們的控制變量)的影響就可以比較了，因此我們就可以通過實驗來驗證優化是否有效。
像Google，Facebook，百度，阿里，微博，大衆點評等互聯網公司很早就採用AB測試框架來驅動業務發展，爲公司創造價值。
業內也有很多提供AB測試SAAS服務的創業公司，通過定製化的AB測試方案來爲其他公司提供AB測試能力，如吆喝科技，ABTester, 雲眼, Testin雲測等等。
講完了什麼是AB測試，我們知道AB測試可以驅動業務發展，那麼AB測試的價值到底體現在哪些方面呢？這就是下節主要講的內容。
2. AB測試的價值
最近幾年增長黑客的理念在國內互聯網盛行，有很多這方面的專業書出版，很多公司甚至設立了CGO(首席增長官)的高管職位。增長黑客思維希望通過從產品中找到創造性的優化點，利用數據來驅動產品優化，提升用戶體驗及收益增長，最終達到四兩撥千斤的效果。隨着公司業務規模及用戶的增長，利用數據來驅動業務發展越來越重要。增長黑客本質上就是一種數據驅動的思維，並且有一套完善的技術管理體系來科學地驅動業務發展，而這套體系中最重要的一種技術手段就是AB測試。
AB測試可以很好的指導產品迭代，爲產品迭代提供科學的數據支撐。 具體來說，AB測試的價值主要體現在如下四個方面。
1.爲評估產品優化效果提供科學的證據
前面說過，AB測試是基於概率論與統計學原理之上構建的科學的測試技術，有很強的理論依據。
AB測試也經歷過多年實踐的檢驗，被證明是有效的方法。前面提到過AB測試是藥物測試的最高標準，在藥品製造業得到了很好的使用和驗證。同時，各大互聯網公司都大量使用AB測試技術，爲整個互聯網的發展提供了很好的榜樣和示範作用。
2.藉助AB測試可以提升決策的說服力
因爲AB測試是有統計學作爲理論基礎，並且又有工業上的實踐經驗作爲支撐，利用AB測試得到的結論具備極大的說服力。因此，在用數據說話上，大家在意識形態上更容易達成一致，這樣就可以讓產品迭代更好更快的推行下去。
3.AB測試可以幫助提升用戶體驗和用戶增長
任何涉及到用戶體驗、用戶增長相關的優化想法都可以通過AB測試來驗證，通過驗證得出有說服力的結論，從而推動產品朝着用戶體驗越來越優的方向發展。
4.AB測試可以幫助提升公司變現能力
搜索、推薦、廣告、會員等涉及到收益相關的產品及算法都可以通過AB測試來驗證新的優化思路是否可以提升盈利性指標。其中盈利性指標可以根據公司業務和發展階段來定義。
總之，一切涉及到用戶體驗、用戶增長、商業變現的產品優化都可以藉助AB測試技術，驅動業務做得更好，AB測試是一種科學的決策方式。那我們在什麼時候需要AB測試呢？
3.什麼時候需要AB測試
如果你像喬布斯這麼牛逼，可以深刻洞察用戶的需求，甚至是創造用戶需求，我覺得你可以不用AB測試，但是世界上只有一個喬布斯。所以，對於我們普通人來說，AB測試在產品迭代過程中還是必要的。那麼是不是所有產品迭代或者優化都需要做AB測試呢？我覺得不一定，需要具體情況具體分析，我認爲下面4點是需要利用AB測試來做決策的前置條件。
1.必須是有大量用戶的產品或者功能點
如果你的產品只有很少的用戶使用，比如一些政府部門的官網。由於用戶少，分組後用戶更少。根據上面AB測試的統計學解釋(大量隨機樣本產生的影響的均值是正態分佈，樣本量小就不是，這時其他因素的影響就可能無法抵消，導致控制變量的比較就無意義)，根據很少的用戶得出的結論是不具備統計學意義的。所以即使做了AB測試，得出的結論的有效性是無法用統計學原理支撐的，因此是不可信的。
同樣的，某個產品雖然用戶多，但是如果某個功能點只有很少用戶用，這跟上面道理是一樣的，是無法做出可信服的結論的。
同樣的，某個優化太細(用戶意識到這種改變的概率很小)，比如就看某個推薦位的顏色深淺是否對用戶點擊是否有影響，這時也需要大量的用戶對這個位置的訪問纔可以得出比較有指導意義的結論。
2.進行AB測試的代價(金錢&時間)可以接受
如果做AB測試的代價太大，比如需要消耗大量的人力財力，這時做AB測試的產出可能小於付出, 這時做AB測試就是費力不討好的事情了。
3.有服務質量提升訴求
如果某個業務或者功能點用戶極少使用，並且也不是核心功能點，比如視頻軟件的調整亮度，這個是一個很小衆的需求，只要功能具備就可以了，好用和不好用對用戶體驗影響不大，這時花大力氣對它進行優化就是沒必要的。
4.變量可以做比較好的精細控制
如果某個功能影響的變量太多，並且我們也無法知道哪個變量是主導變量，甚至都不知道有哪些變量對它有影響，這時就很難利用AB測試了。因爲，AB測試需要調整一個變量同時控制其他變量不變。
如果上面4個條件都滿足的話，我覺得這個功能點是可以做AB測試的。對於toC的互聯網產品來說，其實上面幾個條件是很容易滿足的，所以在互聯網公司有很多地方都可以通過AB測試來優化產品功能，那AB測試在互聯網公司到底有哪些應用場景呢？
4.AB測試的應用場景
在互聯網公司AB測試可以落地的場景是很多的，具體包括如下3大類：
1.算法類
各類算法是AB測試應用場景最多的地方，算法開發人員通過AB測試來驗證一個新的算法或者小的算法優化是否可以提升算法的業務指標。包括推薦、搜索、精準廣告、精細化運營等涉及到算法的產品和業務都是可以利用AB測試技術的。
2.運營類
任何一個互聯網產品少不了運營，在互聯網紅利消失的當下，某個產品是否可以“佔領”用戶的心智，運營將起到越來越重要的作用，甚至有人說互聯網時代將進入一個運營驅動的時代。各類運營手段，如用戶運營(用戶拉新、會員運營等)、內容運營(視頻行業的節目編排等)、活動運營(抽獎等)等都可以借用AB測試技術來驗證哪種運營策略是更加有效的。
3.UI展示及交互類
UI是任何一個互聯網產品可直接被用戶感知的部分，用戶通過UI與互聯網產品交互，用戶對一個產品的感知也是首先通過UI建立的。簡潔美觀的UI界面，流暢的UI交互往往能夠給用戶留下好的第一印象。對於UI視覺及交互部分的優化，往往憑設計師的經驗是不夠的，需要利用技術手段來驗證哪種UI展示風格、哪種交互方式是用戶更喜歡的、能夠帶來最大收益的。
像顏色、字體、按鈕形狀、頁面佈局、操控方式的調整及優化都是可以通過AB測試來驗證的。
現在我們知道了互聯網產品哪些模塊和功能是可以利用AB測試驅動做得越來越好的，那麼大家一定想知道我們怎麼構建一個高效易用的AB測試平臺，並怎樣通過該平臺更好地支撐各類AB測試任務。在下面兩節我們就來講講一個完備可用的AB測試平臺有哪些模塊，怎麼構建一個完整的AB測試平臺。
5.AB測試平臺核心模塊
根據作者構建AB測試平臺的經驗，我認爲一個完備的AB測試平臺至少需要分組模塊、實驗管理平臺、業務接入模塊、行爲記錄分析模塊、效果評估模塊這5大部分(見下面圖2)，這其中分組模塊、實驗管理平臺、業務接入模塊是構建完整AB測試體系必須具備的模塊，行爲收集分析模塊和效果評估模塊是配合AB測試能夠更好的得出可信結論必須具備的支撐模塊。下面我們分別對這5個模塊的功能和價值做簡單說明，讓大家更好的理解爲什麼需要這幾個模塊。
圖2：AB測試平臺核心模塊及支撐模塊
1.分組模塊
分組模塊的目的是根據各種業務規則，將流量(用戶)分爲AB兩組(或者多組)。可以說分組模塊是AB測試最核心的模塊，好的AB分組方案可以讓流量分配的更均勻隨機。同時需要具備根據用戶、地域、時間、版本、系統、渠道、事件等各種維度來對請求進行分組的能力，並且保證分組的均勻性和一致性。
對於推薦系統，“完全個性化範式”和“標的物關聯標的物範式”兩種推薦範式是主要的推薦範式(不熟悉的讀者可以參考《推薦系統的工程實現》第五節推薦系統範式)，第一種範式是個性化推薦，爲每個用戶生成推薦，這時我們可以對用戶做隨機分組。對於第二種範式，如果我們對標的物做隨機分組，是存在問題的，因爲不同的標的物是不一樣的，有些是熱門的，有些是冷門的，可能存在分配不均的現象。我們可以採用基於時間的分配策略，某段時間標的物X分配到A組，另一段時間X分配到B組，只要保證分到AB兩組的時間是公平的就行(比如第一天分到A組第二天分到B組)。
我們團隊基於分組模塊設計了兩個算法，在推薦算法AB測試中得到大量使用及驗證，可以保證分組的均勻性和公平性，並申請了相關專利。
2.實驗管理模塊
實驗管理模塊的目的是讓產品經理、運營人員或者開發人員方便快速的創建AB測試案例，增加新的AB測試分組，調整AB測試方案各個組的比例，讓AB測試跑起來。同時也用於管理AB測試平臺用戶創建、權限管理，讓用戶具備編輯、拷貝、使用AB測試實驗的能力，做到高效易用。
3.業務接入模塊
接入模塊的主要目的是方便在產品迭代優化的各個階段整合AB測試能力，對優化點做各種AB測試。一般通過提供一個AB測試SDK或者AB測試Restful接口的形式供業務方使用。接入模塊需要做到高效易用，最好能夠適用於產品上所有類型的AB測試優化。
我們會在第七節結合我們團隊的真實業務情況詳細介紹推薦系統AB測試的接入實現方案，爲讀者提供業務接入AB測試的參考。
4.行爲記錄分析模塊
行爲記錄分析模塊包含AB測試行爲數據打點、數據收集、數據分析和數據可視化展示等子模塊。
行爲記錄分析模塊主要的目的是當某個產品功能的AB測試在線上運行時，記錄用戶的在AB測試模塊的行爲，將用戶的行爲收集到數據中心，藉助大數據分析平臺來做各種效果評估指標的統計分析與評估，最終確定新的優化點是否是有效的。
在業務實現上, 需要前端在用戶訪問做AB測試頁面的過程中記錄做AB測試的業務標識及對應的方法(策略)標識。因爲在一段時間或者在同一時間整個產品中會有各類AB測試在運行，只有記錄了對應的業務和策略, 我們在數據分析時才能更好的區分一條日誌到底是哪個業務上的哪個策略產生的。最終方便我們將整個AB測試的效果評估、指標分析及可視化做到全自動化，提升整個AB測試迭代的速度。
5.效果評估模塊
AB測試效果評估組件是用於跟蹤AB測試的效果，根據AB測試效果來做出業務、運營、算法調整的決策。
AB測試要評估出A方案和B方案的好壞，這時就需要一個較好的衡量指標了，一般可以採用人均播放量，人均點擊量，人均瀏覽次數，轉化率，CTR等指標來評估。
具體效果評估指標的定義需要讀者根據自己公司行業特點、產品形態、功能點等來定義，指標能夠方便量化，並能夠直接或者間接跟產品體驗、用戶增長、商業變現聯繫起來，畢竟這纔是公司整體目標。
定義好各類效果評估指標後，最好可以將指標計算通用化、模塊化，方便實驗人員快速上線AB實驗，根據不同產品及AB測試案例選擇合適的指標。
有些AB測試(如猜你喜歡推薦系統)只要T+1尺度的指標計算就夠了，有些(如廣告投放算法的AB測試)需要具備分鐘級輸出AB測試結果的能力。儘早知道AB測試結果可以快速做有利決策，避免對用戶體驗產生不好的影響，同時快速決策也可以減少損失或者增加收益。
我們初略介紹完了AB測試平臺的各個模塊，知道了每個模塊的作用和價值，那麼在實際構建AB測試系統時，這些模塊是怎麼組織起來提供服務的呢？這就涉及到AB測試架構實現問題了，這是我們下節主要講解的。
6.業界流行的AB測試架構實現方案
本節我們來講解有哪些可行的AB測試架構實現方案，這些方案是作者結合自己的經驗、思考及參考了業界一些公司AB測試實現方案後的總結。讀者可以根據自己公司的產品特性、現有的基礎架構、人力資源及未來需要做的AB測試類別來選擇適合自己的AB測試架構。
根據作者自己這幾年在推薦系統中做AB測試的經驗及調研和自己的思考整理，我認爲目前有3種主要的AB測試框架實現方案，具體見下面圖3。
圖3：AB測試可行的三種實現架構
根據上面圖3，我們將AB測試架構分爲3大方案，其中方案1在客戶端整合AB測試能力，方案2在接口層整合AB測試能力，方案2又分爲採用統一Router的形式和在web接口層整合AB測試兩大類，方案3在後端業務層實現AB測試能力。我們在下面分別對這些方式做更細緻的講解說明。其中我們公司算法團隊採用的AB測試方案就是方案3，在下一節我們會詳細講解。
下面我們對圖3各種AB測試方案進行拆解，更加細緻的說明各個方案的架構實現。
方案1：通過定製的AB Test SDK來處理AB測試業務
該方案需要開發AB Test SDK，並將SDK整合到前端，通過AB Test SDK與AB測試服務(核心分組模塊)交互來處理AB測試相關功能，採用該方案的公司有微博等。具體架構見下面圖4。
具體AB測試服務與業務接口的交互實現方式可以是如下兩種之一：
a AB測試服務下發兩個不同的接口給AB測試SDK，當用戶請求時，根據用戶的分組，分別調用不同的接口。
b AB測試服務下發同一個接口給AB測試SDK，但是不同的分組對應的參數不同，當用戶請求時，根據用戶所在的分組，選擇不同的參數來訪問該接口(該接口會根據不同的參數獲取不同的數據)。
圖4：通過提供AB測試SDK來進行AB測試的實現方案
該方案的好處是通過統一的SDK來對接AB分組服務，前端業務代碼簡單調用SDK的方法就可以，開發效率高。不好的點是，如果AB測試業務有調整，需要升級SDK，較麻煩(現在很多APP具備通過插件的方式做升級，這時對SDK的修改就不要發版本了，相對會更加靈活)。同時，如果公司有iOS、Android、PC等多個業務的話，需要開發多套SDK，維護成本較大。
方案2：在後端業務層增加相關組件來做AB測試
該方案通過在後端接口層增加相關組件來處理AB測試需求， 該組件通過與AB測試交互來做AB測試， 採用該方式的公司有Google，百度，大衆點評等。其中又可以分爲兩類：
第一類：像Google，百度，AB兩組對比測試業務分別部署在不同的服務器，通過構建一層統一的router來分發流量。具體架構見下面圖5。通過後端統一Router模塊來處理AB測試相關請求。
具體AB測試服務與業務接口的交互實現方式跟方案1類似，這裏不再說明。
圖5：通過後端統一Router來進行AB測試的實現方案
該方案的優點是模塊化，router解決所有與AB測試相關問題，對AB測試業務做調整不需要前端版本升級，只需要升級後端服務即可。但是Router層是整個AB測試的核心，需要具備高併發高可用的能力，否則出現問題會影響AB測試能力的發揮。
第二類：像大衆點評，將AB兩組對比測試業務實現邏輯寫在同一個業務接口，全部業務邏輯在業務服務器完成。具體架構見下面圖6。通過構建AB lib(比如構建一個處理所有AB測試業務邏輯的jar包)模塊來處理AB測試相關業務。
當用戶使用產品觸發做AB測試的功能時，前端調用統一的接口，接口層通過AB lib跟AB測試服務交互獲取該請求對應的分組，並從對應的數據存儲中獲取數據，組裝成合適的格式返回給用戶。
圖6：通過業務端整合AB測試lib來進行AB測試的實現方案
該方案當AB測試調整時也不需要前端做升級, 只需要修改AB lib包就可以了。該方案最大的缺點是如果公司採用多種開發語言做業務接口服務，需要每種開發語言維護一套AB lib庫，維護成本較高。另外AB測試邏輯調整需要升級AB lib包時，需要對所有線上接口做升級，明顯增加了風險。同時，在接口服務中整合AB lib與AB測試服務交互，增加了接口服務的複雜度，如果AB測試服務有問題，可能會影響接口功能或者性能。
方案3：通過在算法業務層跟AB測試服務交互來實現AB測試能力，不需要前端和接口層做任何處理
該方案通過在具體業務中整合AB測試能力來做AB測試，我們團隊採用該方案。該方案比較適合算法類(推薦算法、搜索算法、精準投放、精準運營等)相關業務做AB測試。具體架構見下面圖7。
圖7：通過算法業務層來進行AB測試的實現方案
需要做AB測試的業務模塊通過調用AB測試服務來實現AB測試能力，具體AB測試的實現放在業務中實現(如在推薦推斷時，推薦程序在爲用戶計算推薦結果過程中訪問AB測試服務，確定用戶對應的分組)。當然，可以將這些處理AB測試的操作或者模塊封裝成Jar包，方便各個業務方共用，提升AB測試落地效率。
該方案的好處是(拿推薦來說)前端和接口層不做任何處理，只需在業務中實現AB測試能力，並且不需要根據AB兩組分別對全量用戶計算推薦結果，也不需要爲全量用戶分別存儲AB兩個算法的推薦結果，大大減少計算時間和存儲開銷。
到此，我們講完了所有AB測試架構實現方案。本節我們只是給出了架構實現的架構圖，並對各個方案的優缺點做了簡要說明，並未具體說明怎麼真正實現。在下面一節，作者以我們團隊的AB測試實現方案爲例來詳細說明該怎麼實現AB測試平臺。
7.推薦系統業務AB測試實現方案
前面提到我們公司大數據與人工智能團隊的AB測試就是基於方案3來實現的，目前在推薦搜索等算法業務中大量採用，效果還不錯，在本節我詳細說明一下具體的實現邏輯，方便大家作爲落地的參考。
我們用個性化推薦(如興趣推薦，見下面圖8，對於相似推薦也適用)來說明怎麼利用方案3來做AB測試。個性化的興趣推薦是爲每個用戶推薦一組視頻。
圖8：個性化的興趣推薦，爲每個用戶生成推薦結果
下面圖9是推薦算法接入AB測試框架的業務流，下面我們對下圖中標註數字的4處交互邏輯做簡單說明，方便大家全局理解整個AB測試交互邏輯。
圖9：推薦算法接入AB測試框架(方案3)業務流
對於圖9中標註數字1的部分，我們的AB測試配置人員先在AB測試管理平臺配置AB兩類算法(可以是多個算法同時進行AB測試)的佔比, 見下面圖10(homePagePersonal是首頁的個性化推薦，有三個算法，其中streaming-als比例爲0，streaming-long-videos-v1比例爲0.1，streaming-long-videos比例爲0.9)，這時AB測試服務檢測到了AB測試配置文件有改動，會將對應的新的AB測試配置(或者老的配置的調整)更新到AB測試服務，更新後，算法業務調用AB測試服務時就會獲得最新的用戶分組。
圖10：通過XML格式來配置各個算法的比例
這時具體的業務邏輯調用AB測試接口(算法業務調用該接口後返回的json類似圖11)時就會基於新的分組比例計算某個用戶或者視頻對應的是哪個分組(算法)，不同的分組採用不同的算法來計算推薦列表，參見下面圖11中紅色虛線框中部分，某個用戶的guessulike業務(猜你喜歡業務)對應的是seq2seq算法(基於keras+rnn算法)，可能另外一個用戶得到的是另外一個算法。我們的AB測試框架中的分組算法保證按照配置的各個算法的比例來分配，將所有用戶大致按照該比例分配到對應的算法。
圖11：調用AB測試接口獲取某個用戶對應的推薦業務的算法
對於圖9中標註數字2的部分，算法業務根據某個用戶所屬的算法分組，對該用戶利用該算法計算推薦結果，並將結果存於最終的推薦庫中。參考下面圖12中的流程。該步驟做完後，每個用戶的推薦結果就會存儲在數據庫中，同時我們會在推薦結果數據庫中爲該用戶的推薦結果增加兩個字段，一個biz，一個alg，biz是對應的推薦業務(如相似影片、猜你喜歡等)，alg是對應的算法(如seq2seq等)。
圖12：推薦算法根據用戶所屬的分組分別計算推薦
對於圖9中標註數字3的部分，當用戶使用產品觸發對應的推薦系統時，會調用對應的接口，從相關數據庫中獲取對應的推薦結果，並將結果展示給用戶。其中返回給用戶的接口中是包含biz和alg字段的(見下面圖13中紅色虛線框中部分，該圖就是用戶觸發推薦後後端返回的推薦結果json), 包含這兩個字段的目的主要是將用戶的行爲打點記錄下來，方便對用戶行爲進行統計分析，最終評估出算法的效果。這兩個字段及字段的值就是從存入數據庫的用戶的推薦結果中獲得的。
圖13：返回給用戶的推薦結果中包含biz和alg兩個字段
對於圖9中標註數字4的部分，我們會基於用戶對AB測試模塊的點擊行爲，計算出各個算法的核心評估指標，見下面圖14。其中直接轉化率(從節目曝光給用戶到用戶進入詳情頁的轉化率)，有效轉化率(從節目曝光給用戶到用戶產生播放行爲的轉化率)，付費入口轉化率(從用戶進入付費節目詳情頁到用戶點擊付費按鈕的轉化率)是核心指標。
圖14：根據用戶對AB測試模塊的訪問記錄計算出評估指標，並可視化出來
對於非個性化推薦(如相似影片)的AB測試，基本跟個性化推薦一樣，這裏不再贅述。需要注意的是節目有熱門和冷門之分，在分組中需要加入時間的擾動因子，讓X節目在不同時間段分別用AB兩種策略來計算關聯節目，這在前面也提到了。
針對我們公司推薦系統的AB測試實現，我這裏就介紹完了，其他算法類的AB測試也類似。希望讀者從本節中學到怎麼落地AB測試方案。從中我們也可以看出要實現完整的AB測試能力還是需要做很多開發工作的，涉及到前後端、大數據等多個業務部門，因此需要得到很多部門的支持。
8.開發AB測試平臺需要的資源及支持
前面提到任何涉及到數據驅動運營策略、產品優化都需要依賴AB測試能力。因此，要想更好的利用數據來驅動業務發展，讓產品快速增長， 互聯網公司具備AB測試能力是必須的，可以說AB測試平臺作爲一個基礎服務平臺，在互聯網公司的地位舉足輕重。目前市面上也有很多AB測試的SAAS服務，通過購買這些SAAS服務可以方便的讓自己的產品具備AB測試能力。當然也可以通過自己來開發實現AB測試能力。那到底是自己開發還是選擇第三方的呢？
作者建議初創公司、規模不大的小公司或者非技術驅動但是需要AB測試能力的公司採購SAAS方案，這樣可以快速的讓自己的產品具備AB測試能力，將主要精力放到優化產品體驗上，而不是將精力放到實現一個AB測試框架上。
如果外面的AB測試SAAS方案滿足不了本公司的業務需求，而公司領導非常認可數據驅動方法，並且希望將數據驅動作爲自己團隊的核心能力，期待努力踐行，這時就可以自研AB測試平臺了。下面我講講自研構建AB測試平臺需要哪些團隊的配合和支持。
AB測試屬於基礎架構能力，同時又跟業務緊密結合，需要公司的基礎架構後端團隊、大數據算法團隊、產品團隊、前端團隊、業務部門一起溝通，明確AB測試應用的範圍，短期目標，未來的發展方向，確定AB測試的價值體現形式。最終大家一起協力開發一個適合本公司當前階段和產品形態的AB測試平臺。
其中，業務部門和產品確定需要在產品上進行AB測試的種類，需要具備什麼樣AB測試的能力，大數據算法團隊實現分組的算法方案和進行日誌的收集分析、可視化展示，基礎架構後端團隊設計適合公司業務的AB測試框架並開發後端的各模塊及與前端交互的接口等，前端團隊負責AB測試管理平臺的開發，讓業務部門可以更加方面的使用AB測試工具，同時實現日誌打點及與AB測試平臺的交互能力。
AB測試平臺構建完善後，需要產品提供完善的AB測試接入文檔，讓大家都能夠輕鬆使用該平臺，需要大家一起努力打造利用AB測試來驅動產品迭代的團隊文化，讓更多的業務接入AB測試平臺，通過數據分析得出有價值的結論，讓數據說話，最終讓AB測試平臺爲業務帶來價值。
公司管理層一定需要有數據驅動的意識，否則即使有了AB測試能力也不太會在產品迭代中推進利用AB測試來驅動業務。如果老闆有了數據驅動的意識，需要自上而下推動數據驅動和AB測試在企業的落地。
自己構建一套完備好用的AB測試平臺不是一件容易的事情，還有很多細節方面需要注意，才能讓AB測試真正發揮價值。
9.構建AB測試平臺需要關注的重要問題
我們講完了AB測試平臺的具體實現方案，在設計AB測試平臺中，我們需要關注如下幾點，才能讓AB測試能力得到正確的運用，更好的發揮應有的價值。
1.靈活的分組/分桶
AB測試一般需要根據各種維度對用戶來分組，因此需要設計靈活(方便快速迭代)、有效(效果評估置信度高)的分組方案。
具體可能會根據隨機、用戶版本、用戶地域、時間、渠道、年齡、性別、收入、行爲等各種維度來對用戶分組。AB測試平臺要具備多維度分組的能力。
2.AB測試一定要具備統計學意義上“顯著”的置信度
AB測試是有成本的，AB測試的目的是得出正確的結論來優化產品體驗、提升收益轉化，所以AB測試指標的提升一定要是統計學上“顯著”的，是真實有效的。
關於置信度有很多統計學方法來驗證，這裏我不細講，有興趣的讀者可以自行搜索相關材料。
3.用戶體驗一致性
根據上節講的AB測試的實現方案，有些方案(如方案3)用戶在一定週期內體驗是一致的(同一天多次重複進入該頁面或者使用該功能看到的結果是一樣的)，而有的方案(如方案2第一類)用戶每次進入頁面或者使用該功能看到的結果可能是不一樣的。顯然前一種用戶體驗是一致的，後一種不一致。
個人建議涉及到UI展示及交互的、用戶會多次進入/使用的功能點，利用體驗一致的AB測試方案比較好。但是像廣告投放這類業務，是在不同場景不一樣的，沒必要採用用戶體驗一致的做法。
4.測試周期要足夠長
要讓AB測試得出可信服的結論，AB測試需要經歷一定的週期，才能得出比較有價值的結論。這裏舉一些例子來說明。
像UI及用戶交互的優化，新的UI及交互方式可能開始用戶有新鮮感，但是等用戶新鮮感過去後可能就對該功能沒有那麼熱衷了(這就像你剛找了個女朋友，恨不得每時每刻待在一起，但是過了2年3年，甚至幾個月後，你可能就不是這種想法了)。如果只測試較短時間，發現新功能使用更頻繁，這時如果我們就得出新的優化是比老的好，可能就被數據欺騙了。這時最好的做法是讓AB測試運營一個足夠長的時間段，讓結果穩定下來，再來比較核心指標。具體選用多長的時間需要根據行業及經驗來定，並且在在計算核心指標時，可以剔除掉初期的數據，避免初期的新鮮感影響最終評估結果。
另外，像有些特殊行業的產品，用戶在不同時間行爲是不一樣的，比如視頻行業(特別是智能電視上的視頻應用，由於是多人使用一個產品，每個人的時間是不一樣的，父母可能平時要上班，小孩只有在晚上有時間看電視，老人整天都有機會看電視)，用戶在週末跟工作日的行爲是不一樣的。這是AB測試周期不能是一天的某段時間，也不能是某幾天，最好是一週的整數倍，得出的結論才比較可靠。
5.損失最小性原則
我們做AB測試的目的是優化用戶體驗，但是有可能我們認爲有效的優化在真實上線時反而是不好的，爲了避免這種情況發生對用戶體驗和收益的負面影響。我們在做AB測試時儘量用小的流量來測試新的算法或者優化點，當數據證明優化點是有效的，才逐步推廣到所有用戶。實驗過程中如果數據不好，最多隻影響到測試的這批少量用戶，不至於產生大的負面影響。
6.處理好AB測試與緩存的關係
互聯網公司通過大量採用緩存技術來加速查詢，同時提升整個系統的高性能、高可用能力。當爲某個功能模塊做AB測試時，特別要考慮緩存情況，這時可能會存在問題。
這裏舉個例子說明，如果某個用戶開始是老算法策略，如果在做AB測試時，給用戶分配到了新算法策略，如果有緩存的話，那麼用戶會從緩存獲取到老算法策略，這時跟實際上用戶分配到的新算法策略不一致。
解決方案是當用戶的緩存跟用戶的實際分配的策略不一致時，清空緩存，讓請求回源。當然，具體實現方式可以有很多種且跟具體業務和AB測試實現方案有關，這裏不詳細說明。
最後
本文基於作者做AB測試的經驗及思考來講述AB測試的方方面面，其中關於具體實現方案這塊提到了某些公司的實現方案, 是通過收集了網上的一些材料看到的，不代表現在這些公司還是採用這種實現方式。不過本文講到的這些實現方式確實都是可行的，並且我認爲覆蓋到了主流的AB測試實現方案。
本文只詳細講解了方案3的詳細落地方案，對於方案1，方案2，並未詳細講解，讀者可以根據3的思路自行思考該怎麼具體落地。
由於AB測試是一個非常偏業務的模塊，同時作者在公司中只做了算法這塊的AB測試，對於UI、運營等的AB測試未曾涉及，所以難免有些說法有失偏頗，歡迎大家留言交流探討。
相關文章：
打造工業級推薦系統（一）：推薦算法工程師的成長之道
打造工業級推薦系統（二）：無處不在的推薦系統
打造工業級推薦系統（三）：推薦系統的工程實現與架構優化
打造工業級推薦系統（四）：推薦系統怎麼更好的幫助公司掙錢？
打造工業級推薦系統（五）：推薦系統冷啓動全解析
打造工業級推薦系統（六）：構建優質的推薦系統服務
打造工業級推薦系統（七）：怎麼評估推薦系統的效果？
作者介紹：gongyouliu，有近 10 年大數據與 ai 相關項目經驗，有 9 年推薦系統研究及實踐經驗，目前負責電視貓大數據與人工智能團隊。喜歡讀書，暴走，寫作。業餘維護“大數據與人工智能”公衆號，ID：ai-big-data，持續輸出推薦系統相關文章。個人微信：liuq4360