用途：当仪表盘上堆满 GitHub stars 和页面浏览量，却仍无法回答“GTM 是否有效”时，用这套方法衡量真正重要的指标。核心观点是：获客在用户不回流时毫无价值，应先证明留存，再考虑投入获客。
主要能力：
- 净开发者留存（Frankl）：统计第 1 个月首次使用产品的开发者中，第 2、3 个月仍使用的比例，目标保持在 100% 以上（老用户群通过推荐或扩展增长）。留存不达标时不应聚焦获客。
- DREAM 指标（Frankl）：每个阶段只测一个诚实数字——Discovery 用每月独立真人访客；Research 用 newsletter 订阅、社区加入、关注数；Evaluation 用免费层注册/下载/活跃免费用户；Activation 用月活、频率、会话深度；Membership 用社区中活跃发帖与回答的成员数。
- 周末测试：新开发者能否仅靠文档和 Stack Overflow，在一个周末内、无需支持电话就达到首次价值。目标时间到价值理想小于 1 小时，最多 1 天。
- 增长基准（非 ARR，Frankl）：种子前约 30% 月环比用户增长；A 轮后约 10% MoM；首个 100 万美元 ARR 在 12 个月内算好，9 个月算优秀。
- 归因理念（Czakon）：开发者营销难以归因是正常的，不要过度信任最后触点；增加“你怎么听说我们的？”自由文本字段，用自报归因替代失真的模型，按趋势和方向性信号判断渠道。
- 决策树：若第 2 个月留存不健康，停止优化获客，先修 Evaluation/Activation；若健康，看是否有渠道稳定带来留存用户，有则加码，无则回到前 50 个用户找渠道。
使用方式：先算一个数字——8 周前首次使用的开发者中，过去 2 周仍使用的比例；为每个 DREAM 阶段选一个诚实指标，删除虚荣图表；亲自冷启动走一遍 onboarding 并计时；本周在注册页加“你怎么听说我们的”字段。
适用场景：早期开发者工具或技术产品的 GTM 评估、留存诊断、渠道判断。
限制：资料未提供具体安装命令、代码示例、收费或价格信息；框架来自 Adam Frankl 与 Jakub Czakon，实际效果因产品而异。