检查前，准备哪一段数据？
- 从自己有权维护的服务端代码或调试记录中，提取发送给 Conversions API 的事件对象。保留字段结构、值的类型和需要核对的金额口径，删除 HTTP 请求头及访问令牌。
- 把客户信息替换成虚构占位内容；真实订单号替换为
demo-order-1001，来源地址替换为https://example.com/checkout/complete。如需排查重复，替换时应保留事件 ID 原有的相等关系。 - 保留问题发生时的时间戳，方便检查时间单位；如担心泄露业务时间，可使用同量级的虚构值，并另行核对原始事件发生时间。
- 粘贴单个 JSON 对象或带有
data数组的请求体，点击“检查 JSON”。本工具按 CAPI 命名检查，浏览器 Pixel 的eventID需要另行对照服务端event_id。
这些结果分别说明什么？
| 检查项 | 本地能够发现 | 仍需人工核对 |
|---|---|---|
| 名称与来源 | 名称为空、action_source 缺失或不在已核验取值中。 | 名称是否代表实际用户行为；来源是否准确。 |
| 事件时间 | 数字类型、整数秒、疑似毫秒，以及明显偏离本机时间的情况。 | 设备时钟、真实发生时间和 Meta 当前适用接收时效。 |
| 购买金额 | Purchase 缺少金额／币种、负数、字符串金额或币种格式不正确。 | 币种是否有效；金额是元还是分，是否包含税费、运费或折扣。 |
| 事件 ID | event_id 缺失，或单批内名称与 ID 的组合重复。 | 浏览器与服务端是否发送到相同数据源；是否对应同一次行为；Meta 是否已去重。 |
| 客户信息 | user_data 缺失、为空或类型错误。 | 允许使用的数据、规范化与哈希方式、实际匹配质量。非空不等于有效。 |
示例：为什么有两条 Purchase，却只有一笔订单？
假设同一笔虚构订单在浏览器和服务端各产生一次 Purchase。使用 Meta 推荐的名称与 ID 去重方式时，两端应使用同一名称和同一事件标识：
浏览器 Pixel：event = "Purchase"，eventID = "demo-order-1001" 服务端 CAPI：event_name = "Purchase"，event_id = "demo-order-1001"
如果两端各自随机生成了不同 ID，即使金额、商品和时间相近，也不能据此断定它们会按这组字段去重。反过来，如果两笔不同订单复用了同一个 ID，也应修正生成逻辑。重试同一次事件应保留原标识，新的实际行为应有自己的标识。
本工具看到相同名称和 ID 时只会提示核对。批次里重复了两条服务端事件，并不能证明浏览器事件已经到达或 Meta 已执行去重。可在教学专栏查找 Pixel / CAPI 排查与事件核对的相关文章。
结构检查后，到 Events Manager 核实
- 在 Meta 事件管理工具中选择正确的数据源，进入“测试事件 / Test Events”。界面名称可能随账号和版本变化。
- 按后台说明配置测试事件代码，在你有权操作的测试环境触发一次可识别的行为。测试代码和访问凭证应留在你自己的环境，不要粘贴到本工具。
- 查看浏览器与服务端事件的接收记录，核对事件名、ID、来源、金额与币种，并查看后台提供的去重与诊断信息。收到 HTTP 成功响应不等于归因或去重结果正确。
- 对照同一笔测试订单核查业务日志，再按正常数据的延迟观察报表。测试事件页面、诊断和广告归因报表回答的问题不同，不应仅凭某一处的数量下结论。
为什么金额显示正常，ROAS 还是不对？
value: 4990 与 value: 49.90 都是合法的数字结构，但如果订单为 49.90 美元而系统把“分”直接上报，转化价值就会被放大 100 倍。三个大写字母也只是币种格式；本工具不会把任意三个字母认定为有效货币。请始终回到原始订单，核对收入、税费、运费、折扣和退款的处理方式。
参数与去重说明核验于 2026-09-18。来源：Meta Server Event Parameters、Handling Duplicate Pixel and Conversions API Events。规则会随接口变化，本工具只覆盖页面列出的常见检查。