广告平台与BI转化数据对账事件、去重、时区与回传排查做出海应用的数据对账业务端有支付记录广告报表却少一笔或者反过来多出转化都值得检查。直接改 SDK 之前先确认比较的是同一事件、同一日期口径。口径对齐后沿业务记录、SDK 或 Pixel 触发、中间层接收和平台回传核对。哪两层之间出现差异就从那段链路查起。先确认两边在给哪一笔转化记账广告平台和 BI 都在统计转化但它们回答的问题可能不同广告平台在判断哪些转化可以归给广告BI 则按自己的业务事件和来源规则记录结果。没把这层口径对齐后面查技术链路很容易查错方向。先核对当前归因窗口。同样是一笔付费如果发生在广告互动几天之后一边可能仍把它算进广告转化另一边可能已经不再归给这个渠道。点击后七天、观看后一天或者点击后三十天这些窗口需要按当前账户和转化操作核对Facebook 或 Google Ads 的不同设置不能直接套同一个值。再看归因方式。多个渠道同时投放时Facebook 和 Google 可能都把同一笔转化认领到自己的报表里BI 如果按用户来源或另一套归因规则分配就不会得到简单相加的结果。所以先问清楚每一边怎么认领转化再比较数量。用户、设备和事件的去重规则也要一起确认否则同一个人多次操作、换设备操作都可能让两边计数不同。口径接近以后再把日期和时区对齐有时候两边都记录了同一笔转化只是它落在不同的日期里。用户先点击广告过几天才付费按广告互动日统计的列可能把转化记回点击那天按事件发生日统计的 BI会把它记在付费那天。直接拿两个日报比较就会看到一边多、一边少。这里要看具体报表列。Google Ads 也有按转化时间统计的列不能把所有广告报表都理解成按点击日记录。确认日期口径后再核对广告账户、报表导出和 BI 实际使用的时区。尤其是跨日发生的事件时区不同就足以让同一笔记录错开一天。如果换成同一日期口径后差异明显缩小就先处理报表比较方式差异仍然存在再沿着事件链路往下查。沿着业务事件查找到丢失或重复的位置先确认业务端有没有真实事件再看 SDK 或 Pixel 有没有触发。BI 后端已经记录付款不代表广告端一定收到对应事件。上报延迟、网络失败、追踪权限受限都可能影响广告平台拿到的信号。用了 AppsFlyer、Adjust 这类 MMP还要检查中间层有没有收到事件、伙伴映射是否正确、回传有没有成功。业务端有记录而下一层没有就从这两层之间查起不要只盯最终报表猜是哪边出了问题。数量偏多也要查。比如用户在手机和平板上分别操作两次触发是否应该算两个事件广告平台与 BI 如果分别按设备、用户或事件去重得到的数量就可能不同。先确定应该怎样计数再判断有没有重复上报。查完链路还要确认两边怎样识别用户事件收到了也可能关联不到同一个人。用户在手机 A 点击广告在手机 B 完成安装两边能否把这两个行为连起来取决于可用标识和匹配方式。BI 如果有登录账号可能通过账号关联广告平台可用的信号则未必一样。iOS 追踪权限或浏览器隐私模式也会限制可用标识。这里要把“业务事件有没有发生”和“事件能否匹配到广告互动”分开看前者有记录后者没有归因并不矛盾。检查时把用户 ID、设备标识、事件 ID 及其关联规则列清楚才能知道差异具体来自哪一层。最后核对事件定义、金额和估算方式同名事件也可能指向不同业务。广告侧的 Purchase 在什么条件下触发是提交订单还是实际扣款成功BI 如果以订单支付成功为准两边事件名称一样数量也未必一样。收入同样要拆开看。回传 value 是预估金额还是实收金额是否含税币种怎样转换BI 是否已经扣除了退款或其他项目都要按实际定义核对。只比较收入总数往往看不出这些细节。数量还对不上时检查模型和汇总方式。广告报表可能包含模型估算的转化BI 也可能有抽样、补数或延迟汇总。先确认哪些是实际记录、哪些是估算、数据是否已经完整再判断数量差是不是异常。查完以后把差异对应到处理方式日期错开改报表比较方式触发或回传有问题修对应链路同名事件定义不同核对业务条件和映射。模型估算与实测记录之间的差别也要单独写清楚别把所有数量差都当成漏报。对账时逐项记录这些字段选定同一种事件和时间范围把两侧实际使用的定义填进表里。字段名称按自己的系统记录先核对差异再定位丢失、重复或延迟。检查项广告侧记录BI 侧记录时间报表列按互动日还是转化日、账户时区事件发生时间、服务器及展示时区归因当前模型、点击或观看窗口用户来源与归因规则事件触发条件、映射名、是否去重订单或业务事件定义、去重键金额回传值、币种、税与预估口径实收、净收入、退款与汇率口径链路触发、MMP 接收、映射与平台回传业务事件与日志是否存在参考资料Google Ads转化窗口Google Ads按转化时间报告