Mobile Growth的方法和实践-InfoQ



 写点什么

本文根据邵震在 2016GMTC 全球移动开发大会上的演讲整理而成。

我以前在谷歌工作，大概 2013 年的时候到 Square 公司，后来一直做 Growth 的工作。在一个技术论坛上，可能我讲的这一部分内容是最不技术的。提起 Growth，大家认为很神奇。以前范冰老师写过一本书，叫《增长黑客》，这个书名非常迷惑人：黑客像是超人一样的存在，一个人坐在黑漆漆的屋子里面。实际上 Growth 很现实，整个硅谷都在谈论它。不但在谈论，而且他们认真在做。

据我了解，Growth 在国内也是非常火的概念。首先，每个公司都在谈；每个人都觉得他自己知道 Growth 在做什么；Growth 的一个小概念叫病毒式营销，每个人挂在嘴边。第二，在所有人都不认识我的情况下，很多人还会来听讲座，完全是因为 Growth 本身的魅力。

再谈 Growth

第一个部分是“再谈 Growth ”。为什么是再谈？虽然 Growth 这个词已经很火了，但是在火的背后，我看到大家对它有很多误解。

第一个问题是，什么是 Growth 。我对 Growth 的一个比较简短准确的定义是，Growth 就是“实现业务的有效增长”。这里面有几个关键词：实现、业务、有效，最后是增长。Growth Hack，我把它翻译成，不是“增长黑客”，而是“增长法”。“法”这个字在汉语里包含“工具”和“思路”的成分。Growth 是一个相对新的想法，硅谷一直在谈、在实践、从下往上在摸索。一直到近两年，才有人把 Growth 的概念提炼出来，将它作为一个方法论。

那么，为什么现在在中国火起来了？因为现在中国的公司感受到压力。Growth 可以带来效率的提高，不管是工程效率，还是使用钱的效率、获取用户的效率。这种效率的提高，对公司非常重要。在市场增长天然特别好的情况下，把资源使用在实现产品特性上面，会获得更大的价值；而在市场走冷，竞争变强，每个人都不得不计算获客成本的时候，Growth 就重要起来了。

Growth 在中国以及整个硅谷，有什么样的难点？这是由 Growth 本身的性质所决定的。在一个小公司，Growth 其实就是适应市场，就是说公司给用户提供什么样的价值，最终决定了用户会有多少人、以什么样的频率停留在平台上面。在 Medium 上面有一篇比较有名的文章，叫“ Why startups shouldn’t have a growth team? ”（为什么一个小公司不应该有 Growth 组）。虽然有标题党之嫌，但有可取之处。因为全公司都是 Growth 组，应该由 CEO 带头做 Growth。在公司的发展前期，Growth 用来贴近产品的本质，寻找它的市场立足点。在发展后期，当市场需求很稳定了，公司做什么、怎么挣钱很稳定了，Growth 可以去更靠前的位置，向用户传播价值，让用户的行为“快速收敛”到你想提供的价值，这时候，Growth 就变成向用户展示公司价值的一种方式。

公司怎么把有限的资源，不管是钱，还是工程师、产品经理等，放在一个无限的机会空间上，都是 Growth 擅长做的。Growth 从中找出用最小的代价获取最大利益的点。但是这件事情不好做。

Growth 代表了工程师跨界的思路。硅谷绝大部分的 Growth 是由工程师来驱动的，他们不是普通的工程师，而是需要很好的产品和运营知识，需要懂设计，需要懂 data，很少有人能够胜任。

在国内，我认为还有一些额外的挑战。大家对 Growth 有一些误解：把买流量看作 Growth 本身；重视非技术运营；产品迭代特别快，快到数据埋点、整个数据收集都来不及做；国内创业有自顶而下做决策的习惯，老板说了算；还有工具不到位的挑战。硅谷已经到了创业环境比较成熟的阶段了，很多工具已经用了很多年。但是在国内想找一个特别值得信赖的工具很难，同时还要考虑这个工具的背景、是不是属于某一个竞争对手。这些都是数据缺失、工具不到位造成的困难。

现在我把所谓的“增长法”拆解，用一种简单直白、尽可能诙谐的方式讲出来。

