增长产品中,量化数据分析的几个方法

新闻 大数据
一个产品模块或活动,多少人参与?很好回答。如果没有它,大盘DAU会影响多少?就不太好回答。这个就是“增量贡献”,增量贡献无法直接统计,但又是管理者最关心的话题,因为ROI很重要,要决定在哪里“投资”。下面就谈一谈增量贡献的量化,以及如果没有AB实验,怎么量化?

 增长为什么要做量化

做增长产品的数据分析,和其他的数据分析,个人认为最大的特色在于量化,为什么要做量化?因为,做增长,是个强数据驱动的方法,要把有限的资源发挥出最大的价值,所以必须准确计算出每个Driver的ROI,才能更有效分配资源,做到效率最大化,把好钢用在刀刃上。

举例几个场景:

  • 每次拉新,不但要量化拉新人数,还要量化后续的持续贡献价值

  • 每次拉活,同样,老板关心后续的持续价值

  • 每次活动,老板不但会问,这次活动有多少人参与,还会问,这次活动贡献了多少增量贡献,如果没有这次活动,DAU会是多少?

  • 上线新模块,和活动类似,老板会关心这个模块为大盘带来了多少增量贡献?

可以看出,我把增长产品的量化规为2大类,外部拉量(拉新、拉活)和促进活跃:

  • 外部拉量:拉新方面,业界有比较成熟的LTV模型,难点在于对LTV模型的预估,拉活方面,一般我们只计算当次(当然不严谨,拉活的后续持续贡献非常复杂)

  • 促进活跃:例如做了运营活动,上线新功能、新模块,本质上都是在促进活跃,这里问题的关键就在于,到底促进了多少活跃,后续滚动下来有多大收益?往往,促进活跃投入的资源是非常大的,准确量化增量贡献不易,此部分也是本文讨论的重点。

拉新拉活的量化

这部分,只简单谈一下,因为我的业务范围拉新拉活量化比较少,没有经验,借鉴下比较基础的量化方法

  • 拉新,采用y = ax^b分渠道量化预估,虽然还有很多高大上的算法,但是这个公式实现成本最低的,方法还不错

  • 拉活,对于DAU的贡献,只计算当日首次启动,对于使用时长的贡献等等,按每个session计算

促活贡献的简单量化方法

促活方面,有几个简单的量化方式,虽然不好,但是较为简单,可以参考,后续将会讨论2种比较复杂的量化方式

  • 染色法:对于参与或深度参与的,设定一个阈值,认为是带来的

  • 对比法:对比渗透与未渗透的用户,对比一个周期内活跃天,或周期内总使用时长,作为贡献,但是此方法有严重的幸存者偏差,需要对渗透有着较为严格的定义,例如有一定深度的阈值

  • 时间对比法:对小部分用户做强刺激的时候,常采用对比法,时间上对比,例如对某个渠道做了某些特殊的承接,可以对比渠道不同时间的留存。此方法看似不严谨,但是其实想一想,这是我们应用最多的方法,资本市场,每个Q的财报,常用的同比、环比,本质上就是这种方法;一般公司对部门定的KPI或OKR,都是这种方式,公司不会给一个对照组,用绝对值量化贡献。

  • AB实验法:我认为AB实验的对比,是比较好的方法。这里,要注意2点,第一,有的时候AB实验会层层叠加,简单的AB实验无法量化出短期贡献和长期贡献,第二,有一些时候,因为网络效应的存在或者开发排期的原因,不是所有的产品都有AB实验能力。

多层域AB实验法——准确量化短期和长期贡献

以我负责的模块为例,老板们会关心

  • 长期以来贡献了多少DAU?

  • 每次产品迭代,提高了多少?

  • 严谨一点,我们采用了AB实验的方式核算,最终可能会发现一个问题:短期迭代贡献,不等于长期贡献,为什么呢?(本文重点讲述AB实验,对于1+1≠2话题,详细请看本人的文章《数据分析中,为什么1+1不等于2?》)

  • 有的时候,迭代A和迭代B,有着相互放大的作用,这个时候就会 1+1 > 2

  • 还有的时候,迭代A和迭代B,本质上是在做相同的事情,这个时候就会 1+1 < 2

有些场景,我们的业务需要和去年或上个季度的自身对比,同时业务还不断在多个方面运用AB Test迭代

这个时候,我们准确量化一个长期产品模块的贡献,就需要一个【贯穿】所有活动的对照组,在AB实验系统中通俗称作贯穿层

(说明:实验中,各层的流量是正交的,简单理解,例如,A层的分流采用用户ID的倒数第1位,B层的分流采用用户ID的倒数第2位,在用户ID随机的情况下,倒数第1位和倒数第2位是没有关系的,也称作相互独立,我们称作正交。当然,AB Test实验系统真实的分流逻辑,是采用了复杂的hash函数、正交表,能够保证正交性。)

