广告归因与对账：为什么两张报表都对，数字却不同

广告报表出现差异，第一反应常是查任务有没有丢数据。但如果一张表按点击日统计，另一张按转化日统计，即使输入完全一致，两张表也不该逐日相等。对账前先对齐比较对象，能省掉大量没有方向的日志排查。

以下是教学用的数据模型与排查方法，不代表某个平台的结算规则。

三种事实分开存

考虑一个用户在周一点击广告 A，周二点击广告 B，周三完成支付。支付发生是事件事实；把它归给 B，是某套规则的计算结果；是否计费及金额多少，又取决于计费规则。

因此可以拆成三类记录：

• 行为事实：点击和支付各自的事件 ID、发生时间、接收时间。
• 归因结果：转化 ID、被归因的触点、权重、模型版本、计算批次。
• 结算明细：结算键、币种、金额、规则版本、账期与调整记录。

这遵循事实建模先声明粒度的原则：先说明一行对应哪次观测，再决定维度与指标。不能把支付金额复制到每个触点后直接求和。Kimball：Fact Tables

例如一笔 100 元转化分给 A、B 各 0.4、0.6，应保存原金额与权重，归因金额分别为 40、60；不能把两行原金额相加得到 200。这里还要约定小数精度、舍入以及余数分配规则，最终总额才能守恒。

对账契约比 SQL 更先一步

一份可执行的对账契约至少包含：数据范围、事件时间轴、时区、转化窗口、模型版本、去重键、退款处理、截止时点与舍入精度。少了其中一项，差异就可能只是隐含定义不同。

Google Ads 的官方说明明确区分部分报表按转化时间和按广告互动时间归集的方式。它说明了“同名转化数”也可能有不同时间含义，实际接入仍要按所用接口与列定义核实。Google Ads：归因报表说明

对于上面的例子，我会同时生成两套视图：按转化日回答“周三发生了多少转化”，按触点日回答“周二投放最终带来了多少转化”。前者适合观察业务发生，后者适合评估投放批次。它们可以在完整观察区间对齐，却不保证每天相等。

实时值为什么需要后续修订

周三凌晨的报表可能没收到支付回传，下午补入；周四收到退款；更晚又发现某个触点无效。若只维护一个可覆盖的聚合数，无法解释这些变化。

一种可追踪的实现是保留 as_of_time 和结果版本：事件表保持来源事实，归因表记录某一截止时点的判断，聚合表从选定版本生成。对外清晰区分“暂定”和“已关账”。关账后再修订使用调整明细，而不是静默改掉旧结果。

窗口越长，迟到容忍度越高，但状态、存储和重算成本也更高。这里没有通用的“七天最好”：应先观察回传延迟分布，再结合合同与业务需要设定窗口。超过窗口的事件必须有明确去向，不能因为窗口关闭就从审计中消失。

从总量差异下钻到事件

我的排查顺序是先统一截止时点，再逐层减少比较范围：

1. 比较双方来源清单、分区完成情况和采集记录数，排除未到齐。
2. 比较去重前后数量、无效事件量与迟到量，找清过滤边界。
3. 按来源、事件日、事件类型拆分差值，避免总量正负抵消。
4. 对问题切片按转化 ID 做全外连接，分成仅左、仅右、双方都有但字段不同。
5. 对共同事件比较触点、权重、窗口判断和规则版本。

差异类别        下一步证据
只在左侧        原始回传、接收时间、右侧过滤原因
两侧归属不同    触点候选集、时区、模型和规则版本
数量相同金额不同  币种、退款、权重、精度与舍入

检查结果要落到少量可复现样本，不停留在“差了 0.2%”。同样的差异比例，在低金额测试活动和核心账期里，风险完全不同。验收阈值需要同时考虑绝对条数、金额和关键来源，且每个已接受差异都应有解释。

参考资料

• Ralph Kimball：Fact Tables ，事实粒度与度量一致性。
• Google Ads：About attribution reports ，归因报表、标准报表与时间口径的差异；平台规则可能更新。