考察点
指标体系题把技术问题往业务方向拉了一步，中高级岗位必问。面试官想看两点：你能不能结构化地拆指标（而不是随口报数），以及你是否经历过口径混乱的痛、知道指标字典在治什么病。追问常落在「原子指标和派生指标怎么分」「指标和维度、修饰词什么关系」。
参考答案
指标体系的分层设计
指标体系不是指标清单，是一棵有逻辑的拆解树。设计顺序自上而下：
第一步，定北极星指标。 全公司（或某业务线）只看一个最能代表价值的数：电商是 GMV 或成交用户数，内容产品是消费时长，SaaS 是付费续费额。它的作用是统一努力方向，所有下层指标都要能解释对它的贡献。
第二步，按方法论往下拆。 两套常用框架：OSM（Objective-Strategy-Measure），从业务目标出发，每个目标找实现策略，每个策略配度量指标——比如目标是 GMV 增长，策略之一是提升转化，度量就是下单转化率、支付转化率；UJM（User Journey Model），沿用户旅程拆：曝光 → 访问 → 加购 → 下单 → 支付 → 复购，每个环节配过程指标。两套经常混用：OSM 管「为什么看这些指标」，UJM 管「指标之间的路径关系」。
第三步，区分结果指标和过程指标。 结果指标（GMV、DAU）滞后、不可直接干预；过程指标（加购率、详情页停留时长）前置、可行动。健康的体系是每条结果指标下面挂着可干预的过程指标，业务跌了能沿树定位到哪个环节出问题。指标堆了上千个但涨跌无法归因，就是只有结果没有过程。
落地：原子指标、派生指标、修饰词
树拆完要到可计算的层面，行业里成熟的做法（阿里 OneData 为代表）是把指标拆成三个概念：
- 原子指标：某一业务过程下不可再分的度量，= 业务过程 + 度量 + 聚合逻辑。如「下单金额」（下单过程，sum 金额）、「支付用户数」（支付过程，count distinct 用户）；
- 修饰词：对统计范围的限定，如「渠道 = App」「是否新客 = 新客」「商品类目 = 服饰」。修饰词本质是维度上的约束；
- 派生指标 = 原子指标 + 时间周期 + 修饰词。如「近 7 天 App 端新客下单金额」。
这套分解的价值在于指标可组装：平台上注册原子指标和修饰词各几十个，派生指标由使用方按规则组合生成，不用每个都开发一张表。DWS 层按常用组合预计算宽表，非常用组合即时查询，开发量和口径一致性同时保住。
指标字典解决什么问题
没有字典的公司都经历过同样的混乱：同一个「活跃用户」，运营口径是打开 App，增长口径是完成核心行为，财务只认有交易的——同名不同义；反过来「成交金额」「交易额」「GMV」三个名字其实是一个数——同义不同名。开会对数先吵半小时口径，报表之间永远对不上，数据团队大量时间耗在解释口径而不是产出价值。
指标字典（指标管理平台）就是给每个指标发身份证，登记：标准名称、业务口径描述、计算公式、来源表和字段、统计粒度与周期、负责人、血缘上下游。规矩只有一条但很关键：指标先注册后使用，报表引用的每个指标必须能链接到字典条目，口径变更走评审并通知下游。做得深的团队把字典和 BI 打通，指标定义即计算逻辑（语义层），报表不再手写 SQL，从技术上让「一个指标只有一种算法」。
和数仓分层的关系
指标体系不是飘在数仓外面的文档：原子指标对应 DWD 的业务过程和事实，修饰词对应 DWD/DWS 的维度取值，派生指标对应 DWS 的汇总宽表和 ADS 的应用表。建指标体系和建数仓是同一件事的两面——指标体系定「算什么」，数仓模型定「怎么算、存哪」。评审新指标时同步评审它的数据源落层，指标树和模型表一起演进。
可能的追问
- 指标太多失控了怎么治理？ 定期盘点：按引用次数下线僵尸指标，按名称/口径相似度合并重复指标，给指标分等级（公司级 / 部门级 / 个人临时），公司级指标变更强制评审。
- 派生指标组合爆炸，DWS 宽表放不下怎么办？ 按使用频率分层：Top 组合预计算进宽表，长尾组合靠 OLAP 引擎（Doris、StarRocks）在明细或轻汇总上即时算，用引擎性能换灵活性。
- 业务方坚持要自己的口径怎么办？ 允许存在但必须显式区分：注册为独立指标、名称强制带口径标识（如「GMV-含退款」），禁止和标准指标同名。口径可以有多个，混淆不能有。