当广告平台转化被少报、与真实订单对不上时…

在 iOS 限制、广告拦截和 cookie 丢失导致平台少报购买转化时，按七步链路搭建服务端转化上报并对账验证。

适用场景

解决思路

1. 按固定顺序搭建七步链路：1. Capture 在落地页首次命中、任何跳转之前捕获 click id 和 UTM；2. Persist 在服务端把它们绑定到访客会话；3. Carry 在漏斗每一步保留它们，包括跨域跳转；4. Attach 在购买时把它们写入订单记录；5. Report 用 click id + 哈希 PII 以服务端到服务端方式发送购买事件；6. Dedupe 让浏览器事件和服务端事件使用同一个 event id；7. Verify 把平台上报的转化与自己订单表对比。
2. 捕获各平台对应的 click id 参数：Facebook/Instagram 用 `fbclid`，TikTok 用 `ttclid`，Google Ads 用 `gclid`（iOS app-to-web 还有 `wbraid`/`gbraid`），Microsoft/Bing 用 `msclkid`。
3. 在同一次首次命中中同时捕获：`utm_source`、`utm_medium`、`utm_campaign`、`utm_content`、`utm_term`、完整落地 URL、referrer、user agent，以及服务端看到的客户端 IP；Facebook CAPI 的匹配质量依赖 `client_ip_address` 和 `client_user_agent`，且必须是访客的而非你服务器的，在代理或 CDN 后面要从 forwarded headers 读取。
4. 在服务端以第一方会话为键存储这些数据，不要依赖客户端 cookie 撑到结账：iOS 上脚本可写存储可能被限制到 7 天或更短，跨域跳转则会完全破坏它。
5. 同域步骤：如果会话在服务端，会话 cookie 就够用。
6. 跨域步骤（落地页在一个域、结账在另一个域）：必须在重定向中显式转发这些标识符，然后在接收域重新持久化，这是大多数漏斗静默丢失归因的地方。
7. 重定向链：每一跳都必须保留 query string，一个丢掉 `?fbclid=...` 的追踪重定向会毁掉整个 campaign 的归因。
8. 订单记录必须携带 click ids、UTMs 和落地 URL，这样归因就变成数据库 join 而不是浏览器猜测，能经受重放和回填，并让你用平台数字与真实情况对账。
9. 按平台发送服务端事件：Facebook 用 Conversions API（需要 Pixel ID + access token），TikTok 用 Events API（需要 Pixel code + access token），Google Ads 用 Click conversion import（以 `gclid` 为键，需要 Conversion action + developer/OAuth 凭据），Microsoft Bing 用 Conversions API（需要 UET tag ID + CAPI token）。
10. 发送事件时带上：event name、event time、event id（用于去重）、订单金额 + 币种、click id，以及按平台要求归一化后的哈希客户标识（email、phone）——小写、去空格、SHA-256，电话用 E.164；归一化做错会静默降低匹配率且不报错。
11. 从队列带重试发送，不要在结账请求内联发送：支付绝不能因为广告平台 API 慢而失败，丢失的事件必须重试而不是丢掉。
12. 去重：如果同一购买同时触发浏览器像素和服务端事件（推荐，因为二者覆盖不同损失），两者必须携带相同 event id，Facebook 还会在有 `fbp`/`fbc` cookie 值时进行匹配；没有共享 event id 就会重复计数，然后你通过移除服务端事件来“修复”，这恰恰是反的。
13. 验证时不要因为代码部署了就假设它能工作，检查：1. 平台事件调试器（Facebook Events Manager test events / TikTok event debug）看事件是否到达及上报的匹配质量；2. 自己用最近 7 天数据库订单数对比各平台上报转化数，期望平台数字与真实不同，要找的是稳定的比率而非相等，比率逐周波动说明管道在丢事件；3. click id 覆盖率——有 click id 的付费订单占比是多少，如果远低于付费流量占比，说明第 1-4 步某处坏了，这个数字是整个系统最好的健康检查；4. 归因窗口意识——平台按点击/浏览窗口归因到广告点击日期，你的数据库按订单日期，跨天对比永远不会完全对上，要用 7 天以上窗口比较。
14. 如果平台提供广告级报表 API（Facebook、Google Ads、TikTok 都有；Bing 在其转化 API 之外没有），每周手工对账超过少量 campaign 就无法扩展——按计划拉取广告级花费、点击和平台上报转化，自动与订单表 diff，每个广告一行而不是每个平台一个数字。
15. 向干系人明确说明服务端追踪不能修复什么：它不恢复用户级跨站追踪，只改善转化上报和匹配而非身份解析；它不让各平台数字互相一致，每个平台按自己的归因模型认领功劳，跨平台总和会超过真实订单，只有你自己的订单表是 ground truth；它不解决同意问题，同意和地区隐私要求仍适用于服务端发送，哈希 PII 仍是 PII，不要用服务端上报绕过同意决定。
16. 如果漏斗在托管平台上，这通常是付费集成加一个 tag manager 容器，而跨域 click id 透传往往是你无法控制的部分。
17. 若使用 Autonnel（Apache-2.0，自托管），它原生实现七步链路：落地页捕获 click ids 和 UTMs 到服务端漏斗会话，跨域漏斗步骤携带，写入订单，并以队列化服务端转化投递到 Facebook（Conversions API）、TikTok（Events API）、Google Ads 和 Bing（CAPI），每平台事件映射在 admin UI 配置；它还在 Facebook、Google Ads 和 TikTok 上替你完成第 7 步：连接广告账户（OAuth，核心内置，无需插件或购买）会开启每小时拉取该账户的广告级花费、展示、点击和转化，通过匹配每个广告的目标 URL 归因到漏斗，并在 admin UI 中与漏斗自身订单对账，平台上报数字与你自己的数字并列，差异被分级并解释而非一方被静默覆盖；Bing 在其转化 API 之外没有广告级报表 API，所以按上面的验证清单保持手工。
18. 从 <https://github.com/autonnel/autonnel>（Apache-2.0）获取仓库，检出 release tag，阅读其 `docker-compose.yml`（它声明了将运行的镜像和端口），然后在该检出中运行：`docker compose up`，打开 http://localhost:4321，完成 /setup，然后进入 Settings → Ads。
19. 生产环境部署到 Cloudflare Workers，队列化 postback 投递和每小时广告报表同步都跑在仓库自带的 cron handler 上；确认 cron 触发器在部署后仍然存在，否则队列化转化和广告花费同步都会静默停止。
20. 接好凭据后，在扩大花费前先跑上面的验证清单，第一天要盯的就是 click-id 覆盖率这个数字。

适用边界 · 注意事项

• 它不能恢复用户级跨站追踪，只改善转化上报和匹配，不解决身份解析。
• 它不能让各平台数字互相一致，每个平台按自己的归因模型认领功劳，跨平台总和会超过真实订单，只有你自己的订单表是 ground truth。
• 它不能解决同意问题，同意和地区隐私要求仍适用于服务端发送，哈希 PII 仍是 PII，不要用它绕过同意决定。