在網站和App的產品設計中，經常會遇到關於哪種產品設計方案更優的思考和討論：按鈕大一點好還是小一點好；頁面複雜一點好還是簡單一點好；這種藍色好還是另一種藍色好；新的推薦算法是不是真的效果好…這種討論會出現在運營人員和產品經理之間，也會出現在產品經理和工程師之間，有時候甚至會出現在公司最高層，成爲公司生死存亡的戰略決策。
在Facebook的發展歷史上，曾經多次試圖對首頁進行重大改版，甚至有時候是扎克伯格親自發起的改版方案，但是最終所有的重大改版方案都被放棄了，多年來Facebook基本保持了一貫的首頁佈局和風格。
相對應的是，一直被認爲抄襲Facebook的人人網在Facebook多次改版舉棋不定的時候，毅然進行了重大的首頁改版，擺脫了長期被詬病的抄襲指責。但是諷刺的是，事後回頭再看，伴隨着人人網改版的是用戶的快速流失，並最後導致了人人網的沒落，而Facebook的守舊卻保證了Facebook的持續發展。
讓Facebook放棄改版決定的，正是Facebook的A/B測試。Facebook開發出新的首頁佈局版本後，並沒有立即向所有用戶發佈，而是隨機選擇了向大約1%的用戶發佈，即這1%的用戶看到的首頁是新版首頁，而其他用戶看到的還是原來的首頁。過一段時間後觀察兩部分用戶的數據指標，看新版本的數據指標是否好於舊版本。
事實上Facebook觀察到的結果可不樂觀，新版本的用戶數據指標呈下跌狀態。扎克伯格不甘心，要求繼續放大新版測試用戶的比例，運營團隊一度將新版測試用戶的比例放大到16%，但是數據顯示新版並不受用戶歡迎，數據指標很糟糕。最後扎克伯格決定放棄新版，首頁維持原來佈局。
A/B測試是大型互聯網應用的常用手段。如果說設計是主觀的，那麼數據是客觀的，與其爭執哪種設計更好、哪種方案更受用戶歡迎，不如通過A/B測試讓數據說話。如果人人網當初認真做A/B測試，也許不會貿然改版；據說今日頭條爲了論證兩條新聞之間的分割究竟應該用多寬的距離，同樣是做了數百組A/B測試。
所以A/B測試是更精細化的數據運營手段，通過A/B測試實現數據驅動運營，驅動產品設計，是大數據從幕後走到臺前的重要一步。
A/B測試的過程
A/B測試將每一次測試當作一個實驗。通過A/B測試系統的配置，將用戶隨機分成兩組（或者多組），每組用戶訪問不同版本的頁面或者執行不同的處理邏輯，即運行實驗。通常將原來產品特性當作一組，即原始組；新開發的產品特性當作另一組，即測試組。
經過一段時間（幾天甚至幾周）以後，對A/B測試實驗進行分析，觀察兩組用戶的數據指標，使用新特性的測試組是否好於作爲對比的原始組，如果效果比較好，那麼這個新開發的特性就會在下次產品發佈的時候正式發佈出去，供所有用戶使用；如果效果不好，這個特性就會被放棄，實驗結束。
對於一個大型網站，通常都會開發很多新產品特性，其中很多特性需要進行A/B測試，所以在進行流量分配的時候，每個特性只會分配到比較小的一個流量進行測試，比如1%。但是由於大型網站總用戶量比較大，即使是1%的用戶，實驗得到的數據也具有代表性了。Facebook擁有幾十億用戶，如果A/B測試的新特性對用戶不友好，那麼即使只測試1%的用戶，也有幾千萬用戶受到影響。所以，在進行A/B測試時對實驗流量和特性的選擇也要謹慎對待。
A/B測試的系統架構
A/B測試系統最重要的是能夠根據用戶ID（或者設備ID）將實驗配置參數分發給應用程序，應用程序根據配置參數決定給用戶展示的界面和執行的業務邏輯，如下圖。
在實驗管理模塊裏進行用戶分組，比如測試組、原始組，並指定每個分組用戶佔總用戶的百分比；流量分配模塊根據某種Hash算法將用戶（設備）分配到某個實驗組中；一個實驗可以有多個參數，每個組有不同的參數值。
移動App在啓動後，定時和A/B測試系統通信，根據自身用戶ID或者設備ID獲取自己參與的A/B測試實驗的配置項，根據配置項執行不同的代碼，體驗不同的應用特性。應用服務器和A/B測試系統在同一個數據中心，獲取實驗配置的方式可以更靈活。
移動App和應用服務器上報實驗數據其實就是傳統的數據採集，但是在有A/B測試的情況下，數據採集上報的時候需要將A/B測試實驗ID和分組ID也上報，然後在數據分析的時候，才能夠將同一個實驗的不同分組數據分別統計，得到A/B測試的實驗數據報告。
灰度發佈
經過A/B測試驗證過的功能特性，就可以發佈到正式的產品版本中，向所有用戶開放。但是有時候在A/B測試中表現不錯的特性，正式版本發佈後效果卻不好。此外，A/B測試的時候，每個功能都應該是獨立（正交）的，正式發佈的時候，所有的特性都會在同一個版本中一起發佈，這些特性之間可能會有某種衝突，導致發佈後的數據不理想。
解決這些問題的手段是灰度發佈，即不是一次將新版本發佈給全部用戶，而是一批一批逐漸發佈給用戶。在這個過程中，監控產品的各項數據指標，看是否符合預期，如果數據表現不理想，就停止灰度發佈，甚至進行灰度回滾，讓所有用戶都恢復到以前的版本，進一步觀察分析數據指標。
灰度發佈系統可以用A/B測試系統來承擔，創建一個名叫灰度發佈的實驗即可，這個實驗包含這次要發佈的所有特性的參數，然後逐步增加測試組的用戶數量，直到佔比達到總用戶量的100%，即爲灰度發佈完成。
灰度發佈的過程也叫作灰度放量，灰度放量是一種謹慎的產品運營手段。對於Android移動App產品而言，因爲國內存在很多個應用下載市場，所以即使沒有A/B測試系統，也可以利用應用市場實現灰度發佈。即在發佈產品新版本的時候，不是一次在所有應用市場同時發佈，而是有選擇地逐個市場發佈。每發佈一批市場，觀察幾天數據指標，如果沒有問題，繼續發佈下一批市場。
小結
A/B測試的目的依然是爲了數據分析，因此通常被當作大數據平臺的一個部分，由大數據平臺團隊主導，聯合業務開發團隊和大數據分析團隊合作開發A/B測試系統。A/B測試系統囊括了前端業務埋點、後端數據採集與存儲、大數據計算與分析、後臺運營管理、運維發佈管理等一個互聯網企業幾乎全部的技術業務體系，因此開發A/B測試系統有一定難度。但是一個良好運行的A/B測試系統對企業的價值也是極大的，甚至可以支撐起整個公司的運營管理，我們下期會詳細討論。
思考題
A/B測試需要在前端App根據實驗分組展示不同界面、運行不同業務邏輯，你有沒有比較好的設計方案或者技術架構，可以更靈活、對應用更少侵入地實現這一功能？