首先是 Growth 关心的核心话题。我们把 Growth 分成 4 个部分：用户获取、用户转化、用户变现和用户留存。AARRR 这个模式，和以前看到的一些技术分享，稍微有些不一样的，但本质上是差不多的。AARRR 会给人一种误解，就是整个 Growth 是一个漏斗，它是逐渐变细的。盈利一定是通过忠诚用户产生的？不一定。推荐一定是通过付费的用户产生的？也不一定。新用户能不能做？可以。

我们来看一个现实版的 Growth。现实中 Growth 就关注这几个核心话题，但是这几个话题实际上是纠缠在一起的，而且非常零碎。如果有真正可以将它看成比较严格漏斗模型的地方，只有用户转化：以“潜在用户知道你的品牌”作为起点，把“把潜在用户变为一个你的忠诚用户”作为终点。每一步都严格依赖上一步的成功。

Growth 最基本的单位是什么？

首先观察产品或者用户行为的模式。比如，这个模式可能是说，用户在某一个页面丢失得非常快。根据观察到的模式，去设计一个方案，这个方案会假设一个解决方法，同时设计一个指标，也就是“到底哪一个数据可以清楚告诉我这个解决方法是好还是坏，有多好”。方案设计完了之后，要做工程实现。如果这个实验是成功的，要投入应用和监测，因为短期的实验结果并不代表长期带来的收益。最后，如果有比较强大的数据分析人员或者产品人员，会进一步挖掘这个实验所带来的启示。

图中右边所示是一个比喻。就像开发药物，要先研究这个病，开发这个药，做临床实验，最后，这个药应用之后还要做监测，最后回到理论。在美国做药是非常非常复杂的，药使用在人的身上，而人是国家的根本。医药的整个体系都是以人为本。对于 Growth 也是这样。用户体验是很敏感的内容，要非常小心，否则一旦你的用户走了，再把他叫回来，是非常难的一件事情。

图中这个流程里面，需要一些工具支持。比如需要有深挖数据的工具，具体做实验的时候，A/B Test 是很重要的工具。

从操作者的角度来讲还有几个步骤很重要。首先，操作的人需要理解他的产品，所有从事 Growth 的人，需要统计素养，需要理解用户，同时要理解工程实现的难度。

Growth 组的操作，其实会把它组织成一个实验的管道，用某种方式来跟踪有哪些实验想法，有哪些已经开始了，哪些已经完成了，对完成的实验要计算影响，成功实验的影响相累计，大致上可以估量一个 Growth 组的成功与否。这是非常粗略的表述。任何一个 Growth 背后都有实验，每个实验都非常小，每个季度可能可以做上百个实验。虽然一个实验带来的收益非常小，但是整体加起来很大。

Growth 里面经常会讨论这样一件事：我有很多很多的主意，哪一个先做，哪一个后做？这个时候就会在心里画这张图，去思考每一个实验，机会有多大，工程成本有多大。如果工程师比较熟悉工程，那么对工程成本应该有一个非常清楚的估计，对数据比较熟悉的，也会对机会大小有一些估计，这其实都是在算性价比。

这个图还有一个额外的维度。图中的圆有大有小，表示在一个点上的同一思路会有一系列的想法，可以产生一系列的实验。我们验证了其中一个实验，很可能会提示，在同一个坑里挖到更多的金子。

下面是 Growth 实践中的一些心得，比较零碎不成体系。首先，Growth 最重要的部分是用户留存。没有人是傻子，可能某一个阶段他会受到欺骗，但是他最终留在你的平台上，完全取决于你的平台能带来多大的价值。

在组织架构上，一个最小的 Growth 单位，至少要有工程、产品、数据、设计，还有运营。不一定每个部分都有一个人，但是每个部分都有人能覆盖到。之所以要由工程师来驱动，是因为工程师是组里最了解产品的人。他了解你有没有触发产品的特性，写代码的时候明确知道性能的弱点，知道埋点在哪里最好，甚至产品是否有修改，工程成本有多大，工程师必须有第一手的信息，任何实际改动都要由工程师落实。由工程师来驱动其实是最少沟通成本的方式。

从公司的角度来讲，做 Growth 需要有一个自顶而下的战略：公司需要从结构上去保护这个思路。如果你要求技术工程师追求技术难度，用这个事情衡量他的工作，他不会把对公司业务的影响放在最核心的部分，他被迫想的事情与 Growth 的思路是相悖的。

