增长黑客之“法”——增长策略如何形成

引言#

找到核心变量以后，增长问题已经收窄了很多，但最容易犯的错误也发生在这个时候：团队终于知道该关注哪里，于是马上开始讨论做什么。假设当前最值得改善的是商品详情到加购的转化，会议上很快就能出现一串方案：重做详情页、增加优惠、强化评价、调整价格展示、增加商品对比、换按钮、做内容。每个方案听上去都有道理，可它们针对的不是同一个问题。用户没有加购，可能是没看懂商品价值，可能是不确定是否适合自己，也可能是价格超出预期、信任不足，甚至只是入口带来的用户本身就不匹配。原因不同，值得采取的策略自然不同。因此，在核心变量和具体动作之间，还需要补上一层判断：这个变量为什么会形成现在的结果，改变什么最可能推动它发生变化。

4.1 增长洞察#

数据分析能帮我们找到异常，却不会自动给出原因。“详情到加购转化下降”只是一个结果；进一步发现下降主要集中在新用户，是第一次收窄；继续比较后发现问题集中在某类内容入口，又缩小了一层范围。如果这批用户进入商品页以后频繁查看规格、评价和说明，停留时间也并不短，却依然大量退出，我们至少可以判断，他们不是简单地“看一眼就走”。但做到这里，原因仍然没有确定。用户可能看不懂商品差异，可能觉得价格不值，也可能正在寻找质量证明，或者发现商品和入口内容建立的预期并不一致。行为数据把问题缩小了，却仍然留下了几种不同解释。增长洞察的形成，就是继续区分这些解释。

定量数据适合回答变化发生在哪里、集中在哪些用户、差异有多大以及是否持续；用户访谈、客服记录、评论和真实场景观察，更容易暴露用户在比较、犹豫和决策时遇到的阻力；过去的项目经验和外部案例则可以补充一些当前尚未想到的可能。三类信息没有谁天然更高级，它们解决的是不同问题：

如果数据已经显示某类用户反复查看商品规格和评价，访谈中又不断出现“看不出区别”、“不知道适不适合自己”之类的问题，那么“缺少足够的购买判断依据”就比“用户根本没有兴趣”获得了更多支持。反过来，如果访谈发现用户很清楚商品价值，只是普遍认为价格超过了可接受范围，继续强化内容表达可能就不是最值得投入的方向。判断通常不是一次完成的。第一次分析提出可能性，新的数据继续区分人群，用户反馈帮助解释行为，再回到数据检查这个解释是不是真的覆盖了主要问题。几轮之后，原本宽泛的“转化低”才逐渐变成更有行动价值的判断。

外部产品也可以在这个阶段提供帮助，但值得借鉴的不是页面上出现了什么模块，而是它在解决什么决策障碍。用户评价是在降低质量的不确定性，商品对比是在降低选择成本；场景内容要解决的，则是帮助用户理解价值。只有把表面的做法还原到背后的问题，才有可能判断它和自己的业务是否真的相关。团队经验和脑暴同样可以产生好想法。区别只在于，经验更适合提出“会不会是这个原因”，而不是直接宣布“原因就是这个”。增长工作需要经验。经验最有用的时候，是帮分析提出更好的问题，它给不了答案本身。

洞察不需要把所有未知都消灭。只要原来十几种可能已经被压缩到少数几个，并且其中某一种解释获得了明显更多支持，就具备了继续向前推进的条件。再往下堆更多数据，如果已经很难改变当前判断，分析本身就开始失去边际价值。

4.2 证据与假设#

洞察仍然是一种解释，要让它进入增长决策，还需要把解释变成可以被验证的判断。一个完整的增长假设，至少要回答三个问题：准备改变什么，希望什么结果随之变化，为什么相信两者之间存在这样的关系。最后一个问题通常最重要，“把购买按钮做得更明显，可以提高加购率”，已经有动作，也有目标，但缺少关键的一层：为什么当前没有加购，是因为用户找不到按钮？如果目标用户连购买意愿都没有形成，按钮再明显也解决不了主要问题。只有当现有行为显示，一部分用户已经完成了大部分购买路径，却在关键操作位置反复寻找和退出，用户测试又出现了类似问题，才有理由进一步判断：降低关键入口的发现成本，可能改善这部分用户的加购转化。

