增长工程师到底做什么：AARRR 五个阵地和对应的代码

最近想搞清楚一件事：增长工程师具体在写什么代码。

搜了一圈挺失望的。JD 和科普文翻来覆去就那几句——"数据驱动决策""优化用户旅程""跨职能协作"。全对，但也全是废话，看完你还是不知道明天上班该打开哪个文件。

要我用一句话说的话：增长工程师就是对指标负责的工程师。产品工程师问的是"这个功能该怎么建"，增长工程师问的是"用户为什么不留下来"。

至于这个问题具体怎么拆，有个现成的框架就够用了，叫 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 技术侧（SSR / SSG、metadata、structured data、Core Web Vitals）、programmatic SEO、广告落地页、UTM 与归因链路

其中 GEO（Generative Engine Optimization）是这两年才冒出来的说法：SEO 优化的是搜索结果页的排名，GEO 优化的是让 AI 在回答里引用你。手段有重叠，但目标不是一回事。

• 让市场自助配置落地页。这是"赋能"最典型的落点。如果市场每次改个标题都要提需求等排期，那你就是瓶颈——这个判断挺残酷但是对的
• programmatic SEO：一套模板批量生成成千上万个长尾页。技术上不难，难在内容质量和索引策略，做砸了就是一堆垃圾页被搜索引擎降权
• 归因链路：搞清楚一个付费用户到底是哪个渠道带来的

这个阵地有两个地方比较磨人。

一是周期明显比别的阵地长，SEO 的反馈要等几周到几个月，你没法拿 A/B 实验那套天级节奏去套，等不到显著性就先开始怀疑自己了。

二是归因。多触点、跨设备，加上 ITP（Safari 的追踪限制机制）和 Cookie 弃用这些隐私限制叠一块，很多时候根本不存在"正确答案"，只有"大家都认的口径"。所以花时间进去之前先想清楚：这个归因结果要用来做什么决策？如果只是做个报表好看，那就别做。

阵地二：激活 Activation——让人第一次尝到甜头

这个阵地和后面的变现，是我觉得性价比最高的两块。

指标：激活率（最常用第 7 天激活率）、Time to Value（注册到用出价值的时长，简称 TTV）、注册到首次成功的转化率

方向：注册登录流、onboarding、引导流程、checklist、空状态、首次体验路径

核心概念是 aha moment。有两个词容易混，Appcues 那篇 aha moment 指南分得比较清楚：

• Activation 是用户第一次真的体验到产品价值
• Aha moment 是用户第一次在情绪上意识到"这东西对我有用"

后者在前者之前发生，而且是主观的。几个被引用最多的定义方式：

这三个的共同点是——都是一个可埋点的具体动作，不是一种感觉。这一点比具体定成什么动作更重要："让用户感受到价值"这种说法没法优化，"创建第二个页面"可以。

• 把 aha moment 翻译成一个可埋点的动作，然后盯它的转化率
• 压 Time to Value。各类 activation playbook 的口径是：5 分钟内到达 aha 的产品，30 日留存比 15 分钟以上的高约 40%；自助产品建议压到 20 分钟内
• 从漏斗里找最大的那个掉点，不是你最想改的那个。这两个经常不是一回事
• 变体 B 要是一个具体假设，不是"优化一下"

这个阵地最容易犯的错是把 onboarding 当成一个页面。它其实是一个系统：站内引导 + 邮件序列 + 推送 + 帮助文档 + 上手视频。只改站内那一段经常动不了指标，因为用户是在第二天的召回邮件里流失的。

另外加引导这事容易上瘾，但每多一步就多一层流失。Slack 的做法是三步之内把用户送到"发出第一条消息"。

阵地三：留存 Retention——把人叫回来，但别把人叫烦

指标：次日 / 7 日 / 30 日留存、DAU/MAU（日活 / 月活）、召回率、churn（流失率）

方向：生命周期消息编排（邮件 / push / 站内信）、召回流程、习惯循环、通知策略与频控

• 搭编排基建：把"什么人、在什么条件下、隔多久、收到哪条消息"变成可配置的，而不是每个场景写一段硬编码
• 接现成工具（Customer.io / Iterable / Braze 这类），然后做到运营能自助配置，别让每次改文案都变成一个需求
• 给通知定频次上限，这条下面单独说

这是最容易做出负收益的阵地，因为通知天然短期涨、长期跌。多发通知短期 DAU 一定涨，实验也一定赢，但你在烧用户信任，而这个损失在两周的实验窗口里根本看不见。