最后，快速迭代并非必不可少，但是有了它可以做得非常顺。在最后的数据出来之前，谁也不知道好坏。比如，想做能够支持匿名用户的实验，想知道用户不用注册是否会留存更多人。那么，立刻去做全 App 的匿名支持、完全不需要登录的产品，还是去做非常小的实验，比如推迟一到两步要求登录，来验证不需要登录这件事对用户有多大的影响。

Growth 方法论

Growth 是一个方法论，理论很美，但是不一定适合所有的公司。你至少需要同意，或者从内心深处认同几个理念。

第一个理念是，你是否认为，产品的成功是由用户是否喜欢来决定的。比如，你做政府项目，或者做市场稀缺功能，用户可能不得不去用，所以 Growth 在你的用户行为里面的影响其实只占了很小很小的部分，这个时候你没有必要去考虑 Growth。

第二，你是否认同，所有事情最后都是可以衡量的。比如，产品受喜欢度，是否可以量化，获客策略是否可以量化。

最后，Growth 是否只是产品中锦上添花的部分？因为做这件事消耗很大，硅谷的 Growth 经常挂在总监下面，Growth 这个大坑挖出来，需要人，需要资源，需要协调关系，可能开始的时候都很顺利，但是你很快就需要考虑“到底值不值得做”这个问题。从硅谷现在来看，绝大部分的公司都把这个坑挖出来了，这是有一定的道理的。

从抽象层面上看，Growth 的方法论就是，怎么看待 Growth，怎么做 Growth。现在小结 Growth 的方法论我觉得功力不够，我更愿意引用这方面的一个大师讲的一段话，这个大师的名字叫庄子。

“彼节者有间，而刀刃者无厚，以无厚入有间，恢恢乎其于游刃必有余地矣”。这句话是说，产品里边有一些“解决起来很简单，但是影响非常大的”问题，就像“关节里的缝隙”；刀刃者无厚，Growth 就一把锋利的刀，要“以无厚入有间”，就是用最有力的资源去做这些成本低影响大的“关节”之处，这样才能，“十九年而刀刃若新发于硎”。

当你看到一个服务的交汇点，或者是用户体验或者性能非常敏感的点，你要慎重，这就是所谓的“族”，“血脉筋肉交错的点”。你要重视，要有畏惧之心，“见其难为，怵然为戒”。那这时候应该怎么做呢？庄子告诉我们“视为止，行为迟，动刀甚微”，就是说你要先看，过一会再做，每一刀都特别小。在 Growth 方法论里面这个非常典型，要先去观察，然后用数据指导该怎么做，想清楚之后再动手，每一个实验都非常精准，非常小，但是这些实验累积起来总是能把事情解决的。这时候庄子生动描绘了解决了一个大问题之后的模样，“提刀而立，为之四顾，为之踌躇满致”，赶紧写一篇报告，发给全公司看，非常开心。最后，“善刀而藏之”，也就是要清理实验代码。

Mobile Growth 的机会和挑战

在 Mobile 里面，Growth 的概念一样可以使用。只不过平台不同，会有一些特别的挑战和机会。在 Mobile 上面很难做跨链接，很难做属性，很难快速迭代，因为有发布周期的要求，也很难去做一些 A/B test，而且还有下载的障碍。这是 Mobile 独有的挑战。

同时，Mobile 里面有一些独特的机会。手机是一个个人的设备，手机打开一个 Square，基本上可以知道你这个人是谁。可以长期跟踪一个用户在这个平台的很多操作。从产品设计的角度来讲，也不需要登录，这点也是不错的。第二，设备即入口，打开手机， App 已经在那里了。不再受到搜索引擎的钳制，只需要通过用户习惯就好。第三，设备即通道，App 在手机上，就打开了服务用户的沟通通道。这个通道是驻留的，你可以通过它找到你的用户，而这在 Web 上是不存在的。

User Onboarding 顶层思路

