許多互聯(lián)網(wǎng)公司都會以A/B Test的形式來進行產(chǎn)品決策——通過展現(xiàn)A方案和B方案，通過最終結(jié)果來判斷哪個方案更好。本文筆者將與大家分享自己對于這種決策方式的一些思考。

A/B Test，這是如今互聯(lián)網(wǎng)行業(yè)開發(fā)中常用的方法。它的做法很簡單，某個問題如果有A和B兩個方案，卻無法決定哪個更好。那么不要爭論，直接投入生產(chǎn)進行測試，把用戶分成兩群（劃分標(biāo)準(zhǔn)可以是時間、地域、消費能力等等各種因素，但要樣本足夠大，足夠有代表性），分別展現(xiàn)A方案和B方案，通過最終結(jié)果來判斷哪個方案更好。

這看起來簡單粗暴，但是一種相當(dāng)有效的方法。據(jù)說：今日頭條就大量使用A/B Test來進行產(chǎn)品決策，所以迭代速度很快，效率也很高。不過，今天我想換個角度，談?wù)凙/B Test給我的哲學(xué)啟發(fā)。

我接觸A/B Test是許多年前，那時候A/B Test的概念還沒有流行，當(dāng)時我甚至沒聽說過這個概念。但是，這不妨礙我用它的思想來解決問題。

當(dāng)時我們開發(fā)的系統(tǒng)里的單據(jù)管理頁面有個“大一統(tǒng)”搜索框，設(shè)計初衷很好，希望用戶“一站式”搜索到想看的內(nèi)容。

但是，單據(jù)的屬性太多，原有系統(tǒng)的設(shè)計又很糟糕，用戶在搜索框輸入信息之后，程序要對所有屬性進行逐一匹配檢索，查詢的效率特別低。如果遇上多個用戶同時查詢，系統(tǒng)基本就失去響應(yīng)了。這個問題讓客戶非常不滿，抱怨聲此起彼伏。

我們在仔細分析了用戶的搜索行為之后發(fā)現(xiàn)：用戶搜索時，大量輸入的只有三個屬性——客戶代碼、日期、訂單編號。

這三個屬性的特征很明顯，匹配檢索也可以專門優(yōu)化，速度會大大提升。所以，改進方案也很簡單：收到用戶提交的搜索請求時，先判斷一下是否這三個屬性，如果是就走專門優(yōu)化的渠道。如果檢索不到則彈出另一個界面，引導(dǎo)用戶進行“完整搜索”。

據(jù)測試：這個方案很有效，響應(yīng)速度提升很多，我們也非常有信心。但是，臨到要上線，卻被業(yè)務(wù)（銷售）給叫停了。他們的理由也很充分：這樣改動看起來有道理，但是客戶已經(jīng)習(xí)慣了原來的邏輯，行為結(jié)果會變化（“你怎么知道我的大客戶沒有特殊習(xí)慣呢？”）。而且，這個行業(yè)的客戶大多專注于生意，文化水平不高，最怕的就是系統(tǒng)改了要重新適應(yīng)。這種改動肯定不會受用戶歡迎。

一邊是系統(tǒng)的運行壓力和技術(shù)人員的責(zé)任心，一邊是銷售描述的客戶的慣性阻力。兩邊看起來都有道理，到底應(yīng)該怎么抉擇？

當(dāng)時我有了A/B Test的模糊想法——不進行整體硬切換，讓不同的用戶走不同的邏輯，甚至可以動態(tài)調(diào)整大客戶的搜索邏輯，如果客戶不滿意隨時復(fù)原。好說歹說，終于說服了銷售，可以上線測試。

測試結(jié)果顯示：絕大部分客戶都滿意改進之后的搜索邏輯，能感知到速度大大提升，即便有少數(shù)客戶感覺怪異。但是耐心加以解釋，對比了常用搜索的表現(xiàn)之后，他們都比較愿意“花一點時間學(xué)習(xí)和適應(yīng)”。所以，最終，這次改進的結(jié)果相當(dāng)令人滿意。

這是A/B Test給我的第一個啟發(fā)：

在解決問題之前，如果有多種方案需要抉擇，很可能每種方案都有理由，都有支持的聲音，而且理由嚴(yán)密完整，聲音鏗鏘有力。自說自話，總是能自圓其說。但是，評價決策的最終標(biāo)準(zhǔn)不應(yīng)當(dāng)是這些理由和聲音，而是實際的結(jié)果。

