know-if-its-working

确认产品是否有效

早期唯一重要的指标是净开发者留存率。没有这个指标，你做的就不是漏斗，而是漏勺。

**适用场景：**你一直在追踪 GitHub 星标和页面浏览量，却依然无法回答“GTM 是否有效？”，或者你把精力都投入到获客上，而新用户却在悄悄流失。

核心理念

如果用户不再回来，获客就毫无价值。先证明留存率，只有这样，投入获客才有意义。大多数早期创始人都在优化漏斗顶部，却任由底部不断漏水。先后顺序要调整过来。

框架：净开发者留存率（Frankl）

首次在第 1 个月使用产品的开发者中，有多少人在第 2 个月、第 3 个月继续使用？

• 将其保持在100% 以上（这意味着现有用户群通过内部推荐／扩张而增长）。
• 如果留存率不够稳健，就不要专注于获客：你只是在往一个漏水的桶里加水。
• 这一个关于用户群的问题，比所有虚荣指标图表加起来都更有价值。

框架：DREAM 指标（Frankl）

每个阶段衡量一个真实的数字，而不是页面浏览量或星标。

阶段	重要指标
发现	每月独立访客数（真人）
研究	新闻邮件订阅数 + 社区加入人数 + 关注者数
评估	免费套餐注册数／下载数／免费用户活跃数
激活	月活跃用户数 · 使用频率 · 会话深度
成员参与	社区中积极发帖和回答问题的成员数

**贯穿所有阶段的门槛：周末测试。**新开发者能否通过文档 + Stack Overflow，在一个周末内获得首次价值，**而无需联系支持人员？**目标价值实现时间：理想情况为 < 1 小时，最长 1 天。如果评估／激活阶段在这里受阻，再怎么做渠道营销也无济于事。

增长基准（非 ARR，Frankl）

• **种子轮前：**用户环比增长约 30%
• **A 轮后：**月环比（MoM）增长约 10%
• **首个 $1M ARR：**12 个月内实现算不错，9 个月则很出色

框架：归因理念（Czakon）

开发者营销难以归因，这很正常。开发者看到你的 HN 帖子，读了一篇教程，潜水两个月，然后直接注册。

• 不要过度相信末次触点归因；它会告诉你“直接／自然流量”，却掩盖了真正的投入。
• 添加一个**“你是如何知道我们的？”**自由文本字段。用户自报的归因信息胜过有问题的模型。
• 根据趋势和方向性信号评估渠道，而不是追求虚假的精准度。

决策树：先解决什么问题

Is month-2 cohort retention healthy (users come back)?
├─ NO  → STOP optimizing acquisition. Fix Evaluation/Activation (the weekend test, time-to-value).
└─ YES → is a channel reliably producing retained users?
         ├─ YES → pour more in (and only now consider paid to amplify).
         └─ NO  → go back to first-50-users; find the channel before scaling spend.

看似合理的错误做法

• 虚荣指标：星标、页面浏览量、展示量。它们让人感觉取得了进展，却毫无预测价值。
• 往漏水的桶里获客：花钱吸引永远不会回来的用户。
• 强求准确归因：追求完美模型，而不是根据方向性信号采取行动。
• 忽略周末测试：精心设计的漏斗，却在用户获得首次价值时就失效。

接下来 30 分钟

• 算出一个数字：8 周前首次使用产品的开发者中，有多少百分比在最近 2 周内使用过？
• 为 DREAM 的每个阶段选定一个真实指标；从仪表板中删除虚荣指标图表。
• 亲自从零开始计时完成新手引导流程。超过 1 小时？这就是你最大的 GTM 问题。
• 本周在注册流程中添加一个“你是如何知道我们的？”字段。

---

内容基于真实的开发者工具 GTM 经验，以及 Adam Frankl（The Developer-Facing Startup）和 Jakub Czakon（markepear.dev）的框架。 如果你的数据讲述着一个你看不懂的故事，找个人一起看看。欢迎通过 LinkedIn 联系我。