干货|新浪微博“一次增长黑客实践”总结

作者：李江

9月27日，经过之前很长一段时间的思考，我决定在团队内部尝试一种新的打法，利用增长黑客的方式优化一项业务的核心指标。

我把业务相关的同学召集起来，组建了一只快速迭代小组：小组成员包括了我这个会议主持人加打杂，一位产品经理负责提供产品视角以及确保优化不偏离产品方向，团队中的两位算法工程师扮演了数据分析师的角色，以及另外3位工程师负责系统/策略/算法部分的开发。小组的目标就是为了快速提升业务的核心指标数据。我并没有和大家透露是在尝试增长黑客的方法，我只是说想实验一种新的方法，让每个人承担更多的责任。

整个小组的基本工作方式大致如下：

• 每周为一个开发周期，进行一批灰度实验用于优化核心指标；
• 每周一开数据分析讨论会，数据分析师提供上一轮各项实验的数据分析报告，小组基于此讨论相关策略是否上线或者放弃；
• 周二会再进行一次策略讨论会，要求每位成员至少提供三个新方案，大家共同讨论决定哪个方案进入到新一轮的灰度实验；
• 周三到周五是各项灰度实验的开发时间。我们的大部分实验周四能够完成开发灰度上线，而无法在周五之前完成的实验则延迟到下一轮；
• 周五/六/日是线上观察数据的时间；
• 重复上述步骤；

从9月27日启动，到11月5日完成最后一次的灰度数据分析报告，这一个月多的时间整个团队一共经历了4轮迭代实验测试；我们一共讨论了68个新的策略和算法的改进，完成了其中36项的灰度实验和结果分析；核心指标在此期间上涨了20%+。整个过程中，我很满意团队的工作节奏，合作方式以及最终的产出结果，同时也激发了我自己更多的思考，因此有了这篇文章。

增长黑客的三个核心要素

网上搜“增长黑客”，找到的文章大多数是在聊用户增长和营销的策略和方案，《增长黑客》这本书也是花费了大部分篇幅介绍用户漏斗模型和成功的策略与套路。但作为一个工程师，增长黑客在我看来其实是一套以数据为驱动的方法论。《增长黑客》洋洋洒洒大几百页，最有价值的东西我觉着在前言部分已经介绍完了。这套方法论大致分为三个关键要素：

多角色团队的集体决策

看几乎所有的增长黑客案例，它的核心团队都是由扮演各式角色的成员构成，大部分都包括产品经理，工程师，数据分析师，UI/UE工程师或者市场营销人员。为什么需要这么多的角色共同参与到核心团队中？是因为我们希望在后续的大批量灰度实验中能够去尝试各种角度的可能性。从一个算法工程师的角度，这有点像是将每个人都当成是一个还不错的“弱分类器”，这些“弱分类器”相互之间越独立越好，这样它们有机会共同构成一个效果显著的“强分类器”。为了确保讨论和实验的多样性，另外一个很重要的点是在团队内部实行“平权”，不应该出现某些人决策权过大的情况。所以我们的讨论会只有主持人而没有负责人，所有的决策共同讨论执行。

确保每个人都有充分的讨论权，话语权和决策权这一点对于增长黑客团队非常重要。这次实践过程中，我印象特别深刻的一次是，我们有位工程师提了一个建议：把推荐输出得分第一的物料放到第二个位置试试效果。这个建议当时在我看来毫无逻辑可言，因为如果把算法得分高的物料放到后面，那不就是在否定我们这些算法工程师的价值么。但这个策略最后我们还是上了灰度实验，因为策略并没有和我们观察到的数据表现相冲突，更重要的是这个策略的开发工程师是他本人，反正是他自己的工作量.... 最后的结果很意外，这个策略确实有正向的效果，数据有大概1%～1.5%的提升。对于这个结果我事后的理解是，推荐的场景和搜索的场景还是有较大的区别，搜索是用户有目的的行为，对于搜索结果用户的注意力是从上向下的，而推荐是无目的的行为，用户的注意力焦点可能更集中于屏幕的中间位置。总而言之，给一些看上去不那么靠谱的想法和策略留出灰度实验的空间在黑客增长中是有必要的，也许会带来非常意外的惊喜，只要确保不要重复实验同一个错误就好。

增长黑客为什么能够允许集体决策这件事情？一方面是因为我们能够做大量的灰度实验，所以不需要在讨论的过程中争个你死我活，可以求同存异，可以允许犯错。另外一方面是，虽然是集体决策，但最终决定的判断标准是统一的，就是核心数据指标的增长和提升。我们接下来就要分别聊聊这两点。

数据驱动

