編輯導讀：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，到文案，到頁面結構，到推薦結果，等等?？梢哉f產品體驗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協議