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

如果遇到不熟悉的占位符或需要检查已连接的工具，请参阅 CONNECTORS.md。

在向利益相关者分享之前，审查分析结果的准确性、方法论和潜在偏见。生成信心评估和改进建议。

使用方法

/validate-data <待审查的分析>

分析可以包括：

对话中的文档或报告
文件 (markdown, notebook, 电子表格)
SQL 查询及其结果
图表及其底层数据
方法论和发现描述

工作流程

1. 审查方法论和假设

检查：

问题定义：分析是否回答了正确的问题？问题是否可能被不同解读？
数据选择：是否使用了正确的表/数据集？时间范围是否合适？
人群定义：分析人群定义是否正确？是否存在非预期的排除？
指标定义：指标定义是否清晰且一致？是否与利益相关者的理解一致？
基线和比较：比较是否公平？时间段、群组大小和背景是否可比？

2. 运行交付前QA检查清单

按照下面的检查清单逐项进行——数据质量、计算、合理性以及呈现检查。

3. 检查常见分析陷阱

系统地对照下面的详细陷阱目录进行审查（连接爆炸、幸存者偏差、不完整时间段比较、分母变化、平均数的平均数、时区不匹配、选择偏差）。

4. 验证计算和聚合

尽可能进行抽查：

独立重新计算几个关键数字
验证小计是否合计等于总数
检查百分比是否（接近）合计为100%
确认同比/环比比较使用了正确的基期
验证过滤器是否一致地应用于所有指标

应用下面的结果合理性检查技术（数量级检查、交叉验证、红旗检测）。

5. 评估可视化

如果分析包含图表：

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

6. 评估叙事和结论

审查：

结论是否得到所展示数据的支持
是否承认了替代解释
不确定性是否得到适当传达
建议是否逻辑上遵循发现
置信度水平是否与证据强度匹配

7. 提出改进建议

提供具体、可操作的建议：

能够加强结论的额外分析
应该注明的注意事项或限制
关键点的更好可视化或表述方式
利益相关者可能想要的缺失背景信息

8. 生成信心评估

将分析评为三个等级：

可以分享 -- 分析方法论合理，计算结果已核实，注意事项已注明。有小的改进建议但不阻碍分享。

分享时需注明注意事项 -- 分析基本正确，但存在特定的限制或假设必须传达给利益相关者。列出必须声明的注意事项。

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

输出格式

## 验证报告

### 总体评估：[可以分享 | 分享时需注明注意事项 | 需要修改]

### 方法论审查
[关于方法、数据选择、定义的发现]

### 发现的问题
1. [严重性: 高/中/低] [问题描述及影响]
2. ...

### 计算抽查
- [指标]: [已验证 / 发现差异]
- ...

### 可视化审查
[图表或视觉呈现方面的问题]

### 改进建议
1. [改进及其重要性]
2. ...

### 需要向利益相关者声明的注意事项
- [必须传达的注意事项]
- ...

交付前QA检查清单

在向利益相关者分享任何分析之前，逐项检查此清单。

数据质量检查

源验证：确认使用了哪些表/数据源。它们对于这个问题是否正确？
时效性：数据对于分析来说足够新。注明“截至”日期。
完整性：时间序列没有意外缺口，没有缺失的片段。
空值处理：检查关键列的空值率。空值已适当处理（排除、填充或标记）。
去重：确认没有因错误连接或重复源记录而导致重复计数。
过滤器验证：所有 WHERE 子句和过滤器都是正确的。没有非预期的排除。

计算检查

聚合逻辑：GROUP BY 包含所有非聚合列。聚合级别与分析粒度匹配。
分母正确性：比率和百分比计算使用了正确的分母。分母不为零。
日期对齐：比较使用相同的时间段长度。部分时间段已排除或注明。
连接正确性：JOIN 类型合适（INNER 与 LEFT）。多对多连接没有导致计数膨胀。
指标定义：指标与利益相关者的定义一致。任何偏差都已注明。
小计合计：各部分之和等于整体（在预期范围内）。如果不相等，请解释原因（例如重叠）。

