You need to enable JavaScript to run this app.

4个数据驱动用户增长的痛点背后,有3套最优解

最近更新时间2021.02.28 17:15:10

首次发布时间2021.02.28 17:15:10

4个数据驱动用户增长的痛点背后,有3套最优解

今年8月,笔者曾做过一次小范围的调研,问题很简单:作为管理者,下半年最关注什么?

大部分人的回复也很简单: 赚钱 。但赚钱背后,永远都绕不开另外两个字: 增长

不少公司经常都把各种增长模型挂在嘴上,但真正去实操时,才发现这些理论实践起来很难达到实际效果。

这不仅是由于理论到实践的鸿沟不易跨越,还存在很多业务人员无法直接解决的技术难题。

用户增长就像一座辉煌的宫殿立在山巅,等着我们去朝圣,去进军。但在去往宫殿的路上,并不是一片坦途。 这一路上会有很多坑,坑里还有水,水里还有钉,总是趟不完。

9月8号的见实大会上,火山引擎数据智能解决方案总监孙超赟进行了一次简单干脆的分享,直截了当地说清楚了,火山引擎如何帮业务人员解决其数据运营过程中遇到的各种坑。

现在借助文字实录,我们不妨回到大会现场,听听孙超赟讲到的运营痛点和具体解决方案。如下,Enjoy:


大家好,我今天分享的主题是《技术驱动下的品牌业绩增长》。

理论很简单,现实很骨感

我个人是技术出身,在学技术的时候,很多专业书籍的名字都叫《深入浅出xxx》。今天也用深入浅出的方式,跟大家分享一下数据驱动下的用户增长。

image

我先举个大家都比较熟悉的增长模型。当我们提到“用户增长”时,脑子里会蹦出很多概念,最先出现的可能是上图中的AARRR漏斗模型,通过这个模型可以评估出用户不同的生命周期和阶段。

step1. 引流是用户增长的源头活水,我们会注重高效投放,精准引流;

step2.转化是用户增长的核心,要让用户快速领略产品核心价值;

step3. 留存是用户增长的坚实基础,不断在流量池中沉淀用户的企业才能做大。我认为 用户留存始于价值,久于习 惯;

step4. 变现是用户增长的业务目的,很多时候可以尝试在小程序内变现, 除了用户本身以外,不要忽略广告流量也可以变现;

step5. 自传播是用户增长的持久动力, 不能一味靠自己拉新,还要充分利用用户的社交属性来实现自增长。

比如,疫情期间,ZOOM就将用户的社交属性用到了极致,因为大家一旦开会就会自主下载ZOOM软件,并且不断的影响更多的用户使用ZOOM。

image

上图也是一个可落地实操的方法论,可用在用户的生命周期里的任何阶段。

内环是我们的行为,外环是我们的收获。

通过分析可以得到业务和用户的洞察,通过决策可以得到业务发展的策略,通过做A/B测试、触达和精准运营,并将评估结果产品化。

我举一个具体的案例,大家可能更容易理解。下图是我们的一个社交类产品的客户,用户注册的路径为:下载APP-启动APP-选择注册方式-手机验证-填写个人信息-注册成功。

image

在分析阶段,我们发现从选择注册方式到注册成功的关键路径中,漏斗突然变窄,这意味着用户在这一阶段大量流失。

为什么?因为软件默认首选的登录方式是微信登录,但使用微信登录后仍需要强制用户绑定手机号,这让用户有种被忽悠的感觉。他们会认为,该软件先获取了自己的微信信息,还想继续获取自己的手机号信息。

接下来,我们的决策为:是否可以直接用手机号来登录?通过对A/B实验的对照组评估,发现其转化率远高于之前。因此,我们开始将实验组的结果推广到所有产品上,做全流量铺开。

这么讲,好像用户增长还还挺简单, 用户增长就像一座辉煌的宫殿立在山巅,等着我们去朝圣,去进军。

但对不起,在这里我要给大家泼一盆冷水,因为真正去落地的时候,大家会发现, 在去往宫殿的路上,并不是一片坦途。这一路上会有很多坑,坑里还有水,水里还有钉,总是趟不完。

用户增长之路上的那些大坑

现在,让我帮大家回顾一下,我们经常使用的各种平台工具,都有哪些痛点?

image

第一,先看一下用户分析工具。

其业务目的是通过数据还原事实真相。比如用户的行为路径或流失原因等。而 最大的痛点就是做埋点,因为业务方和技术方在这里会有一个天然的矛盾。

业务方如果想深度分析各个细节点,埋点就一定要精细;但对技术部门来说,精细埋点就意味着要耗费大量的人力,这会严重影响到其他的工作进度。

但如果不投入技术人员,做全埋点或无埋点,就会使得业务人员非常痛苦,他们需要通过各种抽丝剥茧的方式,寻找一些自己需要的业务数据。

第二是A/B测试。

曲卉老师的书里会提到,如果要做增长,一定要做大量快速迭代的A/B测试,其中,A/B测试是前提条件。其业务目的是什么呢?主要是通过小流量的先验,来保证决策的正确性或找出最优解。在这种情况下,面临三个痛点:

01.分流。 因为分流姿势不对,全部努力白费。 比如,有的企业通过用户ID尾号奇偶性做分流。从极限理论上看,奇数和偶数占比各一半,仿佛是没有问题的。

但是一方面有多少企业的数据已经积累到了这极限的边界;另一方面,用这么多数据来做A/B 实验,那就更谈不上小流量先验了。我们还遇到过一些看似“高级”的分组方式,其实都不太严谨。

那么大家一定想知道,我该如何判断自己的分流是否科学?给大家提供一个最简单的方式: 不要做A/B实验,而是做A/A试验。 如果分流科学,那么A/A实验的结果是几乎没有偏差的,可以用来做自验。