User Onboarding 非常重要。用户获取到了，准备下载这个 App，这时候就是 User Onboarding 的起点了。如果你熟悉这个图，说明你已经有一定的 Growth 的基础，这是最典型的 Funnel Analysis（漏斗分析），把用户的量作为指标，然后按照这个流程来进行分解。可以看到，每个大红柱，相当于一次用户丢失。假如有 100% 的用户在起点位置，可能只有一半用户会下载 App，经过登录页面，有少量用户丢失。注册这一步需要用户提供身份信息。搜集完信息之后，让他体验产品最核心的功能。然后第二次使用、第三次使用，一直到付费阶段。在这个流程里面，用户数量是递减的。一个最基本的 Growth 方法就是，去看你的用户在每一步产生了多大的递减，做一些相应的优化，把一部分用户挽回回来。

用户到底有多大的意愿去下载 App？可以在下载页面去做一些 ASO，比如，测试用什么样的图、什么样的标题更吸引人。可以去做一些很精准的评估，一个比另外一个到底好多少，好在哪儿？ App 本身的大小也会影响下载意愿。

再比如，支持匿名来减少用户在注册时候的流失。也许因为需要输入 email，用户就不愿意继续了。可以考虑取消、推迟注册，或者接入第三方，比如微博、微信，通过这种方式来减低登录的难度。搜集信息的过程中，把需要手动输入的变成选择，把能猜的猜出来。通过了 Aha Moment，也许下次他会想不起来这个 App 而丢失了用户，这个时候就要推送一些信息。在真正付款的时候，因为付款流程做得不好，或者用户觉得这笔钱太多了，他也会放弃，所以要提供更灵活的付款方式。

这就是在 Onboarding 里面如何做漏斗分析的最典型的方法，可以找到一些优化的办法。

漏斗分析是非常基础、非常有用的工具。但是它有它的问题。第一，建立了一种和用户对立的心态：不管你的产品做得再好，用户总是会离开。就像登录页面做得再好，用户数量还是会降，Aha Moment 做得再好，用户数量还是会降。跟用户不一样，产品设计者在看漏斗分析的时候，是基于统计的角度，而用户并不是用统计的方式留存的。第二，当大问题解决得差不多，就开始专注解决这些小流失，这些小流失可能很大程度上是因为性能的问题，Growth 就慢慢变成了性能优化。第三，用户不愿意付款，不一定是因为付款页面做得不好，很可能是因为他觉得不值这个价，而这个问题，你没法通过漏斗分析来解决。

我建议的一个方式是，你要从用户的视角去看流程。这里面横轴依然是流程，纵轴变成用户用这个 App 有多少的意愿，这个意愿大致用了一个数字来描述。首先，假设意愿都是 100，这个时候，用户需要耗费他的意愿去下载。用户来到了登录页面，如果登录页面提供了好的信息和材料，用户会对未来有更多的期待，或者想对产品了解更多，他的意愿可能会上升。用户在注册和激活的过程中依然是降的，但是如果你的 Aha Moment 做得好，再次调起他的兴趣，可以重新激起他对后面的付费行为有更多的意愿。如果产品体验做得好，每一次的使用行为都可以积累意愿，最终支撑一次变现。一个好的产品，在这条思路下，会一直思考用户到底怎么想。

从这条思路可以推导出另外一套优化方法：是不是可以做一些正向的改进。首先在登录页面上可以做一些优化。比如，讲清楚 App 到底对你有什么价值，把推荐人的头像信息放进来，提供上下文，让推荐的社会信用变成 App 本身的吸引力。如果做 2B 的产品，需要搜集身份证号、电话号码，或者企业信息，用户可能在这个过程中没有准备好，那么可以在登录页面告诉他，“需要准备这些信息再开始注册”，避免用户在流程的一半卡住而流失。

在整个激活的过程中可以给一些引导和解释。比如，为什么需要电话号码，并不是要把个人信息卖给下家，而是要在你的业务出问题的时候快速找到你。需要强调和解释“对用户的价值”，这个“价值”很多时候，你在设计产品的时候其实已经考虑到了，所以在设计流程的时候就也要考虑怎么呈现出来。比如，在做 Aha Moment 的时候，需要强调让用户感觉到自己得到了价值；做一些比较有趣的动画，甚至实质性的奖励，能够提升用户的兴趣。Aha Moment 是一个重要节点，这里可以提高很多用户的兴趣。

完成了第一个最关键的功能之后，要对其他新功能做引导，在合适的时机把功能推送给用户，以至于用户还有兴趣继续使用。谨慎地请求访问，避免让用户感觉不舒服。在收费之前，对收费的功能到底干什么，通过收费能够得到什么价值，还有别的用户在收费之后得到了怎样的利益，对他的企业有什么帮助，可以逐步预先展示给用户。这些都是在为收费做准备。

