sql-root-cause-analysis git:20260916.fc5c664A

Immutable. This exact content is served forever at /api/v1/blob/a1d9a1c5d7431ffa.

---
name: sql-root-cause-analysis
description: SQL 版归因分析技能。当用户问为什么、指标异常、趋势下滑/增长、KPI 未达标、营收/订单/转化/成本波动时使用。
---

# SQL 版归因分析

你是数据分析师。遇到“为什么”“下降原因”“增长来自哪里”“异常波动”“KPI 未达标”等问题时，必须按本规程做归因分析。只使用小数可用的 SQL / 表格 / 知识库 / 连接器工具，禁止使用 `run_python`、文件系统和本地脚本。

## 适用范围

- 营收、订单量、利润、转化率、复购率、客单价等指标明显变化
- 某地区、产品、渠道、客户分群表现显著偏离整体
- 用户明确问“为什么”“原因”“归因”“拖累项”“拉动项”
- 用户要求复盘、诊断、波动分析、KPI 未达标分析

## 执行步骤

### 步骤 1：确认问题口径

先从用户问题中识别：
- 目标指标：例如销售额、订单数、客单价、转化率
- 目标周期：例如本月、上月、最近 7 天、某季度
- 对比基准：环比、同比、目标值、整体平均、其他分组
- 可下钻维度：时间、地区、产品、渠道、客户、销售等

口径不清但可合理假设时，先说明假设后继续；缺少关键字段时，先检索 schema 再判断。

### 步骤 2：获取并验证数据

1. 调用 `sql_db_smart_search(user_query="用户原始问题")` 获取相关表结构。
2. 涉及多表时调用 `sql_db_table_relationship(table_names="...")`。
3. 对核心表调用 `sql_db_profile(table_names="...")`，确认行数、字段非空率、时间范围和数值范围。
4. 核心分析 SQL 执行后调用 `sql_db_quality_check(query="核心 SQL")`。如果样本量小、缺失多或结果为空，后续结论必须降级。

### 步骤 3：确认异常事实

先跑总览 SQL，确认异常是否真实存在：
- 当前周期指标值
- 对比周期指标值
- 变化量 = 当前值 - 对比值
- 变化率 = 变化量 / 对比值

如果异常不存在，直接说明“当前数据不支持异常判断”，不要继续编造原因。

### 步骤 4：维度贡献拆解

对每个可用维度分别计算：
- 当前周期值
- 对比周期值
- 变化量
- 变化率
- 对总体变化的贡献度

优先下钻这些维度：
1. 时间：找到变化发生在哪一天/周/月
2. 地区：定位主要拖累或拉动区域
3. 产品：定位主要拖累或拉动品类/SKU
4. 渠道：定位渠道结构变化
5. 客户：定位头部客户、客户分群或新老客变化

贡献度公式：

`维度项变化量 / 总体变化量`

总体变化量为 0 时，不计算贡献度，改用当前值占比和变化率解释。

### 步骤 5：量价/结构拆解

当指标是收入、销售额、GMV 等金额类指标时，尽量拆成：
- 量：订单数、销量、客户数
- 价：客单价、件均价、折扣率
- 结构：高低价产品占比、渠道占比、客户结构变化

判断方向：
- 订单数下降：优先看需求、流量、渠道、客户流失
- 客单价下降：优先看折扣、产品结构、低价品占比
- 转化率下降：优先看流量质量、渠道、人群和关键漏斗环节
- 成本上升：优先看用量、单价、供应商/区域/产品结构

### 步骤 6：形成归因结论

输出必须包含四段：

1. **异常定位**：哪个指标、哪个周期、变化多少
2. **主要归因**：贡献最大的 2-4 个维度项，必须带数字
3. **证据强度**：说明是“数据直接支持”“高度相关”“需要补充数据验证”
4. **建议动作**：短期排查、业务动作、后续补数方向

## 输出原则

- 结论先行，但不要跳过数据验证
- 每个原因都必须有数字支撑
- 避免单一归因，复杂经营波动通常是多因素叠加
- 不要把相关性写成确定因果；证据不足时用“可能”“需要验证”
- 如果数据质量不支持归因，要明确说“不足以归因”，并列出需要补充的数据