合理性检查

数量级：数字在合理范围内。收入不为负。百分比在 0-100% 之间。
趋势连续性：时间序列中没有无法解释的跳跃或下降。
交叉引用：关键数字与其他已知来源（仪表板、之前的报告、财务数据）匹配。
数量级顺序：总收入在正确的范围内。用户数与已知数字匹配。
边界情况：边界处会发生什么？空片段、零活动期、新实体。

呈现检查

图表准确性：柱状图从零开始。坐标轴有标签。各面板尺度一致。
数字格式：适当的精度。一致的货币/百分比格式。需要时使用千位分隔符。
标题清晰度：标题陈述洞察，而不仅仅是指标。指定日期范围。
注意事项透明度：明确陈述已知的限制和假设。
可复现性：其他人可以根据提供的文档重现此分析。

常见数据分析陷阱

连接爆炸

问题：多对多连接会静默地倍增行数，导致计数和总和膨胀。

如何检测：

-- 检查连接前后的行数
SELECT COUNT(*) FROM table_a;  -- 1000
SELECT COUNT(*) FROM table_a a JOIN table_b b ON a.id = b.a_id;  -- 3500 (哎呀)

如何预防：

始终检查连接后的行数
如果行数增加，调查连接关系（真的是1:1还是1:多？）
通过连接计数实体时，使用 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%？

交叉验证技术

用两种不同方式计算同一指标 并验证它们是否匹配
抽查单个记录 —— 选择几个特定实体，手动追溯其数据
与已知基准比较 —— 对照已发布的仪表板、财务报告或之前的分析
反向工程 —— 如果总收入是X，每个用户收入乘以用户数量是否约等于X？
边界检查 —— 当过滤到单日、单个用户或单个类别时会发生什么？这些微观结果是否合理？

值得调查的红旗

任何指标在没有明显原因的情况下环比变化超过50%
精确的整数计数或总和（表示存在过滤器或默认值问题）
恰好为0%或100%的比率（可能表示数据不完整）
完全证实假设的结果（现实通常更混乱）
跨时间段或跨分段的相同值（表示查询忽略了某个维度）

可复现性的文档标准

分析文档模板

每个非平凡的分析应包括：

## 分析：[标题]

### 问题
[正在回答的具体问题]

### 数据源
- 表: [schema.table_name] (截至 [日期])
- 表: [schema.other_table] (截至 [日期])
- 文件: [文件名] (来源: [来源])

### 定义
- [指标 A]: [确切的计算方式]
- [分段 X]: [确切的成员确定方式]
- [时间段]: [开始日期] 至 [结束日期], [时区]

### 方法论
1. [分析方法的步骤 1]
2. [步骤 2]
3. [步骤 3]

### 假设和限制
- [假设 1 及其合理原因]
- [限制 1 及其对结论的潜在影响]

### 关键发现
1. [发现 1 及其支持证据]
2. [发现 2 及其支持证据]

### SQL 查询
[所有使用的查询，附注释]

### 注意事项
- [读者在据此采取行动前应了解的事项]

代码文档

对于任何可能重用的代码（SQL, Python）：

"""
分析: 月度群组留存
作者: [姓名]
日期: [日期]
数据源: events 表, users 表
最后验证时间: [日期] -- 结果与仪表板相差在 2% 以内

目的:
    基于首次活动日期计算月度用户留存群组。

假设:
    - “活跃”意味着每月至少有一个事件
    - 排除测试/内部账户 (user_type != 'internal')
    - 全程使用 UTC 日期

输出:
    留存群组矩阵，行为 cohort_month 列，列为 months_since_signup。
    值为留存率 (0-100%)。
"""

分析的版本控制

将查询和代码保存在版本控制（git）或共享文档系统中
注明所使用的数据快照日期
如果用更新后的数据重新运行分析，请记录更改内容和原因
对于重复性分析，链接到先前版本以进行趋势比较

示例

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

/validate-dat

…

在你喜欢的 AI 中提问

文档