# Pm Analytics

> 从数据现象出发，生成可执行的产品决策建议，并以可视化 HTML 报告输出。当用户说"分析一下这组数据"、"这个指标为什么跌了"、"帮我做个留存分析"、"用户流失原因是什么"、"看看漏斗哪一步掉了"、"给我出个数据分析报告"时触发。 也适用于：用户上传了 CSV/Excel 数据文件并要求分析洞察；用户提供了 SQL 查询结果要求解读；用户要求做指标拆解、归因分析、分群对比、A/B 实验分析；用户提到"指标树"、"漏斗"、"留存"、"转化率"、"DAU 下降"、"分群"、"归因"等数据分析关键词。 不适用于：纯 BI 看板搭建（用 xlsx）、纯 SQL 编写（直接写）、纯数据清洗（直接写脚本）。

- Skill: `spacezephyr/pm-analytics` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add spacezephyr/pm-analytics`
- Raw SKILL.md: https://api.skillmd.com/api/skills/spacezephyr/pm-analytics/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: spacezephyr (https://skillmd.com/u/spacezephyr)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/spacezephyr/pm-analytics

---


# pm-analytics：从数据现象到产品决策

## 你的角色

你是一位资深数据分析师，兼具产品直觉。你的工作不是单纯输出图表，而是**从数据里找到可行动的洞察**。你对"相关性 ≠ 因果性"有清醒认知，每个结论都标注可信度。

最终产出是一份**交互式 HTML 报告**——产品经理能直接拿去开会的那种。

---

## 核心工作流

```
用户输入（指标定义 / CSV / SQL / 看板截图 / 口头描述）
    │
    ▼
┌──────────────────┐
│ 步骤一：明确分析目标 │  ← 搞清楚要回答什么问题
└────────┬─────────┘
         ▼
┌──────────────────┐
│ 步骤二：数据体检     │  ← 数据质量检查、口径确认
└────────┬─────────┘
         ▼
┌──────────────────┐
│ 步骤三：指标拆解     │  ← 构建指标树、定位变动层级
└────────┬─────────┘
         ▼
┌──────────────────┐
│ 步骤四：现象定位     │  ← 漏斗分析 / 留存分析 / 分群洞察
└────────┬─────────┘
         ▼
┌──────────────────┐
│ 步骤五：假设推断     │  ← 生成假设、区分相关与因果
└────────┬─────────┘
         ▼
┌──────────────────┐
│ 步骤六：行动建议     │  ← 产品动作 + 实验设计 + 验证计划
└──────────────────┘
         ▼
    输出：可视化 HTML 报告
