heart-metrics

name	heart-metrics
description	设计产品成功指标和埋点时使用。适用于 PRD 第 12 节、上线效果评估、季度复盘。优先使用 Google HEART 五维度 + GSM（Goals-Signals-Metrics）流程。

产品指标设计（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 个）

常见坑

1. 指标太多——10 个指标 = 没有指标
2. 没有防护指标——只看转化率，结果留存崩了
3. 没有基线——上线后才发现"我们以前是多少？"
4. Goal 不是用户层面——"提升 GMV" 是业务目标，不是用户目标
5. 埋点漏属性——只记录"点击了"，不知道点击了什么
6. 没有复盘时间——上线后没人看数据
7. 决策点不明确——指标不达标时不知道该怎么办

防护指标示例

功能：注册引导优化
  核心指标：注册转化率
  防护指标：D7 留存率（防止"注册了但马上流失"）

功能：智能推荐算法
  核心指标：推荐 CTR
  防护指标：用户满意度评分（防止"被算法绑架"的反感）

功能：搜索结果优化
  核心指标：搜索点击率
  防护指标：搜索后修改关键词的比例（防止"点了但不是想要的"）

配套模板

• templates/product-metrics-template.md — HEART + GSM + 埋点事件设计 + 复盘报告模板

与其他 skill 的协作

上游：
  prd-writing → 指标设计是 PRD 第 12 节

平行：
  pol-probe → 实验阶段的指标可以更轻量

下游：
  转交开发 → 实现埋点
  转交数据分析 → 配置看板和报表
  上线后 → 数据分析工作流做实际复盘