بنقرة واحدة
metric-design
设计指标体系时使用。适用于北极星指标、AARRR 海盗模型、漏斗指标、GSM(Goals-Signals-Metrics)框架。帮助团队从业务目标出发,建立可量化、可追踪、可行动的指标体系。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
设计指标体系时使用。适用于北极星指标、AARRR 海盗模型、漏斗指标、GSM(Goals-Signals-Metrics)框架。帮助团队从业务目标出发,建立可量化、可追踪、可行动的指标体系。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
设计 API 认证鉴权和权限矩阵时使用。适用于多角色系统、租户隔离、字段级权限。优先使用 OAuth 2.0 / JWT + RBAC + 资源归属检查。
设计具体 API 端点时使用。适用于资源建模后的下一步、列端点清单、HTTP 方法和状态码选择。优先使用 RFC 7231 HTTP 语义 + GitHub REST 命名规范。
设计 API 错误码和错误结构时使用。适用于错误响应规范、调用方错误处理、调试可观测。优先使用 RFC 7807 Problem Details + 业务错误码 + 调用方处理建议。
设计幂等接口和重试策略时使用。适用于支付、扣减、订单、关键写操作。优先使用 Idempotency-Key + 业务去重键 + 并发冲突处理(ETag/版本号)。
输出 OpenAPI 契约和 Mock 服务时使用。适用于 API 设计的最后一步、给前端/后端/QA 的交付。优先使用 OpenAPI 3.1 + Mock 数据覆盖所有路径 + 详细的下游交接清单。
设计列表接口的分页、筛选、排序、搜索时使用。适用于所有列表 API。优先使用 cursor 分页(大数据)或 offset 分页(小数据)+ 统一筛选/排序规范。
| name | metric-design |
| description | 设计指标体系时使用。适用于北极星指标、AARRR 海盗模型、漏斗指标、GSM(Goals-Signals-Metrics)框架。帮助团队从业务目标出发,建立可量化、可追踪、可行动的指标体系。 |
参考来源:Google HEART Framework、Pirate Metrics (AARRR)、North Star Metric、GSM Framework、Lean Analytics。
1. 业务导向
指标必须回答业务问题,不是为了量化而量化
2. 可行动
每个指标变动都能对应具体行动(不能只看不能动)
3. 可衡量
有明确计算公式、数据来源、统计口径
4. 层次分明
北极星 → 一级指标 → 二级指标 → 过程指标,不混层
5. 口径唯一
同一指标全公司一个定义,不允许多版本
6. 反指标
设防护指标(Guardrail Metrics)防止优化一个指标伤害另一个
定义:单一指标,代表产品核心价值,全公司对齐
选择标准:
- 反映用户获得的核心价值
- 可拆解为团队可影响的子指标
- 领先指标(而非滞后指标)
- 长期增长与短期增长一致
示例:
Spotify → 每周活跃收听时长
Airbnb → 预订间夜数
Slack → 每日活跃团队中发送消息数
电商 → 月度 GMV / 月度订单数
Acquisition(获取) → 用户从哪来?
Activation(激活) → 用户首次体验价值?
Retention(留存) → 用户回来吗?
Revenue(收入) → 用户付费吗?
Referral(推荐) → 用户推荐吗?
每个阶段 2~3 个核心指标 + 1 个反指标
Goals(目标) → 业务想达成什么?
Signals(信号) → 什么行为/现象说明在接近目标?
Metrics(指标) → 用什么数字量化信号?
示例:
Goal: 提升用户活跃度
Signal: 用户更频繁地使用核心功能
Metric: 周均核心功能使用次数(per user)
设计步骤:
1. 定义漏斗起点和终点
2. 拆解中间关键步骤(不超过 7 步)
3. 每步定义转化率 = 下一步人数 / 当前步人数
4. 标注各步骤的平均时长
5. 设置各步骤基准线(Benchmark)
注意:
- 每步定义必须互斥(一个用户不能同时在两步)
- 时间窗口要明确(7 天漏斗 vs 30 天漏斗)
- 区分新用户漏斗 vs 全量用户漏斗
指标名称:[中文名]([英文名])
业务含义:[一句话解释]
计算公式:[分子] / [分母] 或 COUNT(xxx) WHERE ...
数据来源:[表名 / 埋点事件]
统计粒度:[天/周/月]
统计口径:[去重规则 / 时间窗口 / 过滤条件]
责任人:[谁负责这个指标]
反指标:[优化此指标时需要监控什么]
基准线:[当前值 / 行业均值 / 目标值]
1. 明确业务目标(这个阶段最重要的事是什么?)
↓
2. 选择框架(北极星 / AARRR / GSM / 漏斗)
↓
3. 拆解指标层级(一级 → 二级 → 过程指标)
↓
4. 定义每个指标的标准格式(公式 / 口径 / 来源)
↓
5. 设置反指标(防止过度优化)
↓
6. 确认数据可获取性(有埋点吗?有表吗?)
↓
7. 输出指标文档 + 埋点需求
↓
8. 与产品 / 开发 / 数据对齐口径
□ 每个指标是否有明确计算公式?
□ 口径是否无歧义(同一个名字只有一个定义)?
□ 指标层级是否清晰(北极星 → 一级 → 二级)?
□ 是否设置了反指标 / 防护指标?
□ 数据来源是否确认可获取?
□ 时间粒度和窗口是否明确?
□ 是否与产品 / 业务对齐?
□ 是否输出了埋点需求(如果缺数据)?
□ 指标数量是否合理(一级 ≤ 5,二级 ≤ 15)?
□ 是否考虑了季节性和外部因素影响?
templates/metric-framework-template.md — 指标体系设计模板上游:
产品经理工作流 → 业务目标 + 假设
项目经理工作流 → OKR / 里程碑
下游:
sql-analysis → 指标口径落地为 SQL
data-visualization → 指标可视化到仪表盘
ab-testing → 实验指标定义
analysis-report → 指标解读写入报告
后端工程师工作流 → 埋点需求