| name | metric-definition-reviewer |
| description | Use when reviewing or defining a business metric, KPI, or analytics indicator. Checks business intent, population, event definition, time window, grain, filters, edge cases, status lifecycle, consistency, and questions that must be confirmed. |
Metric Definition Reviewer
目标
审查一个指标口径是否清晰、稳定、可计算、可解释。
这个 Skill 关注指标本身，不负责完整建模，也不负责直接写生产 SQL。它要帮助用户发现口径漏洞、边界条件、业务歧义和跨团队对齐风险。
使用场景
使用这个 Skill，当用户需要：
- 定义一个新指标
- 审查已有指标口径
- 对齐业务方和数据团队对同一指标的理解
- 检查看板指标是否容易误导
- 分析 GMV、DAU、留存、转化率、复购率、活跃率、履约率等指标
- 在口径变更前识别影响范围
典型输入：
帮我审查一下“7 日留存率”的口径。
GMV 现在按支付成功订单金额统计，退款是否扣减还没定。
不适用场景
不要用这个 Skill 直接完成：
- 模糊需求澄清，请使用
data-requirement-clarifier
- 表结构设计，请使用
table-design-advisor
- SQL 审查，请使用
sql-reviewer
- 数据质量规则生成，请使用
data-quality-rule-generator
如果用户只提供了一个指标名，必须先列出待确认问题，不能直接给出确定口径。
输入信息
最少输入：
可选输入：
- 业务目标
- 使用场景
- 统计对象
- 事件定义
- 时间窗口
- 统计粒度
- 过滤条件
- 订单、用户、商品、组织等状态流转规则
- 现有 SQL 或看板截图描述
上下文建议
推荐使用 指标口径上下文模板。
最有价值的上下文是：业务含义、统计对象、时间窗口、分子分母、过滤条件、去重规则和边界处理。缺少业务规则时，只能给出推荐口径和待确认问题，不能把行业常见口径当成事实。
审查框架
逐项检查：
- 业务意图：这个指标被用来判断什么。
- 统计对象：统计用户、订单、商品、设备、门店还是组织。
- 事件定义：什么行为算发生，什么状态算有效。
- 时间窗口：自然日、滚动窗口、T+1、支付时间、创建时间还是完成时间。
- 统计粒度：日、周、月、用户、订单、渠道、组织等。
- 分子分母：比率类指标必须明确分子、分母和样本范围。
- 过滤条件：测试数据、内部账号、取消、退款、失败、异常状态是否排除。
- 去重规则：按用户、订单、事件、设备还是业务主键去重。
- 边界条件：跨天、跨月、退款、补单、延迟到账、状态回滚、重复上报。
- 可解释性：业务方看到数值后是否能理解它代表什么。
- 一致性：是否与已有指标、上游系统或财务口径冲突。
输出格式
## 指标口径审查
### 1. 审查结论
### 2. 推荐定义
| 项目 | 内容 |
| --- | --- |
| 指标名称 | |
| 业务含义 | |
| 统计对象 | |
| 统计粒度 | |
| 时间口径 | |
| 分子 | |
| 分母 | |
| 过滤条件 | |
| 去重规则 | |
| 更新频率 | |
### 3. 主要风险
| 风险等级 | 问题 | 影响 | 建议 |
| --- | --- | --- | --- |
### 4. 边界条件
### 5. 待确认问题
### 6. 可选 SQL 伪逻辑
风险等级
- P0：会导致指标方向错误或重大业务误判
- P1：会导致不同团队口径不一致
- P2：会影响解释性、稳定性或长期维护
质量标准
输出必须：
- 明确指出口径是否可用
- 给出推荐定义
- 暴露分子、分母、时间窗口、过滤条件和去重规则
- 标记不能确定的业务规则
- 避免把常见行业口径当成用户公司的确定事实
示例 Prompt
请用 metric-definition-reviewer 审查这个指标：
指标：新用户首购转化率
当前口径：注册后 7 天内完成支付的新用户数 / 新注册用户数
使用场景：渠道投放效果看板
疑问：退款订单要不要算转化？
