Conversions API 和 Meta Pixel 的区别：要不要都装、去重怎么做

Conversions API 和 Meta Pixel 的区别

两者发的是同一类事件，比如 ViewContent、AddToCart、Purchase，区别在于从哪里发出。

• Meta Pixel：在访客浏览器里运行的代码，记录访客在网站上的操作。广告拦截插件、浏览器设置、网络问题、页面加载出错，都可能让它发不出去。
• Conversions API：服务器端的连接，把事件从你的服务器、建站平台、App 或 CRM 直接发给 Meta。Meta 说它受浏览器加载出错、网络问题和广告拦截的影响更小。
• 通过 Conversions API 发的网站事件会关联到你的像素，用于同样的广告优化，也和像素事件一样出现在广告管理工具 (Ads Manager) 和事件管理工具 (Events Manager) 里。
• 它还能发浏览器根本看不到的事件，比如线下门店、线下转化和 CRM 里的事件，或者订阅这类购买之后的行为。
• 两者都不能用来绕开用户同意。Meta 明确说，Conversions API 不是用来规避苹果 App Tracking Transparency 或欧洲 ePrivacy 指令这类数据政策的。

要不要两个都装：Meta 的建议

网站事件的话，Meta 的回答是要。它的最佳实践叫「冗余设置 (redundant event setup)」：Conversions API 和 Meta Pixel 一起用，同样的事件两边各发一份。

• 像素发了 Purchase、InitiateCheckout、Contact，服务器也发这几个。
• 目的是补漏：网络问题或页面加载出错时像素会丢事件，服务器那份能补上。
• Meta 给的目标是事件覆盖率 75%，也就是 Conversions API 事件和像素事件的比例，在事件管理工具的「事件覆盖率 (Event coverage)」标签页里看。
• 服务器事件可以多带一些客户信息参数，帮助 Meta 把事件匹配到账户。打分规则见事件匹配质量。
• 那只用服务器行不行？Meta 的建议是：用 Conversions API 发网站事件时，同时也用像素。

去重是怎么做的

同一个事件从浏览器和服务器各来一份时，Meta 只留一份、丢掉另一份。前提是它能认出这两份是同一次操作。

• 事件名 + 事件 ID (推荐做法)：像素的事件名要和服务器的 event_name 一致，像素的 eventID 要和服务器的 event_id 一致。每次真实操作要有自己唯一的 ID，浏览器和服务器两份用同一个。
• 时间：两份事件要在 48 小时内先后到达才会去重，Meta 一般保留先到的那份。
• 备用办法是 fbp 或 external_id：event_name 相同，再加上两边一致的 fbp 和/或 external_id，也能去重。但 Meta 说这种办法一般只在浏览器事件先到、服务器事件后到时有效，不要只靠它。
• 同一边重复发也会被去掉：像素用同一个 eventID 发了两次同一事件，或者服务器用同一个 event_id 发了两次。
• 如果两边发的是不同事件，比如浏览器发 AddToCart、服务器发 Purchase，就不存在去重的问题。

不写代码怎么接 Conversions API

大多数店铺不需要找开发。官方文档里写到的办法有这几种：

• Shopify：在 Facebook & Instagram 销售渠道里点设置 (Settings) → 数据共享设置 (Data sharing settings)，等级选 Enhanced 或 Maximum，这两档都是像素加 Conversions API；Standard 只有像素。详见 Shopify 的数据共享说明，装像素可以看这篇 Shopify 指南。
• WooCommerce：Meta for WooCommerce 插件 (以前叫 Facebook for WooCommerce) 自带 Conversions API，像素和服务器事件用唯一的事件 ID 去重。
• Meta 说，这类电商平台集成点几下就能开，不额外收费，去重参数也由平台处理。
• Meta-enabled Conversions API：在事件管理工具里一键开启，免费，只支持网站事件。像素已经在发的事件会通过它再发一份，并自动去重。
• Conversions API Gateway：不用写代码，跑在你自己的 AWS 或 Google Cloud 账户上，要付的是云服务费，自动去重。Meta 建议没有用电商平台自带集成的商家用它。
• 直接集成：由开发者写代码发送事件。App 事件和线下门店事件只能走这条路。
• 同一个事件只选一条服务器通道。两套设置都从服务器发 Purchase、ID 又不一样，因为 ID 不同，不会被当成重复事件去掉。

怎么确认 Conversions API 的事件发到了

• 事件管理工具 → 你的数据集 → 测试事件 (Test events)，找到服务器事件那一栏。工具会给一个测试代码，服务器把它作为 test_event_code 参数一起发送，事件就会出现在测试事件窗口里。
• 测完要把 test_event_code 去掉。Meta 说带测试代码的事件不会被丢弃，会进入事件管理工具，用于定向和效果衡量。
• 测试记录在工具里保留 24 小时，也可以点「清除活动 (Clear activity)」清掉。
• 如果平台不让你加测试代码，就看数据集的「概览 (Overview)」。Meta 说事件一般 20 分钟内出现，连接方式 (Connection method) 会显示每个事件是从哪个渠道发来的。
• 再看一下「诊断 (Diagnostics)」标签页，鼠标移到 ! 图标上，能看到问题说明和建议的改法。

怎么判断去重有没有生效

在事件管理工具里打开数据集，找到要查的事件 (先查 Purchase)，点「查看详情 (View details)」。要看的是这几个标签页：

• 事件概览 (Event overview)：看事件量，确认这个事件是不是浏览器和服务器两边都在发。
• 事件去重 (Event deduplication)：显示你发了哪些去重键，以及每个来源有多大比例的事件被去重。比例越高越好，太低时 Meta 会给出警告。
• 这个标签页里的重叠度 (Overlap) 低，说明去重键不唯一，或者某个键只有一边在发。
• 事件覆盖率：服务器事件远少于像素事件，说明服务器那边漏发了。
• Meta 列出的其他问题信号：event_id 缺失或对不上，两边的 event_name、event_id 格式不一致，浏览器和服务器发送的时间差太大，事件数量突然暴涨或暴跌。
• 测试事件工具也能看出哪些事件被接收、被去重、被丢弃。

核对清单

• 先定好哪些事件两边都发，每个事件带相同的事件名和唯一的事件 ID。
• 优先用建站平台的集成或 Meta 自己的免代码方案，别急着自己开发。
• 在测试事件里确认服务器事件到了，然后去掉测试代码。
• 有了真实流量之后，逐个查关键事件的事件覆盖率和事件去重。
• Pixel Audit 能查浏览器这一半：用真实浏览器打开你的店铺，走一遍首页、商品、加购、结账，报告触发了哪些 Meta Pixel 事件、带了什么参数、哪里缺失或重复。它看不到 Conversions API 事件，也不下单、看不到真实的 Purchase，服务器那一半仍要在事件管理工具里查。