Facebook像素和转化API（CAPI）有什么区别？为什么两个都要用

Facebook 像素是什么？怎么工作

Facebook 像素（现在 Meta 叫它 Meta Pixel）是放在网页上的一段 JavaScript 代码。访客打开网页时，他的浏览器会加载这段代码，然后把各种事件发回给 Meta，比如 PageView、ViewContent、AddToCart、Lead 或 Purchase，同时带上订单金额、币种等附加信息。

这些数据有三个用途：衡量哪个广告系列带来了转化；让广告系统学习应该把广告推给什么样的人；以及建立再营销受众，比如加了购物车却还没付款的人。

关键在于，这一切都发生在浏览器端。像素能不能工作，取决于用户的浏览器是否愿意加载脚本、是否愿意把数据发出去。只要中间有东西挡住，这个事件就悄无声息地丢了，你完全察觉不到。

如果刚开始投广告，可以先看 Facebook广告投放教程 打基础。因为像素运行在你的网页上，落地页本身的质量同样重要，可以继续看 落地页是什么。

为什么只用像素，数据收集不全

浏览器端追踪有结构性的弱点，不是安装错误造成的。即使每一行代码都放对了，仍然会因为下面这些原因丢掉一部分数据。

• 广告拦截和隐私类扩展——很多插件从一开始就阻止加载 Meta 的脚本，这部分用户的事件根本发不出去。
• 浏览器的防追踪机制——Safari 有智能防跟踪（ITP），其他浏览器也有类似功能，会限制 JavaScript 创建的 Cookie 的有效期，导致广告点击和几天后才发生的购买越来越难关联起来。
• iOS 的跟踪授权——自从 Apple 加入跨应用跟踪授权弹窗，很多用户选择不允许，Meta 用来匹配用户的数据因此变少。
• 断网或过早关闭页面——用户付完款，在感谢页加载完之前就关掉了标签页，Purchase 事件就没发出去。
• Cookie 同意——如果网站有征求同意的横幅，而用户没有同意，像素本来就不应该运行。

转化 API（CAPI）是什么？和像素有什么区别

转化 API 是让你的服务器以服务器对服务器的方式直接把事件发给 Meta 的通道，不经过用户的浏览器。后台一产生订单，服务器就能立刻把 Purchase 事件发给 Meta，浏览器里的广告拦截插件对这条通道没有影响。

另一个好处是可以发送浏览器拿不到的数据，比如真正确认付款的订单、销售团队核实过质量的线索，或者订单取消。这样广告系统学习用的数据会更接近真实销售。

但 CAPI 并不能取代像素。像素能看到服务器看不到的页面行为，比如浏览商品时的滚动，而且浏览器里有 Meta 的 Cookie 帮助匹配用户。所以 Meta 建议两者一起用，再让系统把重复的事件去掉。

一起用必须用 event_id 设置去重

像素和 CAPI 都发送同一个 Purchase 事件时，如果不告诉 Meta 它们是同一个事件，这笔销售就会被算两次，报表虚高，广告系统也会从错误的数据里学习。

Meta 推荐的做法是两边发送同一个事件编号。像素这边，在 fbq track 命令的第四个参数里放 eventID；CAPI 这边放 event_id，两个值必须一致。事件名称也必须一致，也就是像素的 event 要等于 CAPI 的 event_name，比如两边都是 Purchase。

根据 Meta 的文档，如果在 48 小时内从同一个像素收到 event_id 和 event_name 都相同的事件，系统只保留一个，把重复的去掉。实际操作中，这个编号通常用订单号，或者在用户点击按钮时生成一个随机值，再把同一个值同时交给网页代码和服务器。

事件匹配质量和客户信息的哈希处理

通过 CAPI 发送的事件，只有在 Meta 能匹配出是哪个用户时才有用。事件管理工具里有一个"事件匹配质量"（Event Match Quality）评分，告诉你发过来的客户信息对匹配帮助有多大。发送的参数越完整、越正确，分数越高。

邮箱、电话、名、姓、城市、邮编和 external_id 这类个人信息，必须先标准化，再用 SHA-256 哈希。比如邮箱要去掉首尾空格并转成小写；电话只保留数字、去掉开头的 0 并加上国家代码，所以泰国号码 081-234-5678 在哈希前要变成 66812345678。

有些数据则必须不哈希直接发送，包括 client_ip_address、client_user_agent、fbp（标识浏览器的 _fbp Cookie）和 fbc（用户点击广告时由 fbclid 得来的值）。对于网站事件，Meta 规定必须发送 client_user_agent。

• em、ph、fn、ln、ct、zp、country、external_id——标准化后用 SHA-256 哈希。
• client_ip_address、client_user_agent——从用户请求中取真实值，不哈希直接发送。
• fbp、fbc——从用户的 Cookie 读取后原样传递，不哈希，能让服务器端事件和浏览器端事件匹配得更准。

转化 API 有几种部署方式？该选哪种

没有一种方式适合所有人，要看你的网站用什么搭建、团队里有没有开发，以及你想在多大程度上自己掌控数据。下表总结了四种主要选择。

VPS 在哪里能帮上忙？需要多少配置

用 curl 发送事件的示例

表里后两种方式都需要一台一直开着、有 HTTPS 的服务器。服务器一宕机，那段时间里 CAPI 这边的事件就全部丢失。这正是 VPS 能派上用场的地方。

自己部署服务器端 GTM，Google 有一份手动部署指南，可以把标记服务器作为 Docker 镜像跑在你选择的机器上，需要同时有 tagging server 和 preview server，并把你网站的 HTTPS 子域名指向它们。Google 说明每台机器不要超过 1 个 vCPU，因为多出来的 vCPU 用不上，流量大时建议以集群方式运行。对中小型网站来说，一台 2 vCores / 4 GB 内存的 VPS 同时跑这两个服务再加反向代理，绰绰有余。

如果是自己写一个接收事件再转发给 Meta 的接口，负载非常轻，流量不大时最小的 VPS 就能跑，但最好加上队列或重试机制，以防 Meta 响应变慢。至于 Conversions API Gateway，按 Meta 的文档需要运行在 AWS 或 GCP 账户上，所以不适合普通 VPS。

用 Docker 跑 sGTM 或你自己的接口，迁移机器和更新都会容易得多。如果还想知道 VPS 在投放工作中还能帮上什么，可以继续看 投放广告用VPS能做什么。

• 以 POST 方式发送到 https://graph.facebook.com/vXX.0/PIXEL_ID/events，把 vXX.0 替换成你正在使用的 Graph API 版本，并附上在事件管理工具里生成的 access_token。
• 示例命令：curl -X POST "https://graph.facebook.com/vXX.0/PIXEL_ID/events?access_token=TOKEN" -H "Content-Type: application/json" -d @event.json
• event.json 文件里，data 是事件数组，每个事件包含 event_name、event_time（Unix 时间戳，单位秒）、event_id、值为 website 的 action_source、event_source_url，以及 user_data（包含哈希后的 em、client_ip_address、client_user_agent、fbp、fbc）。
• 测试阶段在 payload 最外层加上 test_event_code，正式上线前删掉。

用测试事件验证，以及常见错误

安装完成后，进入事件管理工具，选择你的像素，打开"测试事件"（Test events）标签页。像素这边，通过测试入口打开网站，实际操作一遍事件；CAPI 这边，把测试代码复制到 payload 的 test_event_code 里。事件几乎会立刻显示出来，并标明来自浏览器还是服务器、有没有被去重。

如果同一个事件在两边都出现、而且系统显示已去重，说明 event_id 设置正确。之后等真实数据进来一段时间，再到概览页看事件匹配质量评分。