data-investigation

数据调查

使用此技能开展快速、准确、可复现的调查，并清晰传达结论，而不是堆砌图表。

目的

每项调查都应在编写第一条 SQL 查询之前，就能用一句话回答。

阶段 1：先明确问题，再查询

1. 先写出一句话结论

编写任何 SQL 之前，先写出预期结论。

示例：队列规模差异是定义问题，而不是产品行为问题。

如果无法写出这句话，说明问题还没有理解清楚。

2. 判断调查类型

类型	触发条件	方法
差异分析	为什么 A 和 B 不一致？	确认差异、定位差异、解释差异
根因分析	为什么这个指标发生了变化？	确认变化是否真实、隔离受影响的细分群体、对齐时间、验证机制
假设检验	X 是否导致 Y？	明确必须满足的条件、检验子主张、确认或否定
可行性检查	这个数字可信吗？	检查粒度、连接、空值、定义重叠

3. 查询前列出 2-3 个相互竞争的假设

不要只基于一个假设开展调查，否则会产生确认偏误。

按可能性排列假设，并注明目前预计哪个假设正确，以及原因。

阶段 2：逐步提高查询的具体程度

1. 先确认，再解释

第 1 步始终是确认异常确实存在，并衡量其幅度。 在确认影响之前，不要跳到原因。

select
    <time_bucket>,
    <source_a_count> as metric_a,
    <source_b_count> as metric_b,
    <source_a_count> - <source_b_count> as gap,
    round(100.0 * (<source_a_count> - <source_b_count>) / nullif(<source_a_count>, 0), 1) as pct_gap
from ...
order by 1

2. 每次按一个维度细分，以定位问题

确认差异后，每一步沿一个维度进行细分：

• 按时间：差异何时出现？
• 按细分群体：哪些对象受到影响？
• 按信号/来源：缺失的是哪条路径？

3. 将时间与上游变更对齐

确定异常开始日期后，检查：

• 相关模型、ETL 作业或应用代码的 git 提交
• 架构迁移或数据源变更
• 指标定义变更
• 发布、营销活动或定价变更等外部事件

可信的根因必须能解释指标为何在当时发生变化。

4. 验证作用机制

确定一个候选原因后，通过机制验证：

• 受影响群体是否符合预测？
• 反事实情况如何？
• 是否有第二个独立信号支持该解释？

不要止步于相关性。

5. 在得出结论前量化每个假设

对每个候选解释都给出一个数字。

示例：

• H1 可解释 1,240 位用户
• H2 可解释 1,050 位用户

如果某个假设无法量化，就还没有得到验证。

阶段 3：SQL 编写规范

调查时使用稳定的时间范围

调查 SQL 应当可复现。除非分析有意用于持续运行且长期适用，否则应优先使用固定范围，而不是滚动窗口。

-- Prefer fixed investigation scope
where created_at >= '2026-02-16'
  and created_at < '2026-04-04'

在重要的 CTE 中明确标注粒度

-- grain: one row per user
with users as (
    ...
)

优先使用命名后的对比结果，而不是原始聚合值

不佳：

select count(*) from ...

较佳：

select
    count(*) as users_in_scope,
    count(distinct org_id) as orgs_in_scope
from ...

保持诊断查询精简，并随时弃用

诊断 SQL 的用途是回答一个问题。不要过早构建庞大且可复用的查询。

阶段 4：沟通规范

开门见山，先给出答案

书面输出的第一句话应陈述结论。

不佳：

我考察了几种可能解释这种差异的原因。

较佳：

差异是因为内部用户未被纳入仪表板查询，却被纳入了数据仓库基准数据。

区分证据与解读

采用如下结构：

1. 结论
2. 证据
3. 拒绝其他假设的原因
4. 建议的下一步行动

说明限制性假设

每项调查都应说明最可能改变结论的关键假设。

示例：

该结论假设受影响周内的后端事件时间戳完整；如果数据摄取有所延迟，差异可能被高估。

第 5 阶段：输出标准

每次调查完成后，都应留下：

1. 一句话答案
2. 最终的 SQL 或笔记本，作为支撑材料
3. 关于被排除假设的说明
4. 后续问题或尚未解决的歧义

常见失败模式

• 把指标定义上的争议当作产品问题
• 比较粒度或时效性不同的数据源
• 未经量化便接受第一个看似合理的解释
• 过早编写一个庞大的查询
• 以图表而非答案收尾

相关技能

• 如果目标是回答业务问题，而非调试分析或指标不一致的原因，请使用 answering-natural-language-questions-with-dbt。