数据驱动谈论了很多年，但很多时候都被错误的当成了KPI驱动。KPI是我们要达成的目标，但它没有办法告诉你怎么达成，KPI的涨跌只能告诉你结果，但没法回答原因，也没法对下一步的方向提供建议。在我看来，数据驱动是一种能力，是增长黑客团队必须具备的一种能力，我把这种能力拆解成三个方面：

• 设定合理数据观测指标的能力

正如前述，我们不能仅仅观测KPI数据，一方面是它反映的角度相对单一，并不能很好的描述整个业务生态内部的变化，无法提供足够的决策支持；另一方面是，KPI数据有可能是不敏感的，需要长时间的灰度才能够观察到数据的变化，此类KPI并不适合作为灰度实验的观测指标。团队需要提炼出更多的指标作为除了KPI之外的辅助观测指标，这些指标能够反映业务某个维度的变化，并且对于灰度实验足够敏感。团队还应该对这些指标做更多不同维度的细分，观察各个细分领域的变化。

• 前置的数据挖掘发现问题的能力

为了支撑能够快速的做大量的灰度实验，我们的实验都不会允许特别复杂，工程上相对易于实验。那么如果有一个灰度实验想法需要投入较大人力的开发怎么办？最好的办法是在实验之前先从数据上验证实验的有效性。能不能事先通过数据分析侧面验证某个想法的可行性，这是一种非常强大的能力，能够节约大量的开发成本。此外，在没有好的实验思路的情况下，数据分析师能否主动从数据挖掘中发现一些有价值的想法和线索给整个团队提供参考，也是增长黑客团队的必备技能。

• 后置的实验结果分析能力

线上灰度不仅仅要验证这个实验本身是否有价值，是否能够上线，还需要为后续的想法和实验提供数据支持和依据，最好的循环应该是 实验 -> 分析 -> 更好的实验。基于此，对于实验结果的分析就不能只是YES or No的答案，而是应该尽可能的分析结果背后的原因。另外，对于观测指标应该在不同维度上做拆分，这样能够帮助我们从一个失败的实验中找到它可能对于某个细分场景有正向的影响。这样的全面分析要求团队的数据分析师同时具备扎实的分析能力和业务能力。

我们团队的数据分析工程师是由算法工程师兼任的，他们每天玩弄数据，熟悉业务，提取各式有效特征，但尽管如此，我仍然认为我们对于数据的分析还不够深入还不够细化。此外，即便是我们这个算法团队，做数据分析的工具还是不够健全，很多的分析需要重头写脚本跑数据，需要消耗大量的人力。数据驱动真的不仅是意识，它是一种实实在在的能力，一种需要各种配套设施和工具，需要团队反复打磨反复提升的能力。

大量快速的灰度实验

能够支持大量的快速的灰度实验是团队能够实施增长黑客打法的关键。满足不了这个条件，意味着较长时间内只能尝试非常有限的灰度实验，从而意味着团队讨论出来的大部分实验方案都必须放弃，只能从中挑选有限的进行尝试，这时候团队就会碰到决策权归属的问题，而一旦碰到这个问题，这个团队就不再是一个平权团队，而会慢慢重新演变成一个决策集中的团队。

因此，能够支持大量的快速的灰度实验是增长黑客团队的核心能力。这里包含有两个关键词：“大量” 和 “快速”，为了解释这两个词，我定义了两个指标：

用“灰度实验时间”来定义“快速”。灰度实验时间又大致可以等于 前期讨论方案时间 + 开发上线时间 + 灰度观测数据时间 + 后期数据分析时间：

• “前期讨论时间” 暂且不聊。
• “开发上线时间” 取决于团队的工程能力，敏捷开发优化的是这部分的效能；同时还取决于工程架构是否支持快速的上线部署，例如，客户端开发能够多快的上线新的灰度方案；还取决于我们之前提到的，是否有可能细化大方案，将复杂功能拆解成小型实验的能力；
• “观测数据时间” 这个指标取决于两部分：一部分是数据分析系统支持实验结果数据能够多快反馈出来。A公司需要一周时间跑数据，B团队需要一天完整的时间收集数据进行分析，C家的灰度系统支持上线后十几分钟后就能够获得反馈报告，那么C的可迭代速度就是A的几十甚至几百倍；另外一部分取决于观测指标的敏感性。并不是所有的指标都很敏感，比如用户留存就不太可能通过几十分钟的数据变化看出来，而用户的点击率能够在非常短的时间内反馈；
• “后期数据分析时间” 取决于数据分析系统/平台的能力，强大的平台能够让非数据专家快速观察分析各类指标和变化，普通的系统需要专人手动的写脚本执行各种统计。
• 很多情况下，我们会更加聚焦“开发上线时间”，而忽略了“观测数据时间”和“数据分析时间”，导致无法快速的做到策略的持续迭代。

