症状是：Events Manager 中显示了一些您的订单系统或 CRM 无法匹配的 Purchase 或 Lead。有一位广告主报告说，一则流量广告一天内带来 105 次购买，而店铺订单为零（店铺平台社区帖子，始于 2023 年 12 月 25 日，由广告主报告）。这种差距指向从未发生的事件或跟踪故障。真实的欺诈操作不会留下差距，因为订单或潜在客户确实存在；它会在之后以拒付或无人能联系上的潜在客户的形式浮现。想先了解机器人和无效流量最初是如何进入 Meta 广告的，请从我们的 Meta 广告点击欺诈指南开始。
我们如何核查。 我们没有进行广告账户测试。Meta 的行为来自 2026 年 11 月 12 日阅读的 Meta for Developers 页面，广告主的情况来自有日期的社区帖子。
Meta Pixel 虚假事件是如何产生的？
可疑事件有三种成因：从未发生的事件（由脚本或无头浏览器触发像素）、产生真实事件的真实欺诈操作（例如测卡订单），以及跟踪故障（重复安装、误触发的设置规则、遗留的 test_event_code）。 一个问题就能把大多数情况分开：您的订单系统或 CRM 中有记录吗？没有记录，且事件能在您自己的页面上复现，说明是故障；没有记录，也无法复现，说明事件从未发生；有欺诈性记录，则说明是真实欺诈。
Meta 较新的文档把存放您事件的地方称为数据集：Meta Pixel（像素）把浏览器事件发送到其中，Meta 转化 API 发送服务器事件，Events Manager 则同时显示两者。像素是一段公开的脚本，其 ID 就在您的页面源代码里。Meta 对 Purchase 的定义是“完成购买或结账流程时”，并将 currency 和 value 列为必需参数（Meta Pixel 参考文档）。这个调用本身并不能证明确实发生了购买。
从未发生的事件。 任何能运行像素的脚本都可以用任意金额调用 fbq('track', 'Purchase')。无头浏览器做同样的事则更不显眼，它会触发真人会触发的那些事件。
真实的欺诈操作。 用被盗银行卡完成结账的测卡机器人会生成真实订单，所以其中的 Purchase 是真实事件。今年 5 月，一位商家报告说有机器人下单了数百件同一商品，影响了其像素（店铺平台社区帖子，始于 2026 年 5 月 16 日，由广告主报告）。我们关于电商点击欺诈防护的页面介绍了店铺一侧的情况。
跟踪故障。 常见的有：像素重复安装、刷新后再次触发的感谢页、生产环境中遗留的 test_event_code、损坏的去重键，以及在错误页面触发 Purchase 的设置规则。在开头引用的那个 105 次购买的帖子里，2026 年 10 月有一条回复建议检查 Event Setup Tool（事件设置工具）中是否有把页面浏览变成 Purchase 事件的规则（由广告主报告）。
Meta 一侧的故障。 一位商家报告说，金额为零的购买抬高了计数，随后在 2025 年 2 月 20 日写道，Meta 已修复其一侧的一个故障，该故障源自 2 月 8 日至 11 日之间的一次代码推送，现已撤回（店铺平台社区帖子，始于 2025 年 2 月 10 日，由广告主报告）。
为什么 Meta 会针对虚假事件进行优化？
我们的解读：Meta 的投放会从您上报的转化中学习，所以一次虚假的 Purchase 或 Lead 会教它去寻找更多与这次虚假访问相似的访问。
价值优化还会带来第二重扭曲：一连串 0 美元或整数金额的 Purchase，会扭曲系统所认为的一位买家能带来的价值，这同样是我们的解读。
虚假事件会在 Events Manager 的哪里出现？
Events Manager 显示事件量、连接方式和去重率，Meta 记载的数据检查只会标记格式有问题的数据，而不是 Meta Pixel 虚假事件。 用它来定位差距，然后到别处确认原因。
- Overview（概览）。 Meta 表示，概览显示“我们在去重之前收到的事件数量”，并且“在 Connection Method（连接方式）下，您可以看到该事件是通过哪个渠道发送的”（验证您的设置，Meta for Developers）。请把其中每日的 Purchase 数量与已付款订单进行比对。
- Event Details（事件详情）。 从概览打开后，其 Event Deduplication（事件去重）标签页会显示“每个事件来源中被去重的事件所占百分比”，以及每个去重键的使用频率（同一页面）。
- Dataset Quality API（数据集质量 API）。 Meta 的数据集质量 API 会检查“value 或 currency 参数缺失或无效”的事件、“与 Meta Pixel 的 IP 不匹配”的客户端 IP 地址，以及“使用同一个占位邮箱而非真实邮箱”的事件（Dataset Quality API，Meta for Developers）。这些都是格式检查；我们没有找到任何 Meta 页面描述过机器人、垃圾信息或欺诈检查，所以格式正确的虚假事件能全部通过。
- Test Events（测试事件）。 Meta 给出的路径是 Events Manager，然后是 Data Sources（数据源），再到您的像素，最后是 Test Events，您带着 test_event_code 参数发送的服务器事件会出现在那里（使用转化 API）。
- 事件匹配质量（EMQ）。 EMQ 显示的是一个事件的客户信息可能与某个 Meta 账户匹配的程度（转化 API 最佳实践），而不是该事件是否具有欺诈性。Meta 表示它“按 1 到 10 评分”，并建议您“力争让事件匹配质量得分达到 6.0 或更高”（验证您的设置）。
我们的解读，不是 Meta 的说法：如果潜在客户事件的 EMQ 在下降而潜在客户数量在攀升，请检查这些潜在客户，因为编造的联系信息无法匹配真实账户。表单不再传递某个字段，同样会拉低 EMQ。
这是虚假事件还是跟踪故障？
大多数现象都既有无害的解释，也有恶意的解释，通常一项检查就能分辨出您遇到的是哪一种。
| 现象 | 通常是故障的情况 | 事件从未发生或属于真实欺诈的情况 | 能够判明的检查 |
|---|---|---|---|
| 没有订单 ID 的 Purchase | 您的设置从未传递订单 ID | 从未发生：真实的 Purchase 都带有订单 ID | 把每个事件的时间戳与订单进行匹配 |
| 在商品页 URL 上触发的 Purchase | 每次刷新页面都会触发 | 从未发生：无法复现，也没有订单与之匹配 | 打开网络面板刷新页面 |
| 整数或零金额 | 某条规则发送了固定或空的金额 | 从未发生：金额与任何商品都对不上 | 把金额与您的价格和订单进行比对 |
| 仅来自浏览器、没有服务器对应事件 | 您的服务器只发送部分事件 | 从未发生：您的服务器会发送每一笔真实的 Purchase | 在概览中比较连接方式 |
| 来自您并不拥有的域名的事件 | 该域名是店铺预览或测试会话 | 从未发生：该域名与您的业务毫无关联 | 检查像素设置中的域名 |
| 同一访客在几秒内产生大量相同的 Lead | 表单被提交了两次 | 真实欺诈：机器人提交了表单，所以 CRM 中有记录 | 把潜在客户与 CRM 记录和时间戳进行匹配 |
| AddToCart 激增，InitiateCheckout 持平 | 某条规则在页面浏览时触发 AddToCart | 从未发生：自动化访问会点击加入购物车 | 按来源、页面和小时对激增进行分组 |
| 数量恰好翻倍 | 两个安装同时触发，或去重键不一致 | 很少是这两种：翻倍通常指向设置问题 | 查看 Event Deduplication 标签页 |
| 全新店铺或广告系列上出现激增 | 设置仍在测试中 | 从未发生：自动化访问会探测新网站 | 与订单和测试日期进行比对 |
| EMQ 下降而数量上升 | 某个表单不再传递一个字段 | 真实欺诈：新的潜在客户带着编造的联系信息 | 在 CRM 中检查这些新的潜在客户 |
| 生产环境中带有 test_event_code 的事件 | 该代码从未被移除 | 很少是这两种：遗留的代码属于设置错误 | 在服务器负载中搜索 test_event_code |
广告主在店铺平台社区帖子中报告过其中的几种现象：
- 固定金额的 Purchase。 一个始于 2021 年 10 月 17 日的帖子，以虚假的 99 美元购买为标题，描述了从商品页触发的、仅来自浏览器的 Purchase 事件。后来有回复说，Meta 客服能看到这些事件是通过合作伙伴集成设置的。
- 新店铺。 一位商家在开店两天后就看到了虚假的加入购物车、结账和购买事件（始于 2020 年 11 月 25 日），另一位商家在两家开店不满 15 天的店铺上看到了同样的情况（始于 2022 年 10 月 19 日）。
- 未知域名。 一位商家在流量权限中发现了约 40 个域名，其中包括店铺预览子域名，有回复认为测试会话可以解释其中一部分（始于 2024 年 4 月 10 日）。
去重能移除什么，不能移除什么
去重移除的是同一个真实事件的多份副本；对于没有服务器副本的虚假浏览器事件，它无能为力。 Meta 会“根据 ID 和名称”匹配事件，也就是 event_id 和事件名称，并且只有在事件“于具有该 ID 的第一个事件之后 48 小时内收到”时才会去重（对像素事件和服务器事件去重，Meta for Developers）。
更重要的是其局限。Meta 表示，“只使用一个事件来源（即仅浏览器或仅服务器）时，不会对事件去重”，并且两个信息相同的连续浏览器事件都会被保留。Meta 还表示，fbp 或 external_id 方法“通常”只适用于“先从浏览器发送、再通过服务器发送”的事件（同一页面）。因此，在浏览器中触发 Purchase 的脚本，每次都会被计入。要搭建事件 ID 的设置，请参阅如何设置去重和经过欺诈过滤的转化。
如何追查一笔可疑的 Purchase
挑出一笔您无法匹配到订单的 Purchase，顺着它追到某个页面、规则或脚本。 这个例子仅作示意，并非真实账户。
- 在概览中找到差距。 把日期范围设为出现差距的那一天，并查看 Purchase 的 Connection Method（连接方式）。
- 收集金额和币种。 您的转化 API 日志中保存着服务器事件的这些信息。金额与任何商品都对不上的、仅来自浏览器的 Purchase 就是线索。
- 把时间戳匹配到订单。 几分钟内没有已付款订单，说明该事件背后没有客户。
- 打开浏览器开发者工具的网络面板，并刷新商品页。观察哪些像素请求被触发，带有哪些参数。
- 用 Meta Ads Data Advisor 确认。 Meta 表示，这个前身为 Meta Pixel Helper 的扩展程序会显示“当前网页上触发的 Pixel 事件数量”及其参数（Meta for Developers）。
- 在 Test Events 中复现。 使用测试数据集，并且不要把 test_event_code 留在生产负载中。Meta 警告说，带有它的事件“不会被丢弃”，并且“会流入 Events Manager，用于定位和广告衡量”（使用转化 API）。
- 检查向像素发送事件的域名，位置在像素的流量权限中。Meta 关于该设置的帮助页面在 2026 年 11 月 12 日对我们未能加载。
刷新页面时触发的 Purchase，会对每位访客都触发。如果规则、主题代码或某个集成能解释它，那就是故障；如果什么都解释不了，请查找被注入的脚本。如果它无法复现，也没有订单与之匹配，请检查它的域名和连接方式：手动触发的调用或其他域名的脚本，永远不会出现在您的网络面板中。
如何阻止 Meta 中的虚假事件
要阻止 Meta Pixel 虚假事件，请限制可以发送事件的域名，修复去重键，移除 test_event_code，然后用已付款订单数据从您的服务器发送 Purchase。
- 检查流量权限。 先排除预览和测试会话，然后在您当前的界面提供该功能时，只允许您自己的域名。允许名单无法阻止您自己域名上的脚本。
- 修复去重键。 对每个真实事件，从浏览器和服务器传递相同的事件 ID 和事件名称。
- 从服务器发送转化事件，并共用同一个事件 ID。 您的服务器知道哪些订单已付款。这不会移除仍会被计入的虚假浏览器事件，但能为您提供一个经服务器确认的 Purchase 数量，用来与它们比对。
- 移除 test_event_code。 每次发布前，先在服务器负载中搜索它。
- 每周对账。 把 Purchase 和 Lead 事件与已付款订单和 CRM 记录进行比对，后者是您的事实记录。
黑色星期五是 11 月 27 日，请现在就按连接方式导出每日的 Purchase、Lead 和 AddToCart 数量，以便用基线来判断促销日的激增，正如我们的Google Ads 与 Meta 假日清单所述。
对于那些是真实的人但没有购买意向的潜在客户，请参阅如何区分低意向潜在客户与机器人。如果差距在更早的点击环节就已出现，请阅读链接点击与着陆页浏览量。
ClickFortify 能做什么，不能阻止什么
ClickFortify 会在 Meta 广告点击之后标记可疑转化，并且可以过滤通过其 CAPI 代理发送的服务器事件；它不会移除 Meta Pixel 在浏览器中触发的事件。
ClickFortify 通过 fbclid 识别 Meta 广告点击，并在着陆页路径上依据 100 多个设备、网络和行为数据点为每次访问评分。它会在点击记录上标记三种可疑转化模式：点击后 2 秒内发生的转化、来自已被归类为机器人的访客的转化，以及一台设备上出现 3 次或更多转化。启用 CAPI 代理后，系统会根据访客的欺诈得分检查转化，被标记的事件会在 Meta 收到之前被丢弃或加上标签。该过滤只覆盖通过代理发送的服务器事件。Meta Pixel 在浏览器中触发的事件仍会到达 Meta，而 ClickFortify 无法阻止手动触发像素的脚本或机器人。
ClickFortify 不会检查潜在客户中的电子邮件地址或电话号码，因此请搭配 CRM 检查。即时表单的潜在客户不是像素事件，ClickFortify 看不到它们；对此请参阅我们的 Facebook 潜在客户广告虚假潜在客户指南。它不会在 Meta 上拦截 IP 地址，也不会建立受众排除。设置方法请参阅 ClickFortify 的 Meta 广告防护。
您也在投放 Google Ads 吗？转化操作一侧的内容请参阅我们的 Google Ads 虚假转化指南。
我们的结论是：先把事件与订单对账并修复故障，因为故障是成本最低的排除对象。当差距出现在付费点击之后，并且在清理后依然存在时，再加上转化检查。想了解该主题的其余内容，请浏览所有 Meta 广告欺诈指南。
