在线广告种类：转化事件被重复触发时怎样保留修复前后记录
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c7971215b0cd.html
📄
在线广告种类：转化事件被重复触发时怎样保留修复前后记录
先给结论：不要急着删除重复的转化记录，也不要直接改回传逻辑。正确顺序是先冻结证据、给每条记录打上“修复前/修复后”标记，再决定哪些数据进入后续分析。重复触发本身不一定是坏事，它至少说明回传链路是通的；真正要区分的是：重复来自同一次转化的多次上报，还是来自两个本应分开的转化被合并计数。
先判断重复属于哪一类，两类处理方式完全不同
把重复触发拆成两种可核对的情况，处理动作差别很大。
- 同一转化被多次上报：用户完成一次表单提交或下单，但页面刷新、回传重试、多端同步导致同一事件被发送多次。特征是转化时间戳接近、订单号或线索 ID 相同、设备与用户标识一致。
- 不同转化被错误合并：两次真实转化因为缺少唯一标识，被系统当成一次或反过来重复计数。特征是时间跨度较大、来源渠道不同、订单号不同但用户标识相同。
区分依据不是看总数涨了多少，而是看能否用订单号、线索 ID、事件 ID 这类业务主键把记录对上。如果主键相同而记录多条，属于第一类；如果主键不同却互相覆盖，属于第二类。只有第一类适合做去重，第二类要先补主键，否则去重会误删真实转化。
修复前：先冻结原始记录，再动手改
发现重复后最常见的错误是立刻在回传代码里加去重逻辑，然后回头发现原始数据已经对不上。可执行的动作是：在修改任何回传或统计逻辑之前，把当前一段时间的原始转化明细导出并单独保存，包含事件时间、业务主键、来源渠道、设备标识和上报次数。
这个动作的结果会直接影响下一步：如果原始明细里同一主键出现多条且时间接近，说明重复发生在回传环节，修复重点在发送端；如果原始明细里主键唯一但统计报表翻倍，说明问题出在统计口径或报表关联，修复重点在数据层。两条路径的修复位置不同，先冻结证据才能避免改错地方。
假设一个场景：某次活动期间表单提交回传被重试，同一线索 ID 在明细里出现三次。冻结后统计这三条的时间差都在数秒内，就可以判定为发送端重试，而不是三个真实用户。这个判断只依赖明细本身，不需要额外假设。
修复后：用标记区分新旧，不要覆盖历史
修复动作完成后，不要直接把旧记录删掉或覆盖。更稳妥的做法是给记录加一个版本字段，例如 record_version，修复前写入 pre_fix，修复后写入 post_fix，同时保留业务主键。
这样做的结果是：后续分析可以按版本分别统计，既能看修复前的重复规模，也能看修复后是否还有重复。如果修复后同一主键仍然出现多条，说明去重逻辑没有覆盖到某个发送路径，需要继续排查；如果修复后主键唯一，就可以把 post_fix 作为后续口径。关键在于新旧记录并存，而不是用新数据替换旧数据。
需要说明的例外是：如果业务主键本身在修复前就不存在，那么加版本字段也无法可靠去重。这时要先补主键，再谈修复前后对比，否则版本标记只是把不可靠的数据分成两份。
什么情况下可以只保留修复后数据
只在一种条件下可以放弃修复前明细：重复记录已经被完整导出并归档，且确认后续分析不再需要按修复前口径回溯。即便满足这个条件，也建议保留归档而不是直接删除，因为一旦发现修复动作影响了其他指标，归档是唯一能还原当时状态的东西。
反过来，如果重复记录涉及计费、结算或对外汇报，修复前明细必须保留。此时“修复后更干净”不能成为删除理由，因为干净的数据无法解释之前为什么多算。
核对修复效果时，别把归零当成唯一证据
修复后重复记录数下降甚至归零，不能单独证明处理正确。归零的合理解释至少有三种：去重逻辑生效、回传链路本身中断导致没有记录、统计口径被改动导致重复不再显示。要区分这三种，需要同时看修复后的总转化量是否与业务侧实际发生的转化数量对得上，以及回传链路是否仍有正常记录。
可执行的动作是：修复后选一个短周期，把系统记录的转化数与业务侧可核对的订单或线索数做一次对照。如果两者接近，说明归零更可能来自去重生效；如果系统记录明显低于业务侧数量，说明可能是链路中断或口径变化，需要回到发送端继续排查。这个对照动作的结果，决定下一步是结束修复还是继续追查。
