validate-data

/validate-data - 分享前验证分析

如果你看到不熟悉的占位符，或需要确认哪些工具已连接，请参阅 CONNECTORS.md。

在与利益相关方分享之前，审查分析的准确性、方法论和潜在偏差。生成置信度评估和改进建议。

用法

/validate-data <analysis to review>

分析内容可以是：

• 对话中的文档或报告
• 文件（markdown、notebook、电子表格）
• SQL 查询及其结果
• 图表及其底层数据
• 对方法论和结论的描述

工作流程

1. 审查方法论和假设

检查以下内容：

• 问题框定：分析是否回答了正确的问题？问题是否可能有不同的理解方式？
• 数据选择：是否使用了正确的表或数据集？时间范围是否合适？
• 样本定义：分析样本是否定义正确？是否存在非预期的排除项？
• 指标定义：指标定义是否清晰一致？是否与利益相关方的理解相符？
• 基线与对比：对比是否公平？时间段、队列规模和场景是否可比？

2. 运行分享前质量检查清单

按照下方清单逐项检查，涵盖数据质量、计算、合理性和呈现方式。

3. 检查常见分析陷阱

对照下方详细的陷阱目录进行系统性审查（连接膨胀、幸存者偏差、不完整的周期对比、分母漂移、平均数的平均数、时区不匹配、选择偏差）。

4. 验证计算和聚合

在可能的情况下，抽查以下内容：

• 独立重新计算几个关键数字
• 验证小计之和是否等于总计
• 在预期情况下，检查百分比之和是否为 100%（或接近 100%）
• 确认同比/环比对比使用的基期正确
• 验证筛选条件在所有指标中是否一致应用

应用下方的结果合理性检查技术（量级检查、交叉验证、异常信号检测）。

5. 评估可视化

如果分析包含图表：

• 坐标轴起点是否合适（柱状图应从零开始）？
• 对比图表的刻度是否一致？
• 图表标题是否准确描述了所展示的内容？
• 可视化是否可能误导快速浏览的读者？
• 是否存在截断的坐标轴、不一致的间隔或会扭曲感知的 3D 效果？

6. 评估叙述和结论

审查以下方面：

• 结论是否得到所展示数据的支持？
• 是否说明了其他可能的解释？
• 不确定性是否得到了恰当的传达？
• 建议是否从研究发现中合乎逻辑地推导出来？
• 置信水平是否与证据强度相匹配？

7. 提出改进建议

提供具体、可执行的建议：

• 能够加强结论的补充分析
• 应当说明的注意事项或局限性
• 针对关键要点的更好的可视化或表述方式
• 利益相关方可能想要的缺失背景信息

8. 生成置信度评估

按照三级量表对分析进行评级：

可以分享 —— 分析方法健全，计算已验证，注意事项已说明。仅有少量改进建议，无阻碍性问题。

附注意事项后分享 —— 分析基本正确，但存在具体的局限性或假设，必须向利益相关方说明。列出必需的注意事项。

需要修改 —— 发现具体错误、方法论问题或缺失的分析，应在分享前解决。按优先级顺序列出必需的修改。

输出格式

## Validation Report

### Overall Assessment: [Ready to share | Share with caveats | Needs revision]

### Methodology Review
[Findings about approach, data selection, definitions]

### Issues Found
1. [Severity: High/Medium/Low] [Issue description and impact]
2. ...

### Calculation Spot-Checks
- [Metric]: [Verified / Discrepancy found]
- ...

### Visualization Review
[Any issues with charts or visual presentation]

### Suggested Improvements
1. [Improvement and why it matters]
2. ...

### Required Caveats for Stakeholders
- [Caveat that must be communicated]
- ...

---

分享前质量检查清单

在与利益相关方分享任何分析之前，请逐项完成此清单。

数据质量检查

• 数据源验证：确认所用的表/数据源。它们是否适用于当前问题？
• 时效性：数据足够新，可以支撑分析。已记录“截至”日期。
• 完整性：时间序列中没有意外缺口，也没有缺失的分段。
• 空值处理：已检查关键列的空值比例。空值已得到适当处理（排除、填充或标记）。
• 去重：已确认不存在因错误连接或重复源记录导致的重复计数。
• 筛选条件验证：所有 WHERE 子句和筛选条件均正确，没有非预期的排除。

计算检查

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

合理性检查

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

呈现检查

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

常见数据分析陷阱

连接膨胀

问题：多对多连接会悄无声息地使行数成倍增加，导致计数和求和虚高。

如何发现：

-- 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)

如何预防：

• 连接后务必检查行数
• 如果行数增加，需排查连接关系（它真的是 1:1 还是 1:多？）
• 通过连接统计实体时，使用 COUNT(DISTINCT a.id) 而非 COUNT(*)

幸存者偏差

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

示例：

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

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

不完整时段比较

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

示例：

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

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

分母偏移

问题：各时间段之间分母发生变化，导致比率无法比较。

示例：

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

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

平均数的平均数

问题：当各组规模不同时，对预先计算的平均数再取平均，会得到错误结果。

示例：

• A 组：100 名用户，平均收入 50 美元
• B 组：10 名用户，平均收入 200 美元
• 错误：平均数的平均数 = (50 美元 + 200 美元) / 2 = 125 美元
• 正确：加权平均数 = (10050 美元 + 10200 美元) / 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）或共享文档系统中
• 记录所用数据快照的日期
• 如果使用更新后的数据重新运行分析，请记录改动内容及原因
• 链接到定期分析的历史版本，以便进行趋势对比

示例

/validate-data Review this quarterly revenue analysis before I send it to the exec team: [analysis]

/validate-data Check my churn analysis -- I'm comparing Q4 churn rates to Q3 but Q4 has a shorter measurement window

/validate-data Here's a SQL query and its results for our conversion funnel. Does the logic look right? [query + results]

提示

• 在任何高风险的汇报或决策之前，运行 /validate-data
• 即使是快速分析也值得做一次合理性检查 -- 只需一分钟，就能保住你的可信度
• 如果验证发现问题，请修复后重新验证
• 将验证输出与分析结果一并分享，以增强利益相关者的信心