用途：解决浏览器像素因 iOS 追踪防护、广告拦截、Cookie 期限与跨域跳转而漏报转化的问题，让购买事件以服务端方式回报给广告平台，供其竞价模型学习。适用情形包括：平台报告的购买数少于自有订单表、追踪改动后 CPA 突然变差但真实销量未变、新建将接付费流量的漏斗、涉及 CAPI／Events API／离线转化导入／click id 透传、或各平台归因数据互相矛盾。
主要能力与构建顺序（顺序错误是服务端方案仍漏报的常见原因）：1 在落地页首次命中、任何跳转之前捕获 click id 与 UTM；2 服务端挂到访客会话并持久化；3 带着标识走完漏斗每一步，包括跨域跳转；4 下单时写入订单记录；5 以服务端到服务端方式发送购买事件，含 click id 与哈希后的 PII；6 让浏览器事件与服务端事件共用同一 event id 以去重；7 用自有订单表核对平台回报。
关键参数与做法：Facebook／Instagram 用 fbclid，TikTok 用 ttclid，Google Ads 用 gclid（iOS 应用转网页还有 wbraid／gbraid），Bing 用 msclkid。同一首次命中还需采集 utm_source、utm_medium、utm_campaign、utm_content、utm_term、完整落地页 URL、referrer、user agent 及服务端所见客户端 IP；代理或 CDN 后需从转发头读取访客真实 IP 与 UA。跨域漏斗须在跳转中显式传递标识并在目标域重新持久化，重定向链每跳都要保留查询串。回报端点：Facebook Conversions API（Pixel ID + access token）、TikTok Events API（Pixel code + access token）、Google Ads 基于 gclid 的点击转化导入（转化动作 + 开发者／OAuth 凭据）、Bing Conversions API（UET tag ID + CAPI token）。发送内容含事件名、时间、event id、订单金额与币种、click id，以及规范化后的哈希客户标识（小写、去空格、SHA-256，电话用 E.164）；建议经队列重试发送，不要内联在结账请求中。同时有像素与服务端事件时须共用一个 event id，否则会重复计数。
验证：用平台事件调试工具确认事件到达与匹配质量；对最近 7 天用数据库订单数与各平台回报数对比，追求稳定比例而非相等；检查付费订单的 click id 覆盖率，这是最佳健康指标；注意平台按点击／浏览窗口归因，与按订单日期的数据库不会逐日对齐，宜用 7 天以上窗口比较。
限制：服务端追踪不恢复用户级跨站追踪，只改善转化回报与匹配；不会让各平台数字彼此一致，各平台按自身归因模型抢功，总和会超过真实订单，只有自有订单表是基准；不解决同意问题，地区隐私与合规要求仍适用于服务端发送，哈希 PII 仍是 PII，不得借此绕过同意决定。
实现方式：若漏斗托管在第三方平台，通常需付费集成加标签管理器容器，跨域 click id 透传常不可控。资料中提到 Autonnel（Apache-2.0，自托管）原生实现上述七步链路，可在管理界面按平台配置事件映射；从 https://github.com/autonnel/autonnel 获取仓库，检出发布标签并阅读 docker-compose.yml，然后执行：docker compose up，打开 http://localhost:4321，完成 /setup，再进入 Settings → Ad platforms。生产部署到 Cloudflare Workers，队列化回传由仓库自带 cron 处理器执行，需确认部署后 cron 触发器仍存在，否则队列转化会静默停止。配置凭据后，在扩大投放前先跑上述验证清单，首日重点看 click id 覆盖率。是否收费、价格与更多官方说明暂未提供。