analysis-qa

审查清单

在向利益相关方展示结果前，请逐项检查以下各部分。

数据基础

• 来源正确：已确认所用的表和数据集适用于当前问题
• 数据时效性：数据足够新；已注明“数据截至”日期
• 覆盖范围：数据集中不存在意外的时间间隔或缺失片段
• 空值处理：已检查关键列的空值率；空值已排除、填充或明确标记
• 重复项控制：行数确认没有因错误的联接或重复的源记录而重复计数
• 筛选准确性：已验证每个 WHERE 子句和筛选条件；没有意外排除或纳入任何内容

计算完整性

• GROUP BY 正确性：所有非聚合列都出现在 GROUP BY 中；聚合粒度与分析问题相符
• 分母有效性：比率和百分比使用预期的基础总体；已防止除以零
• 时间对齐：比较的时间段持续时间相等；不完整时间段已排除或特别说明
• 联接行为：JOIN 类型经过有意选择（INNER 与 LEFT）；多对多关系没有在不知情的情况下推高总数
• 指标准确性：计算出的指标符合业务定义；任何偏差均已记录
• 可加性一致性：预期情况下，小计之和等于报告总计；对于不可加的情况（重叠、重复计数）已作说明

合理性评估

• 数量级：关键数值处于可信范围内；收入非负；百分比在 0-100% 之间
• 趋势连贯性：时间序列没有无法解释的骤升或骤降
• 外部一致性：核心数据与仪表板、财务报告或早前的分析一致
• 粗略计算：总收入大致等于人均收入乘以用户数，等等
• 边界情况：结果在边界情况下合理，例如单日、单个用户或单个类别

呈现质量

• 图表准确：柱状图从零开始；坐标轴带有标签；各面板的刻度保持一致
• 格式清晰：数字使用适当的精度、一致的货币和百分比格式，并带有千位分隔符
• 标题明确：标题传达洞见，而不只是指标名称；包含日期范围
• 限制透明：事先说明局限和假设
• 可复现性：其他分析师能够根据提供的文档复现分析

识别常见错误

多对多联接导致计数虚高

问题所在：联接两个存在多对多关系的表时，行数会在不知情的情况下成倍增加，导致计数和求和结果虚高。

检测方法：

-- Compare row counts before and after the join
SELECT COUNT(*) FROM orders;          -- 1,000
SELECT COUNT(*) FROM orders o
JOIN line_items li ON o.id = li.order_id;  -- 3,500 (unexpected inflation)

预防措施：

• 始终比较联接前后的行数
• 验证联接关系的实际基数
• 使用 COUNT(DISTINCT o.id)，通过多行联接准确统计实体

幸存者偏差

问题所在：分析只涵盖仍然存在的实体，忽略已被移除、流失或失败的实体。

常见场景：

• 研究“活跃用户”的行为，却忽略所有已离开的用户
• 以“我们平台上的公司”为基准，却跳过那些评估后离开的公司
• 分析“成功”案例的特征，却没有任何“失败”案例作为对照组

预防措施：得出结论前，请先问：“这个数据集中缺少哪些对象？如果它们存在，结论会改变吗？”

部分周期比较

问题所在：将仍在进行中的月份、周或季度与已结束的周期进行比较。

典型场景：

• “1 月营收为 $500K，而 12 月为 $800K”，但 1 月才过了一半
• 周二查看时说“本周注册人数下降了”，却是拿本周与完整的上一周进行比较

预防措施：仅比较已结束的周期，或按相同的已过天数进行标准化。

分母变化

问题所在：各周期使用的分母群体发生变化，导致比率比较无效。

典型场景：

• 由于缩小了“符合条件的访客”的定义，转化率看起来有所提高
• 由于在分析过程中重新定义了“活跃用户”，流失率发生变化

预防措施：在所有比较周期中统一定义。标记任何定义变更。

对预先计算的平均值求平均

问题所在：对各组平均值求平均会忽略组规模差异，从而得出错误的总体数值。

示例：

• A 组：100 位客户，平均订单金额为 $50
• B 组：10 位客户，平均订单金额为 $200
• 错误的总体平均值：( $50 + $200 ) / 2 = $125
• 正确的加权平均值：(100 * $50 + 10 * $200) / 110 = $63.64