用“同时可支持的灰度实验数量”衡量“大量”，它的影响因素包括：

• 足够的流量。每一个灰度方案都需要有足够的流量做支撑，这样才能够保证最终灰度结果指标的稳定性。所以有一定流量是增长黑客团队的前提。
• 强大的灰度系统，能够支持的同时实验方案的数量。
• 团队的开发能力，能够同时开发方案的数量。这里除了团队的执行力以外，还需要强调一下团队的规模。传统的软件工程领域有“人月神话”的说法，意思是堆人并不能够缩短软件开发的周期。但在这里，堆人是有帮助的。虽然无法缩短单个方案的开发周期，但可以帮助支持更多方案的并行开发，所谓“韩信点兵，多多益善”。

我们可以用 同时可支持的灰度实验数量 / 灰度实验时间 大致表示一个增长黑客团队的效能，这个效能代表的就是业务的迭代改进速度。迭代改进速度是一个增长黑客团队综合实力的体现，它需要融合团队的数据能力和开发能力，需要有强大的灰度系统和数据分析系统的支撑（看公司最近一个季度的小创新有好几个是关于AB测试平台，很赞）。强大的增长黑客团队的迭代速度能够是一个普通业务团队的几十倍，这是质的提升。

以上三个要素是构建增长黑客团队的基石，它们相互联系，缺一不可。至于其它的什么AARRR模型，增长秘籍等等在我看来都是这套打法在其他人的实践中发现的一些成功率比较高的定势或者套路，但脱离方法论只关注别人成功的具体策略，妄图完全复制就有些刻舟求剑的意思了。

接下来聊一聊我个人积累的一点点想法和思考。

个人的想法和思考

