指标不是数字，是团队对业务的一份共识
“帮我加个转化率。”
这句话几乎是每个数据开发都听过的需求。听起来很简单：分子除以分母。但真正做下去，问题会一个接一个冒出来：
- 转化率的分母是下单量，还是支付量？
- 分子是支付成功，还是发货完成？
- 时间按创建时间算，还是按完成时间算？
- 退款的单算不算？取消的单算不算？测试单算不算？
- 按天算完再相加，和按区间整体算，为什么对不上？
- 两个页面同一个转化率，为什么差 3%？
指标设计的难，从来不在算术，而在定义。这篇文章不聊代码，只聊怎么把指标设计清楚、设计得能长期维护。
一、先想清楚：指标到底是什么
一个指标，本质上是四个部分的组合：
1 | 指标 = 业务含义 + 统计口径 + 时间范围 + 维度组合 |
缺任何一项，这个数字都不可信：
| 缺什么 | 后果 |
|---|---|
| 业务含义 | 没人知道这个数用来回答什么问题 |
| 统计口径 | 不同人算出不同结果，互相不认 |
| 时间范围 | “昨天”到底指自然日还是滚动 24 小时 |
| 维度组合 | 总数对得上，拆开对不上 |
所以设计指标的第一步不是写查询，而是把一句话需求翻译成一份定义。
二、一个好指标的五个要素
我习惯用五个要素来描述一个指标，缺一不可：
- 名称：业务能看懂的中文名，加一个稳定的英文标识；
- 口径：分子、分母、过滤条件、去重方式；
- 时间：以哪个时间字段为准，按什么粒度聚合；
- 维度：能按哪些维度拆分和筛选；
- 状态：草稿、在用、已下线，避免草稿指标被误用。
这些要素写不清楚，指标就只是一个能跑出数字的查询。
三、指标分三层，不要混在一起
一套健康的指标体系，通常分三层：
| 层级 | 定义 | 例子 |
|---|---|---|
| 原子指标 | 直接数出来的量，不可再拆 | 下单量、支付量、退款额 |
| 派生指标 | 原子指标之间的比率、差值、求和 | 完成率、取消率、营收 |
| 业务指标 | 面向业务的组合口径 | 支付转化率、复购率、客单价 |
三层的关系是：
- 原子指标要少而稳，尽量贴近原始数据；
- 派生指标要可组合，由原子指标计算得出，不直接查库；
- 业务指标是视图，可以随业务变化调整，但底层原子指标不变。
很多团队的问题是把三层混在一起：每个报表各自写一段查询，算出来的“营收”有的含退款、有的不含，最后谁也说不清。
分层的好处是：改业务口径只动最上层，底层数据不动；新增业务指标只是组合，不需要重跑历史。
四、口径设计：细节都藏在“关联”和“排除”里
口径描述看起来是一句话，实际包含五个必须明确的部分。
4.1 分子和分母
比率类指标最容易出错的是“分子分母不是同一批单”。
比如支付率：
- 分子是“支付量”，按支付时间算；
- 分母是“下单量”，按下单时间算。
如果直接按同一个时间窗口分别算再相除，会出现“分母里包含还没支付的单、分子里包含窗口外下的单”的情况。
正确做法是：先按各自的时间口径算出分子分母，再跨时间窗口合并后相除，而不是在同一个窗口里直接除。
4.2 时间字段
每个指标必须明确自己的时间字段：
- 下单量按创建时间；
- 支付量按支付时间；
- 退款额按退款完成时间；
- 支付率可能同时涉及两个时间字段。
每个指标都要写清楚自己的时间字段；比率类指标允许分子分母各用自己的时间字段，但必须分别说明。不要把“全局时间”套到所有指标上。
4.3 过滤条件
哪些单要排除，必须写死并留档：
- 测试单、内部单；
- 已删除、已取消、已作废；
- 特定渠道、特定品类、特定活动；
- 历史遗留的“脏数据”白名单。
这些条件不能散落在各个报表里，必须写进指标定义，由引擎统一执行。
4.4 去重方式
“多少单”和“多少个客户”是两回事：
- 按单据计数，用单据条数；
- 按人去重，用去重计数；
- 按设备、按店铺、按会员，各是一个口径。
去重指标不能简单相加：“城市 A 的客户数加城市 B 的客户数”不等于“全国客户数”，因为有人跨城市。所以去重指标在汇总层要单独重算，不能由明细相加。
4.5 状态与生命周期
同一张订单在生命周期里会变状态：待支付、已支付、已发货、已完成、已取消、已退款。
“待支付量”“待发货量”“完成量”其实是同一个集合在不同状态下的切片。设计时要明确：
- 统计的是“当前状态”，还是“某个时间点之后的状态”；
- 状态变化后，历史区间重算时按哪个状态算。
这也是为什么很多平台选择“删除时不物理删除数据，只打排除标记”——状态和删除都要能回溯，历史口径才能重算、才能解释。
五、时间：指标设计里最容易吵架的地方
时间问题通常集中在三处。
5.1 自然日还是滚动窗口
“昨天”可以是：
- 自然日：00:00 到 23:59；
- 滚动 24 小时：现在往前推 24 小时。
经营报表一般用自然日，实时监控用滚动窗口。两者不能混用，否则日报和实时看板永远对不上。
5.2 时区
统计平台的时间必须是单一时区（比如东八区），并且：
- 存储用时间戳；
- 展示按业务时区；
- 跨时区的数据在写入时就转换好，不要查询时再算。
5.3 同比、环比
环比不是“把两个数相减”这么简单：
- 上月 31 天，本月 30 天，直接比会失真；
- 今天还没过完，和昨天全天比会偏低；
- 闰年 2 月、法定节假日，都会影响口径。
正确做法是：
- 窗口由后端统一计算并回传给前端，前端只负责展示；
- 预置几种标准口径（上一周期、上周、上月、去年同期），不要每个页面自己发明；
- 数据不完整时（比如今天还没结束），要么按同口径截断，要么明确标注“数据未完整”。
六、维度：能拆、能筛、能下钻
维度设计要回答三个问题：
- 能不能拆：按城市、店铺、渠道、品类、会员拆开，指标还成立吗？
- 能不能筛：用户能不能按这些维度过滤？
- 能不能下钻：从汇总数字能不能点到构成它的单据？
三个问题对应三种能力，缺一不可。
6.1 维度要分层
省份、城市、店铺是三层；品类、品牌、SKU 是三层。分层之后：
- 汇总行只算一次，不要每层重复算；
- 下钻按层展开，不要一次把所有层铺平；
- 分组数量多时，用树形结构而不是“每个分组一条查询”。
6.2 维度值要稳定
维度值会变：店铺改名、品类调整、渠道合并。
如果报表直接存“店铺名”，改名后历史数据就和新数据对不上。常见解法：
- 存稳定标识（比如编号），展示时翻译成名称；
- 名称取“当前快照”，历史记录里保留“写入时快照”；
- 改名后提供“新旧名称映射”，让用户能查到历史。
6.3 维度爆炸要控制
“按省份、城市、店铺、渠道、品类、品牌、SKU、活动、来源全部分组”——这种需求真实存在，但一次查出来会爆炸。
处理方式：
- 限制同时分组的维度数量；
- 高频组合做成预聚合；
- 分组多时用“汇总加明细”两层结构，而不是一次展开。
七、命名与版本：让指标可以被引用
7.1 命名规范
- 标识用“动词加对象”，比如下单量、支付量、退款额；
- 中文名要和业务说法一致，不要造词；
- 比率类统一用“率”，金额类统一用“额”，数量类统一用“量”；
- 同一个概念在不同页面必须同名，不能一个叫“成交”，一个叫“完成”。
7.2 口径变更必须版本化
这是最重要的一条：改口径不等于改实现，等于换一个指标。
- 老指标保留，历史报表继续用；
- 新口径用新标识，页面上标注“新口径”；
- 两个口径并行一段时间，等业务确认后再下线旧的。
直接改口径的后果是：昨天的报表今天重算变了，没人能解释，也没人敢用。
7.3 指标要有“血缘”
每个指标应该能回答：
- 它依赖哪些原始表、哪些字段；
- 它被哪些报表、哪些页面引用；
- 修改它会影响谁。
没有血缘，改一个指标就像拆一颗不知道连着哪里的炸弹。
八、指标验收：怎么证明它是对的
指标上线前，至少做四类验证：
- 对账：和原有系统、财务口径、业务手工统计对一遍，允许的差异要能解释；
- 边界：空数据、单条数据、跨月、跨年、时区边界、闰年；
- 一致性：汇总等于明细之和（可加指标）；去重指标单独验证；
- 下钻：指标点开明细，条数和金额能对上；对不上要明确“不支持下钻”，而不是给错的数据。
九、指标治理：让体系能活下去
指标不是写完就结束了，它需要持续治理：
- 指标字典：每个指标一行，写清楚名称、口径、时间、维度、状态；
- 变更流程：新增走注册，修改走评审，下线要公告；
- 定期盘点：哪些指标没人用、哪些指标口径重复、哪些指标该合并；
- 权限与范围：谁能看哪些维度、哪些店铺，必须在指标层就约束，不能只靠前端隐藏。
一个常见的反模式是：指标字典是一份文档，实现是另一套逻辑，两边长期不同步。解决办法是让字典和实现同源：新增指标必须同时更新字典，评审时对照检查。
十、十个常见坑
- 分子分母时间口径不一致：同一个窗口分别算再除，结果偏高或偏低。
- 去重指标直接相加：跨维度汇总后人数变多。
- 环比窗口前端自己算：跨月、今天没过完，一定跑偏。
- 物理删除而不是打标：历史报表重算后数字变了。
- 空筛选被当成“不筛选”：权限范围为空时反而返回全量。
- 维度值存名称而不是标识：改名后历史数据对不上。
- 口径散落在报表里：同一个指标多个实现，没人说得清谁对。
- 改口径不版本化：老报表数字悄悄变化。
- 只测总数不测下钻：指标和明细条件不一致。
- 没有状态标记：草稿和正式指标混用，没人知道哪个能用。
十一、一张指标定义模板
新增指标时，可以按这张表填写，填不满就说明还没想清楚：
| 项 | 说明 |
|---|---|
| 中文名 | 业务能看懂的名字 |
| 英文标识 | 稳定、唯一、可引用 |
| 业务含义 | 回答什么业务问题 |
| 类型 | 原子 / 派生 / 业务 |
| 时间字段 | 以哪个时间为准 |
| 分子 | 统计什么 |
| 分母 | 比率类指标的分母 |
| 过滤条件 | 排除哪些单、哪些状态 |
| 去重方式 | 按单 / 按人 / 按设备 |
| 支持维度 | 可拆分、可筛选的维度 |
| 是否支持下钻 | 支持则说明下钻条件 |
| 状态 | 草稿 / 在用 / 已下线 |
十二、结语
设计指标，表面是在写定义，实际是在对齐认知。
一个好的指标，应该让业务、研发、财务看到同一个数字时，不用再问“这个数怎么来的”；也应该让三年后的接手者，能从一份文档里还原出当时的判断。
指标设计得好，统计平台才有地基；指标设计得糊，再快的查询、再漂亮的看板，也只是把分歧放大。