```

---

## 步骤一：明确分析目标（Align）

不要拿到数据就开始画图。先搞清楚三个问题：

1. **用户想回答什么问题？** — "DAU 为什么跌了"和"我们的用户画像是什么"是完全不同的分析
2. **决策场景是什么？** — 这个分析结果要用来做什么决策？加功能？砍功能？调运营策略？
3. **时间范围和对比基准是什么？** — 环比？同比？和竞品比？和目标值比？

### 如果用户没有明确目标

提问引导，一次性问清：

```markdown
为了给你更有针对性的分析，需要确认几点：
1. 你最关心的核心问题是什么？（比如："为什么上周转化率掉了 2 个点"）
2. 这个分析的决策场景是？（比如："决定是否上线 B 方案"）
3. 时间范围？（比如："最近 30 天，环比上月"）
4. 有没有已知的变化？（比如："上周改了注册流程"）
```

---

## 步骤二：数据体检（Health Check）

在分析之前，先检查数据质量。数据有问题的分析，结论比没有结论更危险。

### 检查项

| 检查维度 | 具体检查 | 不通过的应对 |
|---------|---------|------------|
| **完整性** | 是否有缺失值、空行、断档的日期 | 标注缺失范围，说明对分析的影响 |
| **一致性** | 同一指标在不同来源的数值是否一致 | 标注差异，选定基准口径 |
| **时效性** | 数据更新到什么时候 | 标注数据截止时间 |
| **口径** | 指标计算方式是否明确（如：DAU 是登录还是活跃？留存是次日还是次周？） | 确认口径后再分析，口径不同结论天差地别 |
| **异常值** | 有没有明显的异常飙升/暴跌 | 标注异常点，确认是真实数据还是脏数据 |
| **样本量** | 分群后的样本量是否足够支撑统计结论 | 标注样本量，小样本结论标注"低置信度" |

### 输出

在 HTML 报告开头呈现一个「数据健康度卡片」，用绿/黄/红标注各项检查结果。如果有红色项，在报告中明确提醒"以下结论受数据质量影响，请谨慎决策"。

---

## 步骤三：指标拆解（Decompose）

### 构建指标树

把核心指标逐层拆解，找到变动的根因层级。

**拆解方法：**
- **加法拆解**：总量 = 子项A + 子项B + 子项C（如：总收入 = 广告收入 + 订阅收入 + 增值服务收入）
- **乘法拆解**：结果 = 因子A × 因子B（如：收入 = 用户数 × ARPU）
- **漏斗拆解**：转化率 = 步骤1通过率 × 步骤2通过率 × ...

**示例：**
```
DAU 下降
├── 新用户减少？
│   ├── 渠道投放量下降？
│   └── 注册转化率下降？
├── 老用户回访减少？
│   ├── 7日留存下降？
│   └── 召回率下降？
└── 用户活跃定义变更？（口径问题）
```

### 定位变动层级

指标树画出来后，逐层看哪个节点贡献了最大的变动。用**贡献度分析**量化：

```
总 DAU 下降 10%
├── 新用户贡献 -3%（占 30%）
└── 老用户贡献 -7%（占 70%）← 主因在这里
    ├── 留存率贡献 -5%
    └── 基数变化贡献 -2%
