分析工作流

数据分析最大的浪费不是算得慢，而是答非所问。80% 的分析失败发生在拿到数据之前：问题没拆对、指标没定准、口径没对齐。本篇给出从问题到行动的完整工作流，并把每个环节常见的坑提前标出来。

四个层次：先定位你在回答什么

层次	要回答的问题	典型场景	输出
描述性（发生了什么）	现状与趋势如何	本月留存为何下降	指标看板、趋势报表
诊断性（为什么会发生）	驱动因素与相关关系	是渠道、功能还是新版本导致的	下钻分析、归因分析
预测性（接下来会怎样）	未来趋势与概率	下周日活区间预测	预测模型、情景推演
决策性（该怎么做）	不同行动的预期收益	该投增长还是该做留存	决策建议、实验方案

注意：越高层次的分析，对实验与统计的证据要求越强。描述性看板回答不了因果问题——「留存下降了」是现象，不是原因。

七步闭环

1. 问题定义（最重要，也最容易被跳过）

把业务问题改写成可回答的数据问题：

业务问题	模糊	可回答版本
「用户变少了？」	少了多少、哪个群体、何时开始	近 30 天 DAU 环比降 X%，主要来自新/老用户中的哪部分
「活动效果怎么样？」	效果好坏的标准是什么	活动期人均 GMV 相对基线提升是否显著，成本 C 换回 GMV G 是否划算

要点：和提需求的人对齐决策上下文——这个分析要给谁用、做什么决定、最晚何时要。分析没有 deadline 和决策对象，就会无限蔓延。问题定义的质量往往取决于能否回到需求本质而非表象。

2. 提出假设

在取数前先写假设（哪怕是直觉）：

• 留存下降与「某版本上线时间」吻合；
• 影响集中在某入口来源；
• 竞品同期动作放大了流失。

假设让后续分析有证伪方向，而不是把所有维度都拆一遍。可用设计思维的「先假设后验证」精神迁移。

3. 定义指标与口径

• 一个分析问题收敛到 1~3 个核心指标，不要什么都算；
• 书面写明口径：分子分母定义、时间窗口、去重键、异常值处理；
• 口径要在正文一页内写完，避免「算完才发现和别人口径不一致」。

指标设计（北极星、指标树、好坏区分）详见指标体系与埋点。

4. 取数

• 先写 SQL 再问数据字典：字段含义、更新频率、是否为抽样；
• 先取小样核对再全量跑，宁可多一次探查查询；
• 涉及多源 join 时明确主表与粒度，防止重复行放大指标。

取数技巧与性能见 SQL 与取数，数据模型原理见后端·数据库。

5. 清洗与验证

• 对每一列做极值与空值检查，别让脏数据悄悄污染结论；
• 用「占比合计=100%」「总-分=0」「期初+流入-流出=期末」等会计等式做快速校验；
• 关键结论出来前先人工抽查原始明细，建立「数据可信」的信心。

6. 分析

• 描述性结论要配基准（环比/同比/与目标比），孤立数字没有意义；
• 下钻遵循「假设→细分」而非「全维度乱切」；
• 注意区分相关与因果：相关性见实验与统计。

7. 结论与行动

• 每条结论给出决策含义与建议行动，附置信程度与局限；
• 结论页采用「先说答案再说推导」的倒金字塔结构（表达规范见可视化与报告）；
• 明确后续跟进：指标是否要上监控、是否要补实验。

常见坑速查

坑	表现	应对
无问题分析	先取数再想干嘛，报表做一堆没人用	开工前用一句话写下问题与决策
口径漂移	两个会议里同一指标数值不同	口径成文并标版本
幸存者偏差	只分析了还留存的用户	明确分析人群的进入/退出规则
把相关当因果	「用得多=导致留存高」	主动用因果推断或实验验证
结论无人可动	报告交上去没有行动项	每一步带 owner 与下一步时间
分析无穷尽	总觉得「还差一个维度」	设定迭代截止，先交 80 分版本
数字炫耀	堆砌图表不回答原问题	每张图必须回答一个问题

检查清单

• [ ] 问题已被改写为可回答的数据问题，明确了决策对象与截止时间
• [ ] 已写出 1~3 条可证伪假设
• [ ] 核心指标 ≤3 个，口径书面写明
• [ ] 已通过抽样核对理解表结构，全量 SQL 结果通过等式校验
• [ ] 结论区分了相关与因果，标注置信程度与局限
• [ ] 报告按倒金字塔给出结论、建议行动与后续跟进项

相关：SQL 与取数 · 指标体系与埋点 · 实验与统计 · 数据原理见后端·数据库 · 问题定义与产品方向·PRD 互链