预防措施：始终根据单条记录计算平均值。切勿对已汇总的平均值再求平均。

时区不一致

问题所在：不同源系统使用不同时区记录时间戳，导致每日汇总时间错位以及联接不匹配。

典型场景：

• 后端事件以 UTC 记录，而报告层使用美国太平洋时区
• 两张表对“今天”的定义采用了不同的截止时间

预防措施：分析前将所有时间戳转换为同一个参考时区（UTC 是最稳妥的默认选择）。在交付内容中注明时区。

循环定义分群

问题所在：使用正在衡量的结果本身来定义分群，从而得出同义反复的结论。

典型场景：

• “完成新手引导的用户留存更好”——完成新手引导本身就是留存信号
• “高活跃用户带来更多营收”——正是营收贡献让他们成为高活跃用户

预防措施：根据结果周期之前测量的特征定义分群，而不是根据结果本身。

对结果进行合理性检查

快速量级检查

指标类别	验证方法
用户数量	与已知 DAU/MAU 基准交叉核对
营收总额	与已知 ARR 或近期财务报告进行比较
转化率	必须在 0-100% 之间；与仪表板基线进行比较
增长率	月环比增长 50% 以上是否合理，还是意味着数据存在问题？
平均值	根据分布情况，这个数值是否合理？
分群占比	百分比明细之和是否约为 100%？

交叉验证方法

1. 双重计算：通过两条独立的查询路径计算同一指标，并确认结果一致
2. 记录级抽查：选取少量具体实体，手动追踪其数值的完整计算过程
3. 基准比较：与已发布的仪表板、财务系统或此前的分析结果进行核对
4. 反向算术核验：如果营收总额为 X，用户数为 N，那么 X / N 是否接近报告中的人均数值？
5. 微观切片测试：筛选单日、单个用户或单个类别，确认微观结果合理

需要调查的信号

• 某项指标在相邻周期之间波动超过 50%，且没有明确解释
• 总数或合计值落在可疑的整数上（可能是筛选条件或默认值造成的假象）
• 比率恰好为 0% 或 100%（可能表示数据缺失，而非结果完美）
• 结果与假设吻合得过于完美（真实数据几乎总是杂乱的）
• 不同时间段或细分群体中出现相同的值（表明某个维度可能被忽略）

确保可复现性

分析文档模板

每项重要分析都应附上以下文档：

## Analysis: [Title]

### Business Question
[The precise question this work answers]

### Sources
- Table: [schema.table_name] (snapshot date: [date])
- Table: [schema.other_table] (snapshot date: [date])
- External file: [filename] (origin: [description])

### Metric and Segment Definitions
- [Metric A]: [Precise calculation formula]
- [Segment X]: [Exact inclusion/exclusion criteria]
- [Time window]: [Start] through [end], [timezone]

### Analytical Approach
1. [First step and its purpose]
2. [Second step]
3. [Third step]

### Assumptions and Known Limitations
- [Assumption and why it holds]
- [Limitation and its potential effect on conclusions]

### Results
1. [Finding with supporting evidence]
2. [Finding with supporting evidence]

### Queries
[All SQL and code used, annotated with comments]

### Warnings for the Reader
- [Anything the audience should weigh before acting on these results]

为分析代码添加注释

对于可能被他人复用的 SQL 或 Python：

"""
Title: Monthly Cohort Retention
Author: [Name]
Created: [Date]
Sources: events, users
Last cross-checked: [Date] — matched dashboard within 2%

Objective:
    Build monthly retention cohorts anchored on each user's first event date.

Assumptions:
    - "Active" = at least one recorded event in the calendar month
    - Internal and test accounts excluded (user_type != 'internal')
    - All timestamps normalized to UTC

Output:
    Retention grid: rows are cohort months, columns are months since first event.
    Cell values are retention percentages (0-100).
"""

保留审计线索

• 将所有查询和脚本存储在版本控制系统或共享知识库中
• 记录每次分析运行所用数据快照的确切日期
• 刷新定期分析时，记录发生了哪些变化以及原因
• 将当前结果链接到先前版本，以便追踪分析本身的趋势