zhaoxuya520 产品指标设计（Google HEART + GSM）
参考来源：Google HEART Framework、Quantitative UX Research
适用场景
- PRD 第 12 节（指标和埋点建议）
- 上线后效果评估
- 季度/年度复盘
- 决定一个功能是否成功
不适用场景
- 早期探索阶段（用 pol-probe 验证）
- 内部工具（不需要用户指标）
核心原则
1. 先有 Goal，再有 Metric
不能反过来：看到数据再想"我们关心什么"
2. 一个 Goal 可能对应多个 Signal
一个 Signal 可能对应多个 Metric
3. 选少而精
每个功能 1~2 个核心指标 + 1 个防护指标
不要列 10 个指标
4. 必须有防护指标
防止"刷数据"（如：提高注册率但降低留存）
GSM 流程（Goals-Signals-Metrics）
Goal（目标）
想改善什么？（用户层面的目标）
例：让新用户更快理解产品价值
Signal（信号）
什么现象说明改善了？（可观察的行为变化）
例：新用户在第一天完成了核心操作
Metric（指标）
用什么指标衡量？（可量化的数据）
例：D1 核心操作完成率
HEART 五维度
| 维度 | 衡量什么 | 典型指标 | 适用场景 |
|------|---------|---------|---------|
| H Happiness | 用户满意度 | NPS、满意度评分、评价 | 体验优化类需求 |
| E Engagement | 使用深度 | DAU/MAU、会话时长、操作频次 | 粘性/活跃类需求 |
| A Adoption | 新用户激活 | 注册转化率、首次完成率 | 拉新/引导类需求 |
| R Retention | 用户留存 | 次日/7日/30日留存 | 留存/价值类需求 |
| T Task Success | 任务完成 | 完成率、错误率、耗时 | 效率/流程类需求 |
选择规则
不要五个维度都选——选 1~2 个和当前目标最相关的
举例：
- 新功能上线 → Adoption（首次使用率）+ Retention（7 日留存）
- 体验优化 → Task Success（完成率）+ Happiness（满意度）
- 增长功能 → Adoption（转化率）+ Engagement（频次）
- 留存功能 → Retention（30 日留存）+ Engagement（活跃度）
指标设计模板
## 指标设计：[功能名]
### Goal（目标）
[一句话描述要达成的用户层面目标]
### 选择的 HEART 维度
主指标维度：[H/E/A/R/T 中的 1~2 个]
防护指标维度：[防止某个副作用]
### Signals（信号）
| Signal | 描述 | 数据来源 |
|--------|------|---------|
| Signal 1 | [可观察的行为] | [埋点/数据库/日志] |
### Metrics（指标）
| 指标名 | 计算方式 | 当前基线 | 目标值 | 复盘时间 |
|--------|---------|---------|--------|---------|
| 核心指标 | [具体公式] | X% | Y% | 上线后 7 天 |
| 防护指标 | [具体公式] | A% | 不低于 B% | 上线后 7 天 |
### 埋点建议
| 事件名 | 触发条件 | 必要属性 | 可选属性 |
|--------|---------|---------|---------|
| event_name | 用户点击 X | user_id, timestamp | source, version |
### 复盘计划
- 第 1 天：检查埋点是否正常
- 第 7 天：核心指标初步评估
- 第 30 天：完整效果复盘
- 决策点：核心指标未达标 50% → 调整 / 80% → 继续优化 / 100% → 推全
完整示例
## 指标设计：商品搜索功能
### Goal
帮助用户更快找到想要的商品，减少搜索失败导致的流失。
### 选择的 HEART 维度
主指标：Task Success（找到商品的成功率）
防护指标：Happiness（搜索满意度，防止"找到了但不满意"）
### Signals
| Signal | 描述 | 数据来源 |
|--------|------|---------|
| 搜索后点击商品 | 用户点击搜索结果中的商品 | 埋点 |
| 搜索后无结果退出 | 搜索结果为空 + 30s 内退出 | 埋点 |
| 搜索后再次修改关键词 | 一次会话内多次搜索 | 埋点 |
### Metrics
| 指标名 | 计算方式 | 当前基线 | 目标值 | 复盘时间 |
|--------|---------|---------|--------|---------|
| 搜索点击率（CTR） | 点击数 / 搜索次数 | 35% | 55% | 上线 7 天 |
| 搜索成功率 | 有结果的搜索 / 总搜索 | 60% | 85% | 上线 7 天 |
| 搜索后留存（D7） | 搜索过的用户 7 日内再来 | 45% | 不低于 45% | 上线 30 天 |
### 埋点建议
| 事件名 | 触发条件 | 必要属性 |
|--------|---------|---------|
| search_query | 用户提交搜索 | user_id, query, timestamp |
| search_result_click | 用户点击结果 | user_id, query, position, item_id |
| search_no_result | 搜索结果为空 | user_id, query, suggestions_shown |
### 复盘计划
- 第 1 天：检查埋点
- 第 7 天：CTR 和成功率初评
- 第 30 天：完整复盘 + D7 留存
- 决策点：CTR < 45% → 调整算法 / 满意度下降 → 暂停推全
工作流程
1. 明确 Goal（用户层面，不是业务）
↓
2. 列出 Signals（可观察的行为）
↓
3. 转化为 Metrics（可量化）
↓
4. 选择 1~2 个核心指标 + 1 个防护指标
↓
5. 设定基线和目标值
↓
6. 设计埋点（事件名 + 属性）
↓
7. 设定复盘时间和决策点
↓
8. 转交开发（埋点实现）
↓
9. 转交数据分析（指标看板）
质量自检
□ 是否先定 Goal 再选 Metric
□ Metric 是否可量化（不是"提升体验"）
□ 是否有当前基线（不能凭空定目标）
□ 是否有目标值（不能"越多越好"）
□ 是否有防护指标（防止刷数据）
□ 埋点是否包含必要属性
□ 是否定义了复盘时间和决策点
□ 指标数量是否控制在 3~5 个（不要列 10 个）
常见坑
- 指标太多——10 个指标 = 没有指标
- 没有防护指标——只看转化率，结果留存崩了
- 没有基线——上线后才发现"我们以前是多少？"
- Goal 不是用户层面——"提升 GMV" 是业务目标，不是用户目标
- 埋点漏属性——只记录"点击了"，不知道点击了什么
- 没有复盘时间——上线后没人看数据
- 决策点不明确——指标不达标时不知道该怎么办
防护指标示例
功能：注册引导优化
核心指标：注册转化率
防护指标：D7 留存率（防止"注册了但马上流失"）
功能：智能推荐算法
核心指标：推荐 CTR
防护指标：用户满意度评分（防止"被算法绑架"的反感）
功能：搜索结果优化
核心指标：搜索点击率
防护指标：搜索后修改关键词的比例（防止"点了但不是想要的"）
配套模板
templates/product-metrics-template.md— HEART + GSM + 埋点事件设计 + 复盘报告模板
与其他 skill 的协作
上游：
prd-writing → 指标设计是 PRD 第 12 节
平行：
pol-probe → 实验阶段的指标可以更轻量
下游：
转交开发 → 实现埋点
转交数据分析 → 配置看板和报表
上线后 → 数据分析工作流做实际复盘