请教Facebook像素与CAPI去重异常的排查思路

最近在排查一个 Facebook 转化归因问题，想请有实操经验的朋友帮忙看看。站点同时接了 Pixel 和 Conversions API，理论上 purchase 事件应能正常去重，但事件管理工具里经常出现部分重复计数，另有一部分又被判定为缺少关键参数，导致广告组学习阶段拉长，ROAS 看起来也被放大了。

目前我已经做了几轮排查：event_name 保持一致，event_id 由前端生成后传给后端；服务器发送时间控制在 5 分钟内；外部 ID、fbp、fbc 尽量补齐；货币、value、content_ids 格式也统一过。奇怪的是，同一批订单里大概 70% 能正常去重，剩下 30% 表现不稳定。

想重点请教三个方向：一是 event_id 在多页跳转和支付回跳场景下，是否容易被二次生成；二是网关或中间层重试请求时，是否会造成服务端事件重复上报；三是除了测试事件工具外，大家还会用哪些日志字段做交叉核验？如果有稳定的排查顺序，或者遇到过类似案例，欢迎直接给步骤。

先提醒下，后续如果补日志请注意打码订单号、用户标识。排查顺序建议固定：1）先核对同一订单 Pixel/CAPI 的 event_name、event_id、action_source、event_time 是否一一对应；2）重点查支付回跳、SPA 路由切换、thank you 页重复触发，很多 30% 异常就出在这里；3）后端加幂等键，防网关重试重复上报；4）日志至少留 order_id、event_id、fbp/fbc、externa

先提醒下，排查这类问题尽量贴脱敏日志，不要直接晒订单号或用户标识。按顺序查：1）确认 purchase 只在“最终成功页/服务端支付成功回执”各触发一次，重点看回跳、刷新、SPA 路由是否重生 event_id；2）后端给每笔订单加幂等键，排除网关重试和队列补发；3）对账字段建议同时核 event_id、event_time、action_source、event_source_url、order_id、fbp/fbc、client_i

这类 70/30 最像“同单不同 event_id”或服务端重试捣乱。建议先按订单号拉一张表：order_id、event_name、event_id、action_source、event_time、fbp/fbc、external_id、去重结果。重点看支付回跳、thank you 页二次触发、SPA 路由切换、网关超时重放。最好让 event_id 直接绑定订单号或支付流水号，全链路只生成一次。另查服务器是否因 5xx/超时自动重

我也刚踩过类似坑，感觉先盯订单维度最有效：把 order_id、event_id、event_time、action_source、fbp/fbc、HTTP 请求唯一 ID 全拉出来对账。想追问下，你们支付成功页刷新或回跳时，会不会再次触发 purchase？另外后端重试有没有做幂等键？这两个地方我这边最容易出 30% 的漂移。