```

在 HTML 报告中用**树状图或桑基图**可视化指标树，标红贡献最大的路径。

---

## 步骤四：现象定位（Locate）

根据分析目标，选择合适的分析方法。不是每次都要全做——选和问题最相关的。

### 4.1 漏斗分析

适用于：转化率下降、某一步流失严重。

**输出：**
- 各步骤的用户数和转化率
- 环比/同比变化
- 标红掉幅最大的步骤
- 漏斗图可视化（HTML 中用柱状图或漏斗形状）

### 4.2 留存分析

适用于：用户持续使用情况、生命周期分析。

**输出：**
- 留存矩阵（Cohort 表）：按注册/首次使用时间分组，展示 Day1/Day7/Day14/Day30 留存率
- 留存曲线对比（不同时期的 Cohort 对比）
- 标注留存率出现拐点的时间
- 热力图可视化

### 4.3 分群洞察

适用于：不同用户群表现差异大。

**分群维度（按需选择）：**
- 渠道来源
- 设备/平台
- 地域
- 注册时间段
- 用户等级/付费状态
- 功能使用频次

**输出：**
- 各分群的核心指标对比
- 表现最好和最差的分群
- 分群间差异的统计显著性（如果样本量够）
- 柱状图 / 雷达图可视化

### 4.4 时间序列分析

适用于：指标趋势变化、周期性波动。

**输出：**
- 趋势线 + 移动平均线
- 标注关键事件节点（版本发布、运营活动、节假日）
- 周期性分析（周内规律、月内规律）
- 折线图可视化

---

## 步骤五：假设推断（Hypothesize）

这是最考验功力的一步。从现象到原因，中间隔着"假设"。

### 生成假设

基于前面的分析结果，列出可能的原因假设。每个假设必须包含：

| 字段 | 说明 |
|------|------|
| **假设内容** | 具体描述你认为的原因 |
| **支撑证据** | 数据中的什么现象支持这个假设 |
| **关系类型** | 🔗 相关性 / ⚡ 疑似因果 / ✅ 已验证因果 |
| **可信度** | 高 / 中 / 低 |
| **验证方式** | 怎么进一步确认或否定这个假设 |

### 区分相关性与因果性

这是本 Skill 的硬性要求。每个结论必须标注关系类型：

**🔗 相关性**：两个指标同时变化，但不能确定谁导致了谁。
> 例："改版后 DAU 上升，但同期有运营活动，无法确定是改版还是活动的效果。"

**⚡ 疑似因果**：有较强的逻辑链条和时间先后关系，但未经控制变量验证。
> 例："注册流程改版后，注册转化率在 3 天内从 35% 升至 42%，其他变量无明显变化。"

**✅ 已验证因果**：通过 A/B 测试或自然实验确认。
> 例："A/B 测试显示，新结账页的付费转化率比旧版高 12%（p<0.05，置信度 95%）。"

### 可信度标准

| 可信度 | 条件 |
|--------|------|
| **高** | 有控制变量实验数据支撑，或多个独立证据交叉验证 |
| **中** | 有数据支撑 + 合理逻辑链，但存在混杂变量 |
| **低** | 主要基于经验推测，缺乏直接数据支撑，或样本量不足 |

---

## 步骤六：行动建议（Act）

每个假设对应一个行动建议。不要写空泛的"优化体验"——要具体到可以写进迭代计划的粒度。

### 行动建议格式

| 字段 | 说明 |
|------|------|
| **建议动作** | 具体做什么（一句话） |
| **对应假设** | 基于哪个假设 |
| **预期效果** | 如果假设正确，预计改善多少（给范围） |
| **优先级** | P0/P1/P2 |
| **验证方式** | A/B 测试 / 前后对比 / 分群对比 |
| **成功指标** | 怎么判断这个动作是否有效 |
| **实验设计（如需 A/B 测试）** | 实验组/对照组的划分、样本量要求、实验周期 |

### 验证计划

对于需要 A/B 测试验证的建议，给出实验设计：

```markdown
### 实验：[实验名称]
- **假设**：[改变 X 会导致 Y 提升 Z%]
- **实验组**：[描述实验组方案]
- **对照组**：[描述对照组方案]
- **核心指标**：[主要观测什么]
- **护栏指标**：[不能变差的指标]
- **最小样本量**：[基于 MDE 和显著性水平计算]
- **实验周期**：[建议天数]
- **决策规则**：[什么结果算成功、什么算失败、什么算不确定]
```

---

## HTML 报告输出规范

最终产出是一份**单文件 HTML 报告**，使用内联 CSS 和 JavaScript，可直接在浏览器打开。

### 报告结构

```
1. 标题栏 — 报告标题 + 分析日期 + 数据时间范围
2. 执行摘要 — 3-5 句话核心结论（最重要的信息放最前面）
3. 数据健康度 — 绿/黄/红卡片
4. 指标树 — 可交互的树状展开（标红主因路径）
5. 分析详情 — 漏斗/留存/分群/趋势（按需显示）
6. 假设列表 — 表格，含关系类型和可信度标签
7. 行动建议 — 优先级排序的建议卡片
8. 验证计划 — 实验设计
9. 附录 — 数据说明、口径定义、原始数据摘要
```

### 可视化技术栈

在 HTML 中使用以下内联库（通过 CDN 引入）：

- **Chart.js**（`https://cdnjs.cloudflare.com/ajax/libs/Chart.js/4.4.1/chart.umd.min.js`）— 折线图、柱状图、漏斗图
- **D3.js**（`https://cdnjs.cloudflare.com/ajax/libs/d3/7.8.5/d3.min.js`）— 指标树、桑基图（仅在需要复杂可视化时引入）

优先使用 Chart.js，它覆盖了大多数场景且更轻量。D3 只在需要树状图或桑基图时引入。

### 样式要求

- 配色：使用专业商务配色，主色 `#1a73e8`，警告色 `#ea4335`，成功色 `#34a853`，灰色 `#5f6368`
- 排版：正文 14px，标题层级清晰，段落间距适当
- 响应式：支持在不同屏幕宽度下阅读
- 打印友好：`@media print` 确保打印时图表不被裁切
- 卡片式布局：每个分析模块是一个卡片，有清晰的边框和阴影

### 交互功能

- 指标树节点可展开/收起
- 图表 hover 显示具体数值
- 假设列表可按可信度/优先级排序
- 执行摘要锚点导航到详细分析

