筛选结果偏差排查
当报表筛选结果与预期不一致时，基于配置、口径、时间、属性逐层定位根因。
数据分析
异常诊断全行业筛选结果偏差排查是 ThinkingAI 行业 Skill 库中的一项数据排障能力，帮助数据分析师在 AE/TA 报表中发现筛选结果与预期不符、跨报表结果对不上、筛选后异常偏多偏少时，基于报表定义、时间口径、去重逻辑与明细证据逐层收窄根因——不猜原因，只给证据链。这正是 ThinkingAI「10 年行业经验沉淀为开箱即用 Skill」的体现。
#reg_time 过滤后重跑找到了。你的筛选条件一条都没写错，错的是比较本身——两张报表圈的不是同一群人。这 40% 的差异不是数据问题，是队列口径不可比。
一、筛选条件逐条对比
| 对比项 | 事件分析 | 留存分析 | 判定 |
|---|---|---|---|
| 统计事件 | pay_success | pay_success | 一致 |
| 时间范围 | 6 月自然月 | 6 月自然月 | 一致 |
| 用户队列 | 不限队列（全量用户） | 限定 6 月注册队列 | 偏差一 |
| 付费界定 | 任意一次付费触发 | 注册后回访日付费 | 偏差二 |
| 去重逻辑 | 按 #user_id 去重 | 按 #user_id 去重 | 一致 |
二、归因链与证据
事件分析未加 #reg_time 过滤 → 6 月付费的存量老用户全部混入 → 18,760 里有 4,958 个是 6 月前注册的（抽样 50 个差集用户核对，50 / 50 命中）→ 留存分析天然限定初始注册队列 → 两边比的根本不是同一群人。补上「#reg_time 在 6 月」的过滤后重跑：事件分析 13,802 vs 留存分析 13,400，剩余 3% 差异来自留存模型对回访日的界定（注册当日付费不计入回访付费），属可解释范围，证据链闭环。
行业痛点
分析师最常见的困惑不是没有数据，而是数据看起来不对。筛选后结果异常偏多、偏少或为空，约 60% 的分析师每周至少遇到一次，偏差幅度从 20% 到 300% 不等，平均排查耗时 2-4 小时。问题可能藏在报表定义层、时间口径层、筛选逻辑层或数据源头层，不同分析师路径不统一导致结论质量参差不齐。
核心价值
- 四层收窄排查法：定义层 → 结果层 → 样本层 → 明细层，不跳步
- 先定义后结果、先可比后比较、先证据后结论，确保排查结论有据可依
- 上下文拦截机制：先判断问题是否属于筛选偏差排查，不属于时引导到正确 Skill
- 输出闭环结论：根因 + 证据链 + 修正方案 + 验证方法，不草率结束
- 禁止未看定义就猜根因、定义未查清就写 SQL、只给可能原因不给验证等常见错误
适用场景
某报表筛选后结果明显偏多或偏少，怀疑筛选条件或口径问题
两张报表在相近条件下数据对不上，需要定位差异来源
留存分析 vs 事件分析数据不一致，需要验证统计口径或配置问题
筛选后结果为空或异常波动，需要判断时间范围、筛选逻辑还是数据源问题
跨版本或跨项目报表口径对齐，需要标准化排查方法
实战案例
常见疑问
结果为空一定是没数据吗？
不是。结果为空可能是筛选条件与数据不匹配、时间范围过窄或筛选逻辑与报表口径不一致。
能不能直接写 SQL 查明细？
不能跳步。定义层未查清就写 SQL，可能查的是错误口径数据。
和留存分析数据验证有什么区别？
留存数据验证专门解决留存分析 vs 事件分析口径差异；筛选偏差排查更通用。
相关 Skills 推荐
用「筛选结果偏差排查」武装你的 Agent
预约演示，看看它如何在你的业务场景中落地
