指标体系与埋点

没有指标体系的团队会陷入两难：要么「数字一堆但没人知道看哪个」，要么「只有一个总数字却解释不了变化」。本篇讲三件事：用指标树把北极星目标拆解成可下钻的体系、用「指标三性」判断指标本身好坏、用埋点规范保证指标「造得出来且口径稳定」。

分工说明：产品方向·产品指标与增长讲指标如何服务增长决策（AARRR、留存曲线、健康度），本页偏数据侧：指标体系的构建逻辑与埋点/口径落地，两篇互为表里。

指标树：从北极星到可执行

三层结构

层级	作用	例子
北极星（OSM 的 Objective）	全公司唯一指向增长的指标	周活跃用户数
过程指标	描述转化链路与健康度，可分层	注册转化率、次周留存
下钻维度	解释差异来源、定位问题	按渠道 / 版本 / 用户分层拆分

指标树构建步骤

1. 定北极星（要能代表「为用户创造的价值」，见产品方向的北极星指标讨论）；
2. 画出从获客到留存的主干链路，每段放一个过程指标；
3. 为每个过程指标想清可下钻的维度（渠道、设备、版本、新老客…）；
4. 只保留与决策相关的指标——每条链路 3~5 个足矣，指标不是越多越好。

拆解示例（某内容产品的周活跃）

周活跃用户数
├── 新增：新用户数 × 次日留存率（按渠道 / 投放素材下钻）
├── 召回：沉默用户唤醒率（按沉默天数分层下钻）
└── 存量：老用户活跃天数 / 周（按内容消费深度下钻）

用加法/乘法等式表达树（周活 = 日活用户 × 人均活跃天数）能同时拿到解释力：某个叶子变化时，可沿链路上推归因。

指标好坏三性（每个指标都过一遍）

性质	问法	反面例子
敏感	真正变差时它会不会立刻反映	用「30 天活跃」当北极星，短期恶化被稀释
抗操控	团队是否有动机、有手段刷高它	用「曝光量」考核，刷量就能达标
可解释	变化能否自然归因到动作	直接看总 GMV，说不清是客单还是流量变了

凡考核都逃不过Goodhart 定律：指标一旦成为目标就会失真。因此关键指标要配护栏指标（如增长的同时看取消订阅率）。

埋点：让指标造得出来

事件命名规范

规范	例子
小写下划线 + 动词对象	item_click、order_submit
事件=行为，不做形容词	用 video_play 而非 video_played
属性扁平化、值受控	渠道枚举 {seo, ad, invite}，别自由填写

事件三要素自查

• when：触发时点明确（点击即发 vs 曝光后 X 秒）；
• where：公共属性（uid、设备、版本、时间戳）打全，便于后续按任意维度拆分；
• what：业务属性只放该事件真正需要的字段，别把整页数据全塞进来。

埋点验收：上线前必答

1. 采集属性与指标体系里定义的口径字段一一对应？
2. 测试环境里该事件能稳定触发、无重复发送？
3. 版本升级或新旧端并行时，事件协议是否向后兼容？

口径一致性：让数字能对得上

• 每个指标有唯一权威定义并成文（写清：分子、分母、去重键、窗口、时区、异常处理），发布为指标字典；
• 指标字典与埋点事件建立引用关系：改动埋点时能定位受影响指标；
• 复盘/取数时数字对不上，先查口径版本，再查数据（流程见SQL 与取数）。

常见坑速查

坑	表现	应对
指标树失衡	只盯着北极星，无法归因	树要能沿链路下钻归因
指标堆砌	指标库上百个没人维护	只保留「会触发决策」的指标
埋点口径漂移	改版后新旧端数字不齐	协议兼容、字典成文、回归验收
事件名即「结论」	叫 click_quality_good 的埋点	事件只记事实，质量由分析得出结论
属性乱填	渠道自由输入导致无法分组	枚举受控 + 数据校验
缺护栏指标	增长指标涨但质量崩了	关键指标配护栏

检查清单

• [ ] 指标树可沿链路逐层下钻，叶子维度能解释北极星变化
• [ ] 每个关键指标通过「敏感 / 抗操控 / 可解释」三性检查
• [ ] 事件命名符合规范，三要素（when/where/what）齐备
• [ ] 埋点上线前完成口径对照与触发验收
• [ ] 指标字典成文，与埋点事件建立引用关系
• [ ] 关键指标配了护栏指标

相关：SQL 与取数 · 分析工作流 · 指标服务增长决策见产品·产品指标与增长 · 指标考核副作用见项目管理·度量与复盘