📍 WDQWDWQD987AAAAA:136.243.57.164
📱 Mozilla/5.0 (compatible; QlyzeBot/1.0; +https://app.qlyze.io/bot)
🔗 /25bfe27c0335.html
📄

信息流广告转化事件重复触发时怎样保留修复前后记录

核心做法是：不要删掉重复记录，也不要只留一份“修复后”的干净数据。把修复前的原始事件、修复动作、修复后的事件分别留存，并给每条记录打上可区分的标记，让运营、投放、技术三方都能回到同一份事实上去核对。下面分两种条件说明具体选择。

条件一：重复来自同一用户短时间多次上报

如果同一用户在很短时间内产生多条相同转化事件，先判断这是真实多次行为，还是页面或SDK重复上报。区分证据可以看三点：时间间隔是否集中在秒级、设备标识是否一致、事件参数是否几乎完全相同。

这种情况下，修复动作是保留原始流水，另建去重视图，而不是直接在原表里删除。具体做法：

• 给每条原始事件加一个来源标记，例如 raw_before_fix；
• 按用户标识加事件类型加时间窗口生成去重后的记录，标记为 dedup_after_fix；
• 两份记录都保留，报表默认读去重视图，排查时切回原始流水。

这样做的结果是：投放侧看到的转化数会下降，但下降幅度可以被解释；技术侧能证明重复发生在哪一层。下一步应根据去重前后的差值，决定是修上报逻辑，还是调整归因窗口，而不是直接改历史数字。

条件二：重复来自多个角色各自补录或修正

当运营、代理、技术各自对同一批转化做过补录或修正时，问题往往不是技术重复，而是事实版本不一致。这时不适合做自动去重，因为每条记录背后可能是不同角色的判断。

选择依据是：如果分歧集中在“这笔转化算不算”，就保留版本；如果分歧只在“记了几次”，才做去重。实施动作是建立一张变更日志，至少包含：

1. 原始事件标识；
2. 修改人角色；
3. 修改前后数值；
4. 修改原因；
5. 修改时间。

例如假设某次投放中，运营补录了30条转化，技术回滚时又写入30条，结果报表显示60条。保留变更日志后，可以核出这60条来自两次写入，而不是60个真实用户。这个结果会直接影响下一步：是回滚补录，还是保留补录并调整统计口径。

修复前后记录要满足的三个核对条件

无论哪种条件，记录要能被三方核对，至少满足：

• 可追溯：每条修复后记录都能指向对应的修复前记录；
• 可区分：修复前、修复动作、修复后三类信息不混在同一字段里；
• 可复算：给定同一批原始事件，任何人按同一规则都能得到相同的修复后结果。

如果只保留修复后数据，一旦有人质疑转化数，就无法回答“原来是多少、改了什么”。如果只保留修复前数据，投放优化又会继续被重复事件干扰。两者都留，才是可核对的状态。

一个需要提前约定的例外

当平台侧已经对重复事件做过处理，而你本地仍保留原始流水时，两边数字可能长期不一致。这时不要强行让本地数据对齐平台报表，而应明确：平台报表用于投放决策，本地流水用于技术排查。适用条件是你能说明差异来自哪一层；如果说不清，应先暂停用这份数据做预算调整，等核对完成再继续。

保留修复前后记录的目的不是让数字变好看，而是让每个角色都能回到同一份可核对的事实上，再决定下一步动作。