数据思维 · 第 1 篇
假设驱动分析
“没有假设的分析,就像没有目的地的航行——你可能到处都去了,但哪儿也没到。”
在实际工作中,最常见的分析失败模式不是”不会写 SQL”,而是拿到数据后不知道该看什么。假设驱动分析(Hypothesis-Driven Analysis)就是解决这个问题的核心方法论。
什么是假设驱动分析
假设驱动分析的核心思路是:先提出假设,再用数据验证,而不是先看数据再找结论。
传统分析方式往往是”把数据拉出来看看”,结果很容易陷入两个陷阱:
- 数据过载:表太多、字段太多,不知道从哪里下手
- 事后归因:看到数据后强行编故事,把相关性当因果性
假设驱动分析的流程刚好相反:
业务问题 → 提出假设 → 确定验证指标 → 收集/查询数据 → 验证/推翻假设 → 输出结论
一个完整的案例:电商订单下降
场景描述
你是某电商平台的数据分析师,周一早上收到运营总监的消息:
“上周日均订单量比上上周下降了 15%,什么原因?尽快给个分析。”
第一步:明确问题
在动手写 SQL 之前,先把问题拆清楚:
| 维度 | 确认内容 |
|---|---|
| 指标口径 | “订单量”是下单量还是支付成功量?是全品类还是某个品类? |
| 时间范围 | “上周”是自然周还是最近 7 天?对比基准是哪一周? |
| 下降幅度 | 15% 是同比还是环比?有没有季节性波动的影响? |
| 排除因素 | 有没有大促结束的自然回落?有没有系统故障? |
和运营确认后,你明确了:支付成功订单量,本周一到周日 vs 上周一到周日,环比下降 15%,上上周无大促。
第二步:提出假设
根据业务经验和常识,列出可能的原因:
- 假设 1:流量下降了——投放预算减少或渠道出了问题
- 假设 2:转化率下降了——详情页或支付流程出了问题
- 假设 3:客单价没变但某品类出了问题——品类结构变化
- 假设 4:新用户获取减少——获客渠道异常
- 假设 5:老用户流失加速——留存出了问题
第三步:排列优先级
不是每个假设都值得验证。用 “影响大 x 可能性高” 的矩阵排序:
| 假设 | 影响程度 | 可能性 | 优先级 |
|---|---|---|---|
| 流量下降 | 高 | 中 | P0 |
| 转化率下降 | 高 | 中 | P0 |
| 品类结构变化 | 中 | 中 | P1 |
| 新用户获取减少 | 中 | 低 | P2 |
| 老用户流失加速 | 中 | 低 | P2 |
第四步:用数据验证
针对 P0 假设,设计数据查询:
验证假设 1——流量是否下降:
SELECT DATE(visit_date) AS dt,
COUNT(DISTINCT user_id) AS uv
FROM page_views
WHERE visit_date BETWEEN '2025-03-03' AND '2025-03-16'
GROUP BY dt
ORDER BY dt;
结果发现:UV 基本持平,流量没有明显下降。假设 1 排除。
验证假设 2——转化率是否下降:
SELECT CASE WHEN visit_date BETWEEN '2025-03-03' AND '2025-03-09' THEN '上周'
ELSE '本周' END AS week_label,
COUNT(DISTINCT pv.user_id) AS uv,
COUNT(DISTINCT o.user_id) AS buyers,
ROUND(COUNT(DISTINCT o.user_id) * 1.0 / COUNT(DISTINCT pv.user_id), 4) AS cvr
FROM page_views pv
LEFT JOIN orders o ON pv.user_id = o.user_id
AND DATE(o.pay_time) = DATE(pv.visit_date)
WHERE pv.visit_date BETWEEN '2025-03-03' AND '2025-03-16'
GROUP BY week_label;
结果发现:转化率从 3.2% 下降到 2.6%。假设 2 成立!继续深挖。
第五步:深挖根因
转化率下降了,但是哪个环节下降了?拆解漏斗:
| 环节 | 上周转化率 | 本周转化率 | 变化 |
|---|---|---|---|
| 浏览→加购 | 12.0% | 11.8% | -0.2pp |
| 加购→下单 | 45.0% | 44.5% | -0.5pp |
| 下单→支付 | 60.0% | 51.2% | -8.8pp |
下单到支付环节出了大问题!
进一步排查发现:本周三支付网关升级,某银行渠道支付失败率飙升,导致大量用户下单后支付失败。
第六步:输出结论与建议
结论:订单量下降 15% 的主因是支付成功率下降(下单→支付转化率从 60% 降至 51.2%),根因是周三支付网关升级导致 XX 银行渠道异常。
建议:(1) 技术团队紧急修复支付通道;(2) 对支付失败用户推送短信/Push 提醒重新支付;(3) 后续支付网关升级需提前在沙盒环境验证。
假设驱动分析的四个原则
原则一:MECE 原则——假设要互斥且穷尽
MECE(Mutually Exclusive, Collectively Exhaustive)是麦肯锡经典方法论。列假设时确保:
- 互斥:假设之间不重叠
- 穷尽:所有可能性都被覆盖
实操方法:用公式拆解法。例如:
订单量 = UV x 转化率
订单量 = 新用户订单 + 老用户订单
GMV = 订单量 x 客单价
顺着公式拆,天然就是 MECE 的。
原则二:先粗后细——从宏观到微观
不要一开始就钻进细节。先看整体趋势,再逐层下钻:
整体指标 → 分渠道/分品类/分地区 → 具体异常点 → 根因
原则三:对比产生洞察
单独一个数字没有意义,对比才能产生洞察:
- 时间对比:环比、同比
- 空间对比:分城市、分渠道
- 群体对比:新老用户、不同等级用户
- 基准对比:和行业均值、和目标值比
原则四:区分相关性和因果性
看到两个指标同时变化,不要急着下结论。
“冰淇淋销量和溺水人数正相关”——不是因为吃冰淇淋导致溺水,而是因为天热。
验证因果性的方法:
- 控制变量:A/B 测试是最佳手段
- 时间先后:原因应该在结果之前发生
- 排除混淆变量:有没有第三个变量同时影响两者
常见的假设来源
在实际工作中,假设从哪里来?
| 来源 | 举例 |
|---|---|
| 业务经验 | “上次大促后也出现过类似下降” |
| 历史数据 | “去年同期也有季节性波动” |
| 用户反馈 | “最近客服投诉支付失败的量增加了” |
| 竞品动态 | “竞品同期在做大促,可能分流了用户” |
| 产品变更 | “上周上线了新版本,可能影响了体验” |
| 外部环境 | “节假日、天气、政策变化” |
假设驱动 vs 数据探索
假设驱动分析并不排斥数据探索(Exploratory Data Analysis),两者是互补关系:
| 假设驱动分析 | 数据探索 | |
|---|---|---|
| 适用场景 | 有明确业务问题需要回答 | 没有明确问题,想发现机会 |
| 起点 | 业务问题和假设 | 数据本身 |
| 思路 | 演绎法(从假设到验证) | 归纳法(从数据到规律) |
| 风险 | 可能遗漏假设之外的因素 | 可能被噪声误导 |
| 效率 | 高,目标明确 | 较低,但可能有意外发现 |
最佳实践是:日常分析用假设驱动,定期做数据探索发现新机会。
练习题
-
你是一家 SaaS 公司的数据分析师,产品经理告诉你”上个月付费用户续费率从 85% 降到了 78%”。请用假设驱动分析的框架,列出至少 5 个假设,并排列优先级。
-
你发现公司 App 的日活跃用户(DAU)连续三天上升了 20%,但没有任何产品上线或营销活动。请列出可能的假设并设计验证方案。
-
运营同学说”我们最近投放的广告效果变差了,ROI 从 3.0 降到了 1.8”。请用公式拆解法,列出 MECE 的假设清单。
小结
| 要点 | 说明 |
|---|---|
| 核心理念 | 先假设后验证,不要在数据海洋里漫无目的地游泳 |
| 关键步骤 | 明确问题 → 提出假设 → 排列优先级 → 数据验证 → 深挖根因 → 输出结论 |
| 常用方法 | MECE 拆解、公式拆解法、先粗后细、对比分析 |
| 注意事项 | 区分相关性和因果性,不要事后归因 |
下一篇我们将学习 指标体系搭建——如何把业务目标翻译成可量化、可追踪的指标体系。