先分清重复来自哪一层:同一访客在一次会话里多次提交,和同一笔转化被多次上报到百度关键词竞价后台,处理方式不同。前者通常要改页面或表单逻辑,后者要改上报链路。修复前先把原始日志留存,修复后不要覆盖旧记录,而是用同一转化标识把前后两条串起来,这样既能对账,也能判断重复是否真的被消除。
采集端重复,指的是表单、按钮或电话拨号在用户侧被多次触发,例如提交后页面没有立即禁用按钮,用户连点两次;或者同一手机号在不同落地页各提交一次。上报端重复,指的是转化只发生一次,但埋点脚本、回传接口或第三方工具把它发了多遍。两者的证据不同:采集端重复往往能看到两条提交时间非常接近、内容高度相似的记录;上报端重复则常见于同一个订单号或同一个转化标识出现多条上报日志。
判断依据可以按下面这组特征区分:
这一步的实际动作是:把修复前的原始日志按时间排序导出,保留转化标识、上报时间、来源参数和触发位置。结果会直接决定下一步是改前端还是改上报链路——改错一层,重复还会以另一种形式出现。
很多团队一发现重复就先去后台删掉多余记录,这会让修复前后的对比失去基准。更稳妥的做法是先冻结一份修复前快照,再动代码或配置。快照里至少要留下三类信息:原始转化标识、每次触发的时间戳、触发时所处的页面或接口。若后台只保留聚合数,就要从服务端日志或表单系统里补齐明细,否则后面无法证明重复是减少了还是只是被隐藏了。
假设某账户把表单提交作为转化,修复前一周内同一手机号出现两条记录,时间相差四秒。冻结快照后,修复动作是在提交成功后立即禁用按钮并给表单加一次性令牌。修复后再看同一手机号的记录,如果只剩一条,且时间戳与用户实际提交一致,说明采集端重复被处理;如果仍出现两条但第二条来自服务端回传,那说明问题不在按钮,而在回传任务。这个例子里的数字只用于说明比较方法,不代表任何账户的实际水平。
修复后保留记录的关键,是让新旧数据能对齐。做法是给每次转化分配一个稳定的转化标识,修复前和修复后都沿用同一字段名,只在旁边加一列标记处理阶段,例如“修复前”和“修复后”。这样在百度关键词竞价后台看转化数时,可以按阶段筛选,也可以把两个阶段放在一起看总量变化。不要新建一套字段名,否则前后数据无法直接比较。
具体动作可以分三步:
这样做的结果是:既能回答“修复后重复是否减少”,也能回答“减少的是采集端重复还是上报端重复”。如果只保留修复后的干净数据,前者可以回答,后者往往回答不了。
条件一:重复来自采集端,且旧页面即将下线。这时不必花力气去改旧页面的按钮逻辑,重点是保留旧页面的提交日志,并把仍然有效的线索迁到新页面。动作是导出旧页面的转化明细,按手机号或订单号去重后导入新系统,同时在新页面加上防重复提交。结果是旧记录仍可查,新页面不再产生同类重复。例外是:如果旧页面还在投放且短期不能下线,就必须先修旧页面的提交逻辑,否则重复会持续污染新数据。
条件二:重复来自上报端,且旧回传任务需要退出。这时先停掉旧回传任务,但不要删除它已经写出的记录。动作是把旧任务的上报日志单独归档,标注停用时间,再让新回传任务用同一转化标识继续上报。结果是历史转化仍能对账,新任务不会和旧任务同时写同一条转化。例外是:如果旧任务和新任务共用同一个标识生成规则,停用旧任务前要确认新任务不会因为缺少旧任务而漏报。
转化数下降不等于重复被修好。可能是上报延迟、页面改动导致触发减少,或者统计窗口还没走完。反过来,转化数没变也不等于没修好,可能只是重复被转移到了另一个环节。要排除这些解释,至少同时看三样东西:原始触发日志、上报日志和后台聚合数。三者对不上时,先查日志时间口径是否一致,再查是否有任务重跑。
另外,修复前后记录并存时,不要用“去重后的转化数”直接替代“修复前转化数”去做投放决策。去重会改变分母,而分母变化本身就会影响对百度关键词竞价效果的判断。更稳妥的方式是:修复前按原始记录看趋势,修复后按去重记录看趋势,并在同一张表里标出切换点。这样即使数据口径变了,也能看出变化是来自修复动作还是来自口径调整。