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

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

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

AB?Test需求梳理：

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

三、抽象后的使用場景

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

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

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

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

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

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

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

四、衡量指標

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

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

五、AB?Test業(yè)務流程和功能設(shè)計

經(jīng)過競品的調(diào)研，結(jié)合公司實際情況，將業(yè)務流程拆分成四步，即：

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

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

六、完成系統(tǒng)設(shè)計

所有以上的合集，就是ABTest整體的業(yè)務流設(shè)計，之后就可以通過這個完整的系統(tǒng)設(shè)計，來指導具體的產(chǎn)品設(shè)計了。

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

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

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

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

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

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

1. 具體產(chǎn)品設(shè)計

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

2. 上線后的結(jié)果

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

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

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

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

一些復盤的Tips

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

初期不需要，如果是專注于做實驗，得出結(jié)論，在一期的時候只需要有基礎(chǔ)的系統(tǒng)功能就行（實現(xiàn)版本差異、分流、看數(shù)據(jù)這三步）。

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

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

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

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

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

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

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

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

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

本文由 @ 陌紫豐田 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于 CC0 協(xié)議