声明：本文来自于微信公众号见实(ID：jianshishijie)，作者：见实，授权站长之家转载发布。
今年 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测试和用户管理等，最上层是内部增长团队可提供的咨询类服务，属于更为高阶一些玩法。
以上就是我的分享内容，现场分享时间有限，一些深度内容可能无法展开，我们可以在会后进行更为深度的沟通和探索。
