編輯導讀：ABTest是網際網路行業的常用手段，透過高頻測試找最優，ABTest就是協助我們衡量需求收益的好朋友。相比於產品運營高頻使用ABTest，風控比較少用到ABTest，這是為什麼呢？本文作者對此進行了分析，與你分享。
大家都知道流量時代，網際網路產品、運營都在幹嘛呢，高頻測試找最優。即使我們不知道背後的統計學原理，我們也對ABTest耳熟能詳。
在產品做一個功能或需求時，聽到最多的疑問就是：你這個功能/需求能帶來的收益是什麼？收益能有多大？那我們怎麼去衡量一個需求帶來的實際收益？這個時候，ABTest就是協助我們衡量需求收益的好朋友。
那風控模型策略上線做不做ABTest呢？大家可以想一想。
我曾經有過一次面試經歷，對方問我，之前有沒有做過ABTest，我說有。然後要我舉個例子，我想了想，意識到不對勁，瞎解釋了一通。
因為風控策略其實並沒有真正意義的ABTest。
一、ABTest
運營同學想測試：banner高度是否影響點選率？
設計同學想測試：不同分享按鈕的顏色能不能提升點選率？
大資料同學想測試：不同推薦演算法的點選率啊？
ABTest將不同的使用者分成不同的組，同時測試不同的方案，透過使用者反饋的真實資料來找出哪一個方案更好。解決的是多種方案需要拍腦袋確認哪一種更好的問題。
對一個產品設計，往往已經能難直觀判斷是否真的是一種優化了，這個改變，可能來自文案、按鈕的顏色、介面的佈局或者功能的迭代，也可能是推薦演算法。
你說你知道哪個更優？
只能是騾子是馬，拉出來比一比。
根據這些思想，ABTest有幾個關鍵，一個是分流，流量要分配的公平，一個是檢驗，要驗證結論具備統計學意義。
ABTest的統計學知識就不寫了，隨便一搜都有，而我也不會。
值得注意，ABTest是驗證想法方案的策略，而不是戰略。
它不能解決所有問題，因為它並不適合所有情況。
更改登陸頁面可能是一個很好的ABTest候選者，更改網站或表單上的按鈕位置可能也是一個很好的ABTest。一個完整的網站重新設計可能是也可能不是一個好的ABTest，這取決於如何進行實驗。
通常，增量更改非常適合ABTest。注意，缺陷也隱藏在其中，增量測試顯然容易陷入區域性最優。
最常用到ABTest的就是增長部門，那什麼時候應該引入ABTest呢？應該是在找到了一條相對比較可靠的增長路徑之後，透過ABTest來最佳化這條路徑。
二、產品 & 運營
有人總結產品和運營的關係，
產品是把東西做出來，運營是把東西賣出去
。有點意思。
不管是產品還是運營，可以統稱為增長，它們都是為增長服務的。而上面剛說，增長非常適合ABTest。
比如電商行業中典型的增長問題，提升頁面轉化率，包括提升列表頁到商詳頁的轉化率，商詳頁到訂單確認頁的轉化率，訂單確認頁到交易成功頁的轉化率。
這整個流程中太多ABTest的用武之地了，從icon，到文案，到頁面結構，到推薦結果，等等。可以說產品體驗5要素的很多內容都需要經過測試。
再比如，電商平臺為618、雙11促活，想知道是用滿減券好，還是折扣券好。這兩種券，可能在不同品類的商品、不同客群上效果都不一樣。
實際上，很多用於測試的選項你是真的不知道哪個好。
據說，google的設計師不能在兩種顏色中做出取捨時，他們測試了41種不同深淺的藍色。
意料之外情理之中？
我們看下工作中典型的產品&運營工作流，以電商場景為例。
產品和運營同學日常，統計電商搜尋結果頁面的PV、UV、曝光、點選等資料指標，發現該頁面搜尋結果的轉化率很低，即很多使用者進行了搜尋卻沒有點選搜尋結果進店購買。
隨後運營同學對使用者的行為資料和各項指標展開分析，定位問題並進行頭腦風暴，提出多套可行的的改進方案。
之後透過ABTest同時將這些方案發布到線上執行，並記錄實驗日誌，計算轉化率等指標，最後透過分析各個方案的效果指標得到最佳方案。
總結一下，這個工作流可以概括為，發現問題->提出目標->建立假設（提出最佳化方案）->AB實驗->驗證假設，若假設成立則上線新方案，若不成立則繼續頭腦風暴提出新方案再進行實驗。
透過上面的分析，可以發現ABTest已經成為資料驅動增長的必要工具。
三、風控
我只是想寫這一部分，不知道為何要先寫前兩部分。
風控中，做一個新模型，或者一條新策略，都是要充分評估更優的。迭代的模型要跟很多東西對比，首要對比的就是想要替換的模型。策略的最佳化第一個要比的也是原策略。
沒有得到更好的模型效果或者策略效果，別說上線了，你都不好意思說你做了這個工作。
當然，這裡存在倖存者偏差，我們是在“倖存者”上確保了B好於A。
你看，這根本就不是傳統ABTest的工作流，不知道好壞，只能靠上線分流測試。
根本問題出在哪呢？
ABtest的原假設是組別間沒有差異，備擇假設是有差異，目標是拒絕原假設，核心是證偽。
而風控策略呢，很可能是AB沒有明顯區別，也會接受B，因為B的設計更簡化、更清晰、更輕維護。
增長裡B方案的提出是腦暴式的，而風控裡的B方案卻是嘔心瀝血出來的。也許是更復雜的演算法，也許是更精細化的特徵挖掘，也許是目標定義的改變，等。不管是哪一種，一定是為了更好而做的B。當然，不排除即便如此，仍然出現了B不如A的尷尬局面。
這是風控和增長的前提差異。
一個是沒有差異就拒絕，一個是沒有差異就接受。
增長本質上是透過ABTest的思想，把產品決策權交給了使用者。風控並非如此。
風控的新策略不需要保證新的業務指標顯著優於原有業務指標，即使沒有顯著差異，仍然可以上線新策略。
背後的根本原因是，
這些都是不和使用者互動的，
不像產品層，新的UI不比原UI高效則不上。
結果是，產品，除非確認有效，否則就不上，而風控，只要沒有負面影響，就上。
這並不是說風控裡就沒有ABTest。
風控決策引擎裡面的ABTest，一般叫做冠軍挑戰者。只是因為上面提到的這些原因，冠軍挑戰者起的作用只是圖心安而已。絕大多數都沒有起到什麼價值。
大家做風控，不管是模型迭代，還是一個確定的策略工具迭代，例如償債能力，我們評估風險區分性，評估換入換出，評估透過率，評估這評估那。這些都是線下完成，而非線上測試。
本文由@雷帥 原創釋出於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議