数据思维 · 第 1 篇

假设驱动分析

“没有假设的分析,就像没有目的地的航行——你可能到处都去了,但哪儿也没到。”

在实际工作中,最常见的分析失败模式不是”不会写 SQL”,而是拿到数据后不知道该看什么。假设驱动分析(Hypothesis-Driven Analysis)就是解决这个问题的核心方法论。


什么是假设驱动分析

假设驱动分析的核心思路是:先提出假设,再用数据验证,而不是先看数据再找结论

传统分析方式往往是”把数据拉出来看看”,结果很容易陷入两个陷阱:

  1. 数据过载:表太多、字段太多,不知道从哪里下手
  2. 事后归因:看到数据后强行编故事,把相关性当因果性

假设驱动分析的流程刚好相反:

业务问题 → 提出假设 → 确定验证指标 → 收集/查询数据 → 验证/推翻假设 → 输出结论

一个完整的案例:电商订单下降

场景描述

你是某电商平台的数据分析师,周一早上收到运营总监的消息:

“上周日均订单量比上上周下降了 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),两者是互补关系:

  假设驱动分析 数据探索
适用场景 有明确业务问题需要回答 没有明确问题,想发现机会
起点 业务问题和假设 数据本身
思路 演绎法(从假设到验证) 归纳法(从数据到规律)
风险 可能遗漏假设之外的因素 可能被噪声误导
效率 高,目标明确 较低,但可能有意外发现

最佳实践是:日常分析用假设驱动,定期做数据探索发现新机会


练习题

  1. 你是一家 SaaS 公司的数据分析师,产品经理告诉你”上个月付费用户续费率从 85% 降到了 78%”。请用假设驱动分析的框架,列出至少 5 个假设,并排列优先级。

  2. 你发现公司 App 的日活跃用户(DAU)连续三天上升了 20%,但没有任何产品上线或营销活动。请列出可能的假设并设计验证方案。

  3. 运营同学说”我们最近投放的广告效果变差了,ROI 从 3.0 降到了 1.8”。请用公式拆解法,列出 MECE 的假设清单。


小结

要点 说明
核心理念 先假设后验证,不要在数据海洋里漫无目的地游泳
关键步骤 明确问题 → 提出假设 → 排列优先级 → 数据验证 → 深挖根因 → 输出结论
常用方法 MECE 拆解、公式拆解法、先粗后细、对比分析
注意事项 区分相关性和因果性,不要事后归因

下一篇我们将学习 指标体系搭建——如何把业务目标翻译成可量化、可追踪的指标体系。