为什么产品运营那么依赖ABTest,而风控不需要?( 二 )


据说,google的设计师不能在两种颜色中做出取舍时,他们测试了41种不同深浅的蓝色。
为什么产品运营那么依赖ABTest,而风控不需要?
文章插图
意料之外情理之中?
我们看下工作中典型的产品&运营工作流,以电商场景为例。
产品和运营同学日常,统计电商搜索结果页面的PV、UV、曝光、点击等数据指标,发现该页面搜索结果的转化率很低,即很多用户进行了搜索却没有点击搜索结果进店购买。
随后运营同学对用户的行为数据和各项指标展开分析,定位问题并进行头脑风暴,提出多套可行的的改进方案。
之后通过ABTest同时将这些方案发布到线上运行,并记录实验日志,计算转化率等指标,最后通过分析各个方案的效果指标得到最佳方案。
总结一下,这个工作流可以概括为,发现问题->提出目标->建立假设(提出优化方案)->AB实验->验证假设,若假设成立则上线新方案,若不成立则继续头脑风暴提出新方案再进行实验。
通过上面的分析,可以发现ABTest已经成为数据驱动增长的必要工具。
三、风控我只是想写这一部分,不知道为何要先写前两部分。
风控中,做一个新模型,或者一条新策略,都是要充分评估更优的。迭代的模型要跟很多东西对比,首要对比的就是想要替换的模型。策略的优化第一个要比的也是原策略。
没有得到更好的模型效果或者策略效果,别说上线了,你都不好意思说你做了这个工作。
当然,这里存在幸存者偏差,我们是在“幸存者”上确保了B好于A。
你看,这根本就不是传统ABTest的工作流,不知道好坏,只能靠上线分流测试。
根本问题出在哪呢?
ABtest的原假设是组别间没有差异,备择假设是有差异,目标是拒绝原假设,核心是证伪。
而风控策略呢,很可能是AB没有明显区别,也会接受B,因为B的设计更简化、更清晰、更轻维护。
为什么产品运营那么依赖ABTest,而风控不需要?
文章插图
增长里B方案的提出是脑暴式的,而风控里的B方案却是呕心沥血出来的。也许是更复杂的算法,也许是更精细化的特征挖掘,也许是目标定义的改变,等。不管是哪一种,一定是为了更好而做的B。当然,不排除即便如此,仍然出现了B不如A的尴尬局面。
这是风控和增长的前提差异。一个是没有差异就拒绝,一个是没有差异就接受。
增长本质上是通过ABTest的思想,把产品决策权交给了用户。风控并非如此。
风控的新策略不需要保证新的业务指标显著优于原有业务指标,即使没有显著差异,仍然可以上线新策略。
背后的根本原因是,这些都是不和用户交互的,不像产品层,新的UI不比原UI高效则不上。
结果是,产品,除非确认有效,否则就不上,而风控,只要没有负面影响,就上。
这并不是说风控里就没有ABTest。
风控决策引擎里面的ABTest,一般叫做冠军挑战者。只是因为上面提到的这些原因,冠军挑战者起的作用只是图心安而已。绝大多数都没有起到什么价值。
大家做风控,不管是模型迭代,还是一个确定的策略工具迭代,例如偿债能力,我们评估风险区分性,评估换入换出,评估通过率,评估这评估那。这些都是线下完成,而非线上测试。
本文由@雷帅 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议