这样分层后,我们可以按照如下的方式量化贡献

  •      计算长期的整体贡献:实验填充层-填充层填充组 VS 贯穿层2-贯穿层填充

  •       每个小迭代对整个系统的贡献:实验层中的实验组 VS 对照组

  •       周期内,系统全部迭代与上个周期的比较:实验填充层 VS 贯穿层1

类似与上面这种层次设计,在推荐系统中较为常见,在某一些产品或系统中,贯穿层不能够完全没有策略,那么采用去年或上个季度的策略,代表着基准值,从而量化新一个周期的增量贡献

详细可参看《浅谈AB Test实验设计和数据分析(二)——层域模型的设计》 ,https://mp.weixin.qq.com/s/SSRlELhzy3nOkjeYI1nmXg

没有AB实验能力,如何尽量评估贡献?

AB实验固然好,但是有的时候,因为各种各样的原因,特殊时期,没有AB实验,产品上线了。上线后,数据分析师依然有职责量化出贡献,以我负责业务为例,2020的微视集令牌活动,如何量化贡献?

我们思考过程如下:

  •   首先,采用对比法,对比参与活动与未参与活动的活跃天差别。(此步,考虑到了有幸存者偏差)

  • 接下来,为了解决幸存者偏差,分别对比了下两组用户在之前的活跃程度,做了下差分比较。(此步,有考虑同期的其他活动,会因为用户交集太大,无法分离)

  • 最后为了区分同期的其他用户,将是否参与其他用户也做了分组,同时做对比差分。

做了上面的处理,我还存在疑问:

  • 幸存者偏差仍存在,到底还存在多少?

  • 排除幸存者偏差、红包的干扰,依赖主观判断,还有没有其他因素的干扰?如何证明?

  • 评估方法个性化,可否抽象为通用方法?

思考:差分计算和按红包分组本质上排除各种因素干扰,尽可能构建平行世界,说白了,我们在寻找特征相同的用户群,因此,在方法层面也许可以统一

按照上面的思路,我们引入了协变量的概念,这个概念借鉴了因果推断算法

方法如下:

  • 通过多种特征,寻找特征相同的用户群(寻找协变量,协变量非常关键,后文会提到几个原则)

  • 每个群内,按照是否参与活动分为2组(构建平行世界),对比参与与未参与的差异,计算每个群组的贡献

  • 为了增强可解释性和可读性,简化分组,例如:合并小的分组(如合并同特征分段),较少部分特征,原则是简化分组不影响整体结论,同时简化分组也有利于解决过拟合问题

  • 对于部分分组,仍存在较强的幸存者偏差,做特殊标注(这样至少可以量化得到范围

  • 将各个分组的贡献相加,得到量化贡献范围(说明,虽结果不准确,但有一定的范围,也可以供部门决策,数据分析的很重要作用就是辅助决策)

核心流程如下:

说明下寻找协变量的原则,这个非常关键:

  • 选择与评估时间尽可能近的特征,目的是分群尽可能公平,为了构建平行世界,例如:活动前7天的活跃天、使用时长、画像等

  • 选择需要解耦合的业务特征,例如:同期是否领取红包、是否参与其他活动等

  • 不能选择与评估指标有因果性的特征,例如:不能按活动期间的活跃天分群,同时要注意选择解耦合业务的特征,尽可能降低与评价指标的因果性,尽可能用轻度参与特征,例如:是否参与过(1次就算),不能选择“参与的天数”,因为“参与的天数”本身和我们评价的指标活跃天存在因果性。

总的来说,我还是推崇用AB实验衡量贡献,特殊情况下,上面的方法我认为虽然不严谨,这种方法有2点优势,并且我们也在其他业务中推广

  • 统一经验方法,形成通用方法论,解决平行世界构建和业务间解耦合问题

  • 有一定理论支撑(借鉴因果推断思想),可评估误差范围

 

责任编辑:张燕妮 来源: 腾讯大讲堂
相关推荐

2020-07-16 17:26:05

数据分析转化用户

2016-10-24 23:18:55

数据分析漏斗留存率

2017-08-01 16:42:09

数据分析互联网

2022-05-11 11:33:53

数据分析业绩业务

2015-09-23 09:55:26

数据分析分类变量

2019-10-14 15:57:36

数据分析多维度二八法

2020-10-25 08:56:31

数据分析数据大数据

2021-04-28 11:26:54

数据分析业务

2021-09-05 18:28:10

数据分析模型

2020-05-07 11:13:44

NLPAI产品

2022-09-07 15:47:21

数据分析对比分析大数据

2019-06-23 15:53:48

工业大数据数据分析制造

2023-10-29 18:15:41

数据分析趋势分析法漏斗分析法

2019-01-16 18:39:24

数据开发模型

2017-09-05 17:16:18

多维数据分析

2016-10-27 13:53:20

数据分析大数据

2014-05-21 09:35:45

数据分析

2014-05-21 09:40:57

数据分析

2016-07-27 17:06:50

数据运营数据分析Growth Hack

2017-01-23 13:34:44

点赞
收藏

51CTO技术栈公众号