探究灰度測試（A/B Testing）

一段小插曲

前段時間產品改版，產品經理爲了改進用戶體驗，就決定改版用戶的註冊流程頁面，但又怕身份證註冊驗證接口不穩定（第三方的身份證校驗）。

因而產品經理就讓我經過隨機機率去控制註冊流程，讓一部分用戶使用身份證註冊，讓一部分用戶使用手機號註冊。當時我聽這種需求確實有點懵，總感受很差作，產品經理就說了句，先用灰

度測試一下，聽完我就學到了這個「灰度測試」術語，網上研究了一下這個術語，順便把這個需求實現。

 

概念

什麼是灰度測試（發佈）

測試同一個產品發佈，隨機讓一部分用戶會使用新版，一部分用戶仍然使用舊版。好比：A組用戶使用新版，B組用戶使用舊版。

什麼是A/B Testing

測試同一個產品頁面，不一樣的組件設計風格。（顏色，大小，形狀）好比：A組用戶看到購買按鈕是紅色的，B組用戶看到購買按鈕是橙色的。

什麼是Split Test

測試同一個產品頁面，不一樣的佈局設計風格。（左右佈局，上下佈局）好比：A組用戶會在首頁頂部菜單看到註冊按鈕，B組用戶會在首頁banner位看到註冊按鈕。

 

PS：灰度測試是國內IT行業的說法，國外並無這麼一說。某些業界人員認爲灰度測試與A/B Testing是不一樣的概念，認爲灰度測試是從技術上看產品質量問題，A/B Testing與Split Test是從市場上看用戶體驗問題。A/B Testing與Split Test本質是類似的，在我看來，灰度測試與A/B Testing實施方案是同樣的，因此不必去區分灰度測試、A/B Testing、Split Test。

灰度測試≈A/B Testing（兩項測試）≈A/B/N Testing（多項測試）≈Multivariate Testing（多項測試）≈Split Test（分類測試）

 

目的

爲何要進行灰度測試（A/B Testing）

1.從用戶體驗角度來說，能夠分析用戶數據，改進用戶體驗。

2.從產品質量角度來說，能夠保證產品順利迭代，控制產品影響範圍。

 

實施

如何進行AB Testing

第一步：制定A/B Testing的用例。

考慮用戶界面技術實現。

考慮預期用戶界面體驗效果。

 

第二步：肯定A/B Testing的用戶。

1.沒有用戶ID關聯的

根據用戶的IP區域信息來測試。

根據用戶的設備信息來測試。

經過消息推送/提示窗口通知用戶測試。

 

2.有用戶ID關聯的

根據用戶的活躍度來測試。

經過郵件/短信通知用戶來測試。

 

第三步：控制A/B Testing 週期。

週期最好控制在一個月內，週期越長，A/B Testing的結果就容易受到污染。（緣由請看後面）

 

 第四步：收集數據並分析。

不要片面分析結果，進行產品技術分析，數據分析，互動分析（好比社交羣反饋）。

PS：互動分析由爲重要，能直接反饋用戶對產品的見解，請不要忽視社交羣反饋意見。

 

問題

A/B Testing結果是否準確？

不許確，A/B Testing結果會存在必定的偏差，A/B Testing結果偏差產生有如下幾個主要緣由。

1.隨機訪問。

隨機訪問意味着任何用戶訪問該網站都有相同的機率被選擇進入新版（另外一個用戶界面），從而看到網站的A/B Testing的變化。從技術的角度來說，不管是前端，仍是後端控制機率A/B，每每都是基於cookie去控制這個A/B測試的變化。假設用戶更換電腦，更換瀏覽器，清除cookie，那A/B Testing的結果就不許確。

2.用戶樣本過少。

用戶樣本過少意味着產品測試覆蓋率低，不容易發現產品問題。從技術的角度來說，可能抽樣的用戶測試新功能都沒有問題，結果全面推送給全部用戶使用新功能就有可能出現一些產品問題（Bug），那A/B Testing的結果就不許確。

3. 網站營銷活動。

網站營銷活動意味着會提升網站的訪問量，不管網站A/B Testing的變化如何，A 組用戶界面與B 組用戶界面的轉化率都有較大的提高。從用戶體驗的角度來說，看不出哪一組的用戶界面轉化率高，那A/B Testing的結果就不許確。

4.人爲不可控的活動。

人爲不可控的活動因素有不少，好比抽樣的用戶沒時間去使用新功能或者不喜歡使用新功能，又或者同一臺電腦或者瀏覽器給多人使用等不可控因素，那A/B Testing的結果就不許確。

 

總結

A/B Testing結果能夠反饋產品質量問題，但不能準確反饋用戶體驗問題。（若是須要收集更多數據分析網站轉化率，請配合第三方分析工具進行數據分析，好比Google Tag Manager，友盟，百度統計等工具）