写点什么

Mobile Growth 的方法和实践

2016 年 12 月 25 日

本文根据邵震在 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 的核心所在。

作者简介

Google Search 前员工,Square 全栈工程师、Mobile Growth Tech Lead,专注 Square App 的业务增长,关注 Growth 方法论在 Mobile 开发中的具体应用。


感谢陈兴璐对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

2016 年 12 月 25 日 16:431071

评论

发布
暂无评论
发现更多内容

厚积薄发!华为云7篇论文被AAAI收录,2021年AI行业技术风向标看这里!

华为云开发者社区

人工智能 卷积网络 远程监督 域泛化 油气储集层收集

官宣了!Apache ECharts 毕业成为 Apache 软件基金会顶级项目!

百度Geek说

百度 基金会

ICE暴雪正悄悄崛起

DT极客

托管节点池助力用户构建稳定自愈的 Kubernetes 集群

阿里巴巴云原生

Docker 容器 运维 云原生 k8s

利用 Python 分析了某化妆品企业的销售情况,我得出的结论是?

JackTian

Python 数据分析 数据可视化 化妆品 2月春节不断更

Elasticsearch 写一致性原理

escray

七日更 28天写作 死磕Elasticsearch 60天通过Elastic认证考试 2月春节不断更

日记 2021年2月2日(周二)

Changing Lin

个人感悟 2月春节不断更

重点人员动态管控系统开发,智慧公安平台搭建解决方案

WX13823153201

重点人员动态管控系统开发

第三章:产品解决方案作业

让时间说真话

产品经理

前端面试必备ES6全方位总结

魔王哪吒

程序员 面试 前端 ES6 2月春节不断更

使用pgBackRest并行归档解决wal堆积问题

PostgreSQLChina

数据库 postgresql 开源 开源社区

程序员成长第一篇:机会与趋势

石云升

28天写作 2月春节不断更 机会与趋势

ModelArts AI Gallery与HiLens Kit联合开发丨行人社交距离风险提示Demo

华为云开发者社区

华为云 modelarts hilens 行人 社交距离

挖矿区块链_什么是挖矿 带你详细了解挖矿基础知识

v16629866266

华为云FusionInsight助力宇宙行打造金融数据湖新标杆

华为云开发者社区

数据湖 云原生 存储 FusionInsight 华为云

OpenAI将k8s扩展至7500个节点以支持机器学习;Graph Diffusion Network提升交通流量预测精度

京东科技开发者

区块链 开源

玩转IDEA项目结构Project Structure,打Jar包、模块/依赖管理全搞定

YourBatman

Module IntelliJ IDEA Project Structure

Kafka基础简介

架构精进之路

kafka 七日更 28天写作 2月春节不断更

产品训练营 第三次作业

Wangyunnfei

说说常常被研发忽略的原型模式

后台技术汇

28天写作 2月春节不断更

即构自研海量有序数据网络MSDN,构建全球可靠的多云通讯链路

ZEGO即构

数据库表数据量大读写缓慢如何优化(4)【分库分表】

我爱娃哈哈😍

数据库 架构·

史上最清晰的Tarjan算法详解

华为云开发者社区

算法 静态分析 语法树 Tarjan 数据流

挖矿系统APP源码搭建

luluhulian

产品经理训练营第0期-第三次作业

孙行者

第0期 产品经理训练营 问题

SpringCloud 从入门到精通15---Sentinel搭建和服务监控

Felix

EXCEL数据如何去重? Python:这事我比你熟

智分析

Python

MySQL安装教程&问题解决

Mars

MySQL 运维

Idea工具的各种查找快捷键

小马哥

IntelliJ IDEA 七日更 2月春节不断更

即日起 Jira、Confluence 正式停售本地版,中国客户将无法购买

万事ONES

项目管理 开发者 研发管理 团队协作 CTO

用RabbitMQ了好几年之后,我总结出来5点RabbitMQ的使用心得

四猿外

MQ RabbitMQ 消息队列

演讲经验交流会|ArchSummit 上海站

演讲经验交流会|ArchSummit 上海站

Mobile Growth的方法和实践-InfoQ