Duolingo 的处理方式值得抄：先立通知频次的硬上限当护栏，再谈实验。也就是有些实验就算赢了也不采纳。我第一次看到这个做法有点意外——工程师的本能是"数据说了算"，但这里明摆着数据会骗你。

还有个麻烦是节奏。留存指标要等 7 天、30 天才有数，跟"两周一个实验"的节奏对不上，这个阵地的实验得单独排期，别混在常规迭代里。

阵地四：推荐 Referral——让人带人

指标：邀请发出率、邀请转化率、K 因子（一个老用户平均能带来几个新用户）

方向：邀请流、分享流、奖励发放、防刷、归属追踪

这个阵地的问题其实就一个：一个老用户平均能带来几个新用户。 行业里管这个数叫 K 因子，听着专业，拆开看很朴素——就两个环节，有多少人愿意发出邀请，以及收到邀请的人有多少真的注册了。哪一环拉高，整体都会往上走。

不过得先泼盆冷水：真能靠邀请自己滚起来的产品极少。 按 First Round 的口径，消费级产品里一个老用户能带来 0.2 个新用户就算做得不错了。所以别把邀请当增长的主引擎，它更像个放大器——本来能来 100 个人，做好了变成 120 个。

几条已经被反复验证的：

• 双边奖励优于单边，两边都给好处，安装率能高出三到五成
• 奖励要和产品价值对齐。Dropbox 的天才之处是文案写"获得更多空间"而不是"邀请你的朋友"——前者是产品价值，后者是求人帮忙。这个差别我觉得比奖励给多少都重要
• 邀请入口放在情绪高点：完成任务后、达成里程碑时、aha moment 之后。放在设置页里等于没做
• Dropbox 把邀请直接嵌进 onboarding，不是做成一个独立功能

真正的工程难点不是邀请流，是防刷和奖励成本控制。邀请流一天能写完，防刷能拖你一个季度。

阵地五：变现 Revenue——把"想要"变成"付钱"

指标：付费转化率、ARPU（每用户平均收入）、MRR、trial→paid（试用转付费）、LTV（用户终身价值）

方向：paywall（付费墙）、定价页、trial 逻辑、结账、订阅生命周期、升降级、挽留、折扣券

paywall 常被叫做"最重要的单一增长杠杆"，理由挺实在：离钱最近、改动成本最低、A/B 空间最大。

厂商 playbook 里流传的几个经典实验，下面这些来自 Adapty、Botsi 这类订阅工具厂商的清单，有一些其实也已经是行业内大家通用做法：

最后两条最值得记，因为它们反直觉：加个关闭按钮、少几个页面，直觉上是"降低了转化压力"，实测方向却相反。这类反直觉正是要做实验的理由——有时候你的直觉在不一定真的准。

• 先定价格点，再优化该价格下的转化率。 顺序反了会白跑一堆实验，因为价格一变，之前所有转化率优化的结论全部失效
• 按人群分开测。新用户、活跃用户、高意图用户对定价和文案的反应完全不同——高活跃用户吃"高级功能"叙事，新用户吃"先免费试"。同一套文案打所有人，等于放弃一半空间
• 挽留和降级路径也算这个阵地，而且经常被忽略

这个阵地真正难的地方不在页面上。我自己踩过的三件事：

改定价是改系统，不是改页面。 加一档价格，牵出来的是结账、升降级、老订阅用户怎么过渡、券能不能叠加、这一档配多少额度。收款和按比例折算（proration）这些 Stripe 会替你算，省了一大块；但"选哪种折算策略""老用户要不要保价""这档给什么权益"还是得你自己定，而且每一处都要和前端展示对得上。

折扣的维度是乘起来的，不是加起来的。 地区、订阅档位、新老用户、有没有券、有没有在跑活动——每多一个维度，组合数翻一倍，做到后面没人说得清一个用户打开定价页该看到什么价。所以算价必须收到单一入口；前端到处写判断很难查，因为每处单看都是对的。

促销下线比上线难。 这里的难不在扣费——收款走 Stripe，活动结束了老订阅照约定续费，钱不会算错。难在业务侧：当初按活动档位该发多少额度、附带了什么权益，这些逻辑还挂在那批仍然生效的订阅上。代码删早了，钱没错，但那批用户的权益就不对了。所以促销上线的时候就该想好它怎么退场——什么时候能删、删之前要确认哪些订阅还在依赖它。

