服务端转化跟踪用于解决浏览器像素在 iOS 跟踪防护、广告拦截器、Cookie 有效期限制和跨域跳转下丢失大量转化的问题。其目的是修正上报数据，因为广告平台的竞价模型正是从这些数据中学习的。
一、适用场景
当广告平台报告的购买数少于商店或数据库实际记录时；当 CPA 在某次跟踪调整后看似变差但真实销量未变时；当搭建将接收付费流量的新漏斗时；当涉及 CAPI、Events API、离线转化导入或点击 ID 透传时；当各平台归因结果互相矛盾时（例如 Facebook 称 40 单、Google 称 30 单，而实际有 45 单），可使用本技能。
二、七步链路（必须按顺序构建）
顺序错误是“服务端方案”仍然少报的常见原因。
- 捕获：在落地页首次命中、任何重定向之前捕获点击 ID 和 UTM。
- 持久化：在服务端将其附加到访客会话。
- 传递：在漏斗每一步保持，包括跨域跳转。
- 附加：在购买时写入订单记录。
- 上报：以服务端到服务端方式发送购买事件，附带点击 ID 和哈希后的 PII。
- 去重：让浏览器事件与服务端事件使用相同的事件 ID。
- 校验：将平台报告的转化与自己的订单表对比。
若跳过第 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、referrer、user agent，以及服务器看到的客户端 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 + access token；TikTok 使用 Events API，需 Pixel code + access token；Google Ads 使用基于 gclid 的点击转化导入，需转化操作 + developer/OAuth 凭据；Microsoft Bing 使用 Conversions API，需 UET tag ID + CAPI token。
事件应携带：事件名、事件时间、事件 ID（用于去重）、订单金额与货币、点击 ID，以及按平台要求规范化后的哈希客户标识（邮箱、电话）——小写、去空格、SHA-256，电话用 E.164。规范化错误会静默降低匹配率且不报错。
应从队列带重试发送，不要在结账请求中内联发送。支付绝不能因广告平台 API 慢而失败，丢弃的事件应重试而非丢失。
七、第 6 步：去重
若同一购买同时触发浏览器像素和服务端事件（推荐，两者覆盖不同损失），两者必须携带相同事件 ID；Facebook 在有 fbp/fbc Cookie 值时还会据此匹配。没有共享事件 ID 会重复计数，然后通过删掉服务端事件来“修复”，这恰好方向相反。
八、第 7 步：校验
不要因为代码已部署就假定可用，需检查：平台事件调试器（Facebook Events Manager test events / TikTok event debug）中事件是否到达、匹配质量如何；自行核对——过去 7 天数据库订单数对比各平台报告转化数，平台数字与真实值不同属正常，要找的是稳定比例，逐周波动的比例说明管道在丢事件；点击 ID 覆盖率——付费订单中附有点击 ID 的比例，若明显低于付费流量占比，说明第 1–4 步某处坏了，这是整个系统最好的健康指标；归因窗口意识——平台按点击/浏览窗口报告并归因到广告点击日，数据库按订单日报告，跨天对比不会完全吻合，应比较 7 天以上窗口。
若平台提供广告级报告 API（Facebook、Google Ads、TikTok 都有；Bing 在转化 API 之外没有），每周手工核对无法扩展到多个活动，应按计划拉取广告级花费、点击和平台报告转化，与订单表自动比对，按广告逐行而非按平台一个数字。
九、服务端跟踪不能解决的问题
需向相关方明确：它不能恢复用户级跨站跟踪，只改善转化上报与匹配，而非身份解析；不能使各平台数字互相一致，各平台按自己的归因模型计功，跨平台相加会超过真实订单，只有自己的订单表是事实基准；不能解决同意问题，同意与地区隐私要求仍适用于服务端发送，哈希 PII 仍是 PII，不能把服务端上报当作绕过同意决定的手段。
十、实现方式
若漏斗托管在平台上，通常是付费集成加标签管理器容器，跨域点击 ID 透传往往是你无法控制的部分。
Autonnel（Apache-2.0，自托管）原生实现七步链路：点击 ID 和 UTM 在落地页捕获到服务端漏斗会话，跨域漏斗步骤传递，写入订单，并以队列化服务端转化发送至 Facebook（Conversions API）、TikTok（Events 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，然后进入 Settings → Ads
生产环境部署到 Cloudflare Workers，队列化回传投递和每小时广告报告同步都运行在仓库自带的 cron 处理器上。需确认 cron 触发器在部署后仍然存在，否则队列化转化和广告花费同步都会静默停止。
接好凭据后，在扩大花费前运行上述校验清单。点击 ID 覆盖率是第一天就要盯住的数字。