看看我們周圍，有無數(shù)熱鬧的文章在解釋世界，在把某種抉擇描繪得無比英明。但是，支持真實世界運轉(zhuǎn)的并不是這些炫目的解釋，而是現(xiàn)實的邏輯。所以，也才會有“不看廣告看療效”的說法。

扯遠點說，卡爾·波普爾很早就發(fā)現(xiàn)：許多炫目的理論之所以讓人著迷，是因為它們“從來都不可能出錯”，即便出了錯也能自圓其說。

波普爾認(rèn)為：這些理論其實不是科學(xué)的理論，因為科學(xué)理論包含必須有出錯的風(fēng)險，只有不斷通過“驚心動魄”的事實檢驗，理論的科學(xué)性才能得到證明。

許多人大概會記得，在前些年小米春風(fēng)得意的時候，有無數(shù)專家在宣稱。小米掌握了“互聯(lián)網(wǎng)方法論”，當(dāng)然能在手機市場上所向披靡，這是致勝的法寶。

然后，小米出貨量下滑，而oppo和vivo崛起了，于是大家的口風(fēng)瞬間轉(zhuǎn)變，“線下勝過線上”、“互聯(lián)網(wǎng)企業(yè)做實業(yè)根基不穩(wěn)”的論調(diào)開始大行其道。之后小米扭轉(zhuǎn)了下跌的趨勢，為小米歌功頌德的聲音又開始躲起來。

按照IDC最新的數(shù)據(jù)：2019年1季度，主攻線下的oppo手機出貨量出現(xiàn)了6%的下跌，不知道這些專家又要說什么……

不過不管他們說什么，都無法改變一個事實。那就是，如果你只看這些專家的說法，必然會有和許多人同樣的困惑——“看書看來了許多道理，自己仍然不會做決策”。

去年我看了《命運攸關(guān)的選擇：1940-1941年間改變世界的十個決策》，也很有這方面的意思。比如：對于不列顛之戰(zhàn)，如今許多人都在歌頌丘吉爾毫不屈服的堅定意志。但作者要分析的是：當(dāng)時丘吉爾面臨的情境是怎樣的？他是如何決策的？如果他不選擇抗戰(zhàn)，結(jié)果大概會是什么樣？…… 必須承認(rèn)，這樣的分析視角，會給人更多的啟發(fā)和收獲。

回頭來說A/B Test，還是許多年前，還是在系統(tǒng)開發(fā)中，我又遇到過另一件事。

那時候，客戶往往需要整批提交格式化的數(shù)據(jù)。按照日常經(jīng)驗，這種數(shù)據(jù)顯然應(yīng)當(dāng)用Excel的格式最合適。用戶按照我們給定的模板把數(shù)據(jù)分門別類錄入好，最后在瀏覽器里上傳到作業(yè)系統(tǒng)即可。

但是這樣操作也會有問題。Excel文件的交互能力比較弱，如果一次提交幾百上千條記錄，某一條又出了錯，很難告知準(zhǔn)確告知客戶錯誤的位置和類型，修改起來也很不方便。

另外，許多客戶是一天提交一次Excel的，如果在Excel制作的過程中電腦死機或者文件損壞，很可能前功盡棄，之前的工作成果要全部重新來過。

在嘗試了幾次優(yōu)化上傳界面之后，我們決定徹底廢棄之前的做法，直接給客戶提供一個客戶端軟件?？蛻舻卿浿?，可以逐一錄入數(shù)據(jù)，數(shù)據(jù)錄入時軟件會直接和服務(wù)器交互進行驗證-保存，出錯了則即時提示。

這種軟件開發(fā)起來不難，但也很好玩，里面有不少設(shè)計需要花點心思，大家也樂在其中。開發(fā)完之后，我們信心滿滿地介紹給銷售同事，希望他們能推動客戶使用。在我們看來，這是三贏的局面：技術(shù)不必反復(fù)查錯，客戶不必反復(fù)提交，銷售不必反復(fù)溝通。

不出意外，銷售同事第一反應(yīng)就是質(zhì)疑，因為客戶已經(jīng)習(xí)慣了原有的操作，讓他們改變操作習(xí)慣，成本太高。不過，因為之前的搜索欄改進的例子，質(zhì)疑并沒有成為反對，大家約定這個改進也來實地測試一番。

