4. 命名规范与定义：指标命名规范、业务口径定义、技术口径定义

这一章，我们聊聊指标体系的「地基」——命名与定义。

很多团队做指标治理，上来就建表、写SQL、搭看板。结果呢？一个月后，业务问「这个GMV怎么跟财务对不上」，技术说「我按需求文档写的啊」，产品挠头「口径好像变了」……

嗯，这种场景我见过太多次了。说白了，问题就出在命名和定义上——没有规矩，不成方圆。

4.1 指标命名规范：让名字自己会说话

我个人的习惯是：一个好的指标名，应该让一个刚入职的同事看到后，能猜出它大概是什么意思。不需要查文档，不需要问人。

举个例子：

• 错误命名：sale_amt_01、data_v2、指标A
• 正确命名：dwd_trd_gmv_di（交易域-商品-日累计GMV）

我在项目中遇到过最离谱的命名是「最终版_v3_真的不改了」。你想想看，这种名字谁敢用？

4.1.1 命名规范四要素

要素	说明	示例
业务域	指标所属的业务板块	trd（交易）、usr（用户）、mkt（营销）
度量对象	具体衡量的实体或事件	gmv（成交额）、ord_cnt（订单数）
统计周期	数据的时间粒度	d（日）、w（周）、m（月）、y（年）
聚合方式	数据的计算逻辑	sum（求和）、avg（平均）、cnt（计数）

4.1.2 命名规范检查清单

• 是否包含业务域前缀？
• 度量对象是否使用标准词根？
• 统计周期是否明确？
• 聚合方式是否清晰？
• 是否避免使用拼音、缩写、数字序号？
• 是否与已有指标名冲突？

4.2 业务口径定义：让业务和技术说同一种语言

业务口径，说白了就是「这个指标在业务上到底是什么意思」。

我见过最典型的冲突：运营说「活跃用户」是「7天内登录过的用户」，产品说「活跃用户」是「30天内有过购买行为的用户」。两个部门开会，吵了一下午才发现口径不一样。

4.2.1 业务口径模板

我建议每个指标都按这个模板来定义：

指标名称：日活跃用户数（DAU）
业务定义：当天0点至24点内，至少有一次有效登录行为的独立用户数
包含范围：
  - 通过APP、小程序、Web端登录的用户
  - 第三方账号（、QQ）授权登录的用户
排除范围：
  - 爬虫、机器人的登录行为
  - 测试账号
  - 内部员工账号
计算逻辑：按user_id去重计数
特殊说明：
  - 同一用户多端登录，只算1次
  - 跨天登录，每天分别计算

4.3 技术口径定义：把业务语言翻译成技术语言

技术口径，就是业务口径的「技术实现方案」。它要回答的问题是：这个指标的数据从哪里来？怎么算？用什么字段？

我个人的经验是：技术口径写得越细，后期排查问题越省力。你想想看，一个指标跑出来数据不对，如果技术口径里写清楚了「取数逻辑」「过滤条件」「关联关系」，排查起来就是几分钟的事。否则，你可能要翻半天代码。

4.3.1 技术口径模板

指标名称：日活跃用户数（DAU）
数据源：dwd_usr_login_di（用户登录事实表）
取数字段：user_id
过滤条件：
  - login_time BETWEEN '当天00:00:00' AND '当天23:59:59'
  - is_robot = 0
  - is_test = 0
  - is_internal = 0
聚合逻辑：COUNT(DISTINCT user_id)
关联关系：无
调度依赖：dwd_usr_login_di 每日凌晨2点产出
数据校验：
  - 与昨日DAU波动不超过±20%
  - 与周同比趋势一致

4.3.2 业务口径 vs 技术口径

维度	业务口径	技术口径
受众	业务人员、产品经理	数据开发、数据分析师
语言	业务术语、自然语言	技术术语、SQL、字段名
粒度	宏观、概念性	微观、可执行
变更频率	低（业务逻辑变化时）	中（数据源、ETL逻辑变化时）
维护人	业务方 + 产品	数据开发 + 数据治理

4.4 知识体系总览

下面这张图，把命名规范、业务口径、技术口径的关系串起来了。你可以把它当作指标定义的「全景地图」。

4.5 实战建议：从0到1建立规范

如果你所在团队还没有指标命名和定义的规范，别急着一口气全做完。我建议分三步走：

1. 先抓核心指标：挑出业务最常用的20个指标，把命名和口径规范起来。别贪多，20个够了。
2. 形成模板文档：用本章的模板，把每个指标的命名、业务口径、技术口径写清楚。文档要放在团队都能看到的地方。
3. 建立评审机制：新增或修改指标，必须经过评审。评审人包括业务方、数据开发、数据治理。我曾经见过一个团队，评审会开了三次才把「复购率」的口径定下来——但之后再也没有因为口径问题吵过架。