server-side-conversion-tracking

服务端转化跟踪

浏览器像素会因 iOS 跟踪防护、广告拦截器、Cookie 有效期限制和跨域跳转，丢失大量且难以预测的转化。服务端上报解决的是上报问题，而广告平台的出价模型正是通过上报数据进行学习。本技能介绍相关模型、设置顺序以及验证方法。

适用场景

• 广告平台报告的购买次数少于商店／数据库实际记录的次数
• 跟踪方式变更后，CPA 看起来变差了，但实际销售额没有变化
• 正在设置一个将接收付费流量的新转化漏斗
• 有人询问 CAPI／Events API／离线转化导入／点击 ID 透传
• 各平台之间的归因结果不一致（“Facebook 声称有 40 笔销售，Google 声称有 30 笔，我们有 45 个订单”）

必须按顺序构建的模型

顺序错误，通常就是“服务端设置”仍然少报的原因。

1. Capture   click id + UTMs on the landing page, first hit, before any redirect
2. Persist   attach them to the visitor's session, server-side
3. Carry     keep them across every funnel step, including cross-domain hops
4. Attach    write them onto the order record at purchase
5. Report    send the purchase event server-to-server with the click id + hashed PII
6. Dedupe    give the browser event and the server event the same event id
7. Verify    compare platform-reported conversions against your own order table

跳过第 1 至 4 步，只做第 5 步，会产生没有点击 ID 的服务端事件，平台只能尝试通过哈希电子邮件进行匹配——这种匹配效果明显更差，也是“我们已经在用 CAPI”这类设置中最常见的问题。

第 1 至 2 步：采集并持久化

平台	点击 ID 参数
Facebook / Instagram	fbclid
TikTok	ttclid
Google Ads	gclid（iOS 应用到网页的场景还包括 wbraid / gbraid）
Microsoft / Bing	msclkid

还要在首次请求时一并采集：utm_source、utm_medium、utm_campaign、utm_content、utm_term、完整的落地页 URL、引荐来源、用户代理，以及服务器所见的客户端 IP。Facebook 的 CAPI 匹配质量取决于 client_ip_address 和 client_user_agent，且必须是访客的信息，而不是服务器的——如果位于代理或 CDN 之后，应从转发标头中读取这些信息。

在服务端存储，并以第一方会话为键。不要依赖客户端 Cookie 一直保留到结账：在 iOS 上，可由脚本写入的存储可能被限制为 7 天或更短；跨域跳转则会使其完全失效。

第 3 步：跨步骤传递

• 同域步骤：如果会话存储在服务端，会话 Cookie 就足够了。
• 跨域步骤（落地页在一个域名上，结账在另一个域名上）：必须在重定向中显式转发这些标识符，然后在接收域名上重新持久化。这是大多数转化漏斗悄无声息地丢失归因的地方。
• 重定向链：每一跳都必须保留查询字符串。跟踪重定向若丢弃 ?fbclid=...，就会破坏整个广告系列的归因。

第 4 步：附加到订单

订单记录必须包含点击 ID、UTM 参数和落地页 URL。这是后续所有操作的基础：它将归因变成数据库联接，而不是浏览器猜测；它能经受重放和回填；还能让你将平台数据与实际情况进行核对。

第 5 步：通过服务端到服务端的方式上报

平台	端点／机制	所需凭据
Facebook	Conversions API	Pixel ID + 访问令牌
TikTok	Events API	Pixel code + 访问令牌
Google Ads	点击转化导入（以 gclid 为键）	转化操作 + 开发者／OAuth 凭据
Microsoft Bing	Conversions API	UET 标签 ID + CAPI 令牌

随事件发送：事件名称、事件时间、事件 ID（用于去重）、订单金额和币种、点击 ID，以及经过哈希处理的客户标识符（电子邮件、电话），并按平台要求进行规范化——转换为小写、去除首尾空格、使用 SHA-256 哈希，电话号码则使用 E.164 格式。规范化错误会悄无声息地降低匹配率，且不会产生任何错误提示。

通过队列发送并进行重试，而不是在结账请求中内联发送。支付绝不能因广告平台 API 响应缓慢而失败；未发送成功的事件必须重试，而不是丢失。