02.置信度。可以简单理解为, 如果把这个事情再重复做一遍,有多大概率能拿到同样的结果? 我们做A/B实验,置信度就是让我们把结果推向全部产品的保证。

比如,我们看到在置信度95%的前提下,实验组比对照组的提升是(10%-20%)。怎么理解呢?就是我们把这个实验再重新做100次,那么有95次的结果,实验组对比对照组的提升会落在(10%-20%)这个区间之内。

03.发布。现实中,我们可能会遇到直接发布产品后,才发现技术或体验上的问题,不得不回滚到旧版本的情况。

但如果App 是在苹果商店发布的,就需要等7-10个工作日,最后的结果是引起用户负面体验,包括用户的流失。

最理想的状态是逐渐迭代发布,按照10%、30%、50%的节奏,做小流量的分布。

第三是智能运营平台,业务目的就是“四个正确”。

即在正确的时间,通过正确的渠道,把正确的内容,发送给正确的目标用户。进而来保证用户体验,促进用户增长。这里也有三个痛点:

01.多触达通道管理混乱。 比如,触达通道包括站内信、APP push、短信和公众号等。这么多通道哪个更好?即使只做APP push,仍不知道哪个第三方工具或平台更合适。

02.触达时机,重口难调。 有的企业会优先选择早上推push,但有的用户是做公共交通,还有的用户是开车,遇到堵车完全没心情看任何信息。如果解决不了触达效果,就会遇到 运营的“三多两少”问题 ,即投入多,触达多,用户负面反馈多,但召回和转化都很少,运营效果不显著。

第四是用户数据平台 ,就是所谓的CDP,现在很多企业都尝试在做。

CDP的业务目的是一切分析和精细化运营的业务逻辑基础。什么是业务逻辑基础?里面的用户分群是从业务视角创建的,使用过程中不是简单看一下用户分群有哪些。需求会非常多变,会需要实时调整。

如果没有一个好的工具在这里做支撑,底层的数据准备,也就是跑数据的需求,会非常困难。

通常,跑数的需求会提交给技术部门的兄弟,对方的回复可能是,这项工作排期要到一周后才能拿到结果。过程中如果需要小的调整,又需要再等一周。

这就暴露出业务人员的一个痛点: 严重依赖技术部门,跟技术部门沟通起来很复杂,还要被他们的工作排期所制约。 技术部门同样痛苦,因为这也会增长他们的工作负担,影响其他工作内容的推进。

以上,是业务人员在做用户增长过程中,可能会遇到的各种困难。做用户增长,就像是看到一座辉煌的宫殿,但要到达宫殿就需要经历九九八十一难。

是不是要绝望了?悲观的人往往正确,乐观的人往往成功。大家千万不要气馁,接下里,我会分享一下火山引擎是怎么帮助客户克服这些困难的。

火山引擎怎么做用户增长

首先,我们会将 企业团队使用的相关产品进行底层拉通,在企业内形成多个工具相互协作的解决方案 ,你中有我,我中有你,最终实现1+1>2的效果。

image

第一,底层架构的一致性。有什么好处?

很多公司内部做用户增长会遇到“混布”的问题。简单的讲,就是多个工具之间底层结构和版本不兼容,但又不想准备两个集群,那么就要把这些平台强行部署在一个集群上。其部署成本和运维成本都不可控。

火山引擎的底层是拉通的,所有工具类平台都可以和谐地搭载于一个集群上,运维环境单一,硬件成本和运维成本都显著降低。

第二,多平台的整合性。

怎么理解?举个例子,比如一个新家刚装修完,有人买家具时会选一个大品牌,把所有柜子、床都买全,追求品牌整合。

01.在火山引擎的所有功能中,产研侧会以功能区分,从功能角度拆解,不会出现功能冗余和“三不管”的情况,每个功能都只有一个,且都能找到可对接的团队,完全满足MECE原则。

02.业务侧从场景出发,保证场景的完整性。比如,用不同版本文案做触达时,怎么选?我给大家一个简单的办法,对业务人员来说, 在触达场景里嵌入A/B测试功能,就能保证场景的完整性。

03.用户权限统一管理。比如,一些大公司总部下面有很多大区和加盟商,他们对数据的可见性要求极高。

当我们所有工具类底层拉通,从组织架构出发,就能对所有的数据指标和运营活动进行灵活设置,保证业务数据的可见性且相互隔离。

第三,数据统一性。

首先多场景的数据联动,可以解决“数据孤岛”的问题。“数据孤岛”方面,我用一个商品的广告语来总结:“通则不痛,痛则不通”。如果业务人员使用的数据是割裂的,就会很痛苦。

在火山引擎中,我们辛苦建立的数据指标,技术同学辛苦采集上来的业务数据,可以不再只应用于一个场景。比如,不仅可以做用户行为分析,还可以用于A/B测试、智能触达、智能推荐等,让所有上层应用都使用起来。

打个比方, 你的业务就像是一座新建起来的房子,用户增长平台就是整个房子的硬装,而在用户增长过程中所使用的各种策略和方法论,就是整个房子的软装。底层有好的硬装,才能保证上层的软装发挥更好的作用。

image

这张图,是火山引擎的整体架构。前面提到,底层数据是可拉通的,所有数据在底层都可以统一管理。

往上一层有各种工具类,可以做数据分析、优化、A/B测试和用户管理等,最上层是内部增长团队可提供的咨询类服务,属于更为高阶一些玩法。

以上就是我的分享内容,现场分享时间有限,一些深度内容可能无法展开,我们可以在会后进行更为深度的沟通和探索。