data-analysis

数据分析技能

目的

指导所有进行产品或 GTM 数据分析的人，开展严谨且有助于决策的分析工作。此技能有三种模式：

1. 咨询 / 指导 — 用户描述一个数据问题 → 引导其采用合适的框架，指出偏差，并推荐分析方法。
2. 动手执行 — 用户提供数据 → 使用 Python/SQL 按照最佳实践开展分析。
3. 审查 / 审计 — 用户分享现有分析、指标或仪表板 → 对其进行评估并推荐改进方案。

始终提供结构化交付成果，而不是对话式建议。

输出规范

只提供用户实际会用到的内容。切勿将内部脚手架泄露到输出中：

• 不要提供读者无法查看的引用（“§3.2”“根据知识库”“KB §1.4”）。
• 不要叙述模式或流程（“模式：生成”“我已掌握所需信息”“按照此技能的方法”）。
• 交付成果中不要包含技能交接之类的闲聊。

默默应用框架——只有在有助于读者时才提及框架名称，而不是为了展示工作过程。缺少上下文时，用一行说明假设后继续；不要盘问用户。

核心原则

每条建议都必须以这些第一性原理为依据。需要详细方法论或用户提出深入问题时，请阅读完整知识库 references/knowledge-base.md。

1. 决策优先

从决策出发，而不是从数据出发。开始任何分析前，先回答：

• 谁是决策者？
• 基于这份分析结果，他们会采取什么不同的行动？
• 该决策实际需要多高的精度？
• 分析成本是否值得决策带来的价值？

如果分析不会改变决策，就直言不讳，并建议跳过。

2. 探索 ≠ 验证

绝不要把探索过程中发现的模式当作已验证的结论。探索用于提出假设；验证则使用留出数据检验这些假设。呈现探索性发现时，务必将其标注为假设，并建议后续验证步骤。

3. 关注变异

报告分布，而不只是平均值。除均值外，还应列出 P25、中位数、P75 和 P90。在对指标变动做出反应之前，先根据历史 σ 构建控制图，标明上下限。区分普通原因变异（稳定的系统噪声）与特殊原因变异（需要调查的真实信号）。

4. 偏差意识

在每项分析中主动检查并指出以下偏差：

• 幸存者偏差：你是否只分析了留存下来的用户 / 交易？流失用户、失败交易以及从未推进的潜在客户又如何？
• 基准率忽视：样本量是否足以判断结果与历史基准率有所不同？
• 锚定效应：某个单一群组或基准是否扭曲了分析结果？
• 叙事谬误：是否根据顺序相关性构建了因果解释？
• 辛普森悖论：按关键细分维度分层后，整体趋势是否会反转？

5. 统计严谨性

• 始终同时报告指标和样本量。
• 对比例和比率报告 95% 置信区间。
• 对 A/B 测试：运行前计算所需样本量，定义一个主要指标，不要提前查看结果，也不要提前停止。
• 对预测：区分点估计和预测区间。

工作流

A. 指标设计

当用户询问“我应该衡量什么”或需要指标层级时：

交付成果：指标层级文档

# Metric Hierarchy: [Product/Team]

## North Star Metric
- Definition: [precise definition]
- Why: [captures value delivered to users, not just business output]
- Measurement: [exact SQL/event logic]

## L1 Input Metrics (direct drivers of north star)
| Metric | Definition | Owner | Cadence |
|--------|-----------|-------|---------|
| ...    | ...       | ...   | ...     |

## L2 Input Metrics (levers teams can directly influence)
| Metric | Definition | Drives L1 | Owner |
|--------|-----------|-----------|-------|
| ...    | ...       | ...       | ...   |

## Guardrail Metrics (must not degrade)
| Metric | Threshold | Rationale |
|--------|-----------|-----------|
| ...    | ...       | ...       |

关键规则：

• 北极星指标必须体现为用户创造的价值，而不仅仅是收入。
• 自下而上构建：先找出能推动北极星指标的行为，再找到这些行为的领先指标。
• 留存是结果，而非输入——应追溯到激活、功能参与度和回流。
• 纳入护栏指标，防止针对古德哈特定律进行投机取巧。

B. 漏斗分析

当用户询问转化、流失或用户流转时：

交付内容：漏斗分析报告

# Funnel Analysis: [Name]

## Definition
| Step | Event/Condition | Max Time to Next Step |
|------|----------------|----------------------|
| 1    | ...            | ...                  |

## Results
| Step | Users | Step Conversion | Cumulative | 95% CI |
|------|-------|----------------|------------|--------|
| 1    | ...   | ...            | ...        | ...    |

## Segmented View
[Break down by channel, device, cohort — at minimum 2 segments]

## Time Distribution
[How long users take at each step — P25, median, P75]

## Diagnosis
[Where is the biggest drop? Is it consistent across segments?]

## Recommended Actions
[Specific, testable interventions]

避免以下漏斗分析错误：

• 步骤混淆（将两个操作合并为一个步骤）
• 未注明步骤之间的时间窗口
• 统计会话数，而非独立用户数
• 仅基于当前周期内进入漏斗的用户构建分析

C. 队列留存分析

交付内容：留存分析报告

包括：

• 基于时间的队列曲线（注册周/月）
• 行为队列对比（已激活与未激活、使用功能 X 的用户与未使用的用户）
• 曲线形态诊断：曲线是否趋于平缓（找到留存核心用户），还是降至零（没有 PMF）？
• 跟踪第二个顿悟时刻，而不仅是第一个
• 明确指出干预最有效的具体留存周期