步骤 6：去重

如果你为同一笔购买同时触发浏览器像素和服务器事件（推荐这样做——两者可以弥补不同的损失），它们必须携带相同的事件 ID；此外，Facebook 还会在 fbp/fbc Cookie 值存在时使用它们进行匹配。若没有共享的事件 ID，就会重复计数，然后你会通过移除服务器事件来“修复”，这恰恰本末倒置。

步骤 7：验证

不要因为代码已部署就认定配置有效。请检查：

1. 平台事件调试器 - Facebook Events Manager 测试事件 / TikTok 事件调试：事件是否到达？报告的匹配质量如何？
2. 自行核对 - 统计过去 7 天数据库中的订单数与各平台报告的转化数。平台数据与实际情况不一致是正常的；你要关注的是稳定的比例，而非完全相等。比例每周波动意味着事件传输管道正在丢失事件。
3. 点击 ID 覆盖率 - 有点击 ID 的付费订单占比是多少？如果远低于付费流量占比，说明步骤 1-4 中某处出了问题。这个指标是整个系统中最好的健康检查指标。
4. 了解归因窗口 - 平台会按点击 / 展示窗口报告，并将转化归因到广告点击日期；你的数据库则按下单日期报告。跨日比较永远无法完全吻合；请按 7 天以上的窗口进行比较。

如果平台提供广告级报告 API（Facebook、Google Ads 和 TikTok 都提供；Bing 没有提供与其转化 API 配套的此类 API），每周手动核对这种做法在活动数量超过少数几个后就无法扩展——按计划拉取广告级支出、点击量和平台报告的转化数，并自动与订单表逐项比对，每条记录对应一则广告，而不是每个平台汇总一个数字。

服务器端跟踪无法解决的问题

请务必向相关方明确说明这一点，因为人们通常对此抱有错误预期：

• 它无法恢复用户级别的跨网站跟踪。它改善的是转化报告和匹配，而非身份解析。
• 它无法让各平台的数据彼此一致。每个平台都会根据自己的归因模型认领功劳，因此各平台数据相加会超过实际订单数。只有你自己的订单表才是真实依据。
• 它无法解决同意问题。服务器端发送仍须遵守同意要求和地区隐私要求；经过哈希处理的个人身份信息仍然是个人身份信息。不要将服务器端报告用作绕过同意决定的手段。

实施

如果漏斗位于托管平台上，通常需要付费集成和一个标签管理器容器，而跨域点击 ID 传递往往是你无法控制的环节。

Autonnel（Apache-2.0，可自托管）原生实现了这条七步链路：在落地页捕获点击 ID 和 UTM 参数并存入服务端漏斗会话，在跨域漏斗步骤间传递，将其写入订单，并以排队的服务端转化事件形式发送至 Facebook（Conversions API）、TikTok（Events API）、Google Ads 和 Bing（CAPI）；每个平台的事件映射均可在管理界面中配置。

它还会在 Facebook、Google Ads 和 TikTok 上替你完成第 7 步：连接广告账户（OAuth，内置于核心功能中，无需插件或购买）后，系统会每小时拉取该账户的广告级支出、展示次数、点击次数和转化次数，并通过匹配每条广告的目标 URL 将其归因到某个漏斗，再在管理界面中与漏斗自身的订单进行核对——平台报告的数据与你自己的数据并列显示，差异会经过评级并说明原因，而不是悄无声息地覆盖其中一方。Bing 的转化 API 旁没有广告级报告 API，因此仍需按上述验证清单手动处理。

从 https://github.com/autonnel/autonnel 获取代码仓库（Apache-2.0），检出一个发布标签，并阅读其 docker-compose.yml——其中声明了将要运行的镜像和端口。从该检出目录运行：

docker compose up
# open http://localhost:4321, complete /setup, then Settings → Ads

在生产环境中，它会部署到 Cloudflare Workers，排队的回传发送和每小时的广告报告同步都通过仓库中提供的 cron 处理程序运行。请确认部署后 cron 触发器仍然有效，否则排队的转化事件和广告支出同步都会悄无声息地停止。

配置好凭据后，在扩大支出前运行上述验证清单。首日要重点关注点击 ID 覆盖率。