百度广告代理转化事件被重复触发时怎样保留修复前后记录
📱 Mozilla/5.0 (compatible; QlyzeBot/1.0; +https://app.qlyze.io/bot)
🔗 /2728ecd4906b.html
📄
百度广告代理转化事件被重复触发时怎样保留修复前后记录
结论先说：修复前后记录能不能保留，取决于你在修复动作发生之前，是否已经把“谁在什么时间用什么依据判定重复”和“判定后改了什么”分成两份独立记录。如果只有一份日志，修复动作会覆盖原始状态，事后无法区分是代码问题还是判定口径问题。反例是：当重复触发来自同一用户短时间内多次提交、且这些提交本身都是真实转化时，删除重复记录等于抹掉真实数据，此时应保留全部原始事件，只加标记，而不是合并。
先分清“重复事件”与“重复计数”是两件事
很多团队把重复触发和重复计数混为一谈。重复触发指转化事件在数据源层面被上报了多次；重复计数指统计口径把多次上报算成了多个转化。前者是原始数据问题，后者是处理逻辑问题。修复动作针对的对象不同，记录方式也不同。
如果重复来自页面上的转化代码被多次加载，原始事件本身是冗余的，修复动作是去重。如果重复来自统计任务被重复执行，原始事件是干净的，修复动作是修正任务调度。这两种情况下，需要保留的记录字段并不相同：前者要保留事件的时间戳、来源标识和去重规则版本；后者要保留任务执行记录、时间窗口和修正前后的计数结果。把两类问题写在同一张表里，修复后就无法回溯到底是哪一层出的错。
修复前记录要冻结判定依据，而不是只存结果
假设一个场景：某条转化在一天内被记录了三次，运营认为这是重复，技术认为这是三次真实提交。此时如果直接按“去重后保留一条”处理，分歧就被结果掩盖了。可核对的做法是在修复前先写入一条判定记录，包含：判定人角色、判定时间、判定所依据的字段（例如订单号、提交时间间隔、设备标识）、以及判定时看到的原始条数。
这条记录的作用不是追责，而是让后续修复有可比的基准。修复后再写入一条修复记录，包含：实际执行的动作（删除、合并、加标记）、动作影响的记录条数、执行人和执行时间。两条记录用同一个事件标识关联。这样即使后来发现判定错了，也能看到当时是基于什么信息做出的判断，而不是只剩一个无法解释的结果。
保留修复前后记录时，最容易忽略的是“口径版本”
转化事件是否重复，往往依赖一个判定口径，比如“同一设备十分钟内多次提交算重复”。这个口径会随业务调整而变化。如果修复记录里不写口径版本，三个月后回看数据，无法判断当时的去重是合理的还是过时的。
可操作的动作是：每次修改判定口径时，给口径分配一个可引用的标识，并在修复记录中写入该标识。这样当不同角色对同一段历史数据有不同理解时，可以先把口径标识对齐，再讨论数据本身。口径标识不需要复杂编码，一个递增的短字符串即可，关键是让修复记录能指向它。这个动作的结果是：后续核对时，分歧会从“数据对不对”转移到“口径是否适用”，讨论范围更小，也更容易得出结论。
什么情况下不该合并重复事件
如果重复触发来自同一用户的多次真实转化行为，例如同一账户在不同时间完成了多次符合条件的动作，那么这些事件在业务上是独立的。此时正确的动作是保留全部原始事件，只增加一个“疑似重复”的标记字段，由人工或规则决定是否计入统计，而不是在数据层删除。
判断依据可以是一个假设例子：假设同一用户在十分钟内提交了两次，两次都带有不同的订单号，那么即使时间间隔很短，也不能直接判定为重复触发。反过来，如果两次提交的订单号相同、时间戳相同，来源标识也相同，那么更可能是重复上报。这个比较方法的关键是找到能区分“同一事实”和“同一动作被记录多次”的字段，而不是只看时间间隔。
下一步动作：先建一份最小可核对的修复台账
不需要一次性搭建完整的数据治理流程。可以先从一份最小台账开始，至少包含以下字段：事件标识、发现时间、判定依据、判定口径标识、修复动作、修复时间、修复后条数。每次处理重复触发时，先写判定依据，再执行修复，最后补全修复动作。
这份台账的作用是让修复前后记录保持可分离。如果后续发现某次修复影响了真实转化，可以按事件标识回溯到当时的判定依据，而不是只能看到被修改后的数据。执行这个动作后，下一步的核对会从“凭印象争论”变成“按台账逐条比对”，这是把分歧转成可核对项目的实际起点。