所以这个阵地是唯一不能牺牲质量换速度的，30/90 法则在这儿不适用。动手前先分清哪部分是帐篷、哪部分是地基。

五个阵地摆一起看

拉平了对比，差异比我一开始想的大得多：

把其中两个维度画成坐标，位置关系更直观一点：

如果要给一个通用的入场顺序，我会这么排：

激活 → 变现 → 留存 / 推荐 → 获客

• 激活先做：反馈快、技术门槛低、容错高、收益还不错。而且你需要几个赢的实验，来换取后面动定价的许可
• 变现第二：收益最高，风险也最高，所以要在有信誉之后再动
• 留存和推荐往后：观测周期长、容易做出负收益，需要更成熟的判断力
• 获客看基础：公司没有流量基础的话，这个阵地根本没得测

阵地之外：五个阵地共用的能力

五个阵地看着差别挺大，但真上手会发现吃的是同一套底层能力，大概五样。

一、自己拉数据。 最高频的一项。你得能自己把漏斗拉出来、自己看分群差异，不然每个问题都要排队等数据同学，节奏就没了——而增长这行最值钱的恰恰是节奏。

这项的门槛这两年降了很多。数据平台一旦接上 AI，很多查数用自然语言问一句就出来了，不用自己拼 SQL。这是 AI 放大个人能力最直接的例子之一：以前要等人，现在自己就能闭环。但门槛降低不等于这项不重要了——你还得判断问出来的数对不对、该看哪个切面。

二、埋点设计。 这是整条链路的输入端。埋点埋错了或者漏了，后面所有实验结论都是错的，而且你往往发现不了。这块 AI 同样能帮上忙，写埋点代码、检查命名一致性都比人快。

但我的体感是，这块真正的分水岭不是会不会埋，而是别人会不会来问你"这个数能不能信"。会来问你，你就是这条链路的守门人，而不只是个接埋点需求的人——这个位置差别 AI 补不上。

三、实验的统计常识。 不用当统计学家，但几件事必须知道：样本量不够就别下结论、跑到一半别偷看、同时盯十个指标总会有一个"显著"、赢了也可能只是新鲜感（novelty effect）。就这几条，能挡掉大部分假结论。

还得补一条统计课上不会教的：要会怀疑实验平台本身。我踩过一个特别隐蔽的坑——复用了一个跑过实验的互斥层来建新实验，结果曝光量比同层历史低了将近两个数量级。原因是老用户早就被上一轮实验的 holdout 锁住了，只有新用户才会进组。

这个坑难受的地方在于，配置单看全是对的：独占 100% 流量、没有任何限制条件、代码也没问题。你只能从"曝光量比同类实验低了一大截"这个信号反推。所以实验跑起来之后，第一件事不是等结论，是先确认进组人数合不合理。

四、全栈。 增长改动经常横跨前后端——前端改个 paywall，后端得配套改订阅逻辑。你只会一头就得等排期，等排期就没速度。

不过全栈这事我觉得更多是时间问题。只要前面几项在，不管你原本是前端还是后端，学另一端都不会太慢；有了 AI 之后这个速度又快了一截——不熟的那端边问边写就能上手，卡住的地方也不用再等人。所以这行要广度大于深度，但广度本身没那么难补。

五、把结论说清楚。 实验做完，你得让一屋子人相信这个结论、并且照着它做决定。这项最容易被工程师轻视，但它直接决定了实验结果会不会真被采纳——做完没人信，等于没做。

这项 AI 帮得上的是取证：多拉几个交叉验证的切面、把反例找出来、把口径对齐。但"这个结论到底成不成立、要不要照它改产品"，还是得人来拍。

五样摆一起看，我觉得真正稀缺的不是其中任何单独一项。AI 已经把好几项的门槛拉低了——查数、写埋点、甚至生成实验变体，单点上它都能帮你干得挺快。

稀缺的是能把整条流程串起来的人。 一个完整的增长动作是这么一条链：

这条链上只会其中一段，AI 随时能替你干那一段。

前提是基础得有。实验的统计常识、全栈的代码能力这些不能外包，因为你得有能力判断 AI 给你的东西对不对。关于怎么用 AI 提效的同时自己也真的在长，我之前单独写过一篇：《AI 时代如何真正提升自己，而不是成为 Prompt 指令师》。

最后

先补一句：文里那些百分比当参考看就可以了，不用特别当真——大多来自工具厂商自己的博客，没说样本也没说方法。别人的 +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