Meta 转化 API（CAPI）接入指南 2026：去重、匹配质量与怎么验收
转化 API（Conversions API，简称 CAPI）常被说成「浏览器像素的备份」。正是这个说法，让很多接入最后比只用像素还糟：团队接上服务端回传，看着转化数几乎翻倍，几个月后才发现去重从来就没生效过。这篇按「能让数字保持诚实」的顺序讲接入——CAPI 到底改变了什么、四种发送方式、决定数据可不可用的去重规则，以及在相信任何一条转化数据之前该怎么验。
转化 API 真正改变的是什么
浏览器像素从访客设备上报事件。这条路径现在天生是有损的：浏览器的追踪防护、扩展、网络层拦截，都会在事件到达 Meta 之前拿掉一部分，而且拿掉最多的恰恰是你最在意的那部分流量。
转化 API 改成从你的服务器发送同样的事件。事件不经过访客浏览器，因此不受浏览器侧拦截影响。但它受你自己的实现影响：你的服务器不知道的东西，Meta 就收不到。
由此有两个推论，而且都跟「备份」这个词给人的印象相反：
- CAPI 不是像素的替代品。 推荐配置是两边都发同样的事件，然后去重。像素贡献服务器看不到的浏览器侧信号，服务端贡献浏览器根本送不出去的事件。
- CAPI 的数据质量由你负责。 像素会自动采集标识符；在服务端你必须主动附上。客户信息单薄的服务端回传匹配率很差，而它的表现形式不是报错，是被归因的转化悄悄消失。
还没做浏览器侧的，先做那一步：见 Facebook Pixel 接入指南。
四种发送方式
直接对接 API。 你的后端自己调 API。对发哪些事件、附什么数据、什么时候发的控制力最强；代价是研发投入和长期维护。它也是唯一能发送「浏览器里根本不存在的事件」的方式——线下成交、退款、三天后才被判定为有效的线索。
平台自带集成。 主流电商平台都提供第一方 CAPI 连接。上手最快，标准购买漏斗够用；限制是发什么由集成方决定。
合作方或标签管理器集成。 服务端标签管理把事件经由你自己的服务端容器转发。如果你本来就在跑服务端标签，这是不错的中间选项。
Conversions API Gateway。 托管服务，替你把服务端基础设施架起来。缺研发人力时合理，代价是链路上多一个依赖。
对多数团队，诚实的答案是：先用平台集成，再针对平台看不到的那些事件补一个直接对接。
去重：决定这套东西成不成立的那一环
如果像素和服务端都上报了同一笔购买，而 Meta 判断不出它们是同一笔，它就会记成两笔。你的转化数虚高、单次转化成本腰斩，而下游每一个优化决策都建立在一个朝着好看方向错的数字上。
起作用的是两个字段，两边必须对同一次事件保持一致：
event_name—— 两侧用同一个事件名。event_id—— 你为这一次具体发生生成的唯一标识，像素和服务端要发送完全相同的值。
最容易踩的一条规则：event_id 必须每次事件只生成一次，然后共享给两个发送方。在客户端和服务端各自独立生成，会得到两个不同的值，去重完全不会发生。实操上，在渲染页面时由服务端生成，再把同一个值传进浏览器事件里。
去重有匹配时间窗，服务端事件如果比浏览器事件晚太多就配不上对。两边尽量靠近发送。
客户信息：真正决定匹配质量的部分
你附上的每个参数都会先哈希再发送。参数越多，事件能匹配到某个人的概率越高，而这决定了这笔转化到底会不会被归因。
按贡献度大致排序：邮箱、手机号、外部 ID，然后是姓名、城市、州省、邮编、国家。有就一定要带上点击标识（fbc）和浏览器标识（fbp）——这两个来自浏览器，必须刻意采集并传给服务端，而它们正是纯服务端接入里最常见的遗漏项。
哈希之前先规范化：转小写、去首尾空格、手机号去掉标点并带国家区号。一个哈希正确但规范化错误的值匹配不到任何人，而且不会报任何错。
Meta 会给每个事件回报匹配质量分。把低分当成待修的缺陷，不是当成一个可以观察的数字。
接入顺序：这样排能避免返工
- 先确认像素是好的。 浏览器侧坏着，之后每个数字都是含糊的。
- 定事件清单。 从你真正用来优化投放的事件开始。什么都发只会增加噪声和匹配质量问题，不增加任何决策。
- 服务端生成
event_id并传给浏览器事件。 这一步要在写服务端调用之前做，不是之后。 - 附上你合法持有的最丰富的客户信息，先规范化再哈希，包括
fbc与fbp。 - 先发测试端点，在事件管理工具里看着事件到达。
- 用真实流量验证去重，不要用测试事件验。拿同一时间窗的上报数与你自己的订单记录对账。
- 跑几天有量之后再看匹配质量，把最弱的那几个参数补上。
怎么判断它真的在工作
三项检查，而且没有一项是「后台显示有事件」。
你自己的订单数才是标尺。 取一个固定时间窗，用数据库里的订单数对比上报的购买数。大致相等＝正确；显著偏高＝去重没生效；显著偏低＝匹配质量差或事件缺失。
去重状态在诊断里能看到。 事件管理会显示它收到了冗余事件、以及是否完成了去重。「冗余但未去重」就是你要找的故障态。
匹配质量稳定且合理。 一次上线之后分数掉下来，就是某个参数坏了，而它不会用别的方式通知你。
常见问题
有了 CAPI 还需要像素吗？ 需要。推荐配置是两者并行并去重。纯服务端会丢掉浏览器侧信号，匹配通常更差。
接了之后转化数会涨吗？ 真正被找回的事件会让它小幅上升。第一天就大幅跳涨，几乎总是重复计数而不是找回。
没有邮箱怎么办？ 有什么发什么——外部 ID、fbc、fbp 和地理信息仍然有贡献。匹配质量会更低、归因更弱，这是实打实的代价，不是形式问题。
能发送浏览器里从未发生过的事件吗？ 能，而且这是 CAPI 最被浪费的能力：线下转化、电话订单、以及事后才判定合格的线索。
这对广告账户稳定性有帮助吗？ 间接有。度量更准意味着更少基于坏数据做的改动。账户与政策稳定性是另一个话题，见 Meta 广告审核通过与被拒。
一句话版本
像素和转化 API 一起跑，两边发同样的事件，并且每次事件共享同一个 event_id 让 Meta 能去重。附上你合法持有的、经过规范化的最丰富客户信息，包括那两个浏览器标识。然后拿你自己的订单记录去验，而不是拿后台去验——这里的故障不会抛错，它只会让你的数字看起来比实际更好看。
DeepClick 与广告主一起处理 Meta 投放外围的度量层，包括追踪与落地页分发怎么配合。
