03 · 指标体系建模方法论：指标怎么定义和分类

这一章是"需求设计"的核心——在建平台之前，先要把"指标"这件事本身建模清楚。

3.1 指标分类：原子 / 派生 / 复合

快手、火山引擎、美团采用了业界通行的三类指标划分（来源：快手指标中台技术分享）：

类型	定义	构成
原子指标	最基础的度量，不可再拆	业务过程 + 实体 + 度量
派生指标	原子指标 + 维度修饰/时间周期	原子指标 + 时间周期 + 修饰词
复合指标	多个指标的公式计算	指标之间的四则运算

一个贯穿全书的例子（快手，活跃设备）：

• 原子指标：活跃设备个数 = 业务过程（活跃设备）+ 实体（设备）+ 度量（个数）
• 派生指标：最近 1 天活跃设备个数、未来第 7 天留存活跃设备个数（给原子指标加时间周期/修饰词）
• 复合指标：7 日活跃设备留存率 = 未来第 7 天留存活跃设备个数 ÷ 最近 1 天活跃设备个数

这个三层结构是理解整个指标平台的关键：原子指标管口径，派生指标管维度扩展，复合指标管计算。

3.2 OSM 框架：指标体系怎么搭

快手采用互联网行业常用的 OSM 指标框架（来源：快手指标中台技术分享）：

• O（Objective，目标）：业务要达成的目标；
• S（Strategy，策略）：达成目标采取的策略；
• M（Measurement，度量）：衡量策略效果的指标。

OSM 帮助把"业务目标"逐层拆解为"可量化的指标"，避免拍脑袋建指标、指标脱离业务目标。

3.3 指标命名规范：解决"同义不同名"

指标标准化命名，是让"同一含义/口径的指标获得唯一命名"的关键手段（来源：快手指标中台技术分享）。

命名公式（以活跃设备为例）：

原子指标命名 = 业务过程 + 实体 + 度量
  例：活跃设备 + 设备 + 个数 = 活跃设备个数

通过扩展时间周期词 + 修饰词，得到派生指标的标准命名。命名规范直接解决了"同义不同名"问题——含义相同的指标，按规范命名后必然同名。

3.4 词根管理：解决"一词多义"

火山引擎 DataLeap 在幸福里的实践暴露了一个细节问题（来源：火山引擎 DataLeap 分享）：

录入指标过程中发现：一个中文名称有多个英文名称，或一个英文名称在不同业务线下有不同中文含义。

解决方案是词根管理：录入指标前，先在词根管理的字段管理模块查关键字是否已存在，将核心字段命名规范化，避免命名不一致。

词根管理的本质是建立一个业务术语 → 标准命名的受控词典，它是"指标唯一性"的地基。

3.5 业务口径 vs 技术口径：两类人的分工

幸福里的实践把"口径"拆成两层，由不同角色维护（来源：火山引擎 DataLeap 分享）：

口径	含义	维护角色
业务口径	指标的业务定义、分类	业务人员 / 数据分析师 / 数据产品经理
技术口径	指标在具体表字段上的计算逻辑	数据 BP / 数据开发

分工：业务维护业务口径并在看板/产品页面展示；数据 BP 维护技术口径、做指标模型关联、提供数据应用。这样把"业务怎么说"和"技术怎么算"解耦，双方各管一段。

3.6 指标标准化流程（三步）

快手把指标标准化流程归纳为三步（来源：快手指标中台技术分享）：

1. 定义业务口径：名字、描述等业务属性（数据产品经理负责）；
2. 定义计算口径：具体表字段上的计算方法（数据开发负责）；
3. 定义数据集：规划服务场景，把需要的指标维度加入数据集（数据产品/业务负责）。

走完这三步，就完成了"指标规范化 + 指标服务化"的闭环。

3.7 幸福里的落地拆解

火山引擎 DataLeap 给幸福里的实际拆解流程（来源：火山引擎 DataLeap 分享）：

1. 提需流程：数据 BP 做业务指标和分析维度拆分，先查指标字典是否已存在（防重复开发）；不存在则拆解为原子指标 + 时间周期 + 修饰词落入指标平台；
2. 指标录入与维护：按离线数仓主题划分数据域，应用词根管理规范命名，对原子/衍生/复合指标做技术口径维护；
3. 模型打通：结合需求创建数据模型，打通 DataWind 数据集和数据服务。

---

本章要点回顾

• 三类指标：原子（过程+实体+度量）→ 派生（+时间/修饰词）→ 复合（公式）。
• OSM 框架：目标 → 策略 → 度量。
• 命名规范解决"同义不同名"，词根管理解决"一词多义"。
• 业务口径与技术口径分离，两类角色分工。
• 标准化三步：业务口径 → 计算口径 → 数据集。

上一章：02 指标平台概念与演进 ｜ 下一章：04 系统架构设计