业务说"加个新指标，明天上线"——指标需求评审到底该卡哪几关？
先说结论
评审不是审批，是协作。好的评审流程是"3天上线、5个检查点、3方签字"。每个检查点解决一类风险——口径不清、数据源不齐、Owner不明、影响范围不评估、上线没回滚。
评审要分级。北极星指标 → 高级评审（公司级评审会）；业务派生指标 → 中级评审（业务线评审）；私域临时指标 → 轻量评审（自助登记）。一刀切要么过严要么过松。
最关键的是「定义先于实现」。没有定义的SQL先不要写，业务说不清楚定义就让业务先想清楚——这是Senior的底气，也是降低返工率的核心。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
"加个新指标，明天就要"——这是数据团队最常听见、最容易翻车的需求。直接干立刻翻车（口径没对齐、上线就出错），不干又被业务投诉效率低。这道题考的不是技术，是怎么用流程平衡效率和质量。我在出海硬件品牌做指标治理时，把指标平均上线时长从7天压到2天，秘诀就是把评审流程做对、做轻。
业务场景：紧急需求踩过的三次大坑
出海硬件品牌时期，我们栽过三次跟头：
坑1（2022年Q1）：CEO临时要看"高价值用户数"，连夜赶出一版，第二天发现"高价值"没定义清楚。CEO理解的是"近30日付费>500美金"，业务理解的是"累计付费>1000美金"，结果两组数差3倍，CEO当场怒摔。
坑2（2022年Q3）：活动组要"参加双11活动用户数"，没问哪个活动，结果数据团队拉了所有2022年双11促销活动的用户，业务实际只要主会场的，差5倍。
坑3（2023年Q1）：产品要"次日留存率"，没问留存的口径（次日登录？次日有交互？次日有支付？），上线后报表显示65%，业务说"我感觉不到这么高"——我们用的是登录口径，业务期望的是有效互动口径。
流程一：5个检查点的评审SOP
我把评审做成5个检查点，每个点对应一类风险。流程不复杂，30分钟评审会就能跑完：
| 检查点 | 核心问题 | 卡点责任人 | 通过标准 |
|---|---|---|---|
| 1. 定义清晰度 | 口径文字化是否无歧义 | 业务方 | 业务方+数据方都能复述同一句话 |
| 2. 数据源可达性 | 底层数据是否齐全 | 数据方 | 找到所有源表、字段已采集 |
| 3. 与现有指标关系 | 是否与已有指标重复/冲突 | 数据Owner | 字典里查不到等价指标 |
| 4. 影响范围 | 下游是否会被影响 | BI/数据 | 梳理影响报表清单+通知Owner |
| 5. 上线/回滚方案 | 如何上、出问题怎么回 | 数据方 | 有灰度、双跑、回滚预案 |
流程二：分级评审
不是所有指标都需要重评审。我按指标重要性分三档：
[北极星指标 / 高管周报指标]
→ 公司级评审会（每月1次）
→ 必经5个检查点 + CEO/CDO签字
→ SLA: 上线时间≥2周
[业务线核心指标 / 跨部门复用指标]
→ 业务线评审会（每周1次）
→ 必经5个检查点 + 业务负责人+数据Owner签字
→ SLA: 上线时间3-7天
[临时分析指标 / 单报表使用]
→ 自助登记到字典
→ 数据Owner异步review
→ SLA: 上线时间≤1天分级之后，紧急的小需求不被流程拖死，重要的大需求又不会被乱搞。这是平衡效率和质量的关键设计。
流程三：需求模板（治本工具）
所有新指标必须填一张《指标需求单》，模板如下：
Markdown
## 指标需求单
**1. 基础信息**
- 指标中文名: 高价值用户数
- 指标英文名: high_value_user_cnt
- 业务域: 用户域 / 价值主题
- 申请人: 王XX（增长部）
**2. 业务定义（必填，必须无歧义）**
近30日累计支付金额≥500美金的用户数（去重）
**3. 计算口径（必填）**
- 时间窗口: 近30日（含当日）
- 过滤条件: pay_status='SUCCESS' AND user_type!='TEST'
- 计算方法: COUNT(DISTINCT user_id) WHERE 30日累计金额≥500
- 数据源表: dws_trade_user_1d
**4. 业务用途**
用于CEO周报、增长部用户分层运营
**5. 与现有指标关系**
- 与现有 vip_user_cnt 不同（VIP是会员等级口径）
- 数据Owner确认：字典中无等价指标
**6. 影响范围评估**
- 影响报表: CEO周报、增长部周报
- 上游表: 已存在，无新采集需求
**7. 上线方案**
- 灰度: T+1双跑3天
- 回滚: 保留旧字段名，新字段失败时切回这张表填完，95%的需求争议在动手前就解决了。这就是「定义先于实现」的实操工具。
流程四：紧急需求的快速通道
CEO/重大事故等真正紧急的需求需要快速通道：
[紧急需求触发]
↓
[15分钟评审会：业务+数据负责人+CDO]
- 必须文字化定义（哪怕一句话）
- 必须明确Owner
- 必须明确临时还是长期
↓
[临时方案上线]
- 标记 [TEMP] 前缀
- 不进入正式字典
- 不发布到BI主页
↓
[2周内补正式评审]
- 走完5检查点
- 转正或下线快速通道关键是「先用起来再说」+「2周内必须补流程」。我在出海硬件品牌用这套机制处理过CEO临时数据需求15+次，无一翻车。
面试高频追问
追问一：评审会业务方都不来怎么办？
两手准备：①拉Sponsor——评审前先和业务负责人对齐，让他Push下属来参会，这是政治问题不是流程问题。②不来就不上线——把这条写进《指标管理章程》并由CDO背书。我在出海硬件品牌前两个月遇到过几次业务不到，按章程拒绝上线后业务很快就来了——因为他们也急用。
追问二：怎么衡量评审流程做得好不好？
4个量化指标：①平均上线时长（我从7天压到2天）②评审通过率（应该70-80%最健康，太高说明流程形同虚设，太低说明卡得太死）③上线后口径变更率（健康值<5%，高了说明评审没卡住口径问题）④下游报表影响事故数（应趋近于0）。这4个数字是我向CDO汇报治理成效的核心。
追问三：业务方说"流程太重，效率太低"，怎么应对？
用数据说话。我会拉前6个月的事故复盘——每次因口径不清、影响评估不到位导致的返工小时数、CEO投诉次数、数据信任度下降。把这些算成"无流程的隐藏成本"，业务马上闭嘴。同时强调分级评审和快速通道——日常小需求只需要自助登记，不会拖效率。这两个一起出，业务一般就接受了。
实战踩坑：评审做太重导致业务绕路
我刚到出海硬件品牌时，照搬大厂经验做了一套重评审——所有指标都走5个检查点+三方签字。结果业务为了快，直接绕过我们在BI工具里自己写SQL，3个月内BI工具里冒出来400+"野指标"，比治理前还乱。
教训：流程必须分级，必须留快速通道，必须有BI层的强制约束。没有分级的评审就是逼业务造反。后来重新设计成三级评审+BI发布拦截，3个月把野指标清理干净，新增指标100%经过登记。
总结
回答这道题的高分结构：先讲风险（紧急需求踩坑）→ 再讲分级流程（5检查点+三级评审）→ 最后讲快速通道（紧急需求15分钟评审+2周补流程）。能说出"上线时长从7天压到2天""野指标从400到0"这种数字，就是Staff级别答案。强调"流程不是审批、是协作"、"分级是关键"——这是治理的核心insight。
下一篇切到一个最经典的痛点：同一个DAU，离线1200万、实时1180万——双链路口径不一致怎么办？
你们公司新指标上线要走流程吗？平均多久？评论区聊聊～
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长
指标管理 面试通关手册
第6-10篇：口径、维度与一致性
Wood聊大数据
9年大数据老兵，聊技术、聊职场、聊成长