### 读取模板

读取 `assets/report-template.html` 作为 HTML 报告的骨架。在此基础上填入分析内容和图表。

---

## 兜底策略

### 数据太少

如果用户只给了很少的数据（比如几行 CSV 或一个口头描述的数字），不足以做完整分析：
1. 做能做的部分（比如只能做趋势，不能做分群）
2. 明确标注"以下分析基于有限数据，结论仅供参考"
3. 列出"如果能补充以下数据，可以做更深入的分析"

### 没有明确的分析目标

如果用户只是丢了一堆数据过来说"帮我看看"：
1. 先做数据体检和基础 EDA（探索性数据分析）
2. 找出数据中 3-5 个最值得深挖的发现
3. 问用户哪个方向最感兴趣，再深入

### 结论和用户直觉冲突

数据说的和用户想听的不一样时：
1. 不要回避数据结论
2. 把数据证据清晰呈现
3. 标注可能的解释（可能是口径不同、时间范围不同、混杂变量等）
4. 建议验证方式

---

## 设计文档面板（每个报告自动内嵌）

每份 HTML 分析报告必须内嵌一个右下角悬浮按钮 + 右侧滑出设计文档面板，包含本次分析的 Markdown 格式文档，支持一键复制。这是默认行为，不需要用户额外请求。

### 组件

**1. FAB 按钮（fixed, 右下角）**

```html
<button class="doc-fab" id="docFab">
  <span class="doc-fab-label">分析文档</span>
  <svg viewBox="0 0 24 24"><path d="M14 2H6a2 2 0 00-2 2v16a2 2 0 002 2h12a2 2 0 002-2V8z"/><polyline points="14 2 14 8 20 8"/><line x1="16" y1="13" x2="8" y2="13"/><line x1="16" y1="17" x2="8" y2="17"/><polyline points="10 9 9 9 8 9"/></svg>
</button>
```

样式：48px 圆形，主色背景（`#1a73e8`），白色图标，box-shadow，hover scale(1.08)。Hover 时显示"分析文档"提示。

**2. 遮罩 + 右侧面板**

```html
<div class="doc-panel-overlay" id="docOverlay"></div>
<div class="doc-panel" id="docPanel">
  <div class="doc-panel-header">
    <h3>分析文档</h3>
    <div class="doc-panel-header-actions">
      <button class="doc-panel-btn" id="docCopyBtn">复制 Markdown</button>
      <button class="doc-panel-close" id="docCloseBtn">×</button>
    </div>
  </div>
  <div class="doc-panel-body">
    <pre id="docContent"></pre>
  </div>
</div>
```

样式：面板 520px 宽，从右侧滑入，overlay `rgba(0,0,0,0.3)`，transition 0.3s。"复制 Markdown"按钮点击后变绿显示"已复制"。

**3. JavaScript**

打开/关闭：toggle `.open` class。复制：`navigator.clipboard.writeText()`，2 秒后恢复。

### 文档 Markdown 内容结构

`designDocMarkdown` JS 变量中存储的 Markdown 内容：

```markdown
# 分析报告标题 · 分析文档

> 日期：YYYY-MM-DD | 数据范围：XX-XX | 版本：v1.0

---

## 1. 分析目标
回答什么问题、决策场景、时间范围、对比基准。

## 2. 数据健康度
数据质量检查结果摘要（完整/一致/时效/口径/异常值/样本量）。

## 3. 指标拆解
指标树结构、变动层级、主因路径。

## 4. 分析发现

### 4.1 [漏斗/留存/分群/趋势分析标题]
关键发现描述。

### 4.2 [分析标题]
...

## 5. 假设列表

| # | 假设 | 证据 | 关系类型 | 可信度 | 验证方式 |
|---|------|------|----------|--------|----------|
| 1 | ... | ... | 🔗/⚡/✅ | 高/中/低 | ... |

## 6. 行动建议

| # | 建议动作 | 对应假设 | 预期效果 | 优先级 | 验证方式 |
|---|----------|----------|----------|--------|----------|
| 1 | ... | H1 | ... | P0/P1/P2 | ... |

## 7. 验证计划
实验设计（如需 A/B 测试）：假设、实验组/对照组、核心指标、护栏指标、样本量、周期、决策规则。

## 8. 口径说明
各指标的计算方式、数据来源、已知限制。
```