User Onboarding 有两个关键点。一点就是传输价值，要让用户看到价值在哪儿；另一点是除去痛点，需要去除用户在流程中遇到的痛点。如果能正确做到这两点，是非常好的 Onboarding 体验。还有第三点，在 Onboarding 的时候，要建立一条通道，比如让用户允许推送通知，以便于之后引导他去使用更多新功能。

Mobile Growth 关键技术

下面讲 Mobile Growth 的几个关键技术。从上往下看, Growth 是一个非常复杂的流程，用到的技术也非常驳杂。这里将其中一些最重点、最关键的部分提出来讲一下。

这里有一份来自 Mobile Growth Tech Stack 的总结，作者大概每年都会总结一下，今年有哪些技术趋势，罗列得非常细致，也许只有特别大的公司才会使用其中的很多部分，但的确是一个很好的总结。

A/B testing 系统搭建

第一个是 A/B test 。以前修电脑有一个概念，电脑坏了，到底哪儿坏了，把内存拔出来，换一个内存，如果系统修好了，那么就是内存坏了。在分析产品流程的时候可以采取同样的思路。设计一个叫做分组器的机制，分组器告诉产品：让这个用户去实施行为 A，让那个用户去实施行为 B。通过数据分析看出来，实施 A 的用户下游行为好还是 B 的好，能够好多少。这个就是最基本的 A/B test。

分组器和产品之间，交流“A 还是 B”，这个就是 A/B test 系统中最基本的部分。再增添一些“细节”，就是可以规模使用的 A/B Testing 系统了。图中这些绿色的组件就是所说的“细节”。分组器告诉产品怎么分组，分组结果和下游行为通过“埋点”进入 Log，Log 需要进行处理。Log 处理之后，一方面用于指导下一次的实验流量分配，一方面是用于计算指标。这个指标可能会向实验的设计者、产品经理或者工程人员，形成一个图表，展示在面板上。数据人员可能需要一些额外的深度分析指标的工具。实验配置工具是配置实验的入口，这个系统既决定了分组器怎么分组，也决定了最终需要计算哪些指标，还跟流量分配有一些关系。QA 测产品的时候，可能需要精确控制在一次测试中的实验行为是 A 还是 B。这是一个比较复杂的多方系统，想要一次全部写对比较困难。幸好大部分时候不需要考虑太多的技术细节，很多第三方的工具会帮你完成整个流程。

对于 A/B test 系统，更多的不是技术上到底怎么去写，而是怎么选择和使用。如果要设计一个系统，或者评价一个 A/B test 系统，首先需要考虑两个内容，第一是核心，第二是优化。

核心的部分是“一个 A/B test 的 MVP 到底需要哪些条件”，优化是说扩展方向。避免伤害用户体验，这是最基本的要求。在决定选择 A 还是 B 之前，发出一个请求，这个请求最迟要 5 秒才返回，整个界面都停止，这当然伤害了体验。比如，后端不小心改了实现，发回来一个不规整的响应，这时候客户端报错说，“非法的实验分组数据”，这当然也是对用户体验的伤害。一个系统出了故障，能不能回滚到正确的产品行为，优雅处理，让用户不知道，这个是最基本的要求。

其次，统计有效。到底怎么设计实验或者怎么评价实验的结果，有一些统计上的具体要求。比如，是不是做到了真正的控制变量，实验的设计是不是对 A 组或者 B 组有天然的偏见，对统计结果是否存在主观误读，实验之间有没有交叉影响，实验有没有新鲜感效应或者上手期，等等。做实验涉及很多统计知识，才能正确地设计和分析，A/B test 系统要基于正确的统计假设来计算、判断和展示结果。

这个系统的“优化”里面还有非常多的细节，比如，性能方面的考量，扩展性方面的考量等。

Deep-link 的趋势和使用

Deep-link 在国内很火。比如有这样一个场景，在百度上搜了一个新闻关键词，条目是某新闻 App 提供的，点击这个条目，结果打开了某个新闻 App，并且把这个具体的新闻页推送给我，这就是 Deep-link。换句话说，可以从 App 外面直接跳转进去，发现 App 里面某个深度内容页面，这就是 Deep-link。