這次的測試結(jié)果大大出乎我們的意料，絕大部分客戶在試用新軟件之后都不滿意，又回到老的Excel的操作方式上來?！霸趺礃?，說了客戶的操作習(xí)慣不是那么容易改變的吧！” 這一次，獲勝的是銷售同事了。

但是我們并不滿意，一方面，對自己開發(fā)的軟件有足夠的信心（和期望），另一方面，“用戶操作習(xí)慣不那么容易改變”并不能成為萬金油，總有那么強的說服力。

可是，A/B Test的結(jié)果又分明證明，確實我們想錯了。那么，問題到底出在哪里呢？

不甘心的技術(shù)人員走出辦公室，深入到客戶的使用場景去調(diào)查，真相才浮出水面：原來，開發(fā)時犯了想當(dāng)然的錯誤。

開發(fā)人員的電腦配置比較好，開發(fā)使用的是.Net技術(shù)框架，而客戶的電腦并沒有那么新潮，許多仍然在用Windows XP，并沒有自帶.Net Framework，這就讓許多客戶望而卻步了。即便知道要下載.Net Framework，又面臨版本問題，國內(nèi)各種下載站捆綁其它軟件的問題。安裝好之后，因為電腦配置低，程序運行起來響應(yīng)也很緩慢，反而不如Excel干脆利落。

找到問題之后就好辦了。把軟件原有的操作邏輯都保留，.Net實現(xiàn)都廢掉，以原生的Visual Basic重寫。雖然這樣有點折騰，新時代的程序員大多不會寫VB了，要重新學(xué)習(xí)，但結(jié)果是非常好的。重新下發(fā)的版本在客戶的機器上跑得很快，甚至比Excel還要快，迅速贏得了客戶的信任，也在銷售同事那里找回了面子。

這是A/B Test給我的第二個啟發(fā)：

即便一個問題有了最終答案，也不能單純相信最終答案所依附的那種解釋，因為它可能是不對的。盡管這些解釋能自圓其說，但也只是牽強附會，或者流于表面。換句話說，A/B Test這樣的測試只能證明“哪種方案好”，而不能說明“為什么好”，不能替代人工的分析。要認(rèn)清真相，我們不應(yīng)忘記細致探尋其中的理由。

我的第三個例子不是來自自己，而是來自朋友。

近些年，A/B Test已經(jīng)大為流行，會用A/B Test的人也越來越多。對應(yīng)的，愿意討論的人也越來越多了。一次吃飯時，有位朋友跟我說了這么個故事。

這個朋友開發(fā)的用戶登錄界面里面臨一個問題：輸入手機號接收短信驗證碼的界面，是否需要用戶先輸入圖形驗證碼？如果不要求，則這個界面可能被濫用，別有用心的人可以利用這個界面給其他人發(fā)送垃圾騷擾信息。如果要求，正常的用戶流程又不夠順暢，憑空多了一重阻攔。

因為單純憑討論無法決定，他們采用了A/B Test。最終發(fā)現(xiàn)：如今大概黑產(chǎn)肆虐，羊毛黨猖獗，如果要求輸入圖形驗證碼，每天的無效和風(fēng)險登錄次數(shù)少了很多，正常用戶的登錄次數(shù)卻沒有太大的波動。從結(jié)果來看，安排圖形驗證碼顯然是一個更好的選擇。

聽完這個故事，我現(xiàn)場給他展示了一下登錄流程。在輸入手機號，滿心期待可以等來短信之前，硬生生彈出一個“請輸入圖形驗證碼”的界面。

我問他：“你作為普通用戶，你的體驗好嗎？”

他老老實實回答說：“不好?！?/p>

所以，從概率上看，A/B Test的結(jié)果確實防住了很大一部分黑產(chǎn)、羊毛黨，但如果你不幸處于“不需要防住”的那一部分，對你來說這個結(jié)果就非常悲劇了。

你說這個問題確實存在，但是要怎么改進A/B Test呢？

實際上，所有這類決策都會有決策成本。按照80-20原則，你抓住了80%，就放棄了20%。何況現(xiàn)實中未必處處都是80-20，有時候你抓住的只是60%，放棄的是40%，甚至抓住的是55%，放棄的是45%。雖然從總數(shù)上看是不錯的，但實際成本太高，放棄的太多。

