指标定义

如何定义一个可度量、可归因、难被刷的指—一切分析工作的地基

为什么

指标是决策的计量单位。单位错了，由此衍生的每个决策都错，无论分析多精巧。多数分析失败不是数学失败而是定义失败：把机器人算作注册的"signup"、把页面加载算作活跃—active user"、把退款重复计算的"conversion"。好的指标定义强制团队在报出任何数字前先明确分子、分母、时间窗口、排除规则和已知边界情况。这笔前置成本正是六个月后有人问"为什么收入跌—时指标可信的根源。没有书面定义，每个团队成员用不同方式计算同一指标，仪表盘显示的是最后一个工程师实现的那一版

何时使用

在埋点或建仪表盘之前。当商业模式变化、指标被刷、或跨团队数字偏差超 5% 时重新定义

如何做

1. 用平实语言命名指标—Daily Active Users"不是定义—过去 24 小时内执行至少一次核心动作的去重用户—才是
2. 明确分子：哪些事件算、按 user_id 去重、排除内—测试账号
3. 明确分母：若是比率，基线人群和时间窗口是什—4. 列出排除项：机器人流量、测试账号、退款订单、员—5. 写出计算它的 SQL 或事件查询，钉在版本化指标字典里
6. —3 个已知边界情况及处理方式（如用户跨午夜时区边界）
7. 让被该指标考核的团队签—他们会找到你漏掉的刷量路—8. 加单元测试在固定数据集上断言该指标，捕获回归

示例

# 指标：激活率
负责人：@growth-lead  版本—.1  最近复核：2026-09-15

分子：注册后 7 天内创建并部署了项目的用—分母：同一队列注册用户（排除测—机器人账号）
时间窗口— 天滚动，—signup_time + 7d 评估
排除：邮箱域—(test.dev, example.com)、user_id < 1000（内部）

SQL—  SELECT
    count(DISTINCT a.user_id) AS activated,
    count(DISTINCT s.user_id) AS total,
    count(DISTINCT a.user_id)::float / count(DISTINCT s.user_id) AS rate
  FROM signups s
  LEFT JOIN activations a ON a.user_id = s.user_id
    AND a.activated_at <= s.signup_at + interval '7 days'
  WHERE s.email_domain NOT IN ('test.dev','example.com')
    AND s.user_id >= 1000

边界情况—  - 用户部署后删除项目：仍算（部署事件已触发—  - 用户 23:59 UTC 注册：窗口为 signup_at + 7d（UTC），非本地时—  - 用户用两个浏览器：按 user_id 去重，非 cookie

单元测试：fixtures/activation_rate.sql —1000 行样本上断言 rate = 0.421

常见问题

⚠用实现而非意图定义指标 —"DAU 是查询返回的—意味着每次有人改查询指标就漂移，且无人察觉因为没有定义可对照
⚠在生产指标里算机器人和测试账—15% 的机器人膨胀 DAU 并让每个 A/B 测试看起来更显著，导致上线实际不移动人类指标的改动
⚠把虚荣指标（总注册、页面浏览）当北极星 —它单调上升与产品质量无关，只能告诉你时间在流逝，不能告诉你产品在变好还是变坏
⚠指标定义无版—SQL 改了历史数字被追溯改写，团队失去本月与上月对比的能力因为定义是移动靶

最佳实践

✓维护版本化指标字典（单一仓库文件—Notion 页），每个指标有负责人、定义、SQL 查询和最近复核日—这是防止"哪个 DAU—争论的唯一事实源
✓为每个指标在冻结 fixture 数据集上加单元测试，使改写数字的 SQL 变更—CI 中被捕获 —测试是让定义有约束力的东西
✓每季度与被考核团队复核每个指标定义 —他们会提出定义负责人未预见的刷量路径—部署空项目算激活吗—）
✓在字典中区分计数器指标（累积、单调）与比率指标（有界、可跨时比较）—混用导致"总注册涨 10%"的标题只是时间在流逝