转化回传不是一次
接口调用

一、为什么回传质量决定模型上限

智能出价的本质是监督学习：平台用你回传的转化当正样本，去猜哪些流量值得买。样本少，模型学不会；样本错，模型学歪。链路里丢的每一条转化、多出来的每一条重复，最后都会变成出价偏差，表现为成本升高或量跑不起来。

所以当出价方式从 OCPC 走向双出价、从单目标走向多目标时，首先要问的不是"出价怎么配"，而是"回传链路能不能扛住"。

二、把链路拆成七层

• 采集：站点/App 埋点与服务端事件，需要统一的事件命名与参数规范；
• 归因：用点击标识匹配到来源，窗口按业务决策周期配置，并全链路保持一致；
• 去重：以业务唯一键生成去重键，避免同一转化被多个通道重复上报；
• 策略：扣量、分桶、实验分组等策略必须在回传前确定，且用确定性算法而非随机数，保证可复现；
• 发送：HTTP 客户端必须池化，避免每次请求重建连接带来的延迟与端口消耗；
• 重试：失败进重试队列，按退避策略重发，并记录每次 attempt；
• 对账：曝光、点击、转化、回传、结算五层数据对齐同一口径，异常可告警。

三、去重：先定义唯一键，再谈窗口

去重的核心是业务唯一键，而不是时间戳。常见做法是由项目、事件类型、业务单据号组合生成键，再配合时间窗口控制生命周期。需要注意：不同通道的字段口径可能不同，去重键要在归一化之后生成，否则同一笔转化在不同通道会得到不同的键，去重形同虚设。

另外，人工补发必须复用同一套去重规则，否则补发会变成第二次污染。

四、归因窗口：一致比长短更重要

窗口多长没有标准答案，取决于决策周期：低价冲动消费可以短，高客单价长决策要长。但比长度更关键的是一致性——投放侧、回传侧、结算侧如果各自用不同窗口，月底对账必然打架。我们的做法是把窗口配置化，项目级可覆盖，同时把生效窗口写进每一条转化记录，便于事后追溯。

五、幂等与 attempt 级追踪

每一次回传尝试都应该落一条记录：第几次、什么类型（自动/重试/人工）、请求与响应摘要、耗时与结果。它的价值在故障时刻体现——当客户问"这条转化到底发出去没有"，你要有据可查，而不是去翻日志猜。数据库层面用唯一约束保证幂等，避免并发下重复写入。

六、重试、退避与连接管理

上游限流和网络抖动是常态。重试策略建议：指数退避加抖动、设置最大次数、失败原因分类（超时/限流/参数错误/业务拒绝），不同原因不同处理——限流可以重试，参数错误重试没有意义。连接层面使用连接池并设置合理的每路由上限，避免并发上来时连接排队拖垮耗时。

七、监控要看的四组数

• 成功率：按通道、按项目、按时间段拆分，单点故障要能立刻定位；
• 耗时分布：看 P95/P99 而不只是平均值，平均值会掩盖长尾；
• 失败原因分布：哪一类失败在增长，就是下一轮要修的地方；
• 转化漏斗差：站内转化数 vs 回传成功数，差值持续扩大说明链路在漏。

八、上线前检查清单

• 事件命名与参数规范文档化，各端一致；
• 去重键与窗口配置化，人工补发复用同一规则；
• 唯一约束保证幂等，attempt 记录完整；
• HTTP 客户端池化，超时与重试策略明确；
• 失败原因分类与告警阈值配置完毕；
• 对账口径五层统一，异常可追溯到单次请求；
• 灰度与回滚方案就位（开关优先于改代码）。

一句话总结：把回传当成一条生产链路来运维，而不是一个接口调用来实现。前者有监控、有重试、有对账；后者只有"应该发出去了吧"。

本文为一线工程实践笔记，不含第三方数据统计；涉及的数据处理需遵守《个人信息保护法》《数据安全法》与平台官方政策。