發給同事以后，收到了很多反饋，比如：

• 運營同學想測試：banner高度是否影響的點擊率？
• 設計同學想測試：不同分享按鈕的顏色能不能提升點擊率？
• 大數據同學想測試：不同推薦算法的點擊率??？
• ……

這時候，就有了明確的目標用戶和使用場景，結合之前對競品的分析，大概知道了涉及哪些模塊和功能，就進入了下一個需求&功能梳理階段。

AB?Test需求梳理：

作者在需求梳理階段，分成了主要三個方面：一是希望測試的功能（即測試的范圍），二是想通過什么數據來評估實驗差異，三是有沒有具體的分流&分流需求。

三、抽象后的使用場景

結合分層情況，從簡單到復雜，將AB測試的范圍分成了以下幾個層次，從左到右為從實現難度從容易到難，測試范圍從小到大，劃分成了4個層次和微信生態內的測試，具體如下：

1. 表現層：主要指一些UI、文案、顏色層面，比如：按鈕文案不同，界面布局不同、某些小元素的顏色、樣式不同等，相對來說是最簡單的層次，有AB?Test系統以后，僅需要少量的前端研發就能支持的實驗。
2. 信息層：主要某些信息是否展示，如銷量、倒計時等，也相對比較簡單。
3. 功能層：指對單個功能的修改迭代（前面兩個層次都不涉及對功能的修改），會對用戶使用流程等造成影響。

如將之前注冊流程從3步改成2步，或迭代電商下單流程等，可以用于功能的灰度發布。

這里要指出的是：研發會在這個層面有相對較多的測試需求，如測試不同SDK的崩潰率，不同第三方服務的線上響應速度等，做系統設計的時候一定要記得收集研發的需求。

版本層，可以理解成為對功能的大幅度修改，可以使用AB?Test作為灰度發布的工具，如：首頁大的改版，商詳頁的重大改版等。

另外，有一個專屬于微信的，就是微信推送（模板消息的文案、推送策略）和分享的（文案、配圖），公司主做微信社交電商業務，也加入了考慮范圍內。

于是就有了上方這個圖，之后就到了整個功能的業務流程設計。

四、衡量指標

順便收集了需要通過什么指標來衡量AB?Test時不同版本的差異，梳理后主要有以下幾個。也需要在系統設計初期和研發溝通，確認能收集到對應數據。

• 點擊通過率 Click-through Rate (CTR)
• 轉化率 Conversion Rate (CR)
• 更新率 Renewal Rate
• 跳出率 Bounce Rate
• 平均保留率 Average Retention
• 平均使用量（應用，手機網站、網頁，App屏幕或游戲場景上的時間），
• 平均每用戶事務數Average Transactions Per User
• 凈推動者指數 Net Promoter Score (NPS)
• 客戶滿意率 Customer Satisfaction Rate
• 平均每用戶收入 Average Revenue Per User (ARPU)
• 平均訂單大小 Average Order Size

五、AB?Test業務流程和功能設計

經過競品的調研，結合公司實際情況，將業務流程拆分成四步，即：

1. 發起實驗，主要是產品或運營。
2. 配置實驗，即通過代碼方式，實現AB版本的差異以及數據收集等。
3. 開始實驗，即實驗上線，包括了在實驗過程中一些流量比例的管理，查看實時數據等。
4. 結束實驗，即實驗有結果以后，結束實驗。

通過業務流程的分析，基本就能劃分出需要哪些系統功能和運營后臺功能了（其實第一個版本可以不需要運營后臺，詳細的分析在最后）。

六、完成系統設計

所有以上的合集，就是ABTest整體的業務流設計，之后就可以通過這個完整的系統設計，來指導具體的產品設計了。

七、一期功能設計（刪掉所有非必要的）

AB?Test這類相對復雜系統的搭建其實有兩種形式：一種是業務驅動的搭建方式，比較像MVP，我們先能簡單的測，再去迭代更多功能；另一種是系統架構的方式，一開始就搭建一個相對比較完善的系統功能。

大部分公司都會選擇業務驅動的方式，自己就是如此。因此，這時候就需要確定首期到底AB?Test什么？

最后，采用了業務驅動的搭建方式，并且確定了首期要上線的測試是什么——即驗證在砍價活動的列表頁，將主按鈕從【去砍價】變成【免費拿】能否提升點擊率，也就是最早提到的數據的實驗。

因為系統設計階段，基本搭建的是完整的AB?Test系統需要的功能點，這時候需要做的就是確定一期功能點。刪的方法也比較簡單，就是把所有沒有必要的功能都刪掉。最后做到，如果沒有這個功能，這個實驗就做不下去。

最后和研發反復溝通以后，并且根據當前研發資源加了一些白名單、流量比例調整等，同事去掉了很多非必要功能，包括了版本分流、實時查看數據等（在上面的系統架構圖中用虛線框住的部分）。那么，減掉這些以后，就是一期需要做的功能，這時候搭建AB?Test系統的主要需求分析和設計階段就完成了。

1. 具體產品設計

之后就進入具體的產品設計，簡單來說就是結合競品“抄”了，這部分沒有太多值得分享的點。關鍵的事項都已經在之前做了，不外乎做原型，交互設計，寫文檔之類，不再贅述。

2. 上線后的結果

首期上線以后，取得了還算不錯的效果，修改一個三個字的文案，用戶點擊進入商詳的點擊率直接從21%提升到了39%。

看到結論的時候也略顯震驚，雖然筆者大概能猜到新文案會好一些。但遠沒有意料到簡單的三個字會有這么大的變化，點擊率幾乎翻了一倍（可以在99.99%置信度里認為方案二更好）。

略有感慨：PM隨時隨刻要對未知的充滿好奇和敬畏。

于是這就完成了AB?Test系統從0~1的搭建??！

一些復盤的Tips

1. 是否需要一個專門的運營后臺來管理實驗？

初期不需要，如果是專注于做實驗，得出結論，在一期的時候只需要有基礎的系統功能就行（實現版本差異、分流、看數據這三步）。

因為在實際開發出運營后臺之后，發現運營后臺能做的事情非常有限，反倒花了很多的資源和精力，不過完成的系統架構分析一定是必不可少的。

2. 在收集實驗場景的時候一定要問研發

自己在做的時候就是只收集了產品、運營、設計的需求，到后期的時候才發現研發也是AB?Test的用戶之一，在設計的時候也需要覆蓋他們的使用場景。

3. 公司是否有必要自己做一個AB?Test系統？

必要性不強，現在可用的這類第三方服務商很多，比如：GrowingIO、VWO等，他們提供了很完善的后臺功能和SDK，只需要比較少的接入成本就能開始測試。

如果不是公司規模特別大，或者有限制無法接入第三方平臺，建議都使用第三方服務。

4. 在什么階段應該引入AB?Test？

最常用到AB?Test的就是增長部門，但什么時候應該引入AB?Test，應該是在找到了一條相對比較可靠的增長路徑之后，通過AB?Test來優化這條路徑。

因為AB?Test所能帶來的優化基本都是百分比型的，對還沒有找到自己核心增長方式的業務來說，提升有限，反倒會花費很多資源。增長PM在那個階段應該更加投入到能帶來指數型或者倍數增長的方式里去。

本文由 @ 陌紫豐田 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于 CC0 協議