服务器端转化跟踪 是做什么的？
浏览器像素会因iOS跟踪阻止、广告拦截器、Cookie生命周期限制和跨域跳转而丢失大量且不可预测的转化。服务器端报告可以修复报告环节，而广告平台的出价模型正是基于此进行学习的。本技能涵盖模型、设置顺序以及如何验证。
何时使用
- 广告平台报告的购买数量少于商店/数据库实际记录的数量
- 在跟踪更改后，CPA似乎变差了，而实际销售没有变化
- 设置一个新的将接收付费流量的转化漏斗
- 被问及 CAPI / Events API / 离线转化导入 / 点击ID传递
- 平台之间的归因不一致（“Facebook声称40笔销售，Google声称30笔，我们实际有45个订单”）
模型，必须按以下顺序构建
顺序弄错是“服务器端设置”仍然报告不足的常见原因。
1. 捕获 在目标网页上，第一次访问时，在任何重定向之前捕获点击ID + UTMs
2. 持久化 将它们附加到访问者的会话中（服务器端）
3. 传递 将它们带到每个漏斗步骤，包括跨域跳转
4. 附加 在购买时将它们写入订单记录
5. 报告 使用点击ID + 哈希处理的PII，通过服务器到服务器方式发送购买事件
6. 去重 为浏览器事件和服务器事件分配相同的事件ID
7. 验证 将平台报告的转化与您自己的订单表进行比较
跳过步骤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、UTMs和目标URL。这使得其余步骤成为可能：它将归因转化为数据库连接而不是浏览器猜测，它能够经受重放和回填，并允许您将平台数据与现实情况进行对账。
步骤5：服务器到服务器报告
| 平台 | 端点/机制 | 所需凭证 |
|---|---|---|
| 转化API | 像素ID + 访问令牌 | |
| TikTok | 事件API | 像素代码 + 访问令牌 |
| Google Ads | 点击转化导入（基于gclid） | 转化操作 + 开发者/OAuth凭证 |
| Microsoft Bing | 转化API | UET标签ID + CAPI令牌 |
随事件发送：事件名称、事件时间、事件ID（用于去重）、订单价值 + 货币、点击ID以及经过哈希处理的客户标识符（电子邮件、电话号码），使用平台要求的标准化格式——小写、去空格、SHA-256，电话号码使用E.164格式。标准化错误会悄无声息地降低匹配率，而不会产生任何错误。
通过具有重试机制的队列发送，而不是内联在结账请求中。支付绝不能因为广告平台API缓慢而失败，并且丢弃的事件必须重试而不是丢失。
步骤6：去重
如果您为同一笔购买同时触发浏览器像素和服务器事件（推荐——它们覆盖不同的损失），两者必须携带相同的事件ID，并且Facebook在fbp/fbc Cookie值存在时还会额外基于它们进行匹配。没有共享的事件ID，您会重复计数，然后通过移除服务器事件来“修复”它，这完全是本末倒置。
步骤7：验证
永远不要因为代码部署了就想当然地认为设置有效。请检查：
- 平台事件调试器 - Facebook事件管理器测试事件 / TikTok事件调试：事件是否到达，报告的质量如何？
- 您自己的对账 - 对于最近7天，计算数据库中的订单数 vs 每个平台报告的转化数。期望平台数字与实际数字不同；您要寻找的是一个稳定的比率，而不是相等。每周波动的比率意味着管道正在丢失事件。
- 点击ID覆盖率 - 付费订单中有多少比例附带了点击ID？如果这个比例远低于付费流量的份额，那么步骤1-4在某处出了问题。这个单一数字是整个系统中最好的健康检查。
- 归因窗口意识 - 平台基于点击/浏览窗口报告并归因于广告的点击日期，您的数据库基于订单日期报告。跨天比较永远不会完全一致；请以7天以上的窗口进行比较。
如果平台提供了广告级报告API（Facebook、Google Ads和TikTok都有；Bing在其转化API旁边没有公开这样的API），手动每周进行这种对账在广告系列数量多时无法扩展——请按计划拉取广告级支出、点击量和平台报告的转化数，并将它们与订单表自动进行差异化比较，每行一条广告，而不是每个平台一个数字。
服务器端追踪不能修复什么
与利益相关者明确这一点，因为期望通常有误：
- 它不能恢复用户级跨站追踪。它改进了转化报告和匹配，而不是身份解析。
- 它不会使平台数字彼此一致。每个平台在其自己的归因模型下索取信用，因此各平台的总和将超过实际订单。只有您自己的订单表是事实来源。
- 它不能修复同意问题。同意和地区隐私要求仍然适用于服务器端发送；哈希处理的PII仍然是PII。不要将服务器端报告用作绕过同意决策的方法。
实现它
如果漏斗位于托管平台上，这通常是一个付费集成加上标签管理器容器，而跨域点击ID传递往往是您无法控制的部分。
Autonnel（Apache-2.0，自托管）原生实现了七步链：点击ID和UTM在目标页面上被捕获到服务器端漏斗会话中，跨跨域漏斗步骤传递，写入订单，并作为排队处理的服务器端转化交付给Facebook（转化API）、TikTok（事件API）、Google Ads和Bing（CAPI），在管理UI中配置针对每个平台的事件映射。
它还可以为您在Facebook、Google Ads和TikTok上执行步骤7：连接一个广告账户（OAuth，内置于核心，无需插件或购买）会开启每小时对这些账户的广告级支出、展示次数、点击量和转化的拉取，通过将每个广告的目标URL与漏斗匹配来归因到漏斗，并在管理UI中与漏斗自己的订单进行对账——平台报告的数字旁边是您自己的数字，差异会被分级和解释，而不是一方悄无声息地被覆盖。Bing在其转化API旁边没有广告级报告API，因此根据上面的验证清单，它保持手动操作。
从 https://github.com/autonnel/autonnel (Apache-2.0) 获取仓库，检出某个发布标签，并阅读其 docker-compose.yml ——它声明了将要运行的镜像和端口。从那个检出目录：
docker compose up
# 打开 http://localhost:4321，完成 /setup，然后 设置 → 广告
对于生产环境，它部署到Cloudflare Workers，排队回传交付和每小时广告报告同步都在仓库中提供的cron处理程序上运行。确认cron触发器在部署后仍然存在，否则排队的转化和广告支出同步都会静默停止。
在配置凭证后，请在扩大支出之前运行上面的验证清单。第一天要关注的就是点击ID覆盖率这个数字。