Back to Details

know-if-its-working

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Know if it's working

判断市场推广是否奏效

The only early metric that matters is net developer retention. Without it, you're not running a funnel; you're running a colander.
Use this when: you're tracking GitHub stars and pageviews and still can't answer "is GTM working?", or you're pouring effort into acquisition while new users quietly churn.
早期唯一重要的指标是net developer retention（净开发者留存率）。没有它，你运营的不是漏斗，而是漏勺。
适用场景： 你一直在追踪GitHub星标数和页面浏览量，却仍无法回答“GTM是否奏效？”；或是你在获客上投入大量精力，新用户却悄悄流失。

The core idea

核心思路

Acquisition is worthless if users don't come back. Prove retention first; only then does spending on acquisition make sense. Most early founders optimize the top of the funnel while the bottom leaks. Fix that order.
如果用户不会回头，获客毫无意义。先证明留存率达标；只有这时，在获客上投入才合理。大多数早期创始人会优先优化漏斗顶部，却忽略底部的流失漏洞。请调整这个顺序。

Framework: net developer retention (Frankl)

框架：net developer retention（Frankl提出）

Of all the developers who first used the product in Month 1, how many used it in Month 2? Month 3?
  • Hold it above 100% (meaning existing cohorts grow through internal referral/expansion).
  • Below solid retention, do not focus on acquisition: you're filling a leaky bucket.
  • This single cohort question tells you more than every vanity chart combined.
在第1个月首次使用产品的开发者中，有多少人在**第2个月？第3个月？**仍在使用？
  • 需将该指标保持在100%以上（意味着现有用户群通过内部推荐/功能拓展实现增长）。
  • 若留存率未达标，不要聚焦获客：你只是在给漏勺灌水。
  • 这一个用户群问题所反映的信息，胜过所有虚荣指标图表的总和。

Framework: the DREAM metrics (Frankl)

框架：DREAM指标（Frankl提出）

Measure one honest number per stage, not pageviews, not stars.
StageThe metric that counts
Discoveryunique human visitors / month
Researchnewsletter subs + community joins + follows
Evaluationfree-tier signups / downloads / active free users
Activationmonthly active users · frequency · session depth
Membershipcommunity members actively posting & answering
The gate before all of it, the weekend test: can a new developer get to first value over a weekend from docs + Stack Overflow, no support call? Time-to-value target: < 1 hour ideal, 1 day max. If Evaluation/Activation fails here, no channel work will save you.
每个阶段只衡量一个真实指标，而非页面浏览量或星标数。
阶段关键衡量指标
Discovery（发现）月度独立访客数
Research（调研）邮件订阅数 + 社区加入数 + 关注数
Evaluation（评估）免费版注册数 / 下载量 / 活跃免费用户数
Activation（激活）月活跃用户数 · 使用频率 · 会话深度
Membership（会员）积极发帖和答疑的社区成员数
所有环节的前置门槛：周末测试：新开发者能否仅通过文档+Stack Overflow，在周末完成首次价值实现？Time-to-value（价值实现时间）目标：理想<1小时，最长1天。如果评估/激活环节在这一步失败，任何渠道运营都无法挽救。

Growth benchmarks (non-ARR, Frankl)

增长基准（非ARR，Frankl提出）

  • Pre-seed: ~30% month-over-month user growth
  • Post-Series-A: ~10% MoM
  • First $1M ARR: within 12 months is good, 9 is excellent
  • 种子轮前：月用户增长率约30%
  • A轮后：月增长率约10%
  • 首个100万美元ARR：12个月内达成算良好，9个月内达成算优秀

Framework: attribution philosophy (Czakon)

框架：归因理念（Czakon提出）

Developer marketing is hard to attribute and that's normal. A dev sees your HN post, reads a tutorial, lurks for two months, then signs up direct.
  • Don't over-trust last-touch; it will tell you "direct/organic" and hide the real work.
  • Add a "how did you hear about us?" free-text field. Self-reported attribution beats a broken model.
  • Judge channels on trend and directional signal, not spurious precision.
开发者营销难以精准归因，这是正常现象。开发者可能看到你的HN帖子、阅读教程，潜伏两个月后直接注册。
  • 不要过度依赖最后触点归因：它只会显示“直接/自然流量”，掩盖真正有效的工作。
  • 添加一个“你是如何了解到我们的？”自由文本字段。自我报告的归因比失效的模型更可靠。
  • 基于趋势和方向性信号判断渠道效果，而非追求虚假的精准度。

Decision tree: what to fix first

决策树：优先修复什么

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.
第2个月用户群留存率是否健康（用户会回头）？
├─ 否  → 停止优化获客。修复评估/激活环节（周末测试、Time-to-value）。
└─ 是 → 是否有渠道持续带来留存用户？
         ├─ 是 → 加大投入（且仅在此时考虑付费投放放大效果）。
         └─ 否  → 回归前50个用户阶段；找到有效渠道后再扩大投入。

Mistakes that look reasonable

看似合理的错误做法

  • Vanity metrics: stars, pageviews, impressions. They feel like progress and predict nothing.
  • Acquisition over a leaky bucket: buying users who never return.
  • Demanding clean attribution: chasing a perfect model instead of acting on directional signal.
  • Ignoring the weekend test: a beautiful funnel that dies at first-value.
  • 虚荣指标：星标数、页面浏览量、曝光量。它们看似代表进展，却无法预测任何结果。
  • 漏勺式获客：获取不会回头的用户。
  • 追求完美归因：执着于构建完美模型，而非基于方向性信号采取行动。
  • 忽略周末测试：漏斗看似完美，却在首次价值实现环节夭折。

Your next 30 minutes

接下来30分钟可做的事

  • Compute one number: of the devs who first used it 8 weeks ago, what % used it in the last 2 weeks?
  • Pick one honest metric per DREAM stage; delete the vanity charts from your dashboard.
  • Time yourself doing your own onboarding cold. Over an hour? That's your #1 GTM problem.
  • Add a "how did you hear about us?" field to signup this week.
Built from real dev-tool GTM experience, with frameworks from Adam Frankl (The Developer-Facing Startup) and Jakub Czakon (markepear.dev). When a framework can't make the call, that's what a human is for: The DevTool GTM Company.
  • 计算一个数据：8周前首次使用产品的开发者中，有多少比例在过去2周仍在使用？
  • 为DREAM的每个阶段选择一个真实指标；从仪表盘中删除所有虚荣指标图表。
  • 模拟新用户体验自己的注册流程。耗时超过1小时？这就是你当前最大的GTM问题。
  • 本周在注册流程中添加“你是如何了解到我们的？”字段。
基于真实开发者工具GTM经验构建，框架来自Adam Frankl（《面向开发者的创业公司》）和Jakub Czakon（markepear.dev）。 当框架无法做出判断时，就需要专业人士介入：The DevTool GTM Company。