指标需从目标推导而非从可采集数据出发
别名: 目标推导指标 · Goals-Signals-Metrics · 自下而上指标
概念解释
目标推导的指标（goal-derived metrics）从“我们要判断什么已经发生”往下找观察，而不是从日志里已有的字段往上找用途。Goals–Signals–Metrics（GSM）的第一跳是目标：先写下成功长什么样，再问什么现象能指示它，最后才指定计数规则。从可采集数据出发的路径相反：因为点击流、停留时长、推送到达已经在库里，就让它们成为“体验指标”。能采集不等于值得判断。
机制
埋点体系按工程便利生长：事件在开发时被加上，字段按存储成本取舍，报表按现成聚合生成。这条供给链不经过目标。结果是仪表盘上堆满回答过时问题的数字，真正要判断的目标——例如“值班医生能在两分钟内找到患者过敏信息”——可能没有任何对应字段。自下而上还会锁定后续设计：既然时长可采，优化就变成加长会话；既然打开率可采，优化就变成把入口做红。目标一旦后置，产品会被数据供给塑造，而不是被要回答的问题塑造。GSM 把推导方向反过来，是为了让缺失的观察暴露出来：目标写得清楚、现有数据接不上，就应该补采集或改目标，而不是改用一个碰巧能画图的字段。
怎么研究
把现行仪表盘上的每个指标回溯到它声称服务的目标；画不出目标的标为无主。对每个真实目标做一次“若只有现有数据，能否区分达成与未达成”，记录缺口。比较两种方案生成过程：一组先写目标再选指标，一组先列可采字段再贴目标，看后者有多少目标是事后贴上去的。也可以做决策回放：一次发布评审里被引用的指标，有多少能在会前的目标清单里找到对应项。
边界
早期探索可以先看现有日志，用来发现目标本身应该是什么；那是问题形成，不是度量方案。合规、性能、事故监测等工程指标可以不从体验目标推导，但它们也不应被改名为体验成功。目标推导不保证目标选得对；选错目标再严谨往下推，只会精密地走偏。数据平台的限制会迫使暂时使用次优指标，此时要标明“代理、待补”，而不是把将就写成原则。
怎么落地
- 先用一句话写本周期要判断的成功，禁止以“我们有哪些数”开会。
- 每个目标下面只允许出现为它服务的指标；现成字段对不上就记为缺口，而不是改写目标去迁就字段。
- 新建埋点必须附带它所服务的目标；无目标的事件不得进入体验报表。
- 季度清理：指标能指向目标的保留，只能指向“因为能采”的下线。