这一次,我用数据分析提升了用户转化率

大数据 数据分析
某在线教育机构,每周会开免费的直播,所有用户预约后可以观看直播。业务方期望通过直播能提升用户的付费率。

“数据分析,要分析出具体业务优化点”是很多公司对数据分析师的要求,也是让很多同学们头大的问题。

怎么从一个个数据指标里,得出一个优化结论?今天结合一个具体问题场景,系统讲一下该怎么做。

问题场景:

某在线教育机构,每周会开免费的直播,所有用户预约后可以观看直播。业务方期望通过直播能提升用户的付费率。

但执行了一段时间后,业务方开始纠结:到底直播报名后观看率与观看人数,对付费率有没有用?毕竟开直播也有成本,为啥总感觉开的场次多了,转化率似乎没啥提升??

问:如何分析该问题?直播业务优化点在哪里?

01常见错误做法

很多同学习惯于数据库里有啥字段就用啥,不区分场景,不打标签,结果自然分析不出东西。比如本例,很有可能原始数据记录,就是一个名叫XXX的直播,有XX人报名,有XX人观看,没了。不深入思考的话,很有可能倾向于:

1、拿每日直播总观看人数&每日销量总数,做相关分析,看相关系数是多少

2、拿每一场直播的观看人数&直播后购买的人,计算直播转化率,然后画一条折线图

3、拿每一场看直播的人&报名了没看直播的人,分两组,计算购买率

这样能算出三个数字,但是下结论的时候,就很容易被业务挑战:

1、我发现直播人数和销量相关系数0.76——所以呢!所以又怎么样???

2、我发现最近三周直播转化率在下降——废话!我早知道了……

3、我发现看了直播的购买率高出5%——废话!肯定高呀,所以呢?

常见的质疑就是这么来的。这些结论之所以都是废话,是因为业务看了以后,真的不知道能干啥。业务方期望听到的优化建议,是:直播还能不能做!能做的话,做多少场?做啥话题?挂啥链接?不能做的话,我要怎么解决销售问题!这才是有用建议。

图片

那么,如何解决问题呢?

▌第一步:理解业务场景

找业务优化点,第一步当然是回到业务本身。从教育业务本身来看:所有用户一锅炖的来开直播,就不是个很合适的行为。因为不同用户的需求完全不一样:

1、新注册用户:对教育机构和课程都不熟悉,需要建立信任

2、已付费一次用户:如果人家刚上2节,就催着买新课,肯定没人买单

3、已付费n次用户:用户已经有了学习成绩&学习进度,再推也是推进阶课程

总之,不同的人,在教育上需求天生有差异。

很多同学看到这里,本能地会提出:分人群开展直播,效果就好啦!

这样也会被喷哦,因为理解业务场景,仅仅是个开始。

▌第二步:分析业务痛点

在提建议的时候,要避免提:“指标低了,要搞高”、“混播不好,建议分开”这一类听着合理,实则无脑的建议。

为啥?因为人不是傻子。看到指标低了,肯定会想着搞高,有精力做分散场次,肯定会想着分开做。违反常识的做法,背后一般都有隐情。要进一步梳理,先找到业务痛点再说。

从表面上看,目前的问题是:直播带来的转化效果不明显。

再深层次看,可能的问题是:直播一锅炖,缺少分类指引。

再深层地看,为啥会一锅炖,背后隐情,很可能是:

1、有的话题,所有人都感兴趣。比如职业发展、基础技能等等,没必要分。

2、直播也有成本,需要时间&制作内容。但新人获取的节奏不固定,如果针对新人做,排期很麻烦。

3、老用户的学习状态并没有单独统计给组织直播的同事,导致无法了解每个学习进度下,到底有多少人。

4、拆分人群以后,可能某些人群人数很少,转化率不足以支持单独做一场直播。

5、即使拆分,也不见得能提升转化率,目前没有数据证明这一点。

总之,所谓拆分,可能只是看起来很美好,实操纠结点很多。

但是,这些具体的纠结点,对数据分析来说简直是如获至宝。分析的问题越具体,越容易得结论,分析的问题越模糊,才越难出结论。有了具体痛点,可以看:如何用数据解决问题。

