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

• 運(yùn)營(yíng)同學(xué)想測(cè)試：banner高度是否影響的點(diǎn)擊率？
• 設(shè)計(jì)同學(xué)想測(cè)試：不同分享按鈕的顏色能不能提升點(diǎn)擊率？
• 大數(shù)據(jù)同學(xué)想測(cè)試：不同推薦算法的點(diǎn)擊率??？
• ……

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

AB?Test需求梳理：

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

三、抽象后的使用場(chǎng)景

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

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

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

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

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

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

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

四、衡量指標(biāo)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

略有感慨：PM隨時(shí)隨刻要對(duì)未知的充滿好奇和敬畏。

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

一些復(fù)盤的Tips

1. 是否需要一個(gè)專門的運(yùn)營(yíng)后臺(tái)來管理實(shí)驗(yàn)？

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

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

2. 在收集實(shí)驗(yàn)場(chǎng)景的時(shí)候一定要問研發(fā)

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

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

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

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

4. 在什么階段應(yīng)該引入AB?Test？

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

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

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

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