D. 销售与收入分析

当用户询问销售管道、预测、赢单率或收入时：

交付内容：收入分析报告

根据相关情况涵盖：

• 销售管道速度 =（商机数 × ACV × 赢单率）/ 平均销售周期——拆解各项，找出拖累业绩的因素
• 交易延期情况，按阶段、销售代表和交易规模细分
• 销售管道覆盖率：根据历史赢单率验证（而非行业基准）
• 预测准确度：计算 MAPE，按预测人员和交易类型跟踪偏差
• 收入队列 NRR：按获客渠道、ACV 区间和细分市场拆分
• 流失/收入收缩分析：生存曲线、先行指标（登录量下降、功能使用减少、支持请求激增）

对于线索评分：使用所有进入销售漏斗顶端且带有结果标签的线索进行训练，而不只是已成交的交易（幸存者偏差）。

对于 CRM 数据质量：标记僵尸交易（开放时间超过平均周期的 2σ），建议设置最低必填字段，并优先采用自动数据补全，而非手动录入。

E. A/B 测试设计与审查

交付内容：实验设计文档或审计报告

设计时：

# Experiment: [Name]

## Hypothesis
[Specific causal claim, not vague improvement goal]

## Primary Metric
[Single metric the test is powered for]

## Guardrail Metrics
[Metrics that must not degrade]

## Sample Size Calculation
- Baseline rate: X%
- MDE: Y% (smallest change worth acting on)
- Power: 80%
- Required N per arm: Z

## Duration
[Pre-specified, covers at least one full business cycle]

## Analysis Plan
[Pre-registered: primary metric, segments to examine, correction method]

审计时，检查是否存在：窥探数据、多重比较未进行校正、分析单位错误、新奇效应、样本比例不匹配，以及将统计功效不足的测试判定为“无效果”。

无法进行随机实验时，建议使用准实验方法（DiD、回归不连续、合成控制），并明确检查其假设。

F. 仪表板审查/审计

审查现有仪表板或指标设置时：

交付内容：仪表板审计报告

针对每项指标/仪表板，回答：

1. 这项变化会影响哪项具体决策？
2. 由谁做出该决策，决策频率如何？
3. 定义是否精确，并在各团队间保持一致？
4. 是否有防止指标被操纵的护栏指标？
5. 展示的是分布，还是仅有平均值？
6. 是否包含置信区间或样本量？
7. 是否遵循 Tufte 的数据墨水比例原则（没有图表装饰、直接标注、图表类型恰当）？

标记数据作秀：构建仪表板只是因为有数据，而不是因为某项决策依赖这些数据。

G. 动手分析数据

用户提供实际数据（CSV、数据库等）时：

1. 先验证：检查空值、重复项、架构问题和整洁数据违规情况（值出现在列标题中、一列包含多个变量）。
2. 先探索，再下结论：展示分布，而不只是汇总结果。计算任何聚合值前，先使用直方图、散点图和箱线图。
3. 采用简洁的代码模式：
   • SQL：每个 CTE 只承担一种用途，使用描述性 CTE 名称，优先使用窗口函数而非自连接，并在 CTE 层级添加注释。
   • Python：采用方法链，清晰组织代码单元（导入 → 加载 → 验证 → 探索 → 分析 → 总结），使用参数化笔记本。
4. 标注明确：每项发现都必须标明是探索性（假设）还是验证性（已检验），绝不混淆两者。
5. 提供结构化输出：使用上述适当的交付内容模板，而非自由形式的叙述。

反模式检测

审查任何分析时，都要主动检查以下失败模式，并指出问题：

反模式	信号	修正方法
数据作秀	仪表板没有关联的决策	指定决策者和行动，否则就弃用
指标泛滥	各团队对“活跃”的定义不同	建立规范的指标层级，并统一定义来源
幸存者偏差	分析只基于活跃用户或赢单	明确纳入流失或丢单的群组
相关性 → 因果关系	“做了 X 的用户留存更好，所以要推动 X”	追问：背后的机制是什么？能否进行因果检验？
过度依赖平均值	对偏态分布只报告一个均值	展示 P25/P50/P75/P90 及分布情况
虚假精确	只给出点估计，未提供 CI 或样本量	添加置信区间和样本量
分析瘫痪	等待更多数据，迟迟不做决策	预先规定足够的数据标准，并设定截止日期

何时不应进行分析

遇到以下情况时，应指出问题并建议跳过分析：

• 决策已做出（数据只是事后论证）
• 样本过小，无法区分信号与噪声
• 数据未能衡量关注的现象
• 收集可信数据所需的时间超过了决策的相关时限

参考资料

如需深入了解方法，请阅读 references/knowledge-base.md。其中涵盖：

• 第 1-2 节：第一性原理、认知偏差、整洁数据、数据质量
• 第 3 节：产品分析（指标层级、漏斗、群组、激活、细分）
• 第 4 节：销售分析（销售管道速度、预测、线索评分、NRR、流失、CRM 质量）
• 第 5 节：实验（A/B 测试、准实验方法、护栏指标）
• 第 6 节：分析工作流（SQL/Python 模式、文档、BI 工具）
• 第 7 节：可视化（Tufte 的原则、图表选择、不确定性沟通）
• 第 8 节：反模式（数据作秀、指标泛滥、幸存者偏差、分析瘫痪）

如果用户的问题需要本 SKILL.md 未涵盖的详细方法，请查阅相关章节。