前几天和朋友聊天，他问我最近在做什么。我张嘴想解释，卡住了。
"增长工程师"这个头衔说出去基本没人知道是干嘛的，而网上能搜到的答案翻来覆去就那几句——"数据驱动决策""跨职能协作"，全对，但听完你还是不知道这人每天到底在干啥，还写不写代码。
于是干脆自己盘了一遍。
要我用一句话说的话：增长工程师就是对指标负责的工程师。产品工程师问的是"这个功能该怎么建"，增长工程师问的是"用户为什么不留下来"。
至于这个问题具体怎么拆，有个现成的框架就够用了，叫 AARRR。
这框架挺老了，2007 年 Dave McClure 提出来的，把一个人从陌生人变成付费用户的过程切成五段：
- Acquisition 获客——用户怎么找到你
- Activation 激活——第一次用，有没有用出价值
- Retention 留存——还会不会回来
- Referral 推荐——会不会带人来
- Revenue 变现——会不会掏钱
想系统补这套框架的背景，推荐范冰的《增长黑客》。它整本书就是按 AARRR 这五段铺开的，每段有哪些手段、配什么案例都讲得挺细。先看那本，再回来看下面这些代码层面的东西会顺很多。
这五段谁都会背。但很少有人往下说一层：每一段背后都对应一堆不同的活儿。 改什么代码，查什么数据，优化什么流程，其实都不一样。
所以我按这五段重新捋了一遍。我管它们叫五个"阵地"，因为确实是一块一块去打的——同时开五条战线不现实。
有件事得先说，不然后面容易误会：增长代码的质量标准和产品开发不是一套。 Alexey Komissarouk 那篇里有句话我觉得特别到位——核心团队 ship to release，增长团队 ship to validate：核心工程师追求 90% 的质量标准以求代码长期存活，而增长团队的代码，一年后只有约 30% 还在生产环境。他管这叫 30/90 法则。Pragmatic Engineer 的比喻更形象：产品工程盖摩天大楼，增长工程搭帐篷。帐篷本来就不该盖成摩天大楼。
所以下面看到哪块代码显得糙，那是故意的——代价是监控告警得做得很硬，测试覆盖低你只能靠线上指标兜底。
五个阵地摆在用户旅程上是这样的：
这张图里有个容易被忽略的事：推荐和另外四个不是一类东西。 那四个是用户往前走的四段路，推荐是一条把出口接回入口的环——所以它的收益方式也不一样，后面讲到那节再说。
阵地一：获客 Acquisition——把人领到门口
指标：访客数、注册转化率、CAC（获客成本）、渠道 ROI
先摆一层地图：流量从哪来。大概五类——自然（SEO、GEO、内容、社区）、付费（SEM、信息流、社交广告）、合作（KOL、BD、affiliate 联盟分佣）、平台分发（应用商店、插件市场、GitHub 这类开发者平台）、产品自传播（分享、邀请、用户产物的公开页）。
这里面内容运营、KOL、PR 这些基本不用工程介入，跳过。真正落到工程手上的是下面几块。
方向：落地页系统、SEO / GEO 技术侧（SSR / SSG、metadata、structured data、Core Web Vitals）、programmatic SEO、广告落地页、UTM 与归因链路
其中 GEO（Generative Engine Optimization）是这两年才冒出来的说法：SEO 优化的是搜索结果页的排名，GEO 优化的是让 AI 在回答里引用你。手段有重叠，但目标不是一回事。
- 让市场自助配置落地页。这是"赋能"最典型的落点。如果市场每次改个标题都要提需求等排期，那你就是瓶颈——这个判断挺残酷但是对的。当然现在 AI 很发达，甚至可以让市场同事自助去修改。
- programmatic SEO：一套模板批量生成成千上万个长尾页。技术上不难，难在内容质量和索引策略，做砸了就是一堆垃圾页被搜索引擎降权
- 归因链路：搞清楚一个付费用户到底是哪个渠道带来的
还有一类值得单独拎出来：有些渠道，工程本身就是渠道，不是在支撑渠道。 programmatic SEO 是一个，另外两个是免费工具引流（做个小工具站把人引过来，《Traction》里管这叫 engineering as marketing）和用户产物的公开页——把用户生成的东西做成能被搜索引擎索引的页面，用户越多页面越多，流量又带来更多用户。这三个不需要先有预算、也不需要先有内容团队，工程师自己就能把流量从零做起来。
另外这个阵地有两个地方比较磨人。
一是周期明显比别的阵地长，SEO 的反馈要等几周到几个月，中间做的有问题不会有很明显的反馈，基本上只能在 Google Search Console 上看 audit 情况，以及 ahrefs 等这类站点也可以给出一些建议。
二是归因。多触点、跨设备，加上 ITP（Safari 的追踪限制机制）和 Cookie 弃用这些隐私限制叠一块，很多时候根本不存在"正确答案"，只有"大家都认的口径"。所以花时间进去之前先想清楚：这个归因结果要用来做什么决策？如果只是做个报表好看，那就别做。
阵地二：激活 Activation——让人第一次尝到甜头
这个阵地和后面的变现，是我觉得性价比最高的两块，反馈来的快。
指标：激活率（最常用第 7 天激活率）、Time to Value（注册到用出价值的时长，简称 TTV）、注册到首次成功的转化率
方向：注册登录流、onboarding、引导流程、checklist、空状态、首次体验路径
核心概念是 aha moment。有两个词容易混，Appcues 那篇 aha moment 指南分得比较清楚：
- Activation 是用户第一次真的体验到产品价值
- Aha moment 是用户第一次在情绪上意识到"这东西对我有用"
后者在前者之前发生，而且是主观的。几个被引用最多的定义方式：
| 产品 | aha moment |
|---|---|
| Slack | 团队累计发出 2,000 条消息 |
| Dropbox | 第一次上传共享文件夹 |
| Notion | 创建第二个页面 |
这三个的共同点是——都是一个可埋点的具体动作，不是一种感觉。这一点比具体定成什么动作更重要："让用户感受到价值"这种说法没法优化，"创建第二个页面"可以。
- 把 aha moment 翻译成一个可埋点的动作，然后盯它的转化率
- 压 Time to Value。各类 activation playbook 的口径是：5 分钟内到达 aha 的产品，30 日留存比 15 分钟以上的高约 40%；自助产品建议压到 20 分钟内
- 从漏斗里找最大的那个掉点，不是你最想改的那个。这两个经常不是一回事
- 变体 B 要是一个具体假设，不是"优化一下"
这个阵地最容易犯的错是把 onboarding 当成一个页面。它其实是一个系统：站内引导 + 邮件序列 + 推送 + 帮助文档 + 上手视频。只改站内那一段经常动不了指标，因为用户是在第二天的召回邮件里流失的。
另外加引导这事容易上瘾，但每多一步就多一层流失。Slack 的做法是三步之内把用户送到"发出第一条消息"。
阵地三：留存 Retention——把人叫回来，但别把人叫烦
指标：次日 / 7 日 / 30 日留存、DAU/MAU（日活 / 月活）、召回率、churn（流失率）
方向：生命周期消息编排（邮件 / push / 站内信）、召回流程、习惯循环、通知策略与频控
- 搭编排基建：把"什么人、在什么条件下、隔多久、收到哪条消息"变成可配置的，而不是每个场景写一段硬编码
- 搭建工具：方便运营自助配置发邮件、站内信、push 等触达用户的信息
- 给通知定频次上限，这条下面单独说
这是最容易做出负收益的阵地，因为通知天然短期涨、长期跌。多发通知短期 DAU 一定涨，实验也一定赢，但你在烧用户信任，而这个损失在两周的实验窗口里根本看不见。
Duolingo 的处理方式值得借鉴：先立通知频次的硬上限当护栏，再谈实验。也就是有些实验就算赢了也不采纳。我第一次看到这个做法有点意外——工程师的本能是"数据说了算"，但这里明摆着数据会骗你。
阵地四：推荐 Referral——让人带人
指标：邀请发出率、邀请转化率、K 因子（一个老用户平均能带来几个新用户）
方向：邀请流、分享流、奖励发放、防刷、归属追踪
这个阵地的问题其实就一个：一个老用户平均能带来几个新用户。 行业里管这个数叫 K 因子，听着专业，拆开看很朴素——就两个环节，有多少人愿意发出邀请，以及收到邀请的人有多少真的注册了。哪一环拉高，整体都会往上走。
不过得先泼盆冷水：真能靠邀请自己滚起来的产品极少。 按 First Round 的口径，消费级产品里一个老用户能带来 0.2 个新用户就算做得不错了。所以别把邀请当增长的主引擎，它更像个放大器——本来能来 100 个人，做好了变成 120 个。
几条已经被反复验证的：
- 双边奖励优于单边，两边都给好处，安装率能高出三到五成
- 奖励要和产品价值对齐。Dropbox 的天才之处是文案写"获得更多空间"而不是"邀请你的朋友"——前者是产品价值，后者是求人帮忙。这个差别我觉得比奖励给多少都重要
- 邀请入口放在情绪高点：完成任务后、达成里程碑时、aha moment 之后。放在设置页里等于没做
- Dropbox 把邀请直接嵌进 onboarding，不是做成一个独立功能
真正的工程难点不是邀请，是防刷和奖励成本控制。这里的防刷其实就是我们常说的风控，最简单的就是通过 IP 来判断是不是同一个用户在刷（当然可能会误判）。邀请一天能写完，风控策略得一直补。
阵地五：变现 Revenue——把"想要"变成"掏钱"
指标：付费转化率、ARPU（每用户平均收入）、MRR、trial→paid（试用转付费）、LTV（用户终身价值）
方向：paywall、定价页、trial 逻辑、结账、订阅生命周期、升降级、挽留、折扣券
paywall 常被叫做"最重要的单一增长杠杆"，理由挺实在：离钱最近、改动成本最低、A/B 空间最大。
厂商 playbook 里流传的几个经典实验，下面这些来自 Adapty、Botsi 这类订阅工具厂商的清单，有一些其实也已经是行业内大家通用做法：
| 改动 | 报告的结果 |
|---|---|
| 月付旁边加年付（约 6 折） | 每用户收入 +80%，trial 转化 +22% |
| trial 从 7 天缩到 3 天 | trial→paid +12~18% |
| 对未订阅用户追加一次 trial offer | trial 启动 +240% |
| 单页 paywall vs 多页 | 单页赢 |
| 硬 paywall 加上关闭按钮 | 有时反而提升转化 |
最后两条最值得记，因为它们反直觉：加个关闭按钮、少几个页面，直觉上是"降低了转化压力"，实测方向却相反。这类反直觉正是要做实验的理由——有时候你的直觉不一定真的准。
- 先定价格点，再优化该价格下的转化率。 顺序反了会白跑一堆实验，因为价格一变，之前所有转化率优化的结论全部失效
- 按人群分开测。新用户、活跃用户、高意图用户对定价和文案的反应完全不同——高活跃用户吃"高级功能"叙事，新用户吃"先免费试"。同一套文案打所有人，等于放弃一半空间
- 挽留和降级路径也算这个阵地，而且经常被忽略
这个阵地真正难的地方不在页面上。我自己踩过几件事：
折扣的维度是乘起来的，不是加起来的。 地区、订阅档位、新老用户、有没有券、有没有在跑活动——每多一个维度，组合数翻一倍，做到后面没人说得清一个用户打开定价页该看到什么价。所以算价必须收到单一入口；到处写判断很难查，因为每处单看都是对的。
促销下线比上线难。 活动结束了老订阅照约定续费，钱不会算错。难在业务侧：当初按活动档位该发多少额度、附带了什么权益，这些逻辑还挂在那批仍然生效的订阅上。代码删早了，钱没错，但那批用户的权益就不对了。所以促销上线的时候就该想好它怎么退场——什么时候能删、删之前要确认哪些订阅还在依赖它。不能粗暴地直接下线，影响用户权益，很容易损失用户的信任。
所以这个阵地是唯一不能牺牲质量换速度的，30/90 法则在这儿不适用。动手前先分清哪部分是帐篷、哪部分是地基。
五个阵地摆一起看
拉平了对比，差异比我一开始想的大得多：
| 阵地 | 反馈速度 | 技术难度 | 单位改动收益 | 容错度 |
|---|---|---|---|---|
| 获客 | 慢（周~月） | 中 | 中 | 高 |
| 激活 | 快（天） | 低 | 高 | 高 |
| 留存 | 慢（周） | 中 | 高 | 低（易负收益） |
| 推荐 | 中 | 中高（防刷） | 中低 | 中 |
| 变现 | 快（天） | 高 | 最高 | 最低（和钱有关） |
把其中两个维度画成坐标，位置关系更直观一点：
如果要给一个通用的入场顺序，我会这么排：
激活 → 变现 → 留存 / 推荐 → 获客
- 激活先做：反馈快、技术门槛低、容错高、收益还不错
- 变现第二：收益最高，风险也最高，改动要确保不会影响用户付费流程，不然相当于凭一己之力就断了公司的现金流（有点夸张，哈哈）
- 留存和推荐往后：观测周期长、容易做出负收益，需要更成熟的判断力
- 获客看流量：顺序问题，不是重要性问题。下游还漏着的时候先灌流量，等于花钱买流失，所以一般放最后。但有个例外——如果站点流量本身就很小，前面几个阵地根本跑不出显著性，那就得先把量做起来，不然什么都测不了。
阵地之外：五个阵地共用的能力
五个阵地看着差别挺大，但真上手会发现吃的是同一套底层能力，大概五样。
一、自己拉数据。 最高频的一项。你得能自己把漏斗拉出来、自己看分群差异，不然每个问题都要排队等数据同学，节奏就没了——而增长这行最值钱的恰恰是节奏。
这项的门槛这两年降了很多。数据平台一旦接上 AI，很多查数用自然语言问一句就出来了，不用自己拼 SQL。这也算是 AI 放大个人能力最直接的例子之一：以前要自学 SQL 才能闭环，现在会查的难度已经降低很多，更多的是判断能力，要看什么数据，是否准确，看什么切面。
二、埋点设计。 这是整条链路的输入端。埋点埋错了或者漏了，后面所有实验结论都是错的，而且你往往发现不了。这块 AI 同样能帮上忙，写埋点代码、检查命名一致性都比人快。
三、实验的统计常识。 不用当统计学家，但几件事必须知道：样本量不够就别下结论、跑到一半别偷看、同时盯十个指标总会有一个"显著"、赢了也可能只是新鲜感（novelty effect）。就这几条，能挡掉大部分假结论。
再补一条，实验跑开之后，要偶尔去看看，不是去看具体数据表现，而是要样本、曝光量是否正常，避免因为平台、配置等问题导致实验不及预期，到结束再看就已经太晚了。我之前就踩过一个特别隐蔽的坑——复用了一个跑过实验的互斥层来建新实验，结果曝光量比同层历史低了将近两个数量级。原因是老用户早就被上一轮实验的 holdout 锁住了，只有新用户才会进组。
四、全栈。 前端出身的人做增长确实容易上手——文案 A/B、落地页、埋点这些，前端自己就能闭环，不用等谁。所以入口从前端进没问题。
但天花板在另一头。收益最大的那些改动基本都压在后端：定价、订阅状态、发券、额度。只会一头，这类需求你就只能提出来然后等排期——而增长这行最值钱的恰恰是节奏。
不过全栈这事我觉得更多是时间问题。只要前面几项在，不管你原本是前端还是后端，学另一端都不会太慢；有了 AI 之后这个速度又快了一截——不熟的那端边问边写就能上手，卡住的地方也不用再等人。所以这行要广度大于深度，但广度本身没那么难补。
五、把结论说清楚。 实验做完，你得让一屋子人相信这个结论、并且照着它做决定。这项最容易被工程师轻视，但它直接决定了实验结果会不会真被采纳——做完没人信，等于没做。
这项 AI 帮得上的是取证：多拉几个交叉验证的切面、把反例找出来、把口径对齐。但"这个结论到底成不成立、要不要照它改产品"，还是得人来拍。
五样摆一起看，我觉得真正稀缺的不是其中任何单独一项。AI 已经把好几项的门槛拉低了——查数、写埋点、甚至生成实验变体，单点上它都能帮你干得挺快。
稀缺的是能把整条流程串起来的人。 一个完整的增长动作是这么一条链：
这条链上只会其中一段，AI 随时能替你干那一段。
但要把整条链串起来，前提是每一段的基础你都得有。实验的统计常识、全栈的代码能力这些不能外包——你得有能力判断 AI 给你的东西对不对，不然串出来的是一条错的链，而且你不会发现。
最后
先补一句：文里那些百分比当参考看就可以了，不用特别当真——大多来自工具厂商自己的博客，没说样本也没说方法。别人的 +80% 到我这儿可能就是 -3%，流量结构和价格带都不一样。一般就拿它判断一下这个方向要不要测一测，够了。
增长拼的更多是判断力，不是技术难度。 你很少写复杂代码，但你得决定该写哪段代码。上面那张定位图就是为这个准备的——它不告诉你怎么写，只告诉你在哪儿下手赢面大。
不过这话容易被理解成"增长不需要工程能力"，得补一句。恰恰相反：要支撑高频实验，地基得先打好。 拿定价举例，你希望随时能上一个促销、换一档价格、开一个 A/B，那算价、发券、订阅状态这套底层就得先抽干净。这是实打实的工程活，而且做得好不好，直接决定了业务能不能"快上快下"——地基没打好，每个促销都是一次手工作业。
所以更准确的说法大概是：日常改动的技术难度不高，但支撑这些改动的地基，技术难度不低。
如果你现在就想动手：先把产品的核心指标找出来，没有就顺手定一个；然后把漏斗拉出来，找漏得最多的那一段。那就是你该发力的地方——不是你最想改的那段，是漏得最多的那段。
引用来源
- The Pragmatic Engineer：What is Growth Engineering?
- Alexey Komissarouk：How to Build a Growth Engineering Team that Wins
- First Round Review：K-factor — The Metric Behind Virality
- Appcues：The aha moment guide
- June：Activation playbook
- Adapty：Paywall experiments playbook
- Botsi：19 Possible Paywall A/B Tests to Try