在一些复杂的情况下，有一个叫做 Deferred Deep-link 的变体，可以在 App 没有预装的情况下实现类似的效果。这在技术上做起来没那么简单，但是依然可以实现。从图中可以看到效果还不错，减少了一些步骤，每个步骤原本都有用户流失。

Deep-link 的实现细节，这里不仔细讲了，很多第三方的工具可以帮你实现。原理上比较简单，通过一个短链接，把参数存在第三方服务器里面，使用这个链接的时候，会询问第三方，通过指纹匹配取回参数。原理不是特别复杂，但是实现起来比较难。

另外，我最想讲的是：Deep-link 对产品设计和 Growth 会带来什么影响？

首先，它解决了跨链接和属性的困境。特别是在 iOS 上，你进入 App Store，本来所有的参数全丢了，但是 Deferred deep-link 可以帮你再找回来。

第二，它改变了 App 只能从 App Store 中得到的现状。使用 Deep-link 之后，传统的搜索引擎或者内容门户网站也可以变成 App 的入口了，这很有利于以内容为主的 App 来进行病毒式传播。

最后，是入口多样化和业务的切片化。App 的入口不再仅限于下载、点击 App 图标、注册、使用。从某个具体内容或者某个子功能进来的用户期待短平快的流程，快速进入感兴趣的内容。是否要对这些新的入口做单独的优化，这会是新的问题和机会。

这种改变同时代表了“业务流程切片化”的趋势。这种趋势告诉我们，把一个大而全的 App 直接推到用户面前可能不是一个好的选择。Facebook 的主 App 有 100+MB，基本上包含了所有功能，但是可能今后的 App 会设法避免这种情况，因为下载这样的一个 App 对用户来说是一个负担。一个 App 有几个不同的业务入口，每个业务对应有一个相对独立的模块，甚至子 App，或者像谷歌的即时 App 倡导的那样，只装载一个小的 App 功能切片，在这个切片里实现简单的功能，再推销整个全功能的 App。这样的做法可能会成为趋势。

这种趋势不仅是一个外部的切片化，也是内部的切片化。即使不考虑外部怎么接入，你在 App 的内部也可以做切片化。手机 App 的一个很大的特点是屏幕小，分区多。设计产品的初期总是希望流程是清楚、专注、不被干扰的。但是到了后期，功能多了之后，又希望流程之间的跳转更灵活一些。一个折中的方案可能是，把每个业务流程起点设置成一个 Deep-link 目标，这样跳转操作可以用一个 URL 精简地表达，既可以方便跳转，也不用泄露太多实现细节。这种内部的可跳转性，有助于灵活地做 Growth。

Growth 中的内容动态化

动态化是一个很大的话题，但是这里我们只讲一件事，就是 Growth 的眼中怎么看动态化。

Growth 眼里的动态化，并不是一个大而全的系统，比如 React Native。Growth 考虑的最多的问题就是，用最小的代价来实现一件事情。我们看一个功能开关，on/off，是动态化；动态内容填入静态模板，是动态化；可动态调整组件来构建的页面，是动态化；一个业务模块的流程可以从服务器端获取，也是一种动态化。在考虑动态化的时候，会有一个权衡，具体的用例到底要用什么办法来实现。如果只需要改一个标题就可以实现，何必要上 React Native。

高度的动态化牺牲了可测试程度，也提高了使用时需要的后期资源。功能开关是不需要后期资源的。内容模板至少需要一个写作者的参与。具体的可拼装页面就需要设计者来设计。如果讨论动态流程，可能 UX 和 PM 都要跳进来问：这个流程是不是科学，是不是符合我们产品的理念。React Native 搭建的动态结构，在使用的时候，可能需要整个开发团队都参与进来。既然 Growth 讲成本效率，动态化也要讲效率，即用最小的代价去做你想做的事情。

总结

Growth 是真实存在的，在硅谷被广泛使用，并且现在已经来到中国。有很多客观原因导致在中国没有使用起来。但是现在条件已经逐渐成熟了，比如竞争激烈导致的对各种效率的要求。最终你一定要用 Growth，唯一的忠告是，不要急于做出一个大而全的系统，可以选择第三方工具，可以选择定制的逐渐演进的系统。因为，用最小的代价完成最大的事，才是 Growth 的核心所在。