增长,对任何企业都是永恒的主题。不论初创公司还是已成熟的大企业,在经历一段高速发展后,都会触碰到阶段性的天花板。能否持续创新和保持增长,正是一家公司走向伟大或平庸的关键。
在“网络效应”非常明显的互联网领域,通常是得用户者得天下。所以对赢得用户的重要性,再如何强调都不为过。特别是企业增长,往往和用户增长有很大的重叠部分。
增长黑客的概念大家都懂,但碰到一个具体的产品大家还是不知道应该怎么做用户增长、怎么构建用户增长团队,仅停留在增长黑客的概念层面。
- 在国内具体环境下,针对一个产品,应该怎么做用户增长?
- 用户增长与渠道投放的关系是什么?
- 用户增长的基本方法论有哪些,如何应用这些方法论?
- 用户增长与产品的关系是什么?
- 用户增长与运营的关系是什么?
- 用户增长与品牌市场的关系是什么?
- 如何构建一个理想的用户增长团队?
确定增长的阶段性目标
其实,做用户增长和选择公司战略有点类似,最大的挑战不是如何做,而是到底应该把有限的资源投到哪些地方、选择什么样的增长项目。要想确定当前阶段需要做的增长项目,就要明确当前的战略目标是什么。
在商业竞争中,如果竞争对手做了某个产品功能,一般我们跟风做,就算效果没有达到预期,往往也说明了我们市场嗅觉敏锐、反应及时,不会被过多诘责。相反,如果这个产品功能被证明效果很好或者你的老板觉得非常好,而你没有做的话,后果往往很严重。所以从个人角度来说,跟竞争对手做同样的动作,常常是最安全的,但一般都不是最好的。这个时候,认清当前目标尤为重要,要以终为始、深度思考,方能有理有据独立决策。
增长组织保障
我常听到这样一种声音:组织保障是最容易的,不就是组建一个用户增长团队,去协调各种资源做增长项目,然后实现增长目标嘛!这种想法暴露了一个很严重的问题——实现用户增长的组织保障常常是最容易被忽略的。
“天下武功,唯快不破”,这句话在用户增长上也适用,尤其是处于激烈竞争环境中时。用户增长的本质是通过数据驱动的迭代测试把主观认知变为客观认知,用测试的冗余性换取增长的确定性。如果不能实现快速迭代测试,是无法形成增长势能的。靠提需求、走产研、大排期,是不可能实现快速迭代测试的。因此,这也是考虑用户增长组织保障的基础。
常见的实现用户增长的组织形式有四种。
第一,由原有的某个职能团队兼做用户增长,例如产品团队、运营团队或者市场营销团队。采用这种组织形式的最大问题是团队往往受到自己原有工作视角的局限,不能站在全公司的视角最大限度地整合利用所有资源来做用户增长。如果兼做用户增长的团队不是产品团队,一般在增长项目的排期上都会遇到不小的挑战,因为用户增长工作的优先级很多时候和产品团队工作的优先级是冲突的,这种冲突会体现在具体的项目排期上。这一组织形式是唯一一种不需要成立专门的用户增长团队的。
第二,成立一个专门的项目增长团队,该团队的职能主要由增长项目经理负责。其具体工作有:制定增长策略,提出增长创意,设计增长方案,同时作为PMO(项目管理中心)推动项目落地、拿到结果,并对增长结果负责。采用这种组织形式的好处是有专业的负责用户增长的人员,但是在协调资源上的难度,很多时候比第一种组织形式还要大,因为该团队的成员可能不来自任何一个原有部门,没有任何根基。
第三,成立一个专门的用户增长团队,由产品、研发、运营、市场、PR(public relation,公关)等团队派出BP(business partner,商业合作伙伴)支持用户增长团队的工作,这些BP的绩效由用户增长团队的负责人决定或主要根据用户增长团队的意见来决定,从而形成一个增长FT(功能团队)。而且,这些BP中的大部分人是要把全部精力投入在用户增长工作上的。相对而言,市场或PR等团队在用户增长项目上的需求强度不如产研高,因此这些团队可以通过BP机制部分投入。与前两种组织形式相比,这种组织形式有了巨大的进步,因为已经形成了软闭环,在用户增长项目迭代上效率较高,带来的增长势能也比较足。
第四,成立一个专门的用户增长团队,该团队的职能涵盖自有的产品、研发、运营和市场等各种职能,从而形成小的硬闭环。采用这种组织形式是迭代速度最快的,也是最少见的。因为建立这样的组织结构,往往会面临各种挑战,例如:如何解决团队成员的职业发展问题,如何在公司内部建立对应的支撑体系,如何消除其他职能部门的不满等。
通常,我们总是希望用一种对现有组织冲击最小的方式来建立一个用户增长团队,这种想法是完全可以理解的。但是,从用户增长效率的角度来说,如果用户增长这项工作不值得我们在组织上做大调整来保证增长效率,那说明它在我们心目中没那么重要。用同样的方法或组织形式做事,却期待得到不同的结果,这听起来简直不可思议,可这却是我们经常在做的事!
一个公司如果没有专门的用户增长团队,很多不同部门的人都会认为自己是做用户增长的。因为这个领域相对热门,如果哪个人是做用户增长工作的,那么在市场上是有溢价的。但是,一旦增长达不到预期,这些声称自己做用户增长的人都不会觉得是自己的责任,从而出现“有功人人蹭,见锅拼命甩”的情况。因此,一个公司要想做好用户增长,一定要有一个合理的增长组织结构来保障。
增长曲线跨越
做用户增长,如果只是沿着同一条增长曲线发力,那么最终一定会走到死胡同,无法实现持续增长。
一个优秀的用户增长团队,一定要在早期就考虑增长曲线的跨越问题,并投入资源进行相应的探索。这种探索,往往也是公司对未来发展方向的选择,因为很多探索会颠覆公司现有的生意模式。通常来说,在对新曲线进行探索时,公司要有独立的机制和投入,否则增长团队就应该承担起类似的职责。但增长团队在承担类似职责时,要和公司最高领导层达成一致。至于如何探索,则和具体公司的具体业务高度相关,很难有一个通用的方法论。
用户增长就是用测试的冗余性来换取增长的确定性,增长曲线的跨越也是同样道理。一次尝试就探索成功,这几乎是不可能的。
我们做各种功能型增长项目,其实就相当于制造一艘艘的驱逐舰、导弹巡洋舰等,比建造航空母舰相对简单一些,要求的产研资源也相对较少,但是缺乏航空母舰的远程持续输出能力。而做一个能支撑策略型增长的平台,就相当于建造一艘航空母舰,上面的舰载机承担策略型增长的任务。如前文所述,增长项目要求各职能团队进行配合,其中最重要的是产品经理和研发团队。在产品经理和研发团队开发项目、进行功能型增长的探索时,增长BI分析师和增长项目经理可能会缺乏比较有效的抓手持续推动增长,也就是说他们缺乏实施策略型增长的平台。如果他们的任何增长举措都需要通过功能型增长产研项目来实现,其效率是很低的。因为一个功能型增长项目没有取得预期的增长效果,就得靠下一个项目,可能需要很多个功能型增长项目才能发现一个增长爆点项目,从而取得超预期的成果。如果我们总是期待由这种功能型增长项目来创造增长爆点,那在一个个功能型增长项目开发上线的周期中,增长项目经理和增长BI分析师的工作量其实是不饱和的,这也是团队最容易出问题的时候。而且,这对于整个团队效率最大化也是不利的。这主要是基于以下两方面原因。
第一,在做了几个功能型增长的项目以后,如果没有取得预期的增长效果,产品经理和研发工程师就会有一定的挫败感,会觉得是在浪费时间。我在前面说过,我们做增长的本质是用测试的冗余性来换取增长的确定性。但是这个理念并不是每个产品经理和研发人员都能认识到的。做了几个项目看不到预期的火爆增长效果,他们就会产生一些失落,这样更不利于后续的增长项目推进。其实,他们的这种预期本身就是不实际的。因为很多公司成立用户增长团队,往往都是在产品增长遇到瓶颈后。这时简单、明显、迅速就能带来增长的项目,早就已经被做过了,剩下的都是不明显、具有探索性的硬骨头。既然是探索性的,那谁也不能保证做一个项目就能成功,只不过经验丰富一些的团队成功的概率大些,知道迭代的方向而已。
这些用户增长的本质性规律并不是所有人都能理解,所以我们需要尽快规划一个航母级别的用户增长项目。这种项目通过增长项目经理和增长BI分析师的持续策略迭代,每次都能带来一些增长,长期累积能产生很可观的增长效果。但是这种航母级别的增长项目,周期相对较长,用的资源较多,而且还依赖一些基础能力的建设。如果产品本身的前期积累不够,不具备一些关键的基础能力,航母级项目的规划与实施会受到极大限制。
第二,在没有航母的时候,增长项目经理和增长BI分析师经常处于项目上线节点之间的空闲期,由于没有一个航母平台提供增长抓手,这段时间就会显得很尴尬,也会让增长不连续。如果能有一个平台让他们不断迭代各种小策略,筛选一定的用户群来执行这些策略,就可以充分利用推进功能型项目(造驱逐舰、导弹巡洋舰等)的空隙时间,让大家持续推动策略型增长。
低频与高频产品增长方法的差异
在做用户增长的早期,我做的都是电商、社区等高频产品。做这类高频产品的用户增长的最大好处之一是迭代后能很快看到结果,很容易形成正反馈的闭环。后来,我做了一个超低频产品的用户增长,发现这一过程很痛苦,因为迭代后要想看到结果需要比较长的时间,很难快速验证一些想法,这对用户增长是很不利的。
在下面这个矩阵图(如图3-4所示)中,我把不同的产品映射到上面。其实,沿着纵坐标从下往上的那个箭头就代表了典型的用户增长方向,即让不用我们产品的人使用我们的产品,让使用我们产品的人更高频地使用。而沿着横轴从左到右那个箭头则代表了“+互联网”的过程,也就是传统产业与互联网的融合过程。沿着横轴的这个箭头,其实也是我之前提到的整合型用户增长发力的方向,不过这不是本节的重点。在这部分我想和大家重点讨论一下沿纵轴从下往上的那个箭头,也就是如何刺激用户产生需求、如何吸引用户。
根据价格需求理论,我们知道,一般来说价格越低用户需求越高。因此,很多互联网产品都会针对新用户设置体验价,甚至免费。而且,有些本来就是免费的产品甚至需要通过发红包等方式吸引用户。图3-5描述了针对高频、低频产品的不同激励模型。
我们先看一下这张图的上半部分,这是高频产品的激励模型。在用户增长项目中,很多激励手段都符合这一模型。如果针对的是高频产品中的非交易型产品,一般给用户实际的物质激励效果会比较好,例如发红包等;如果针对的是高频产品中的交易型产品,使用主业优惠激励会更合适,例如发放打车优惠券、电商平台打折券、免费体验券等,因为这样的激励更精准,带来的ROI也更高,即使激励到了没有需求的用户,如果他们不去交易,我们也不用兑现激励。而且后者还有一个好处,就是天然引导用户产生一个非常重要的HVA——首单。所以对于交易型产品,如果能用主业优惠激励,尽量不要使用其他物质激励。
对于高频产品,用户的决策过程往往都是比较快的,决策链条比较短。所以通过激励很容易就能扩大需求,切掉一部分竞品用户。另外,更吸引人的是,这类产品的蛋糕很容易做大,也很容易通过激励产生新的需求。例如电商、打车、共享单车等,只要对用户进行合适的激励引导,就能产生增量需求。同时,再配合其他增长优化手段(一般是漏斗型增长)来降低用户的体验门槛(例如共享单车免押金、免认证、免费首次骑行),较容易就能让这部分增量用户产生体验产品或交易的闭环。因此,对于很多高频产品,尤其是短决策链、低门槛的产品,通过补贴来刺激用户并不是恶性竞争,而是一个激励新需求产生、培养用户习惯的过程。只要控制好预算,尽量测算好补贴与ELTV的关系,这会是一个非常良性的过程,缩短了产品被用户接受并习惯的时间。
在理想的情况下,我们肯定希望吸引过来的用户越精准越好,这样转化效率会更高,平均CAC也会更低。但实际上,在获取用户的时候,即便通过各种用户群画像更精细地定位,我们也很难保证只覆盖强需求用户。而且,在一个平台从0到1的时候,为了快速起规模,各种渠道都发力比较猛,肯定会有大量弱需求用户被覆盖到。
低频产品针对强需求用户的处理过程和高频产品一样,都是引导用户产生交易/体验闭环。而针对弱需求用户,就要分成两种情况:
- (1)如果客单价相对较低,我们就要通过价格的改变来改变用户的需求频次,例如高价餐厅、豪华车等;
- (2)如果客单价非常高,那我们对于价格的改变幅度就很有限,基本不能影响用户的消费决策,例如买车、买房等。
我们先来看客单价较低的情况。当然,这里说的客单价较低,其实是相对于另外的低频产品而言的。高价餐厅、豪华车等相比普通餐厅和快车等,客单价还是比较高的。高价餐厅和豪华车之所以消费频次低,还是价格决定的。如果这类产品的价格能降低一下,是可以让用户沿着价格需求曲线往高需求方向滑动的。我把这些产品叫作价格可控型产品。
一般来说,产品的定价是经过全面研究分析后决定的,而用户增长要研究的是如何在给定价格的前提下提升ALTV。在这种情况下,提升ALTV的关键有两个:
- 第一,通过提供一个一次性的与场景挂钩的优惠体验价,让用户增加对低频产品使用场景的联想;
- 第二,利用供给端的闲置时间,提升供给端利用效率。
如图3-6所示,低频高客单价产品的用户价值分布和高频低客单价产品的用户价值分布是很不一样的。图3-6展现的低频高客单价产品用户价值分布曲线,其实是一种偏极端的情况,展示的是用户在生命周期中只产生一次交易的情况。但这种极端情况更有利于方法论的说明。
在这种分布下,低频高客单价产品的用户增长团队肯定希望能够精准圈住当下就有交易需求的强需求用户。但是在实际的用户获取过程中,仅仅锁定这部分用户来做各种推广是非常难的。在通过各种激励吸引强需求用户时,不可避免地也会引来一部分弱需求用户。这部分用户虽然目前没有交易需求,但是将来可能会产生交易需求。既然已经把他们吸引到平台上了,那怎么才能让这部分用户的价值最大化呢?
我们当然是希望这些用户现在能对我们的产品留下深刻印象,未来有需求的时候能第一时间想到我们。然而,这只是我们单方面的美好愿望。如果用户现在只是简单地浏览或在获得物质激励后就不再使用或卸载我们的产品,那他们将来有需求时是很难想起我们的。既然我们已经花成本把这部分弱需求用户吸引过来了,尽管这不是我们的主动选择,但价值最大化的做法就是引导他们去体验一下产品的核心功能。体验过才容易记住,这相当于给他们埋下了一条快思考线索。当他们未来真的有需求时,马上就能根据现在埋下的快思考线索,联想到我们的产品。这其实和很多品牌打广告的原理有点类似,只不过大部分广告都是通过不断重复来给用户留下印象的。但是在信息爆炸的今天,即便多次重复,用户也未必能记住。相反,如果能让用户去体验产品的核心功能,经历与产品的互动,那他们记住我们产品的可能性就会大大增加。
另外,如果被吸引来的弱需求用户是“泥沙”的话,我们也可以顺便寻找一下泥沙中的钻石,也就是我们真正关注的强需求用户。但需要明确一点,这部分用户虽然使用了我们的产品,也未必就一定会在我们的平台上进行交易。
如图3-7所示,低频高客单价产品,其用户贡献的价值是阶跃变化的;而高频低客单价产品,其用户贡献的价值是随时间缓慢变化的。
下面,我们先介绍一下低频高客单价产品的用户价值变化。对于低频高客单价产品,在一定时间内,就是一个零和游戏。用户如果在其他产品上成交,就不会再在我们产品上产生交易。在用户产生交易决策前,有一个关键窗口期。在这期间,用户会综合各方面因素做出最终的交易决策。而我们肯定是希望自己能够在关键窗口期介入,去影响用户的决策,从而让用户选择我们的产品来做交易。但是这有一个前提条件,就是我们能够识别出哪些用户是强需求用户,毕竟这些用户没有自带强需求标签。
而这需要我们有一个用户成交意愿识别模型,能尽量在用户成交前的关键窗口期把这部分强需求用户识别出来。通过用户的各种行为,我们如果能建立一个预测模型,是能够对用户的成单意愿做一定概率预测的。一旦我们开始做这项工作,预测模型就能通过逐步迭代提高预测的准确率。
在识别出这部分用户后,我们就要针对他们进行资源投入倾斜,把最优质的资源集中在这部分已经识别出的强需求用户上。尤其是那部分已经被识别为强需求但并没有在成单漏斗中向下转化的用户,他们大概率是把我们的产品作为一个信息参照物,然后选择在别的平台成单。前面我们说了,对于低频高客单价的产品,中短期就是一个零和游戏。所以,我们要尽最大努力争取每一个成单用户,尤其是我们已经识别出的强需求用户。对这部分被识别出来的根据当前趋势可能不会在我们平台成交的用户,我们应该进行资源超配投入,例如给这部分用户超出预期的大额主业优惠券、提供专属VIP(贵宾)服务、增加信息的推送等。只要转化这部分用户的边际收益不为零,我们就应该想尽一切办法争取他们。我们一定要通过针对这些精准用户的资源超配投入,来形成相对竞品的区域兵力优势。
这种零和游戏的对抗,和打仗特别像。根据克劳塞维茨《战争论》的思想,我们应该尽量对竞争对手造成最大的伤害,这才是对我们最有利的。所以,如果竞争比较激烈,为了不让这部分用户跑到竞争对手产品那儿去,哪怕是边际收益为负,有战略性的亏损,我们也应该把这部分用户争取过来。不过在实际中,一般并不会出现竞争惨烈到边际收益为负的情况,如果我们能识别出这部分强需求用户,这就是一个非对称的竞争,因为可能只有我们知道这部分用户是强需求用户,竞争对手并不一定知道。利用这种非对称的信息优势,我们能相对比较容易地、有针对性地吸引用户。而且随着模型迭代、精确度和及时性的提高,越早识别这部分用户,我们的竞争优势越明显。
通过这一节的介绍,大家可以看到低频产品的增长和高频产品的增长有很大不同。高频产品相对比较容易产生增量需求,所以在增长策略上的腾挪空间比较大。低频低客单价的产品,通过价格的调整,还是能产生一定增量需求的,但核心是要教育引导新用户,让他们知道使用产品的新场景,同时还要充分利用空闲的供给。而对于低频高客单价的产品,其需求几乎不能沿着价格需求曲线滑动。有限的利润空间决定了我们的激励或优惠力度不会对用户的交易需求产生任何影响。但是,对于顺便吸引来的弱需求用户,我们也要从长线考虑,引导他们体验产品核心功能,给他们埋下快思考线索,从而让他们在将来有需求时第一时间想起我们。而对于吸引来的强需求用户,我们要尽可能提前识别出他们来,锱铢必较,让他们在我们的产品上形成交易闭环。
增长功能的用户体验——掌控感
对于互联网产品,我们所说的用户体验是指在特定的场景下,用户能在与产品交互的过程中比较爽地满足自己的需求。这里面的三个关键要素是场景指向性、过程完整性、交互爽感度。由于产品功能的体验不是本书讨论的重点,我在此对前两个关键要素就不详细阐述了。第三个关键要素——给用户创造爽感是非常重要的,因为很多互联网产品都不是强刚需产品,并不是用户的唯一选择,在市场上还有其他竞品。通常来说,产品的首要功能肯定是解决用户的痛点,但是在大家都能解决用户痛点的情况下,就要看谁能解决得更好,甚至是谁能创造爽点。很多时候,互联网企业为了创造爽点,不会让用户直接看透产品的各种逻辑,而是会让他们通过探索来获得满足感。
举一个极端的例子,比如游戏。用户玩游戏就是纯粹为了得到爽感,但如果游戏设计得很直白简单,用户一下就能知道下一步究竟应该如何操作是最好的,那这个游戏一定是很无聊的。当然,这是个比较极端的例子。在实际中,大部分产品都是同时解决痛点和提供爽点的。而增长功能的用户体验和一般产品功能的用户体验的评判标准是不同的。对增长功能用户体验来说,最核心的就是掌控感,要能无缝引导用户产生HVA。能否成功引导用户产生HVA、提升ALTV,是评判增长功能用户体验的唯一标准。
增长功能其实也算一种产品功能,只不过它是一种非常特殊的产品功能。一般的产品功能都是从用户角度出发的,是为了满足用户的某个需求而设计出来的交互逻辑。而增长功能是从公司的角度出发的,是为了提升ALTV,让更多用户产生我们期望的行动。也就是说,用户希望通过使用产品满足自己在某个场景的特定需求,而我们希望用户产生特定的动作(HVA)。所以,用户的需求和我们的期望之间存在矛盾,而弱化这个矛盾的关键是让增长功能对用户透明。
有些时候,用户当下的需求刚好和公司希望用户产生的HVA是一致的。不过很多时候,我们希望用户产生的HVA尽管对用户长期是有利的,但并不是他们当下最想做的事。无论用户当下的需求是否和我们希望其产生的HVA一致,我们都需要设计一定的增长逻辑去引导他们产生HVA。这个引导逻辑,其实就是考验用户容忍度。人们对于自己没有掌控感的事特别容易感到疲惫,容忍度一般都比较低。让增长功能对用户透明的核心就是让他们有掌控感,也就是让用户对于HVA引导逻辑中的下一步要干什么做到心中有数,不需要再思考下一步应该点击哪里或是输入什么信息。
每个产品,都有自己的UI风格,不管是品牌还是UI团队,肯定都希望各处能保持一致,但保持一致的目的是什么呢?如果产品设计风格一致、格调高雅,但用户使用的频率越来越少甚至不再使用,那也是没有任何价值的。而这一点具体到增长功能的交互设计,就是要让用户有掌控感,尽量让用户在每个页面都知道怎么做,甚至还能知道下一步能得到什么。在整个引导逻辑的通道中,应该让用户像在开车一样,自然而然地打方向盘,不用动脑去思考是否应该踩油门或往哪边打方向盘。如果为了保持UI风格一致性或因为其他审美理由,让整个引导逻辑的交互被阉割了,让用户失去了掌控感,这是不正确的。我们必须在掌控感和产品整体风格之间做一个平衡,而且只要稍微深入思考一下,通常是能找到这种平衡的。
增长功能是不能独立存在的,必须依附于主产品功能,而且增长功能一般都是引导用户去体验主产品功能过程中比较关键的一部分,也就是HVA。所以,增长功能用户体验的设计是不能和主产品功能一样的。增长功能是一个通往HVA的通道,在这个通道中,不能让用户思考自己应该往哪里走,要让用户像在脑中装了一个GPS(全球定位系统)一样,对于往哪里走心知肚明。对用户来说,整个过程要像开车一样,拥有高度掌控感,不会因为在中途迷路或缺乏耐心而退出。
逆向思维
在漏斗型、功能型、策略型、整合型这四种增长类型中,我最喜欢的是策略型增长。这种增长形式能非常方便地让我们在一个测试失败后就迅速切换不同策略继续测试。所以在做策略型增长时,我们一般都要做一系列的规划,当前测试失败后我们下一步应该验证什么、测试什么都要提前想清楚、规划好,做到无缝衔接。
在战略、统计上,大部分增长测试都不能带来预期的增长,所以测试的数量非常重要,要用测试的冗余性换增长的确定性。但是在战术上,针对每一次增长测试,我们都需要精心设计,以确保它的成功,尤其是在做功能型增长时,更是要做好“事前验尸”。“事前验尸”这个概念听起来挺吓人,但它是一种典型的逆向思维方式。我们在做增长项目方案时,应该提前想一下,如果这个项目失败了,可能是哪些因素导致的。在列出各种影响因素后,我们要仔细分析,专注于影响圈,看我们对于哪些因素还能额外做一些积极改变。
一般在做项目时,我们都会考虑到底还要做哪些事情才能提升项目成功的概率。这一思考过程其实还有另外一面,即想想到底还有什么因素可能导致项目失败,我们应该做哪些方面的改变来降低失败概率,如果失败了我们下一步的计划是什么。所以,我在和团队成员讨论项目的时候,经常在最后都会问一句:如果咱们的方案不成功,下一步应该怎么办呢,是否有备选方案呢?
亚马逊是一个典型的利用逆向思维的公司。我在亚马逊总部时,参加了Work Backwards(逆向工作法)的培训。这个培训强调的是从交付给顾客的产品出发倒过来规划工作:一开始,先写一篇新闻稿,通常一页左右;再假想产品已经做完,要通过媒体正式对外发布。在这篇新闻稿中,通常要引用一些假想用户对这个产品的评论,要想象一下这个产品推出后是否有用户针对一些场景激动地说出赞美之词;然后,还要把用户经常会问的问题也写好。在写这些文档的过程中,我们必须完全进入用户的角色来思考。
在完成上面两步后,我们还得详细描述用户使用产品的体验是怎么样的,可能还需要先做一些简单的原型;同时,还需要先写好用户使用手册,给用户介绍这个“已经发布”的产品,告诉他们如何使用。当然,好的产品一般都不需要用户手册。这些都是逆向工作法的必要步骤。其目的就是让产品经理或其他相关人员,在一开始就坐时光机到未来,想象一下产品做出来后的情况。即使使用了这种方法,亚马逊仍然有很多不成功的产品,例如2014年营销声量非常大的Fire Phone手机。但这种逆向思维工作法让亚马逊在一开始就避免了很多无用产品的开发,而且提升了产品成功的概率,亚马逊开发出了很多非常成功的产品。
再来回顾我之前在亚马逊做用户增长的例子,来具体说明逆向思维在具体项目中的应用。2014年感恩节,我们决定做一个rank push(排名冲刺),让亚马逊购物App在苹果App store美国免费榜上冲进前10名。我们希望在圣诞节前的礼物准备季获取更多曝光,通过排名增长为亚马逊购物App带来更多的自然下载量。之前,亚马逊购物App的排名从来没有在榜单上进入过前10。所以我们当时的目标是在一定的预算下,让亚马逊购物App排名进入App store免费榜单的前10。我们在过程中做了大量的数据分析,以确定具体需要多少下载量、多少预算才能进入前10。当时,我们就问了自己一个问题:假如到了这个排名冲刺项目快结束的时候,没有足够的下载量,不能支持亚马逊购物App排名冲进前10名,我们应该怎么办?
所以当时,我额外争取了后备火力,联系好了更多的冲榜下载资源作为后备军。如果到时数据分析发现下载成本可控,但是亚马逊购物App还没有进入前10,我就会动用后备火力。因为当时App store每3小时刷新一次排名,所以我们每3小时就会分析一次数据。但最终由于成本相对偏高,超过了预期,没有调用后备火力。因为策略得当,再加上惯性的作用,我让亚马逊购物App历史上第一次排到了App store美国免费榜第10名,实现了效率最优化。
我想通过这个案例说明两点:(1)在做增长时一定要有逆向思维,要考虑如果不成功,我们的后手是什么;(2)做任何决策,尤其是涉及金钱投入时,要尽可能多地通过数据来决策。
逆向思维在很多时候能给我们带来决定性的影响。就像过马路一样,如果是单行道,我们的本能是看车来的方向,没有车就觉得安全了,可以过了。但是除了关注车来的方向,我们更需要关注的可能是车逆行的方向。如果一辆车敢于在单行道上逆行,那这辆车的司机极有可能非常不遵守规则或处于醉驾的状态,这样的司机是更致命的,如果我们不特别留意,会给自己带来非常大的伤害。我们的思维也是有惯性的,倾向于看“车来的方向”。但很多时候,决定生死成败的,其实是我们能否看到“车逆行的方向”!
用户增长与产品、团队等的关系
用户增长虽然是一个新兴的领域,但却是一个公司非常核心的部分,所以需要公司各个团队的紧密配合。即便很多公司的估值都是由用户量和用户价值(ALTV)决定的,也从来没有听说一个公司只有用户增长团队,而不需要其他团队的。用户增长其实是一项锦上添花的工作,要让用户增长团队发挥威力,是需要一些基础的,而这些基础一般都是公司的产品、运营、品牌、市场等团队打下的。但要实现ALTV的进一步增长,就需要专业的用户增长团队来做了。
如果没有专业的用户增长团队,而让产品团队、运营团队、市场团队等做用户增长,会带来三方面的问题:(1)大家都觉得自己可以做,但是如果没有做好,没有人会觉得自己应该对结果负责;(2)因为每个团队都觉得自己可以做,所以相互之间其实在暗地里较劲,合作是比较困难的;(3)用户增长对专业性的要求还是比较高的,虽然各个专业团队在自己领域可能都有比较高的造诣,但这恰恰会让大家受路径依赖思维的影响,反而不一定能做好用户增长。
但用户增长团队如果能成功,也一定离不开各个团队的紧密配合。用户增长比其他工作更需要各个团队的协同配合,所以用户增长的成功是公司各团队协同的成功,是大家的功劳。要想做好用户增长,搞清楚用户增长团队与其他团队的定位与关系是非常重要的。
用户增长与产品团队
在讨论用户增长团队与产品团队的异同之前,我重复一下我对用户增长的定义:以终为始,利用一切资源让更多用户更高频地使用核心产品功能。这个定义里的“更多”和“更高频”其实对应了ALTV的两个乘数因子,即用户量和LTV;而引导用户去使用核心产品功能,则是让我们更专注于能让LTV提升的目标动作。这个定义并没有说我们需要构建一个让用户喜欢、能在某个方面满足用户核心需求的产品,因为这不是用户增长团队的工作,而是产品团队的工作。就如我在前面提到的,用户增长团队做的是锦上添花的工作,如果没有一个满足基础用户体验的产品,用户增长工作是无法有效开展的。即使强行开展用户增长工作,也是事倍功半。
要想做好用户增长,就要站在巨人的肩膀上,而最基础的就是我们的产品要达到一定的体验门槛,能够舒适地满足用户的需求。我举一个例子来说明体验门槛的重要性。假设我们要做一个找公共厕所的App(某些App其实已经有这个功能),为了快速上线,我们前期并没有对公共厕所的分布位置进行实地考察,只是从网上扒了一些数据,然后就在App上展示给用户。由于没有对App上展示的厕所在线下进行相关验证(无论是自己验证还是众包),就有可能出现两种极度影响用户体验的情况:
- (1)由于定位不准确或者信息错误,用户到达App上所显示的位置发现根本就没有这个厕所,这时他很急,使用感觉肯定很差;
- (2)厕所卫生状况很差,苍蝇肆虐、臭气熏天,用户也许勉强先解决一下紧急需求,但他下次可能再也不会光顾,并且大概率形成负面口碑。
我虚构了上面这个例子,只是想说明如果没有一个达到基础体验门槛的产品,用户增长是不可能做起来的。如果吸引来的用户对我们的产品产生负面印象,不再使用还是小事,他们也许还会给出负面评价,从而给我们造成极大的伤害。负面口碑传播的威力是非常大的,很多时候远大于正面口碑。这主要是由于以下原因。
在传播正面口碑的时候,我们一般是有一定心理压力的,因为要看一下传播这个口碑是否符合我们的格调和人设,因为我们不希望显得自己低俗。另外,我们可能还会想:这个东西我觉得好,可如果别人觉得一般,那会不会显得我没见过世面?如果用力推荐,别人是不是会觉得我们有利益关系?总之,在传播正面口碑的时候,我们考虑的因素会比较多,决策相对没那么容易。但是在传播负面口碑的时候,我们就没这么多顾虑,因为在传播负面口碑时我们一般都会在心理上有复仇的快感,而且会认为自己觉得差别人觉得好,那说明我们的要求比较高,心理上有碾轧优势。另外,在传播负面口碑时,我们不用担心别人怀疑我们的利益动机。
所以,一旦让用户传播负面口碑,会对产品造成极大的破坏。即使后来产品体验提升了,也很难让这部分用户再回来使用我们的产品。而且,我们还很难吸引被这部分用户安利负面口碑的其他用户。相比一个从来没听说过我们产品的用户,我们需要额外花费很多精力才能让这部分被安利负面评价的用户来体验产品。
产品团队提供的基础用户体验框架是做用户增长的前提,否则做增长就是无米之炊。为了有一个能满足用户基础体验和核心需求的产品框架,产品团队要做大量的工作,这些工作包括但不限于:市场调研、需求分析、产品定义、产品设计、项目管理、产品宣讲、产品生命周期管理等。从做事的底层逻辑来看,我们做一个产品功能肯定要进行充分的调研、分析、聚类等,就是希望产品功能做出来后能够充分解决用户需求,是沿着成功假设的逻辑来做的。很多时候,我们要采用毕其功于一役的打法。
但用户增长的本质是用测试的冗余性来换取增长的确定性,所以很多测试都是以失败告终的,是沿着失败假设的逻辑来做的,很少会有毕其功于一役的情况出现。然而,用户增长团队做的HVA引导逻辑也是一种产品功能,需要借助产品团队来实现。这个时候,和产品主框架体验的设计不同,我们要按照用户增长的方法论来设计整个HVA引导逻辑。由于大家的底层思考逻辑不同、工作习惯不同、采用的方法论也不同,所以在通过产品团队来实现用户增长逻辑时可能会出现一些矛盾。那我们该如何解决这些矛盾呢?可以按照以下逻辑来解决:
如果做的是产品主体体验框架,毫无疑问得按照产品团队的思路来;但是如果做的是HVA引导逻辑,就必须根据用户增长团队的思路来。其实,产品团队和用户增长团队的想法都没错,但如果在组织上没有合理的设计,那很多在项目执行层面的矛盾是无法调和的。在项目执行层面去解决问题,永远都是按下葫芦浮起瓢,只有再深入一层才能真正解决问题。
下面,我列举自己之前的一些经历,来说明一下由于组织设计不合理导致的一些问题。如前所述,由于所处领域不同,做事的底层逻辑和方法论也不同,大家在有分歧的时候不太能相互理解,只会觉得对方不专业。在这种情况下,用户增长团队相对处于劣势。因为产品团队和其所采用的方法论的发展已经非常成熟了,对于产品团队的作用大家也都比较认可。而作为一个新兴领域,很多人都不太了解用户增长是做什么的,甚至会相对片面地认为用户增长就是拉新、获取新用户。即使是正在做用户增长的团队,很多也是处于逐步摸索阶段,没有成熟的方法论。所以在别的团队眼中,用户增长团队往往都看起来不专业,这是因为大家都是从自己的角度看问题的。做产品,用户增长团队肯定不如产品团队专业;做营销,用户增长团队肯定不如市场营销团队专业;做其他用户增长以外的工作,用户增长团队肯定也不如其他团队专业。在一家公司,如果其他团队说用户增长团队不专业,指的是其他方面,这是可以理解的,因为术业有专攻。但如果其他团队说用户增长团队在用户增长领域不专业,那就要仔细讨论一下了,看其他团队积累的相关经验、思考、方法论是否有资格来下这种论断。在组织设计上,一定要本着专业人做专业事的想法,通过合理的协调配合机制,发挥最大合力。
除了由于做事底层逻辑、方法论、专业领域不同产生的矛盾,用户增长团队与产品团队还存在绩效牵引带来的矛盾。我就曾经遇到过这种情况。我在之前也提到过,如果公司给用户增长团队配备很多相对资深的人员来设计、推进增长项目,而给产品团队只配备了一个资历相对较浅的产品经理来处理所有的增长需求,而且他还只投入了50%左右的精力来做与增长相关的功能,那这个初阶产品经理就会成为整个链条的瓶颈。人的能力都是需要时间和项目经验来积淀、成长的,在这种情况下,即使这个初阶产品经理再努力,投入百分之百的精力(何况还不是),也会限制组织能力的最大发挥。
当然,对于产品团队而言,这种安排是能找到各种合理的理由的。我只能说,对于这种安排,我可以理解,但不能接受。所以我才在第一章“增长组织保障”那一节,一再强调增长团队有闭环产品经理的重要性。无论这个闭环产品经理是属于用户增长团队还是从产品团队BP过来形成FT,都没有关系,因为核心是用户增长产品经理的绩效与晋升要100%和用户增长团队的绩效挂钩,由用户增长团队的负责人来决定,占用用户增长团队的绩优和晋升名额。
一个公司要想做好用户增长,产品团队是非常重要的,没有产品团队提供的基础和保障,增长就是无源之水。但如果只是组建了一个专业的用户增长团队,没有在组织上进行合理的设计,也无法产生合力。有了组织保障,用户增长团队与产品团队能理解彼此做事方法的差异且尊重对方的专业性,就能充分发挥合力,让增长收益最大化。
用户增长与运营团队
用户运营团队在做的事情和用户增长团队所做的事情,在形式上看是有一部分重合的。我之所以说在形式上,是因为二者在本质上还是有比较大不同的。普通的用户运营团队,经常会在一些关键事件节点,搞一些活动来刺激用户的活跃度或交易量,比如在情人节、愚人节、劳动节、儿童节、七夕等节日做一些数据盘点类的H5、小游戏,或者造一些节日,比如一些购物节等,这些都是典型的运营团队的工作。
而用户增长团队所做的工作虽然表面上看起来和运营团队的很像,但在根本上还是专注于两个目的:
- (1)聚焦周期重复性以改变用户的习惯;
- (2)聚焦于引导用户产生HVA。
下面,我举两个实际的例子来说明这两个聚焦点对项目设计的影响和与常见的用户运营工作的不同。
用户增长与品牌市场团队
用户增长团队与品牌市场团队的定位和所起到的作用其实是不同的。通常来说,信息不对称会让品牌和营销带来更高的产品溢价,越是不透明的产品越需要品牌营销。一个产品的信息透明度越高,用户就越容易对其功效产生直观感受。例如:一个线上信息类产品,无论其品牌是什么、做什么宣传活动,其提供信息的好坏以及是否能满足用户的需求很容易就能通过与其产品的交互来确定;而如果是一瓶洗发水,用户在不知道品牌的情况下,很难确定这款洗发水是哪个品牌的、究竟好在哪里。用户在用洗发水的过程中获得的大部分感受,其实都来自心智中对其品牌的认知。
因此,在互联网公司,处于核心的永远都是产品和研发团队。当然,最近几年,用户增长团队也越来越重要。而品牌营销部门在互联网公司的影响力,就远远不如在传统快消品公司的影响力大。快消品行业以卖货为主,对用户来说,很多产品在可量化体验上的差异并不是很大,所以该行业的品牌营销部门会把重点放在影响用户的每一次消费决策上,故而传统的营销4P对用户的购买决策有很大影响。而且,传统营销讲究的是认知大于事实,主要强调去影响用户的心智。与其不同的是,互联网行业希望用户先使用、体验产品,强调事实(体验)远大于认知。对大部分互联网产品来说,最重的类似购买产品的消费决策其实是下载App,但这也比快消品的购买决策要轻很多。用户下载App不但不用花钱,还可能在注册后获得一笔现金,也没有使用场地的限制,有网络就行,所以互联网产品的决策门槛比快消品低很多。
另外,很多互联网产品满足的都是一些泛需求,用户决策的负担没那么重,下载和注册等行为的机会成本就是在沙发上的一些闲暇时间而已。而快消品一般是满足用户刚需的,需要用户花钱去购买,可能还涉及用户对生活品质的认知,虽然其对生活品质未必会有影响。显然,用户在购买快消品时,决策的负担相对较重,此时用户做决策很大程度上不取决于产品体验,而是取决于自己对该产品的品牌认知和营销4P。只要快消品的质量不是很差,就不太会影响用户的决策。快消品质量在这里其实是一个保健因素:如果产品质量不及格,肯定会对用户的购买决策(尤其是复购决策)产生负面影响;而只要产品质量达到及格线,对于用户的购买决策就是没有影响的,因为用户通常无法通过体验产品来分辨不同产品间的差异。这个时候,用户的决策很大程度上就是受品牌认知和营销活动影响。
通过品牌和营销来引导用户产生决策,成本相对是较高的。但是传统快消品毕竟需要用户付费购买,所以只要采用合适的品牌营销方法、控制好ROI,这一策略在该行业还是比较适用的。而且除了品牌和营销(Branding+STP+3C+4P),快消品行业也没有其他太好的抓手。虽然快消品计算ROI相对互联网产品要困难一些,但还是可以大概算出投入产出比的。
做用户增长其实也是影响用户的决策,让用户选择下载并体验我们的产品、使用某项功能、产生交易,从而提升LTV。不过,所有的投入必须和转化联系起来看,严格评估ROI。具体来说就是,用户增长要专注于从获取用户到他们离开产品的整个生命周期的管理和转化引导,而且这个过程需要严格的数据驱动。
总体来说,用户增长和品牌营销都是希望影响用户的决策。但二者也有不同:用户增长影响的决策更偏微观,一般是影响用户体验产品的某个环节,例如是否要点击某个按钮到下一步、是否要使用某个功能、是否要购买会员等;而品牌营销影响的更多是偏宏观的决策,比如是否要购买某个产品。由于互联网产品一般都采用免费使用或基础服务免费但增值服务收费的模式,所以这类产品偏宏观决策的门槛比较低,不能很好地发挥品牌营销的威力。对互联网产品而言,商业价值贡献更大的是各种偏微观的决策,而这正好是用户增长擅长的领域。
此外,用户增长团队也需要与品牌市场团队紧密配合,才能取得理想的增长效果。
一个成功的用户增长团队,背后一定得到了其他各个团队的支持,所以才能取得超预期的增长结果。而大家能配合好的前提是相互尊重,用户增长团队要认识到其他专业团队的重要性,其他团队也要认识到用户增长领域的专业性。如果公司组建了一个用户增长团队,那肯定是因为做增长需要拥有专业技能的人才,否则让现有团队兼做就行,没必要大费周折。用户增长是让整个公司都能受益的事,如果各个团队能拧成一股绳,心往一处想,形成合力,一定能产生令人意想不到的增长效果。
如何搭建用户增长中台
过去几年,用户增长越来越被重视,其背后的一个关键因素就是线上流量成本的飙升。只要粗放地做手机预装就能低成本获取用户的时代早就一去不复返了。很多时候,通过各种昂贵的线上广告获取用户的成本比用户的LTV还要高。尽管大家都希望能够免费获得用户,但这几乎是不可能的,即使能获得也只是非常少量的用户。所以,企业面临两个选择:要么降低用户获取成本,要么提升用户的LTV。
而要持续健康地获取用户并提升用户的LTV,有一个增长中台的支撑并提供各种基础工具,效率会高很多。对于有多条业务线或者是有线上、线下不同产品的公司而言,增长中台显得尤为重要。一个好的增长中台会让一家公司在下面几方面得到提升。
增长基础能力建设
做用户增长时,如果平台缺乏必要的基础能力,常常会事倍功半。所以,增长中台的一项基础工作就是建设相关的基础能力。其实,大家一听就知道这项工作的重要性,但是在实际工作中,却往往容易忽略。很多时候,我们觉得只要能找到做增长的优秀人才,就能马上实现可观的增长。但实际上,用户增长是一个系统性工程,如果缺乏必要的基础能力,再厉害的增长专家也会到处被掣肘,难以发挥自己的能力。
增长所需要的基础能力,如果不由增长中台来统筹规划并建设,各个业务线或其他团队是不太有动力来做的。因为基础能力的建设往往很少能得到认可和喝彩,而具体业绩目标的实现往往是万众瞩目的。然而,业绩目标的达成离不开基础能力的支持。所以,这种基础工作必须由增长中台来提前规划建设。常见的基础能力的平台有A/B测试及流量控制平台、DMP(data management platform,数据管理平台),钱包系统、激励券营销系统、LTV计算跟踪系统等。
激励券营销系统
一般对于交易型产品,尤其是中频、高频交易产品而言,没有激励券营销系统是不可接受的。很多时候,用户并不是真的缺那几元钱,但那几元优惠券带来的心理上的愉悦感远胜于物质补偿。这种心理上的愉悦感会影响用户决策的天平,使其向我们预期的方向倾斜。好的激励券营销系统是策略型增长的主要载体之一。图5-1是一个包含了券转赠机制的激励券营销系统示意图,该系统可以同时分发主业券和第三方券。
不同业务线可以根据自己的需要,生成各种主业券发给用户,但在券管理模块要进行预算管理和券核销,以保证不同业务线在生成激励券时是有对应预算的,不会出现先斩后奏的情况。在券使用或过期后,券管理模块要进行相应的核销或预算恢复。
要在分发接口控制模块把激励券通过平台塞券、用户领券、用户转赠券等方式发放到用户账户上。相关环节要有反作弊措施,防止黑产作弊刷券。除了分发主业券,分发接口控制模块还要能分发异业券。同时,异业合作伙伴也能通过平台来领我们的主业券作为福利发给它们的用户。一般来说,平台通过活动让用户领券和异业合作方领券发给它们的用户,采用H5的方式会比较好,这种方式适合不同场景的分发。如果这类H5平台做得强大,还能根据不同活动、不同异业合作方来生成定制化的领券页面。
如果用户使用了激励券,那要在券管理模块进行核销,从而形成闭环;而如果用户没使用激励券,那就需要把预算释放回券管理模块,用于生成其他激励券。如果券还包括翻倍或膨胀等增加金额的玩法,还需要在券管理模块重新进行预算申请。
图5-1只是一个示意图,一般根据自己的产品特性和交易场景,企业的激励券营销系统可能会简单很多。同时,这个激励券营销系统还应该和A/B测试及流量控制平台配合,从而实现对用户精准发券,并能衡量增量收益。
在搭建好激励券营销系统并运营一段时间后,可以在系统中加上规则引擎,以实现自动化策略增长。一般在前期,通过增长BI分析用户数据,可以圈定用户群和其对应的激励券规则;在确定发券用户群和券规则后,通过对系统的手动配置把券发给目标用户;随后,分析发券用户群和对照组用户群的后续价值贡献差异,计算出发券带来的增量价值。
一般经过几次测试和迭代,我们就能沉淀下来一些明确的规则,例如对于A用户群组,在其产生某个特定行为的时候就可以向他们发放一张一定价值的激励券。这时,我们可以把这个规则开发下来固化,让系统自动执行。每当用户的行为满足一定条件时,就会触发规则引擎执行相应的发券动作。
如果规则引擎做得再强大一点的话,甚至可以让增长人员直接添加券生成规则,不需要通过开发来固化每条规则。不过,也不用一下搞出个无限手套,最好循序渐进地来,通过不断迭代来优化激励券营销系统。
有一点是大家一定要记住的,不要一开始就直接开发固化的规则,一定要先通过增长BI手动分析数据,在经过多次测试验证了这些规则后,再把它们固化。把确定的规则自动化,手动不确定的探索,只有这样才能兼顾效率和效果。
LTV计算跟踪系统
LTV的计算是一个逐步迭代优化的过程,在增长中台要有专门的团队来持续跟踪优化LTV的计算。成熟产品的用户量相对较大,数据积累的时间也比较长,其ELTV的计算就会更准确一些。而对于新产品,由于其用户量相对较小,在计算LTV时,受统计偏差的影响就会大一些;而且,由于其用户数据累积的时间相对较短,ELTV的估算准确度也会相对低一些。
但不管是新产品还是成熟产品,在计算其LTV/ELTV时,都有两个关键点需要特别注意。
一是随着产品和运营系统的完善,用户在产品中的贡献是逐步提升的。但是我们在计算LTV/ELTV时,依据的都是历史数据,假设未来和过去一样,所以会相对低估LTV/ELTV的价值。因此在计算LTV/ELTV时,我们要对未来的趋势有个预判,再适当加上一个增长因子,以使LTV/ELTV更能代表用户在未来的贡献。
二是很多产品是有网络效应的。随着网络效应的增强,用户会在这个生态中花更多时间,产生更多交易。比较典型的就是电商平台。随着卖家增多或平台提供更多的商品,用户在这个电商平台上的消费也会越来越多。对于电商平台这种具有双边网络效应的平台,卖家与买家的增多并进入相互促进的正反馈循环,对于用户LTV和ALTV的提升是巨大的。因此,对于有网络效应的产品,我们一定要对其网络效应形成的临界点有一个判断,在跨过这个临界点后,后续的增长往往是几何级数的。
如果在早期计算LTV/ELTV的过程中没有考虑产品的网络效应,就会导致计算的LTV/ELTV严重偏低。而我们用这种偏低的ELTV来决定用户获取成本,就会过分保守。而且现在很多赛道上都有不止一个竞品,竞争非常激烈。这种过分保守的策略会让我们贻误战机,让我们错过取得战略优势的时间窗口。
在总体计算LTV/ELTV后,我们就需要对计算过程按照获取用户的渠道或方式进一步细分。在实际获取用户的过程中,我们都是按照不同的渠道来展开工作的,例如通过应用商店广告、DSP广告、视频平台广告、用户分享拉新和平台B端服务者拉新(把这两种分享拉新方式也当成渠道)等。虽然每个渠道都能触达各种用户,但是在统计上,每个渠道获取的用户其实都有自己的特征,这会导致从同一渠道获取的用户在产品的价值贡献轨迹上有类似之处,即从同一渠道获取的用户的LTV/ELTV是相对接近的。
我们计算LTV/ELTV的原因之一,是要用它来衡量我们的用户获取成本是否合理。而获取用户一般又是分渠道的,所以针对不同的渠道,我们应该有一个更精细化的ELTV来指导我们制定用户获取成本策略。
通过对用户ELTV变化的监测和模型的估算,我们能够知道引导用户产生HVA给我们带来的增量收益。而不同渠道获取的用户,即使产生同一个HVA,其带来的增量收益可能也是不同的。所以针对不同渠道获取的用户,我们可以给予不同的激励以引导他们产生相应的HVA。
总体来说,对LTV的计算跟踪是一个需要不断更新并持续精细化的工作。我们要把相应的工作成果及时应用到最新的用户增长策略和项目当中,使其相互促进从而形成正循环。
平台流量获取
如果一个平台上有多条业务线,那对于各条业务线来说,获取用户最快的方式就是洗平台的流量,即把平台上没有访问自己业务线内容或使用自己业务的用户吸引过来。各条业务线采用这样的方式并没有错,这是性价比最高的方式。但最后可能会造成的后果之一是每条业务线在考核周期内的用户量都上涨了,但平台的用户量却没有上涨。因此,需要有一个团队对平台整体的用户量负责,该团队的目标就是把用户吸引到平台上来,这个职责最好由增长中台来承担。
我认为增长中台在获取平台用户的过程中,要遵守两个原则:(1)如果能把钱给到用户,就尽量不要给渠道、流量平台或广告公司;(2)如果能给主业优惠券,就尽量不要给红包等现金激励。
这两个原则其实非常好理解。把钱给流量渠道,用户是没有感知的。而且如果大家都把钱给渠道,渠道的流量成本也会被进一步抬高。如果把钱给用户,则至少和用户形成了一定的关联,也许部分用户还会记得你的好。就算用户不领情,也埋下了进一步进行口碑传播的线索。
虽然把钱直接给用户的激励作用非常明显,但也会同时产生两个副作用:一是用户可能领了钱就跑路,不会使用我们的产品,更不用说产生HVA了;二是可能会吸引来很多作弊的用户,也可能不是很多用户,就是少数几个专业的作弊黑产组织。
在实际情况中,虽然我们知道给现金不是一种好的方式,但是由于系统基础能力的限制,例如没有激励券营销平台,有时候也不得不先给用户现金。这一般也是公司反作弊团队和作弊黑产组织斗智斗勇的时候。如果非要给用户现金激励,那在活动设计之初就要考虑反作弊,反作弊需要增长中台联合大数据及研发团队一起来做。
一些简单的反作弊规则,例如限制同一IP地址、同一设备号、同一地理位置、同一手机号码能领取的红包数量,专业的黑产组织很容易就能规避。因此需要引入机器学习作弊终端的特征,进行有针对性的屏蔽。这是一个不断反复的攻防战,特别耗费精力和资源。而且一旦作弊黑产组织突破了我们的屏障,可能会让我们一下损失很大。
因此,一定要有一个自动化的红包预算监控机制。例如:对每天需要发放的红包总金额做一个限制,超过这一金额就自动停止发放;在活动说明中放上相关说明,让用户知道每天的红包数量是有限制的,顺便营造红包稀缺的氛围;同时,从用户体验角度,提前把活动紧急停止的页面设计好。因为如果黑产作弊触发了这个开关,在用户领红包时就可以弹出这个提前设计好的页面,给出“活动过于火爆,今天红包已经领完,请明天早点参与”的说明。
另外,晚上12点到凌晨6点之间是比较容易出问题的,因为这个时间段很可能技术人员都在休息,这也给了作弊黑产一个绝佳的时间窗。这个时间段一般正常用户非常少,所以为了安全起见,可以把现金红包功能暂时关闭。
总体来说,增长中台应该承担平台流量获取的任务,把用户先吸引到平台,再进行二次引导分发。当然,增长中台也可联合各条业务线做一些运营活动,通过宣传某个业务条线的服务来获取平台用户。但无论其具体如何操作,平台流量的获取都是增长中台非常重要的工作之一。
增长人才赋能
通常来说,平台上的每条业务线都有自己个性化的增长需求,有很强的动力去组建自己的增长团队。但是用户增长是一个专业化相对较高的工作,而大家又往往认识不到其专业化,因此各业务线在组建增长团队时,经常不能准确识别增长人才。
由于各业务线的用户增长和平台用户的整体增长是紧密相连的,所以更好的方式应该是由用户增长中台集中招聘各业务线的增长人员,然后再把他们BP到各业务线去支持各业务线的增长。派到各业务线的增长BP一般双线汇报给业务线负责人和增长中台负责人。增长BP的量化绩效要完全根据业务线的增长目标来确定。而增长BP的能力成长部分则由增长中台来决定。也就是说,增长BP的绩效应该更多由业务线来决定,而其晋升则更多地由增长中台来决定。
增长BP在业务线的工作必须要得到业务线负责人的全力支持才更容易开展,因为增长是一个综合性的工作,绝不是一两个人或团队单枪匹马就能搞定的。在具体到每个增长项目的设计和实施时,则应该回归到增长中台,由增长专家组来评审及把控,以保证项目方案的高质量设计和执行。
总体来说,对于增长BP赋能业务线增长的机制,其关键是各业务线要负责定目标、给资源,而增长中台则负责人才输出及培养、专家中心项目把控。同时,在实行这一机制时,还要定期让支持各业务线增长的BP进行轮岗,从而更有利于接下来要介绍的两项工作的开展。
平台跨业务线LTV提升
如果一个平台上有多条不同的业务线,那在KPI导向下,一般每条业务线都只会关注用户在自己业务上贡献的LTV,而对于用户在其他业务线上的贡献则不会留意。有时候,有些业务线甚至希望用户不要使用平台的其他业务,只停留在自己的业务内,因为它们担心用户的预算或时间会被平台上的其他业务“分流”。这种看似很幼稚的想法的产生也是有一定原因的:每条业务线都有自己单独的KPI,而且很多成功的业务负责人都是强目标导向的,所以在紧盯目标的时候,他们不光会动作变形,眼睛也像戴上了滤镜,对一些更重要的事情会视而不见。
站在增长中台的角度,提升用户对整个平台的LTV贡献才是最重要的。这就需要增长中台深入思考和分析各业务线之间的逻辑关系,有时还需要把各业务线强行关联起来开展一些综合项目。
我在这里举一个脑洞大开的例子,虽然现实中不一定真的有这种业务场景。例如,我们发现用户在工作时间经常去川菜馆、湘菜馆吃比较辣的菜系,但是在家叫外卖却只叫比较清淡的食物。这是否说明他家里可能有年龄比较小的小孩不能吃辣,所以外卖只能叫比较清淡的食物?如果从餐饮的消费水平和家庭住址看,这个用户的家庭收入是比较高的,那这是否说明他家里还有高品质儿童用品和课外培训教育的需求呢?假如我们的平台刚好提供类似的服务,而这个用户还没有体验过,那我们如何让他来体验平台的这些服务呢?这就需要我们发起一些跨条线的测试项目来验证,这中间可能既涉及数据的交叉引用,还涉及业务体验环节的交叉推广。
上面这个脑洞大开的例子所描述的场景是否存在并不重要,重要的是增长中台作为一个支撑平台,要有全局性的视角,要和业务线形成互补,要始终寻找提升平台用户LTV的机会,并形成跨条线的联合项目去测试。
用户增长团队如何构建
用户增长是一个新兴的领域,行业里做用户增长的人大多也只做了一两年甚至几个月,所以大家其实都处于边做边学的阶段。但如果能提前具备某些方面的能力,在做用户增长时就会比较顺手。当具有不同背景、不同能力的人聚在一起时,我们要对他们的工作和思维惯性有所了解,这样才能更好地帮助大家发挥合力。在做用户增长时,除了针对具体项目层面的引导,用户增长团队还应该形成自己独特的团队文化。这种文化就像胶水,能把背景各异的人黏在一起,让他们的力往一处使。
用户增长团队成员能力模型
我以前在组建用户增长团队的时候,给负责招聘的同事提的需求是:如果能招到有做用户增长经验的人最好,招不到也不用强求。我希望招聘综合能力强的候选人,要有创造力,有做产品经理的经验也行,最好懂一点技术,有战略视角,还懂一点运营,如果做过数据分析就更好了,要是还有创业经验那就完美了。一般没等我说完,负责招聘的同事就把我怼回来了:你去找一个这样的人给我看看!
其实我之所以提出这样的需求,是因为我发现背景丰富的同学在做用户增长时,会更加得心应手。以我自己为例,我最早是做研发的,后来自己创业,也做过职业经理人,还出国读了MBA,管过研发、产品、运营、战略、BI和用户增长团队。我发现自己在做用户增长时,如鱼得水,以前做不同工作的经历就像一颗颗珍珠,被用户增长这条线穿成了一条项链。
在组建用户增长团队时,除了之前就做过用户增长的人以外,理想的候选人应该有与产品、技术、运营、战略、BI、用户研究等一个或多个方面相关的工作经验,如果还有创业经验或心理学知识就更好了。上面说的几个方面之间的关系比较像加法,而创业经验和心理学知识则更像乘法因子,能把专业能力给放大。
因为创业本身就是一个不分方向,任何事都要做,自己要对用户、收入或利润结果直接负责的综合性项目,所以有创业经验的团队成员,在设计增长逻辑、推动增长项目落地时,思路会更加开阔,主人翁意识会更强。而了解心理学的团队成员在设计增长逻辑时,特别善于把握用户的心理。我们的大部分增长逻辑,都是为了让用户产生特定的HVA,引导用户做出我们期望的决策。所以,如果对用户心理的工作机制和决策过程有了解,设计出的增长逻辑引导框架就会更有说服力。
如何招募不同背景的人组成增长团队
像组建产品或技术团队一样去组建一个增长团队,而且里面每个成员的用户增长经验都很丰富,还能形成梯队,这几乎是不可能的。在实际组建用户增长团队的时候,很多候选人在简历上都号称做过用户增长,但实际上对用人单位来说,能找到几个用户增长经验相对丰富一点且有实战经验的人就已经很不错了,要招有自己的方法论的人就更难了。所以,用户增长团队成员还需要同时从不同背景的候选人中招募。
刚开始组建用户增长团队时,我们希望候选人最好具有综合背景,如果以前从事过超过两种以上的工作,绝对是加分项,但现实中这样的候选人相对比较难找。后来我就采用了一种替代性方案,让不同背景的人凑在一起组成一个团队,这样大家就可以借鉴别人之前的专业经验。虽然我可以接受不同背景的人做用户增长,但是有一个底线:没有数据驱动理念、对数据不尊重的人,我是绝对不会招的。在把这些背景各异的候选人组成团队后,我发现不同背景的人在做增长时,会遇到不同的挑战。
产品经理背景的候选人转做用户增长相对还是比较有优势的,因为很多用户增长功能和产品功能非常类似。但我也看到产品经理背景的候选人在做增长时,存在两个非常大的问题:(1)很容易把项目做成一个单纯的功能型增长项目,没有充分考虑失败假定,在设计增长功能逻辑的时候,很容易忽略兼容策略型增长项目,从而导致设计出的增长逻辑的灵活性较差;(2)前期和BI沟通不充分,没有提前设计好分析方案和数据埋点。
数据分析师背景的人在分析方案设计和数据埋点方面是比较有优势的,但是在推进项目并与相关人员沟通时就不太顺畅,容易谈崩,从而影响项目的落地进度。
策略背景的人一般逻辑性都比较好,在项目方案的框架设计方面是比较强的,但是在HVA引导逻辑的细节把控上还需要提升。他们存在的另外一个比较大的问题是项目落地经验相对欠缺,从而容易导致两方面的问题:(1)觉得自己在逻辑推演上已经想得很清楚了,在没有实际经验或是深入调研的情况下,很容易对一些事情做草率的判断;(2)在把项目推进落地并拿到测试结果的过程中,很容易陷入一些低谷状态走不出来。也就是说,他们很容易在一开始设计方案的时候信心满满,迫不及待想要推进,但是中间遇到一点困难和挫折,韧性就不那么足了。
还有其他背景的人在转做用户增长时,也都会在某个方面遇到比较大的挑战。过去的成功经验铸就了我们的职场竞争力,但正如增长的非连续性一样:如果我们是在同一个领域(同一条曲线)继续开展工作,那以前的经验就是成功的关键;如果不是在同一个领域工作,例如从其他工作岗位转做用户增长,那过去的经验就只能部分借鉴。然而很多时候,人们都有路径依赖的倾向,毕竟过去的成功经验是最有说服力的,但过去的成功也可能会成为现在失败的原因。所以,作为一个增长团队的负责人,在组建团队的时候,要看到大家以前的背景对后续工作的影响,在帮助团队成员补足短板的同时让大家尽量把自己的优势发挥出来。
既然我们把不同背景的人聚在了一起,那对他们之前的工作方式和后续可能遇到的一些挑战,都必须要有一定了解,这是团队负责人的职责。这样在大家做增长项目时,就可以根据团队不同成员的背景特点,对项目予以不同程度的关注。尤其是针对他们可能会遇到挑战的地方,要重点监控并引导。有时候,这种引导可能不是项目本身层面的,而是精神层面的。
用户增长团队的文化——正能量
由于不同的管理者有不同的领导风格,所以不同的团队可能会形成带有不同管理者烙印的独特文化。但无论什么文化,只要能把团队凝聚在一起,让大家朝同一个方向坚定前进,就是好文化。不过在用户增长团队中,文化中正向积极的因素一定要比较强,因为用户增长是用测试冗余性换取增长确定性,大部分测试都是会失败的,所以团队成员在面对失败时的精神面貌就尤为重要。
虽然团队成员知道大部分测试会失败,但是团队外的人未必了解。我看到不少其他岗位的人,认为用户增长和做广告创意差不多。他们觉得用户增长就是想到一个非常棒的创意或很厉害的功能,然后就能带来用户量飞跃式增长,但其实他们对用户增长的底层逻辑是不清楚的。在增长测试失败后(这是常态),他们可能还会有一些负面评论,例如觉得增长团队的人能力不行或不专业,从而影响增长团队的士气。
所以,正向积极的增长团队文化不光能让团队成员坦然面对失败的测试,从中分析数据、汲取灵感、获取经验,还能让团队能正确面对外部的压力。知易行难,相对于实际做事,做评论永远都是最容易的。尤其是在出现一些评论者无法理解的结果时,他们的评论会显得更为雄辩,因为这些结果大概率其他人也无法理解。
为了消除这些负面因素对团队的消极影响,我在团队提倡的文化就是“正能量”。“正能量”分为正言、正行、正念三个层面,争取让团队成员能做到福从心起,心随言动。
正言
“正能量”文化首先要求团队成员既不要有负面言论,也不去散播负面情绪和言论。如果遇到一些挫折我们就说负面的话,那这种负面情绪在我们说话的时候就会被放大。同时,这种负面言论又会对团队其他成员造成影响,从而形成一个恶性循环。这种负面情绪最大的危害就是让人忽略工作本身带来的满足感,使大家难以在工作中进入心流状态。
因此,我们应该在生理体验和话语层面都保持积极的习惯和心态,这样才能直面增长测试失败的挑战和团队外的负面声音,做到愈挫愈勇、心随言动!
正行
在做用户增长测试的时候,我们经常会发现结果达不到我们的预期。在这种情况下,除了自己不说消极言论、不散播负面情绪之外,还应该积极推进下一步工作。按照我们之前所说,做项目之前我们已经有项目会失败的心理准备,所以对于下一步要做什么,我们应该是胸有成竹的。这个时候,我们需要采用正行的态度,始终关注自己能改变的事,从失败中成长,这样就能很快走上增长的正循环。
我们在生活和工作中会关注非常多的事情,这些事都在我们的关注圈之内。但其中只有一小部分是我们可以改变的,这些事属于我们的影响圈。很多时候,我们不知不觉地在为关注圈的事忧虑、烦恼,耗费了大量能量、心力,这反而让我们无法去改变影响圈中的事情,从而导致我们能改变的事越来越少,陷入恶性循环。如果我们始终把能量集中在影响圈内,这种能量就是积极能量,会扩大我们的影响圈,让我们能做的事越来越多、越来越重要。如果我们经常把能量集中在关注圈,这种能量就是消极能量,它会缩小我们的影响圈,让我们的影响力越来越弱。
因此,盯住长期目标,时刻聚焦我们能改变的、能帮助我们实现目标的事,不让关注圈里的事分散我们的精力,始终专注于效能的提升,这就是正行。
正念
正念的概念大家可能都知道,其实就是要我们关注当下,关注自己的存在。更多关于正念的解释,在网上就能搜到,我就不展开了。在这个部分,我想分享的是如何在工作中引入正念的视角,让工作本身能带给我们幸福的满足感。
由于用户增长工作本身的性质,很多增长测试的失败会不断带来负面影响。如果在做用户增长的时候,只是凭着一股劲支撑着自己,工作本身对自己是一种消耗,那迟早会坚持不下去。用户增长工作虽然非常有挑战,但其实是非常有趣的。
只要我们能专注于工作本身,就能感受到能力在自己身上“滋滋”地成长,就像看到嫩芽破土而出一样,就能够从工作中获得极大的满足感。不管是带来巨大增长的项目,还是不如预期的项目,都是用户增长工作的一部分。如果我们总是盯着增长的结果,忽略我们自己,忽略在工作中的成长,不能享受这个过程,不能从工作中吸收能量,那用户增长就会变成一件得不偿失的事!
—— 欢迎在线投稿 ——
特别提示:关注本专栏,别错过行业干货!
PS:本司承接 小红书推广/抖音推广/百度系推广/知乎/微博等平台推广:关键词排名,笔记种草,数据优化等;
咨询微信:139 1053 2512 (同电话)
首席增长官CGO荐读:
更多精彩,关注:增长黑客(GrowthHK.cn)
增长黑客(Growth Hacker)是依靠技术和数据来达成各种营销目标的新型团队角色。从单线思维者时常忽略的角度和高度,梳理整合产品发展的因素,实现低成本甚至零成本带来的有效增长…
本文经授权发布,不代表增长黑客立场,如若转载,请注明出处:https://www.growthhk.cn/cgo/user/33596.html