data-validation

数据验证 Skill

交付前质量检查清单、常见数据分析陷阱、结果合理性核查，以及保证可复现性的文档规范。

交付前质量检查清单

在向利益相关方分享任何分析结果之前，请逐项检查以下清单。

数据质量检查

• 数据源验证：确认使用了哪些表/数据源。它们是否适合回答当前问题？
• 时效性：数据足够新，能支撑本次分析。已记录数据的“截至”日期。
• 完整性：时间序列或细分维度中没有意外缺失。
• 空值处理：已检查关键列的空值率。空值已得到恰当处理（排除、插补或标记）。
• 去重：已确认不存在由错误 JOIN 或重复源记录导致的重复计数。
• 过滤条件验证：所有 WHERE 子句和过滤条件均正确，没有非预期的排除。

计算检查

• 聚合逻辑：GROUP BY 包含所有非聚合列。聚合粒度与分析粒度一致。
• 分母正确性：比率和百分比计算使用了正确的分母。分母不为零。
• 日期对齐：对比使用相同长度的时间段。不完整的时间段已排除或已注明。
• JOIN 正确性：JOIN 类型恰当（INNER 与 LEFT 的选择）。多对多 JOIN 没有放大计数。
• 指标定义：指标与利益相关方的定义一致。任何偏差均已注明。
• 小计求和：在预期的情况下，各部分之和等于整体。若不相等，需说明原因（例如存在重叠）。

合理性检查

• 量级：数值在合理范围内。收入不为负数，百分比介于 0% 至 100% 之间。
• 趋势连续性：时间序列中没有无法解释的跳升或跌落。
• 交叉核对：关键数字与其他已知来源一致（仪表盘、往期报告、财务数据）。
• 数量级：总收入处于合理范围内。用户数与已知数据相符。
• 边界情况：边界处会发生什么？例如空细分群体、零活跃时段、新实体。

呈现检查

• 图表准确性：柱状图从零开始。坐标轴已标注。多个面板之间刻度保持一致。
• 数字格式：精度恰当。货币/百分比格式统一。必要时使用千位分隔符。
• 标题清晰度：标题点明洞察，而不只是指标名称。已注明日期范围。
• 限制说明透明：已材料明确说明已知的局限性和假设。
• 可复现性：他人依据所提供的文档即可复现本次分析。

常见数据分析陷阱

JOIN 数据爆炸

问题：多对多 JOIN 会悄无声息地使行数成倍增加，从而虚高计数和求和结果。

如何检测：

-- Check row count before and after join
SELECT COUNT(*) FROM table_a;  -- 1,000
SELECT COUNT(*) FROM table_a a JOIN table_b b ON a.id = b.a_id;  -- 3,500 (uh oh)

如何预防：

• 每次 JOIN 之后都要检查行数
• 如果行数增加，需排查 JOIN 关系（究竟是 1:1 还是 1:多？）
• 通过 JOIN 统计实体数量时，使用 COUNT(DISTINCT a.id) 而非 COUNT(*)

幸存者偏差

问题：只分析当前仍然存在的实体，忽略了已被删除、流失或失败的实体。

示例：

• 分析“当前用户”的行为，会遗漏已流失的用户
• 研究“正在使用我们产品的公司”，会忽略那些评估后离开的公司
• 只研究“成功”结果的特征，而不研究“失败”结果

如何预防：得出结论之前，先问一问“谁不在这个数据集里？”

不完整时段对比

问题：将不完整的时段与完整时段进行比较。

示例：

• “1 月收入为 50 万美元，而 12 月为 80 万美元”——但 1 月尚未结束
• “本周注册人数下降了”——在周三检查，却与完整的上一周对比

如何预防：始终筛选为完整时段，或比较同一月内相同日期/相同天数的数据。

分母偏移

问题：不同时期之间分母发生变化，导致比率不可比。

示例：

• 转化率提升，是因为你更改了“符合条件”用户的统计口径
• 流失率变化，是因为“活跃”的定义被更新了

如何预防：在所有被比较的时期中使用一致的定义。记录所有定义变更。

平均数的平均数

问题：当各组规模不同时，对预先计算好的平均数再求平均，结果是错误的。

示例：