▌第三步:归纳分析逻辑

业务痛点可能是很分散的,用数据进行解决,需要的是分析逻辑。一个最简单的构建逻辑的方法是:从大到小,从粗到细,先排除明显可见的问题,再追细节。

本案例中,站在数据角度,可以将以上业务痛点,总结为三大类问题:

1、现有直播,是否真的转化率不行?仅限于特定主体不行,还是都不行?

2、现有用户,是否转化率天生有差异?哪些能被直播突破,哪些不行?

3、现有产品,是否都适合直播转化,不同单价,是否有不同场景。

这三个问题能直接推导出具体优化建议。

但注意,这三个问题,可能是相互纠缠的,比如一场直播没有带货成功,可能是直播本身不行,也可能是用户没需求,也可能是产品不匹配。此时需要构造分析逻辑。

从题目来看,业务方并没有纠结用户&产品,而是从直播切入。因此构造分析逻辑的时候,也应该从直播开始,先看排除直播本身没有组织好的问题(如下图)。

图片

其次,在教育类产品中,直播话题天生和待销售的产品有关系,但是和观看用户不一定有关系。特别是小白用户,经常分不清自己真正要学哪一块,随便看看的情况很普遍,因此第二层级可以分用户,区分新注册用户/老用户(如下图)。

图片

这样建好了分析逻辑,可以填充数据了,但还是建议做一些准备工作。

▌第四步:进行数据准备

为了描述业务状况,经常需要使用大量的标签,很有可能这些标签并未事先准备好。因此需要做准备。

比如本案例中:

1、直播的标签(学习主题、讲师水平、适用于群体、难度)

2、用户标签(新用户/老用户,新用户的来源渠道,老用户)

3、产品标签(适合群体,价位,学习主题)

这些都需要一一准备好,这样后续分析才能有线索。

注意:很有可能业务方要分析结论要得很急,之前的基础建设非常地差,根本没有时间一一打标签。此时就要提醒业务方:不打标签的情况下,无法对问题深入分析。建议至少把一些特别重要的先打上,不然总是临时抱佛脚,就总进步不了。

▌第五步:输出分析结论

有了以上所有准备,最后一步就是数据填充,根本就是水到渠成的事。而且这样分析,能按图索骥的找到问题最明显的点,从而提出非常细致的优化建议(如下图,注意,由于篇幅限制,下图没有完整展示全部推演逻辑,有兴趣的同学可以自己补全)。

图片

在构建分析逻辑的时候,实际上每一类用户对应的情况,已经是一个具体的业务优化点,只不过数据是最终裁判。哪一类情况出现的多,就有限解决哪一类问题。并且,出现两个因素相互纠缠的时候,也以看数据多少,选择主要问题来解决。这正是数据分析有用之处。不然千头万续,无从下手。

02小结

所以,深入业务场景,剥丝抽茧,层层论证,才能更好地得到优化点。注意:作为优化建议,一般都是从补缺的角度来提,但是补齐现有缺点,并不意味着就是最优解,很有可能有更好的点子。

责任编辑:武晓燕 来源: 接地气的陈老师
相关推荐

2024-07-08 11:33:45

2018-07-23 16:13:27

Google欧盟Android

2024-05-15 10:14:00

CRDT数据类型协同编辑

2019-06-05 13:00:00

2019-11-08 16:05:54

Promise前端链式调用

2019-09-12 09:40:34

秒杀系统高并发

2024-03-11 08:47:30

CRDT数据类型协同编辑

2016-03-31 17:01:26

桂林甲天下

2021-07-03 08:59:49

动态代理JDK

2018-08-07 14:45:52

编程语言JavaScripthtml

2013-11-01 13:21:43

Testin手游用户体验

2016-11-08 07:58:02

乐视难关科技新闻早报

2019-04-12 11:25:24

华为

2016-01-06 11:15:03

VR

2014-07-18 17:14:16

小米苹果雷军

2021-03-11 12:15:37

Kubernetes云原生容器

2019-11-05 11:17:11

Java虚拟机技术Java 堆

2019-03-06 08:56:03

阿里云服务器VPN

2021-08-29 08:14:30

GPU CSS gpu
点赞
收藏

51CTO技术栈公众号