# Business Root Cause Analysis

> Use when diagnosing business metric changes or anomalies such as GMV decline, conversion drop, retention loss, churn increase, revenue change, lead decline, or active user fluctuation with a structured root cause analysis plan.

- Skill: `shisuidata/business-root-cause-analysis` (Agent Skill)
- Install (CLI): `npx skillmds@latest add shisuidata/business-root-cause-analysis`
- Raw SKILL.md: https://api.skillmd.com/api/skills/shisuidata/business-root-cause-analysis/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Finance & Business
- Author: shisuidata (https://skillmd.com/u/shisuidata)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/shisuidata/business-root-cause-analysis

---


# Business Root Cause Analysis

## 目标

把“某个业务指标变差了”拆成可验证的归因假设、数据检查路径和行动建议。

这个 Skill 不负责凭空给出唯一原因，而是帮助用户建立一套可执行的排查框架。

## 使用场景

使用这个 Skill，当用户需要：

- 分析 GMV、转化率、留存、活跃、收入、线索、续费等指标异常
- 把老板的一句“为什么下降了”拆成分析任务
- 为业务复盘准备归因树和验证路径
- 判断是流量、转化、结构、供给、价格、产品体验还是数据口径问题
- 给数据分析师或业务负责人输出下一步排查清单

## 不适用场景

不要使用这个 Skill 处理：

- 没有任何指标、时间范围或对比基准的泛泛讨论
- 只做单一有序路径转化，应使用 `funnel-analysis`
- 只做留存矩阵，应使用 `retention-cohort-analysis`
- 只写最终报告，应使用 `data-analysis-report-writer`
- 需要判断 SQL 是否算错，应使用 `sql-reviewer`

## 输入信息

最少输入：

- 异常指标
- 异常时间范围
- 对比基准：环比、同比、上周同期、实验对照等
- 已知现象或初步数据

推荐输入：

- 指标口径和计算逻辑
- 可用维度：渠道、地区、端、用户类型、商品、套餐、内容类型等
- 相关业务事件：活动、改版、投放、价格、库存、算法、系统故障
- 历史波动范围
- 数据表、看板或 SQL 结果
- 业务方已经排除或怀疑的原因

## 上下文建议

优先使用这些模板准备上下文：

- [分析上下文模板](../../context/templates/analysis-context.md)：适合指标异常和专题归因
- [指标上下文模板](../../context/templates/metric-context.md)：适合口径不清或指标争议
- [报告上下文模板](../../context/templates/report-context.md)：适合后续沉淀成复盘报告

如果问题明显属于某个行业，建议补充行业上下文：

- [电商行业上下文](../../context/industries/ecommerce.md)
- [SaaS 行业上下文](../../context/industries/saas.md)
- [内容社区行业上下文](../../context/industries/content-community.md)

上下文不足时，先输出假设树和验证数据需求，不要直接断言原因。

## 分析流程

1. 确认异常是否真实：口径、数据延迟、采集、分母变化、节假日和自然波动。
2. 拆解指标公式，识别核心驱动因子。
3. 按时间、结构、人群、渠道、地域、产品、供给、体验等维度定位异常集中点。
4. 将可能原因分成数据问题、流量问题、转化问题、结构问题、供给问题、产品问题、外部因素。
5. 为每个假设设计验证指标、查询维度和所需数据。
6. 按影响大小、可验证性、可行动性排序。
7. 输出结论边界：哪些能确认，哪些只是待验证。

## 输出格式

```markdown
## 归因分析结论

## 异常确认

## 指标拆解

核心指标 = 驱动因子 A * 驱动因子 B * 驱动因子 C

## 假设树

| 假设 | 可能机制 | 需要验证的数据 | 优先级 |
| --- | --- | --- | --- |

## 已知证据

## 下一步验证计划

| 步骤 | 要查什么 | 维度/口径 | 预期判断 |
| --- | --- | --- | --- |

## 可行动建议

## 待确认问题
```

## 质量标准

输出必须：

- 先确认异常是否真实，再讨论原因
- 明确指标公式和拆解维度
- 不把相关性直接写成因果
- 每个假设都要对应验证数据
- 建议要区分“立刻能做”和“验证后再做”
- 对数据口径、样本量、季节性和业务事件保持敏感

## 示例 Prompt

```text
请用 business-root-cause-analysis 分析这个问题。

背景：SaaS 产品 5 月第 3 周新用户激活率从 42% 降到 31%。
激活口径：注册后 7 天内完成创建工作区、邀请成员、完成一次核心任务中的任意 2 个。
对比基准：过去 4 周均值。
已知变化：
- 5 月 15 日上线了新版引导页
- 付费投放渠道 B 的注册占比从 20% 提升到 38%
- 产品团队反馈没有大面积故障
可用维度：渠道、设备、地区、注册类型、是否进入引导页。

请输出归因假设树、验证路径和下一步建议。
```