编辑导读：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协议
,