那么，怎么解決這種問題呢？

解決這種問題并不是靠A/B Test，而需要輸入更多的信息。

如果你的登錄界面只輸入一個手機號，讓用戶收一個短信驗證碼，就是把A/B Test做出花來，也沒有什么用。如果你輸入的不只有用戶的手機號，還有用戶的IP、瀏覽器版本等等信息，如果是在專屬App里登錄，還可以加上Wi-Fi網(wǎng)絡(luò)、地理位置、設(shè)備ID等等信息……

你的信息更豐富了，決策邏輯就可以更復(fù)雜，可以調(diào)整的空間也更大。如果要做A/B Test也可以做更細致，可以從多層次、多角度來做A/B Test。

這位朋友聽了之后若有所思，回頭找安全、風(fēng)控等等行業(yè)的朋友聊了一圈，得到了更完整的方案。再過幾個月我去看他們的系統(tǒng)，已經(jīng)基本做到了“對正常用戶勿打擾，對風(fēng)險用戶自動驗證”的水平，用戶體驗比之前粗暴彈出圖形驗證碼好了很多。

實際上，這是我前些年思考的結(jié)果，也是A/B Test給我的第三個啟發(fā)：

A/B Test不是萬能的，不能迷信。

它只能教我們?nèi)绾螐慕o定的選項中擇優(yōu)，但許多時候選項本身的層面不對，或者粒度太粗。所以，即便做了A/B Test，結(jié)果也未必盡如人意。許多時候我們需要跳出來，輸入更多的信息，或者改進A/B的粒度，往往能取得更理想的結(jié)果。

如果你有印象大概會記得：2002年8月12日，公安部在北京、天津、深圳、杭州四個城市推行了個性化車牌。個性化車牌有6位，前三位可以由用戶自行選擇數(shù)字或者字母。這種給予極大自由的政策，一經(jīng)推出就引發(fā)民眾熱捧。不幸的是，政策公布之后還不到兩周，就因為“技術(shù)原因”叫停了。

據(jù)媒體報道：這項政策被叫停的真正原因在于，許多用戶自定的車牌有爭議，比如BWM-001、FBI-001、USA-911、PLA-081之類，甚至還有SEX-001等等“出格”現(xiàn)象，被認(rèn)為“不符合精神文明建設(shè)”。后來還有不少“專家”引用這個例子，證明“社會現(xiàn)階段不能太過自由，否則就會出各種幺蛾子，影響穩(wěn)定”之類的結(jié)論。

在我看來，這恰恰是個典型的因為粒度過粗、層次不當(dāng)?shù)睦?。如果只是粗放?guī)定“用戶可以選擇/不選擇個性化車牌”，對“個性化車牌中不容許哪些內(nèi)容”又沒有任何細致的規(guī)定，結(jié)果當(dāng)然五花八門，出乎意料。

拿它當(dāng)例子來證明“社會不能太過自由，否則就會影響穩(wěn)定”，就更是匪夷所思——自由從來都是和規(guī)定相聯(lián)系的，沒有什么正經(jīng)的人主張社會需要毫無約束的自由。

系統(tǒng)智能與否，體現(xiàn)在它能動用多少信息，對多少情況進行細致的分析，給出對應(yīng)的處理，而不是一兩條簡單的if-else萬事。

同樣的道理，解決問題水平的高低，也體現(xiàn)在問題的解決者能夠動用多少信息，事先制定多少分門別類的規(guī)則，事后依據(jù)多少細致的分析，而不是簡單粗放得到一個結(jié)論了事。

最后做個簡短總結(jié)：

• A/B Test很好，可以用來戳穿各種貌似合理的奇談怪論。
• 做A/B Test不只是技術(shù)上做點事情就完了，沒有細致認(rèn)真的分析，還是可能走彎路。
• 要想給出更優(yōu)的解決方案，并不能完全依賴A/B Test，輸入更多的信息，掌握更多的計算能力，才可能得到更優(yōu)的解決方案。

作者：余晟，微信公眾號：余晟以為（ID：yurii-says）

來源：https://mp.weixin.qq.com/s/VVS49gO9M8gMgWQ73KdKvA