业务方说“报表数不对”——你第一步该干什么？

这是每个做报表的人都躲不掉的场景：早上刚坐下，投放同学在群里甩过来一句“昨天的ROI报表数不对，比我在广告后台看到的少了一截”。这道题面试官不是想听你背排查手册，而是想看你有没有一套稳定的排查方法论——遇到“数不对”是慌乱地翻SQL，还是有章法地缩小范围。我在某短剧出海公司做广告ROI报表，这种质疑几乎每个月都会来一次，处理多了就沉淀出了固定套路。

真实场景：ROI报表比广告后台少了15%

我在某短剧出海公司负责广告ROI报表。有一次投放同学反馈：报表上某渠道昨天的安装量比渠道后台少了差不多15%，质疑我们数据丢了。我当时没有直接去翻ETL代码，而是先拉着他把双方的口径写在同一个文档里，逐项对比。结果发现两个差异：一是时区——渠道后台用的是UTC，我们报表用的是业务约定的美东时间，“昨天”这个词在两边根本不是同一个24小时；二是归因口径——渠道后台按点击归因算安装，我们按激活成功算，中间天然有转化损耗。两项加起来，15%的差异完全解释得通，一行代码都不用改。

-- 对口径的第一步：把双方的“昨天”翻译成明确的时间区间
-- 渠道后台（UTC）的“昨天”：
--   2025-03-10 00:00:00 UTC ~ 2025-03-11 00:00:00 UTC
-- 我们报表（美东 UTC-5）的“昨天”：
--   2025-03-10 05:00:00 UTC ~ 2025-03-11 05:00:00 UTC
 
-- 用同一个UTC区间重跑我们的明细，看差异是否收窄
SELECT channel_id,
       COUNT(DISTINCT device_id) AS install_cnt
FROM dwd_ad_install_di
WHERE event_time >= '2025-03-10 00:00:00'   -- 按对方的UTC口径
  AND event_time <  '2025-03-11 00:00:00'
  AND channel_id = 'xx_channel'
GROUP BY channel_id;

把时间口径对齐后差异从15%缩到3%，剩下的3%再用归因口径解释。先对口径的好处是：它成本最低（不用读代码、不用重跑任务），而且命中率最高。

第二步：把问题定义成“最小可复现”

如果口径对齐后数字还是对不上，就要把问题收窄到最小范围。

# “数不对”问题定义模板（我团队的群里就贴着这个）
1. 哪个报表、哪个指标？   例：ROI日报的“新增安装数”
2. 哪个时间、哪个维度切片？ 例：3月10日，US地区，渠道A
3. 期望值 vs 实际值？      例：期望 12,000，报表显示 10,200
4. 期望值的来源是什么？    例：渠道后台截图 / 业务系统查询
 
# 第4条最关键——对方的“正确数字”本身也可能是错的

第4条特别重要。业务方拿来对比的“正确数字”，可能来自另一张口径不同的报表，甚至来自他自己手工跑的SQL。先确认参照物本身可信，再开始查自己的链路，不然会白白排查一天。

第三步：沿链路分层对数，找到分界点

确认真的有数据问题后，才进入技术排查。核心动作是分层对数：同一个统计口径，在链路的每一层各跑一遍，看数字从哪一层开始不对。

-- 同一口径在各层分别统计，从下游往上游查
-- 1. ADS层（报表直接读的表）
SELECT COUNT(DISTINCT device_id) FROM ads_roi_daily
WHERE dt = '20250310' AND country = 'US' AND channel = 'A';
 
-- 2. DWS层（轻度汇总）
SELECT SUM(install_cnt) FROM dws_ad_channel_1d
WHERE dt = '20250310' AND country = 'US' AND channel = 'A';
 
-- 3. DWD层（明细）
SELECT COUNT(DISTINCT device_id) FROM dwd_ad_install_di
WHERE dt = '20250310' AND country = 'US' AND channel = 'A';
 
-- 4. ODS层（原始数据）
SELECT COUNT(DISTINCT device_id) FROM ods_ad_install
WHERE dt = '20250310' AND country = 'US' AND channel = 'A';
-- 哪两层之间数字跳变，问题就在那一层的加工逻辑里