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

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

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

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

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

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

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

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

理论很简单，现实很骨感

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第二是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的效果。

第一，底层架构的一致性。有什么好处？

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

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

第二，多平台的整合性。

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

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

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

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

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

第三，数据统一性。

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

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

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

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

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

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