• 增长黑客到底是指什么？正如前文反复陈述的，我认为它是一个方法论，是一种新的打法。新的打法首先需要新的认知，团队内部需要认可数据驱动的工作方式，团队中的每个人都要有对结果负责的主动性，它提倡平权团队，所以团队中的强势人物需要能够适当约束自己的权利，等等。但光有新的认知不够，更重要的是要求团队具备新的能力。它要求你的数据分析师能够同时熟悉业务，能够从数据中发现问题而不仅仅是按照要求生成数据报表；它要求技术团队在考虑技术架构的时候要预先把灰度测试系统和数据分析系统融合其中，要能够支持多种灰度方案的快速上线（哪怕是客户端）。这种种能力是在长期实践中积累磨合出来的，不是随便看了一本书就可以照搬的。所以我并不看好大部分尝试增长黑客的团队，想的太简单了。
• 增长黑客适合于什么样的场景？我的理解，适用于解决目标明确但方法不确定的问题。所谓目标明确，是指期望达到的结果是可量化的，能够转换成一个或者少数几个具体的数据指标。所以构建产品的初期显然就不适合采用增长黑客的打法。另一方面，所谓方法不确定，是指我们所面临的是一个开放式的问题，没有明确的解决方案。一般情况下我们开发产品需求，解决的是一个相对封闭的问题，因为需求和解决需求的方案是已知的，这时候更强调的是团队的执行力。而解决开放式问题，更为重要的是团队的创造力。
• 为什么增长黑客现在越来越火？我觉着主要是两个原因：一是早几年前中国互联网还停留在“对标”阶段，照着国外的产品做，大家比的就是谁“对标”的更快。而最近几年开始精细化耕作，发现光“对标”已经不太够用了，创新的重要性越来越突出；二是人口红利的结束。人口红利的时代PK的对象是竞品，比的是谁的功能更丰富，谁的速度更快能更早的抢占用户。人口红利的结束，意味着所有其它占用用户时间的产品都成为了竞品，游戏要开始和小视频抢夺用户时间，竞争中的不确定性变得更大，因此会更加强调产品的创新性和应变能力。
• 传统打法的团队组织架构，以产品经理或者业务负责人为中心节点，他们负责和其它成员的沟通以及决策的制定，而其它成员各司其职主要负责方案的执行。虽然有时候团队也会在一起开个沟通会议，但基本就是一个星状的组织结构。这种组织结构的优势在于决策的效率和执行力。增长黑客团队的组织架构更类似于网状的结构，没有特别明确的中心节点，强调通过相互之间的碰撞和协作产生创造力，同时通过数据驱动的方式让团队能够按照同一方向前进。（这小节的理解有点像《赋能》这本书里面的内容...）
• 增长黑客团队中谁最重要？我觉着多样化的角色每个都挺重要，但如果非要找一个的话，我认为是数据分析专家。增长黑客团队对于数据分析专家的要求很高，需要他能够主动的从数据中发现业务的问题和给业务的发展方向提供建议和思路。这需要数据分析专家同时具备业务理解能力和很强的数据挖掘能力，而不是像现在很多团队中的数据分析师，只是业务负责人进行数据分析的一个辅助帮手和工具。我也曾经想过，有没有可能产品经理或者业务负责人来扮演数据分析专家的角色。后来琢磨觉着不太可行。一方面是因为好的数据分析师需要有很强的数据思维和分析能力，这个能力是需要经过长期的实践打磨的。即便我们团队的算法工程师来做这事我仍然感觉还欠缺一些功底，更何况是产品经理；另一方面是数据分析师如果要有好的产出，需要长时间沉浸在数据清洗和分析挖掘的过程中，需要花费大量的时间干着沙子里面淘金的脏活累活，产品经理很难有精力能够投入这么多的时间。我觉着最理想的状态是团队里面有一个具备一定数据思维的业务专家，以及一个熟悉业务的数据分析专家，双引擎驱动效果应该最好。
• 我看过一些增长黑客的资料，似乎很多人强调增长黑客能够带来社会化自我营销或者爆炸式的增长，连《增长黑客》这本书为了宣扬它的观点举的例子都是那种特别戏剧性的创意，我个人不认可这种观点。黑客增长的目的如果只是为了达成某个“引爆点（The Tipping Point）”，那这种打法的适用范围就太小了，因为并不是所有场景和产品都存在一个“引爆点”的。我觉着增长黑客最大的能力是通过大量的灰度实验，持续性的发现新的增长点，从而实现长时间的复利增长。和投资领域一样，长期的可持续的复利增长才是我们应该追求的目标。举个最简单的例子，假设我们的灰度实验能够帮助我们在每周都发现一个效果仅仅提升2%的策略或者方案，那么6个月之后会发生什么呢？
• 我是一个算法工程师，会很不自觉的将增长黑客的工作方式和做算法的方式做对比。算法工程师为了解决所面临的问题，首先需要对问题进行分析和建模；而一个产品也是为了解决用户的某个需求而提出的模型，这个模型里面包含了最基本的产品逻辑和规则。算法模型中大量的参数需要调节；产品也有很多的细节需要打磨。为了调节模型中的参数，我们需要准备两个东西：定义清楚模型训练的损失函数（Loss），以及准备充足的训练数据；为了优化产品的体验，增长黑客同样需要两个东西：定义清楚增长的具体数据指标，以及一定的流量进行灰度实验。算法模型的训练通过计算训练样本的损失，调节参数拟合损失最小的梯度方向；增长黑客通过利用流量做大量灰度实验，挑选出能够获得增长的方案。两者都需要持续的快速迭代。所以在我这个算法工程师眼中，增长黑客其实是把我们做算法模型的流程移植到了产品优化和市场推广的工作中。
• 增长黑客应该很难解决产品建模这个问题，这件事情还是交给专业的产品经理和创业者去做。增长黑客能够做到的是快速的优化产品模型，如果说产品模型本身决定了这个产品的上界，那么增长黑客能做的就是尽快尽可能的拟合到这个上限。所以一种可能的打法是，迅速的复制市场上刚刚起来的经过验证的产品模型，然后用增长黑客的方式借助于流量实验进行快速的优化迭代，赶超原有产品。所谓“后发先至”。我觉着这可能会是大厂山寨其它产品的新思路，不仅仅利用流量更迅速接触到用户占领市场，而且可以利用流量比小厂做更快速的演进。
• 做算法的人都知道，训练模型的时候通过小步梯度下降不断迭代，最后收敛到的往往是局部最优而不是全局最优。算法工程师为了绕过这一点一般都会把模型改造成凸优化的问题，这样局部最优同时也是全局最优。我个人猜测，采用黑客增长方式优化产品可能同样会碰到这个问题，而产品模型可能要比为我们的算法模型更为复杂，很难保证会是一个凸优化。怎么解决局部最优的问题？我觉着可能有两个手段：一个方式是让产品尽可能的简单，如果非要把产品做的复杂加特别多的功能，那就可以考虑把产品分拆成产品矩阵的方式。另外一点就需要增长团队的负责人在已经拟合到局部最优的时候有勇气跳出现有思路另辟蹊径。（本小节纯属个人臆断）

结尾

增长黑客的打法要用好了其实是件挺难的事情，我们自己的实践也就是做了点皮毛工作。难点在于需要重新调整组织工作的方式，需要有一系列的系统来支撑新的工作流程，更难的在于它对于团队成员的要求很高。团队中的每个人都需要有更加积极主动的态度，需要对业务有更加深入的理解，能够在发散的讨论和强执行力之间顺利的切换。很庆幸我们的团队成员如此优秀，谨以此文献给他们。