风控不需要做ABTest?

数据管道

共 2613字,需浏览 6分钟

 ·

2021-10-13 14:54

你们好,我是宝器!


大家都知道流量时代,互联网产品、运营都在干嘛呢,高频测试找最优。即使我们不知道背后的统计学原理,我们也对ABTest耳熟能详。


在产品做一个功能或需求时,听到最多的疑问就是:你这个功能/需求能带来的收益是什么?收益能有多大?那我们怎么去衡量一个需求带来的实际收益?这个时候,ABTest就是协助我们衡量需求收益的好朋友。


那风控模型策略上线做不做ABTest呢?大家可以想一想。


我曾经有过一次面试经历,对方问我,之前有没有做过ABTest,我说有。然后要我举个例子,我想了想,意识到不对劲,瞎解释了一通。


因为风控策略其实并没有真正意义的ABTest。


01 

ABTest


  • 运营同学想测试:banner高度是否影响点击率?

  • 设计同学想测试:不同分享按钮的颜色能不能提升点击率?

  • 大数据同学想测试:不同推荐算法的点击率啊?


ABTest将不同的用户分成不同的组,同时测试不同的方案,通过用户反馈的真实数据来找出哪一个方案更好。解决的是多种方案需要拍脑袋确认哪一种更好的问题。


对一个产品设计,往往已经能难直观判断是否真的是一种优化了,这个改变,可能来自文案、按钮的颜色、界面的布局或者功能的迭代,也可能是推荐算法。


你说你知道哪个更优?


只能是骡子是马,拉出来比一比。


根据这些思想,ABTest有几个关键,一个是分流,流量要分配的公平,一个是检验,要验证结论具备统计学意义。



ABTest的统计学知识就不写了,随便一搜都有,而我也不会。


值得注意,ABTest是验证想法方案的策略,而不是战略。


它不能解决所有问题,因为它并不适合所有情况。


更改登陆页面可能是一个很好的ABTest候选者,更改网站或表单上的按钮位置可能也是一个很好的ABTest。一个完整的网站重新设计可能是也可能不是一个好的ABTest,这取决于如何进行实验。


通常,增量更改非常适合ABTest。注意,缺陷也隐藏在其中,增量测试显然容易陷入局部最优。


最常用到ABTest的就是增长部门,那什么时候应该引入ABTest呢?应该是在找到了一条相对比较可靠的增长路径之后,通过ABTest来优化这条路径。


02

产品 & 运营


有人总结产品和运营的关系,产品是把东西做出来,运营是把东西卖出去。有点意思。


不管是产品还是运营,可以统称为增长,它们都是为增长服务的。而上面刚说,增长非常适合ABTest。


比如电商行业中典型的增长问题,提升页面转化率,包括提升列表页到商详页的转化率,商详页到订单确认页的转化率,订单确认页到交易成功页的转化率。


这整个流程中太多ABTest的用武之地了,从icon,到文案,到页面结构,到推荐结果,等等。可以说产品体验5要素的很多内容都需要经过测试。


再比如,电商平台为618、双11促活,想知道是用满减券好,还是折扣券好。这两种券,可能在不同品类的商品、不同客群上效果都不一样。


实际上,很多用于测试的选项你是真的不知道哪个好。


据说,google的设计师不能在两种颜色中做出取舍时,他们测试了41种不同深浅的蓝色。


意料之外情理之中?


我们看下工作中典型的产品&运营工作流,以电商场景为例。


产品和运营同学日常,统计电商搜索结果页面的PV、UV、曝光、点击等数据指标,发现该页面搜索结果的转化率很低,即很多用户进行了搜索却没有点击搜索结果进店购买。


随后运营同学对用户的行为数据和各项指标展开分析,定位问题并进行头脑风暴,提出多套可行的的改进方案。


之后通过ABTest同时将这些方案发布到线上运行,并记录实验日志,计算转化率等指标,最后通过分析各个方案的效果指标得到最佳方案。


总结一下,这个工作流可以概括为,发现问题->提出目标->建立假设(提出优化方案)->AB实验->验证假设,若假设成立则上线新方案,若不成立则继续头脑风暴提出新方案再进行实验。


通过上面的分析,可以发现ABTest已经成为数据驱动增长的必要工具。


03

风控


我只是想写这一部分,不知道为何要先写前两部分。


风控中,做一个新模型,或者一条新策略,都是要充分评估更优的。迭代的模型要跟很多东西对比,首要对比的就是想要替换的模型。策略的优化第一个要比的也是原策略。


没有得到更好的模型效果或者策略效果,别说上线了,你都不好意思说你做了这个工作。


当然,这里存在幸存者偏差,我们是在“幸存者”上确保了B好于A。


你看,这根本就不是传统ABTest的工作流,不知道好坏,只能靠上线分流测试。


根本问题出在哪呢?


ABtest的原假设是组别间没有差异,备择假设是有差异,目标是拒绝原假设,核心是证伪。


而风控策略呢,很可能是AB没有明显区别,也会接受B,因为B的设计更简化、更清晰、更轻维护。



增长里B方案的提出是脑暴式的,而风控里的B方案却是呕心沥血出来的。也许是更复杂的算法,也许是更精细化的特征挖掘,也许是目标定义的改变,等。不管是哪一种,一定是为了更好而做的B。当然,不排除即便如此,仍然出现了B不如A的尴尬局面。


这是风控和增长的前提差异。一个是没有差异就拒绝,一个是没有差异就接受。


增长本质上是通过ABTest的思想,把产品决策权交给了用户。风控并非如此。


风控的新策略不需要保证新的业务指标显著优于原有业务指标,即使没有显著差异,仍然可以上线新策略。


背后的根本原因是,这些都是不和用户交互的,不像产品层,新的UI不比原UI高效则不上。


结果是,产品,除非确认有效,否则就不上,而风控,只要没有负面影响,就上。


这并不是说风控里就没有ABTest。


风控决策引擎里面的ABTest,一般叫做冠军挑战者。只是因为上面提到的这些原因,冠军挑战者起的作用只是图心安而已。绝大多数都没有起到什么价值。


大家做风控,不管是模型迭代,还是一个确定的策略工具迭代,例如偿债能力,我们评估风险区分性,评估换入换出,评估通过率,评估这评估那。这些都是线下完成,而非线上测试。

·················END·················

推荐阅读

  1. 我在字节做了哪些事

  2. 写给所有数据人。

  3. 从留存率业务案例谈0-1的数据指标体系

  4. 数据分析师的一周

  5. 超级菜鸟如何入门数据分析?


欢迎长按扫码关注「数据管道」

浏览 23
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报