指标体系设计原则：原子指标与派生指标、业务过程与维度、指标命名规范与口径统一

指标字典搭建，最怕什么？

怕口径对不上，怕同名不同义，怕业务方和开发吵起来。

我做了这么多年数据架构，见过太多团队在指标上栽跟头。说白了，问题根源就一个——设计原则没定死。今天咱们就把这几个核心原则掰开揉碎讲清楚。

原子指标与派生指标：指标的「基因」与「变体」

先问个问题：你觉不觉得，很多指标其实长得像亲戚？

比如「当日订单金额」和「当月订单金额」，本质都是「订单金额」，只是时间范围不同。这就是原子指标和派生指标的关系。

我在项目中遇到过最典型的坑：业务方说「我要看转化率」，结果开发做了个「支付用户数/访问用户数」，业务方却说「不对，我要的是支付用户数/加购用户数」。你看，原子指标没定清楚，派生指标全是扯皮。

类型	定义	示例	是否可复用
原子指标	不可再拆分的业务度量	支付金额、下单用户数	是，全局唯一
派生指标	原子指标 + 维度 + 业务限定	2024年Q1北京地区男性用户的支付金额	按需创建，避免冗余

业务过程与维度：指标的「骨架」与「血肉」

你想想看，指标不是凭空产生的。它一定依附于某个业务动作。

用户下单，这是一个业务过程。下单发生在哪个渠道？哪个商品？哪个时间？这些就是维度。

我习惯把业务过程比作「骨架」，维度比作「血肉」。骨架决定了指标从哪里来，血肉决定了指标怎么切分。

举个例子。业务过程是「用户支付」，那原子指标就是「支付金额」。维度可以是「支付渠道（/支付宝）」「支付时间（小时/天/月）」「用户等级（普通/VIP）」。你看，一个原子指标，配上不同维度，能衍生出几十个派生指标。

为什么会这样？因为维度是有层级的。核心维度（时间、渠道、用户）几乎每个指标都要用，非核心维度（天气、营销活动）只有特定场景才用。混在一起，就是灾难。

指标命名规范与口径统一：别让「同一个指标」变成「两个世界」

我见过最离谱的事：同一个「GMV」，运营部算的是「支付成功金额」，财务部算的是「已到账金额」，差了整整一个「退款」的坑。两个人拿着报表吵架，最后发现口径不一样。

所以，命名规范和口径统一，是指标字典的「宪法」。

命名规范：一看就懂，不用猜

我个人习惯用这套规则：

命名格式：[业务域]_[业务过程]_[原子指标]_[统计周期]_[维度限定]

示例：
- order_pay_amount_daily          —— 订单支付金额（日）
- user_login_count_weekly         —— 用户登录次数（周）
- product_refund_rate_monthly     —— 商品退款率（月）

组成部分	说明	示例值
业务域	所属业务线	order, user, product
业务过程	具体动作	pay, login, refund
原子指标	核心度量	amount, count, rate
统计周期	时间粒度	daily, weekly, monthly
维度限定	可选，特殊场景	channel_wechat, city_beijing

口径统一：把「潜规则」变成「显规则」

口径不统一，本质是「定义权」没归属。我建议每个指标都要有口径文档，包含：

• 指标定义：一句话说清楚这个指标算什么。
• 计算公式：分子分母分别是什么，数据源从哪里取。
• 排除规则：哪些数据不算？（比如测试订单、内部员工订单）
• 更新频率：T+1还是实时？

举个例子：

指标名称：order_pay_amount_daily
定义：每日支付成功的订单金额总和
计算公式：SUM(pay_amount) WHERE pay_status = 'success' AND date = 当前日期
排除规则：排除测试订单（order_type = 'test'）、退款订单（refund_status != 'full'）
数据源：dwd_order_pay_di
更新频率：T+1 凌晨2点

知识体系总览

下面这张图，把今天讲的核心逻辑串起来了。你可以把它当成指标字典设计的「导航图」。