广告联盟是什么：转化事件被重复触发时怎样保留修复前后记录
📱 Mozilla/5.0 (compatible; QlyzeBot/1.0; +https://app.qlyze.io/bot)
🔗 /3fedb31e836f.html
📄
广告联盟是什么：转化事件被重复触发时怎样保留修复前后记录
先给结论：如果重复触发来自你自己的埋点或回传脚本，修复时应保留同一转化ID下的“修复前原始记录”和“修复后更正记录”，用状态字段区分，而不是覆盖或删除旧行；如果重复触发来自联盟侧回传或对方系统，你无法改写对方数据，就只能在本方落库时做去重标记，并单独留存原始回传日志。判断走哪条路，取决于重复事件的第一现场在谁手里。
先判断第一现场：重复发生在采集端还是接收端
“广告联盟是什么”在这里不是概念题，而是数据责任边界题：联盟是替你分发广告、并按约定回传转化的一方，转化事件往往要经过落地页脚本、你的服务端、联盟回传接口三段。重复触发的第一现场决定了修复动作的落点。
- 第一现场在本方采集端：同一用户刷新、返回或页面重载导致脚本再次上报，事件ID相同或可推断相同。此时你有权改写自己的落库逻辑。
- 第一现场在联盟接收端：你只上报一次，但联盟后台或回传链路出现重复计数。此时你改不动对方，只能在本方留证。
可区分的证据：拉出同一时间窗的原始上报日志，看重复行的event_id、click_id、occur_time是否完全一致。完全一致通常指向重试或重放；时间戳相差数秒且参数略有不同，更可能是页面被重新触发。这个判断结果直接影响下一步是改脚本还是改对账口径。
条件一：重复源在你可控的采集端，保留双版本记录
适用前提是你自己掌握事件表结构和写入逻辑。做法是给转化记录加一组状态字段，而不是物理删除重复行。
- 新增
record_state字段，取值如raw（修复前原始写入）、corrected（修复后更正）、void（确认作废）。 - 修复动作只做两件事：把原重复行标记为
raw并附上fix_batch批次号；写入一条corrected记录，指向被更正的原始行主键。 - 对账和报表默认只读
corrected与未被更正的raw，把void排除在转化数之外，但保留在审计视图里。
这样做的实际结果是：转化数回落，但你能随时回答“修复前是多少、修复后是多少、差额来自哪几条”。代价是表体积增长，需要在查询层加过滤条件，否则下游报表会把两版都算进去。假设某次活动有100条原始上报，其中12条被判定为重复触发，修复后转化数从100变为88，而审计视图仍能看到那12条及其更正关系——这是说明比较方法的假设例子，不代表任何真实项目数据。
条件二：重复源在联盟或外部接收端，只做本方留证
适用前提是重复计数出现在你无法写入的系统里。这时不要试图在本方“修正”对方数字，而应把原始回传日志原样留存，并在本方对账表里加一列去重标记。
- 留存原始回传报文，包含接收时间、参数原文和来源标识，不做任何清洗。
- 在本方对账表中按
click_id加事件类型做去重，标记dup_suspect，但不删除原始行。 - 与联盟对账时，用本方去重后的数字和原始报文同时呈现，说明差异口径，而不是单方面宣布哪个数字正确。
要注意一个反常现象：本方对账表去重后数字下降，并不自动证明联盟侧统计有误。请求量、回传量或某项统计归零，也可能来自回传延迟、字段缺失、时区差异或对方口径调整。把这些可能性一并列出，比直接下结论更利于后续沟通。
退出旧合作关系时，哪些记录必须留、哪些可以归档
旧系统或旧合作关系退出时，重复触发记录的处置要分两类。必须长期保留的是：原始上报日志、更正批次号、状态字段变更历史，以及与对方往来的对账口径说明。这些是解释历史数字的唯一依据。可以归档或压缩的是：已经确认作废且无争议的重复明细，但仍要保留其主键和作废原因，不能整表清空。
一个可执行的动作是：在退出前导出一次全量快照，按record_state分组计数，并把快照与对账说明一起存档。这个动作的结果是，即使后续旧接口下线、旧脚本停止运行，你仍然能解释“为什么当时的转化数和现在重算的不一样”，而不是只剩一个无法追溯的数字。
例外：确认重复无争议且无对账需求时可以简化
如果重复事件已被双方书面确认、金额已结清、且不存在后续审计或争议可能，可以只保留去重后的结果表和一份作废说明，不必保留全部原始行。但这个例外成立的条件很窄：一旦涉及未结清款项、跨期对账或监管留存要求，就必须回到保留双版本的路径。判断标准不是“现在看起来没问题”，而是“未来是否可能有人要求你还原当时的过程”。
把这条标准落实到动作上：在决定简化前，先确认对账周期是否已关闭、合作方是否已确认最终数字、内部是否还有依赖该数据的报表。三项都确认后，再执行归档，并记录执行人和执行时间，便于日后追溯。
