AARRR
AARRR
把增长过程拆成获取、激活、留存、收入和推荐五个阶段。
有可追踪事件，需要讨论获取、激活、留存、收入和推荐的具体问题时使用。先定义事件、人群、观察期与分母。
事件定义、同批用户、完整观察窗口、去重规则和收入或推荐口径。
可解释的阶段指标、缺口和待检验的增长假设。
先理解，再动手
使用步骤
分别检查获取、激活、留存、收入、推荐，定义事件、用户群、时间窗口和分母。它是增长诊断框架，收入与推荐未必严格串行；不同时间或人群不能直接比较转化率，不编造漏斗数字。
- 01
定义各阶段含义
- 02
设置阶段指标
- 03
分析用户从一阶段到下一阶段的转化
- 04
找出瓶颈
- 05
设计实验优化对应阶段
五项不必是线性路径，也不自动共用分母。留存需完整观察窗口；不能把付费人数与推荐人数相除，冒充推荐转化率。
看清框架结构
从一份空白提纲开始
复制到你的文档，填入真实的业务事实与判断。
查看空白提纲
AARRR · 空白提纲 什么时候用：有可追踪事件，需要讨论获取、激活、留存、收入和推荐的具体问题时使用。先定义事件、人群、观察期与分母。 需要准备：事件定义、同批用户、完整观察窗口、去重规则和收入或推荐口径。 预期产出：可解释的阶段指标、缺口和待检验的增长假设。 使用边界：五项不必是线性路径，也不自动共用分母。留存需完整观察窗口；不能把付费人数与推荐人数相除，冒充推荐转化率。 工作问题： 期望结果： 已有证据与假设： 未知项与下一项核查： 填写说明：用户群、起止时间、各阶段事件和分母。 1. 口径与观察窗口： 填写说明：渠道、触达目标用户及获客指标。 2. Acquisition 获取： 填写说明：首次获得核心价值的行为与指标。 3. Activation 激活： 填写说明：回访/复用事件、周期和队列。 4. Retention 留存： 填写说明：付费事件、收入指标与阻力。 5. Revenue 收入： 填写说明：分享/邀请事件及真实推荐效果。 6. Referral 推荐： 检查清单 □ 各阶段定义适合本业务。 □ 每阶段都有可量化指标。 □ 优化动作针对真实瓶颈。 考虑下一个框架 As is / To be: 某项指标已有同人群同窗口的基线和目标时，用现状与理想对照明确差距及需要调查的问题。 https://bizthinkframe.com/zh/frameworks/as-is-to-be BizThinkFrame · https://bizthinkframe.com/zh/frameworks/aarrr
跟着案例走一遍
虚构教学案例找到软件增长中的薄弱环节
组织、人物、数据和结果均为虚构，仅用于说明框架用法。
背景与问题
云桥要从增长数据中选择下一轮实验。
团队只追新注册，没有检查后续使用与付费。
手头有哪些材料
- 同一注册批次：200 家注册，60 家激活，24 家次月仍活跃
- 其中 12 家付费，6 家带来有效推荐
如何使用这个框架
- 定义每个阶段的业务事件与观察窗口。
- 24/60=40%只在同批且完整次月观察下成立；计划回访未记录再次协作的团队，不断言永久流失。
- 将推荐视为可能发生在不同阶段的行为，不机械视为线性最后一步。
选择“首次协作后持续使用”作为实验方向，而非立即扩大投放。
60家激活团队中24家次月仍协作，只有同批且观察窗口完整时才构成40%留存率；12家付费团队与6家推荐团队的重叠未知，不能相除当推荐转化率。
相邻数字相除前，先排除三种错误
AARRR用来选择客户问题，每项先定义事件和合格人群。团队、个人、访问、交易是不同单位；卡片排在前面，不表示它一定是后项的前置条件。
三种情况先停：批次或观察窗不一致；跟进尚未完整就判未返回；不知道付费与推荐人群关系，就拿两个数量相除。先检查成员和资格，再计算真正要回答的比例。
原例24/60的留存比较以次月窗口完整为条件。实际追踪还要把“次月”写成准确起止日期。12个付费、6个推荐不能单独说明重叠、净收入或未返回原因。
选择调查问题，不迷信漏斗形状
生命周期摘要可以定位问题，了解任务、定义指标与比较购买历史则各需材料。某窗口没有行为，不等于永久流失。
| 方法 | 输入 | 产出 |
|---|---|---|
| AARRR | 批次成员、事件口径和完整窗口 | 生命周期问题与有依据的比例 |
| KPI树 | 兼容的数量、金额和分母 | 可复算指标拆解 |
| 用户旅程图 | 有归属的任务与触点记录 | 待查体验缺口 |
| RFM | 同规则下的合格购买历史 | 待验证购买行为组 |
完整案例：六个团队全部保留，资格不混算
这是独立虚构六团队批次，不是上方200团队的子样本或估计。T1–T6在2026年8月3–9日注册。激活指注册后完整七天内首次真实协作；留存指激活团队在9月1–30日再次协作。本教学材料这些窗口均已完整。
付费记录指9月内至少一笔支付记录，金额与退款状态未给；推荐指9月内至少带来一个可归属的新团队。计的是推荐者团队，不是新团队数量，新团队也不加回注册批次。支付与推荐两列互不要求对方先发生。
完整台账中，T5、T6未激活，所以对当前留存定义不具资格，不填成留存失败。这不宣称他们以后永远不会协作，而是保留本次口径的分母。
| 团队 | 激活 | 合格者留存 | 支付记录 | 推荐者 |
|---|---|---|---|---|
| T1 | 是 | 是 | 是 | 是 |
| T2 | 是 | 是 | 否 | 是 |
| T3 | 是 | 否 | 是 | 否 |
| T4 | 是 | 否 | 否 | 否 |
| T5 | 否 | 不具资格 | 否 | 否 |
| T6 | 否 | 不具资格 | 否 | 否 |
先算集合，再调查原因
6个中4个激活，保留一位小数为66.7%；4个激活者中2个返回，本定义留存50%。全部6个中2个同时达到激活和留存，是33.3%，回答的是另一问题。T3、T4只是在9月无合格返回记录，不能据此判永久流失。
支付记录者2个、推荐者2个，交集却只有T1。因此支付记录者中的推荐占比是1/2=50%，不是2/2=100%。数量相等不代表成员相同。T2无支付记录却推荐；T3有支付记录却无合格留存事件。这些数量都不能给出收入金额或利润。
结论是先核对成员与分母，再查持续协作。回到原200团队案例，应取得有权使用的实际台账，不能拿这6条替代。确认事件捕获、身份规则、完整窗口和重叠后再接受比例。询问合格未返回团队近期任务与障碍，不预设他们不感兴趣；追踪缺口与确认无事件分开。
若提议改变产品，执行前约定资格、范围、结果窗与复查。保留原批次和口径，追加结果并说明规则变更。持续协作与相关质量、支付资料一起看；某个数增加不证明因果或盈利。卡片提示去哪里查，不自动决定干预。
检查你的思考
再问自己几个问题
- 当前增长卡在获客、激活、留存、收入还是推荐？
- 每个阶段最能代表成功的指标是什么？
- 哪个阶段的改善会带来最大整体收益？
完成前的检查清单
- 各阶段定义适合本业务。
- 每阶段都有可量化指标。
- 优化动作针对真实瓶颈。