abb运营模式(为什么产品运营那么依赖ABTest)
编辑导读: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协议
,
免责声明:本文仅代表文章作者的个人观点,与本站无关。其原创性、真实性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容文字的真实性、完整性和原创性本站不作任何保证或承诺,请读者仅作参考,并自行核实相关内容。文章投诉邮箱:anhduc.ph@yahoo.com