• A 组：100 名用户，平均收入 50 美元
• B 组：10 名用户，平均收入 200 美元
• 错误：平均数的平均数 = (50 美元 + 200 美元) / 2 = 125 美元
• 正确：加权平均数 = (100 × 50 美元 + 10 × 200 美元) / 110 = 63.64 美元

如何预防：始终从原始数据进行聚合。绝不要对已预先聚合的平均数再求平均。

时区不匹配

问题：不同数据源使用不同时区，导致数据错位。

示例：

• 事件时间戳使用 UTC，而面向用户的日期使用本地时间
• 每日汇总所用的截止时间不一致

如何预防：在分析前将所有时间戳统一为单一时区（推荐 UTC），并记录所用时区。

分群中的选择偏差

问题：分群依据的是你正在衡量的结果本身，从而形成循环论证。

示例：

• “完成引导流程的用户留存率更高”——显然，他们是自我选择的结果
• “高级用户带来更多收入”——他们之所以成为高级用户，正是因为他们产生了收入

如何预防：基于处理前的特征定义分群，而不是基于结果。

结果合理性检查

量级检查

对于分析中的任何关键数字，都应通过“常识判断”进行验证：

指标类型	合理性检查
用户数	是否与已知的 MAU/DAU 数据相符？
收入	与已知的 ARR 相比，数量级是否正确？
转化率	是否介于 0% 与 100% 之间？是否与仪表盘数据一致？
增长率	月环比 50% 以上的增长是否现实，还是存在数据问题？
平均数	结合你对分布的了解，该平均数是否合理？
百分比	各分群百分比之和是否约为 100%？

交叉验证方法

1. 用两种不同方式计算同一指标，并验证二者是否一致
2. 抽查单条记录：选取几个具体实体，手动追溯其数据
3. 与已知基准对比：与已发布的仪表盘、财务报告或既往分析进行比对
4. 反向推算：如果总收入为 X，那么人均收入乘以用户数是否大致等于 X？
5. 边界检查：当筛选到单日、单个用户或单个类别时会发生什么？这些微观结果是否合理？

需要排查的危险信号

• 任何指标在环比期间变化超过 50%，且没有明显原因
• 计数或求和结果恰好是整数（可能说明存在过滤或默认值问题）
• 比率恰好为 0% 或 100%（可能说明数据不完整）
• 结果完美印证了假设（现实通常更为复杂）
• 不同时间段或分群之间数值完全相同（可能说明查询忽略了某个维度）

可复现性的文档规范

分析文档模板

每项非平凡的分析都应包含：

## Analysis: [Title]

### Question
[The specific question being answered]

### Data Sources
- Table: [schema.table_name] (as of [date])
- Table: [schema.other_table] (as of [date])
- File: [filename] (source: [where it came from])

### Definitions
- [Metric A]: [Exactly how it's calculated]
- [Segment X]: [Exactly how membership is determined]
- [Time period]: [Start date] to [end date], [timezone]

### Methodology
1. [Step 1 of the analysis approach]
2. [Step 2]
3. [Step 3]

### Assumptions and Limitations
- [Assumption 1 and why it's reasonable]
- [Limitation 1 and its potential impact on conclusions]

### Key Findings
1. [Finding 1 with supporting evidence]
2. [Finding 2 with supporting evidence]

### SQL Queries
[All queries used, with comments]

### Caveats
- [Things the reader should know before acting on this]

代码文档

对于可能被复用的任何代码（SQL、Python）：

"""
Analysis: Monthly Cohort Retention
Author: [Name]
Date: [Date]
Data Source: events table, users table
Last Validated: [Date] -- results matched dashboard within 2%

Purpose:
    Calculate monthly user retention cohorts based on first activity date.

Assumptions:
    - "Active" means at least one event in the month
    - Excludes test/internal accounts (user_type != 'internal')
    - Uses UTC dates throughout

Output:
    Cohort retention matrix with cohort_month rows and months_since_signup columns.
    Values are retention rates (0-100%).
"""

分析的版本控制

• 将查询和代码保存在版本控制系统（git）或共享文档系统中
• 记录所用数据快照的日期
• 如果分析使用更新后的数据重新运行，应记录变化内容及原因
• 对于周期性分析，链接到以往版本，以便进行趋势对比