前面的内容入口案例也是一样。如果数据和用户反馈逐渐表明用户已经产生了兴趣，却迟迟无法判断商品是否适合自己，那么假设可以收敛为：如果降低用户理解商品差异和判断适配性的成本，这类用户的加购转化应该改善。这样的表达里，需要被验证的是“决策困难是否影响了转化”，不是某一个具体模块能不能涨数据。把作用机制留在假设层，后面的方案才有调整空间。一个假设是否已经足够清楚，可以用几个要素简单检查：

预期变化不一定非要写成一个非常精确的百分比。有历史数据、相似实验或稳定基线支持时，可以给出合理的变化区间；证据还不足时，明确变化方向和判断标准，比为了显得专业随手写一个精确数字更有意义。假设也不应该追求“证明自己是对的”，如果新的数据与原来的解释冲突，就应该调整判断。一个好的假设必须允许自己被推翻，否则所谓验证最后只会变成给既定方案寻找支持。这一点在实际工作中很容易被忽略：团队已经对某个方案投入了时间，越往后越容易有意无意地寻找支持它的数据。有用的证据恰恰包括反证。核心用户没有表现出预想中的困难，或者调整之后用户行为没有沿着假设中的路径变化，原来的解释就该降低优先级。

4.3 策略设计#

假设逐渐清楚以后，策略才有了起点。假设关心的是“为什么”，策略关心的是：面对这个原因，准备从哪个方向改变。假如目前更可信的判断是，内容入口的新用户已经产生兴趣，但缺乏判断商品是否适合自己的依据，那么策略可以是“降低商品理解和选择判断的成本”；如果问题主要来自用户对质量和售后的不确定，策略就可能转向“降低购买风险感知”；如果分析发现入口承诺和实际商品之间存在明显偏差，策略甚至可能不该落在详情页，而是回到入口人群和内容表达的调整上。

好的策略不会直接规定某个功能，却也不能停留在“优化体验”、“加强内容”、“提升信任”这种过于宽泛的表达。它需要对后续行动形成约束，让团队知道哪些方案是在解决同一个问题，哪些虽然也可能涨指标，却已经偏离了当前判断。策略通常需要同时明确四件事情：针对谁，改变什么机制，影响哪个核心变量，以及什么代价不能接受。以前面的场景为例：

这里的“有效转化”尤其重要，增长策略如果只追求眼前一步，很容易把问题往后推。通过夸大表达或者过度刺激，详情加购确实可能变好，但支付没有改善，退款反而上升。原来的问题没被解决，只是往后挪了一步。

同一个核心变量也完全可能存在几条候选策略。加购低可能来自价值理解不足，也可能来自购买风险、价格预期或商品匹配。证据还不足以排除其他解释时，不必急着把它们揉成一个“大而全”的策略，可以先保留几条逻辑清楚的方向，后面再根据证据和验证成本决定先动哪一条。策略越清楚，后面的动作反而越容易丰富，因为团队不再围绕“还能做什么”发散，而是在一个明确机制下寻找更合适的实现方式。

4.4 策略与方案#

策略决定改变的方向，方案负责把这个方向落成具体动作。两者分开以后，增长工作才有可能留下比需求清单更有价值的东西。比如策略是降低用户判断商品是否适合自己的成本，实际方案可以是重构商品信息、增加真实使用场景、提供关键差异对比，也可以通过用户反馈、专业说明或服务保障来完成。方案可以完全不同，但它们验证的是相近的机制，这一点在真实项目中尤其明显。