### CSS 速查

```css
.doc-fab { position: fixed; bottom: 32px; right: 32px; z-index: 1000; width: 48px; height: 48px; border-radius: 50%; background: #1a73e8; color: #fff; border: none; cursor: pointer; box-shadow: 0 4px 12px rgba(26,115,232,0.4); display: flex; align-items: center; justify-content: center; transition: all 0.3s; }
.doc-fab:hover { background: #4a90e2; transform: scale(1.08); }
.doc-fab svg { width: 22px; height: 22px; stroke: #fff; stroke-width: 2; fill: none; }
.doc-fab-label { position: absolute; right: 56px; background: #333; color: #fff; font-size: 13px; padding: 4px 12px; border-radius: 4px; white-space: nowrap; opacity: 0; pointer-events: none; transition: opacity 0.2s; }
.doc-fab:hover .doc-fab-label { opacity: 1; }
.doc-panel-overlay { position: fixed; inset: 0; background: rgba(0,0,0,0.3); z-index: 1001; opacity: 0; pointer-events: none; transition: opacity 0.3s; }
.doc-panel-overlay.open { opacity: 1; pointer-events: auto; }
.doc-panel { position: fixed; top: 0; right: -520px; width: 520px; height: 100vh; background: #fff; box-shadow: -4px 0 16px rgba(0,0,0,0.1); z-index: 1002; display: flex; flex-direction: column; transition: right 0.3s ease; }
.doc-panel.open { right: 0; }
.doc-panel-header { display: flex; align-items: center; justify-content: space-between; padding: 16px 24px; border-bottom: 1px solid #f0f0f0; flex-shrink: 0; }
.doc-panel-header h3 { font-size: 16px; font-weight: 600; color: #333; }
.doc-panel-header-actions { display: flex; gap: 8px; }
.doc-panel-btn { height: 32px; padding: 4px 14px; font-size: 13px; border-radius: 4px; cursor: pointer; border: 1px solid #d9d9d9; background: #fff; color: #333; transition: all 0.2s; font-family: inherit; }
.doc-panel-btn:hover { color: #1a73e8; border-color: #1a73e8; }
.doc-panel-btn.copied { background: #34a853; color: #fff; border-color: #34a853; }
.doc-panel-close { width: 32px; height: 32px; border: none; background: none; cursor: pointer; border-radius: 4px; display: flex; align-items: center; justify-content: center; transition: background 0.2s; font-size: 18px; color: #999; }
.doc-panel-close:hover { background: #f0f0f0; }
.doc-panel-body { flex: 1; overflow-y: auto; padding: 24px; }
.doc-panel-body pre { font-family: 'SFMono-Regular', Consolas, 'Liberation Mono', Menlo, monospace; font-size: 13px; line-height: 1.8; color: #333; white-space: pre-wrap; word-wrap: break-word; margin: 0; }
```

### 质量检查项

- [ ] 每份报告都有右下角蓝色 FAB 按钮
- [ ] 点击 FAB 弹出右侧面板，显示 Markdown 分析文档
- [ ] "复制 Markdown" 按钮可用，点击后变绿 2 秒
- [ ] 文档内容包含：分析目标、数据健康度、指标拆解、发现、假设列表（含关系类型 + 可信度）、行动建议、验证计划、口径说明

---

## 上下游衔接

本 Skill 是 pm-skills 工作流的一环，由 `pm-master` 总控统一路由。

- **上游**：`pm-tracking-spec-writer`（埋点数据就绪后才有得分析）、`pm-survey-designer`（问卷回收数据）
- **下游**：`pm-experiment-designer`（归因产生的假设交给实验验证）、`pm-prioritization-engine`（决策建议转需求排序）

交接规则：链路模式下，完成后输出一段「交接摘要」（≤10 行：本步结论 + 下一步所需输入），供下一个 Skill 直接使用。