我曾经有一个零售项目，在同一阶段围绕商品交易转化做过几类尝试。其中更完整的种草内容版本在当时样本中带来了约 38.5% 的加购率提升；强化价格和倒计时等信息的版本没有得到统计显著结果；底部行动按钮的调整，效果也相对有限。这个结果只能代表当时的用户、商品和实验条件，不能直接推广成跨场景规律。如果只记录方案，最后留下的经验很容易变成“种草有效，价格展示没用，按钮也不重要”。这样的结论既粗糙，也很危险。把这些动作放回各自的机制，会得到完全不同的信息。内容版本主要试图让用户更充分理解商品和购买理由；价格面板更偏向强化价格感知与决策刺激；按钮调整主要减少操作层面的摩擦。它们都希望影响转化，却在尝试改变不同东西。当时的结果能够支持的只是一个相对克制的判断：在那组条件下，围绕商品理解和购买理由的改变获得了更强的正向信号，而价格展示和操作层调整没有得到同样程度的支持。它提高了某种机制判断的可信度，却不能证明“内容永远比交互重要”。

所以一次方案失败，未必意味着整个策略该立即放弃。策略判断仍然有充分证据时，失败可能只是具体实现没有改变预期机制。反过来，如果几个不同方案都围绕同一个机制尝试，却始终看不到应有的用户行为变化，新的研究又开始反驳原来的判断，继续换页面样式就没太大意义，需要重新检查的是策略本身。

一次有效方案也同样需要克制。页面上增加某个模块之后转化提高，值得留下的知识不是“以后都加这个模块”，而是这个变化为什么产生了作用。如果起作用的是用户获得了更清楚的决策依据，那么在另一个场景里，很可能通过完全不同的方式达到同样目的。团队能沉淀下来的，不是“我们做过哪些功能”，而是“在什么用户、什么场景下，我们曾经相信什么，采取了什么动作，结果怎样改变了这个判断”。经验走到这一层，才开始可复用。

4.5 ICE 与决策约束#

当几条策略都有一定依据，资源却不足以同时验证时，优先级需要再次收敛。ICE 是一个够用的辅助工具，它分别看 Impact、Confidence 和 Ease：如果判断成立，可能产生多大影响；目前有多大把握相信它；以及获得答案需要付出多少成本。

• Impact 仍然要回到当前核心变量和业务结果。一个改动范围很大，不代表实际影响一定更大；一个只作用于少数用户的方案，也可能因为这些用户恰好处于关键转化位置而值得优先验证。

• Confidence 则取决于当前已经掌握的证据。只有团队经验支撑的判断，和同时得到行为差异、用户研究以及历史结果支持的判断，不应该拥有相同的信心。随着新信息出现，这个判断也会变化，它更像当前时点的置信程度，而不是给策略贴上的永久标签。

• Ease 也不能只理解成开发工时。有些功能技术实现很简单，却需要大量内容生产、商务协作或者规则调整；另一些完整方案看起来很重，但关键判断可能很容易获得初步答案。需要比较的是：为了减少当前最重要的不确定性，要投入多少资源。

ICE 的分值没有必要追求精确。它本来就是帮助团队快速比较候选想法，不是用来算出唯一答案的公式。优先级判断本身就包含经验和取舍，分数的价值是把判断依据显性化，而不是制造一个绝对正确的排序。还有一些条件不能交给分数决定。策略必须能够解释它给用户带来的真实价值，而不是只提高某个局部指标；投入和潜在收益需要基本匹配；业务、法律、隐私和合规风险不能因为增长空间大就被忽略；退款、投诉、留存、满意度等关键结果，也应该成为明确的决策边界。

例如，通过隐藏关键信息、制造虚假的紧迫感或者增加退出障碍，短期可能真的提高某个转化数字，而且实现成本也很低。这些方案并不会因为 ICE 得分高就变成好策略。类似地，一个方案提高了支付率，却同步带来明显更高的退款与投诉，也不能只看支付率判断成功。

经过这样的筛选，排到前面的应该不再是一串零散功能，而是少数几条相对完整的判断：它们针对明确的用户和核心变量，有可以解释的机制，也已经获得一定证据支持，值得投入有限资源进一步验证。策略形成后，不确定性并没有消失，只是原来“我们可以做很多事情”的混乱，已经收敛成“这几个判断最值得先被验证”。接下来需要解决的，是怎样用合适的验证方式，以尽可能低的成本获得足够可信的结果。