前阵子有个客户找过来，做的方向是工具类应用的竞价投放，每天点击量大概一千二三的样子。他们的回传链路是自己搭了个中转服务，再推给广告平台。技术负责人当时给了几条硬约束：单地域双节点部署，链路中间有一段跨机房调用，验收标准是当天产生的转化第二天凌晨之前得全部可见。跑了两个礼拜，智能出价模型开始不对劲了，转化成本一会儿高一会儿低，同一批关键词在报表里转化量怎么都对不上。后来查下来，出价策略本身没毛病，是数据回传延迟把模型搞得跟半瞎似的。
调出价系数这事儿先放一边。真正要回答的是更靠前的问题——回传延迟到底在什么边界内不会把智能出价模型搞崩，哪些情况能忍，哪些必须马上处理。我准备从延迟来源、影响条件、排查顺序、止损决策这四个层面来拆。
回传延迟的四种来源，性质不同容忍度也不同
经常有人一上来就问，延迟几个小时算高。这问题真没法一句话回答，因为延迟的性质不一样，传导到模型身上的路径也完全不同。按来源拆的话至少四类，处理优先级也不在一个档次上。
链路传输延迟
用户完成转化动作之后，这个事件要经过好几跳才能到广告平台的接口，每一跳都会叠时间。一般这类延迟是秒级到分钟级的，特点是稳、可预测。怎么判断呢——在同一时段里抽一部分事件，把埋点触发的时间戳和平台实际接收的时间戳拉出来对一下，差值波动如果控制在小范围里（几十秒以内），那属于正常链路开销。可要是差值突然从几秒蹦到十几分钟，那基本能确定是某一跳堵了或者在疯狂重试。
实际操作层面，可以在中转服务里把事件入队和出队的时间戳都记下来，每一跳的耗时打个点。但要注意，打点本身会增加日志量，并发高的时候得考虑采样。验证的时候别只看平均值，平均值会把长尾藏起来，要看耗时的分位数分布。
为了少调几次接口，不少团队会把转化事件先写进库，然后按批次定时往外推。这种延迟是分钟级到小时级的，特点是有固定的时间窗口。判断方法就是看批次间隔和窗口多大，要是窗口设得比模型的学习周期还长，那影响就会被放大。
不过这类延迟的调整余地是最大的。可以把高价值的转化事件单独拎出来走实时通道，低价值的继续走批量，按事件价值来分流。麻烦的地方在于分流逻辑本身需要维护一套规则，规则一多就容易出配置冲突。
归因回填延迟
有些转化不是当下就发生的。用户注册完隔天才付费，或者点击之后过了好几天才形成有效线索，这都算。这种延迟跟链路没关系，是业务本身的转化周期决定的。判断的时候去看转化路径的时间分布：大部分转化如果都在点击后两小时内完成，那回填延迟的影响就小；转化周期要是拉到好几天，模型看到的永远是滞后的样本。
这类延迟没法消除，只能把口径对齐。具体做的时候要跟业务方确认清楚归因窗口，把回传时间戳统一到同一个口径上，别出现报表里一部分按点击时间算、一部分按回传时间算的情况。
重试与补偿延迟
回传失败之后的重试机制会额外引入延迟。失败一次隔几分钟重试，要是连续失败，时间就能拉到几十分钟甚至更长。判断方式看两个东西——失败率和重试次数的分布。失败率低但重试次数多，说明链路不太稳；失败率高而且重试很频繁，那可能是接口或者鉴权出了问题。
重试肯定不能无限次搞，得有上限，还得有退避策略。验证的办法是模拟接口不可用，看重试队列积压成什么样，确认积压不会把正常事件挤出去。
延迟影响模型稳定性的三个条件
同样延迟两小时，有些账户的模型照样跑得挺好，有些账户就开始乱套。差别就出在下面三个条件上。
条件一：回传延迟与模型学习周期的比值
智能出价模型有自己的学习窗口，一般按小时或者天来更新对转化率的估计。回传延迟要是远小于学习窗口，模型基本感觉不到；可一旦延迟接近甚至超过学习窗口，模型就是在拿旧数据做决策了。判断这个比值不需要精确算数值，看一个信号就行：当天的转化数据第二天才大量到达，而模型当天已经在调出价了，这说明延迟已经侵入学习周期了。
操作上，把回传时间戳和模型更新日志放到同一条时间轴上比对，看看模型每次更新的时候手里有多少新鲜样本。模型更新日志未必完全开放，退一步也可以看平台后台的转化时间分布。
条件二：流量结构与转化密度
转化密度低的账户对延迟更敏感。日均一千多次点击、转化就几十个的账户，每个转化样本都很金贵，延迟导致样本缺失会直接把估计扭曲掉。转化密度高的账户，单样本缺失被平均掉了，敏感度就低一些。
判断条件就是算转化密度——转化数除以点击数。密度越低，延迟越得严控。操作上按广告系列分组看密度，低密度、高预算的系列优先纳入延迟监控。
条件三：出价策略的激进程度
目标转化费用策略比 maximize clicks 对数据质量敏感得多，因为前者依赖对转化率的连续估计，后者只看点击。出价目标越激进，对延迟的容忍度就越低。判断条件是看出价波动的幅度——如果出价在一天之内反复大幅调整，而回传数据还没到位，那波动大概率是延迟引起的。
不同策略的敏感度没有官方阈值可查，只能做对照观察：在回传延迟改善前后，看出价波动有没有收敛。
一套可执行的排查顺序
发现问题了别急着改回传链路，先按顺序定位。下面这几步是我平时用的。
- 对齐时间口径：把埋点时间、中转入队时间、出队时间、平台接收时间这四个时间戳拉到同一张表里，先确认延迟出在哪一段。
- 看延迟分布： 算 P50、P90、P99 分位数。长尾比平均值更能说明问题，P99 要是远高于 P50，说明存在偶发但严重的阻塞。
- 算转化密度： 按系列算转化数除以点击数，把低密度系列标出来。
- 比对模型更新窗口： 看模型每次更新时，近一个窗口内的转化样本完整度是多少。
- 做对照： 出价策略先别动，优化回传链路，观察一到两个学习周期后的出价波动和转化成本变化。
匿名实战复盘：工具类应用的回传链路改造
说回开头那个客户。背景约束前面提过了：工具类应用，日均点击一千二三，单地域双节点部署，回传走自建中转再推平台，验收要求是当天转化次日凌晨前可见。他们踩的坑有三个。
批处理窗口设太长了，这是第一个坑。最初他们把转化事件按十五分钟一批推送，单看好像不长，但跟模型的学习节奏叠在一起，模型决策的时候用的就是上一批甚至上上批的数据。第二个坑是跨机房调用没做超时隔离，有一次机房网络抖动，重试队列积压了将近四十分钟，正常事件全被堵在后面。第三个坑是报表口径混用，运营看的按点击时间算，技术看的按回传时间算，两边一对不上就以为数据丢了。
调整分了三步走。先把高价值转化事件从批处理里拆出来，走独立的实时通道，低价值事件继续批量推。然后给跨机房调用加了超时和熔断，超过阈值直接走备用路径，不再无限重试。最后把报表口径统一到回传时间，后台加了一个"近一小时样本完整度"的看板。
最终的状态是：延迟从原来十几分钟到四十分钟不等，收敛到大部分事件两分钟内到达，长尾控制在十分钟以内。出价波动明显收敛了，转化成本在随后两周里回到一个相对稳定的区间。出价策略层面一点没动，改的全是回传链路和口径。
止损阈值与下一步决策
什么时候该动手，什么时候还能再观察观察，用一个决策表来收束。
回传延迟 P90 小于模型学习窗口的十分之一：可以继续观察，不用立即动手。；P90 接近学习窗口的三分之一，同时转化密度偏低：进入排查，优先看批处理窗口和重试队列。；P99 频繁突破学习窗口，或者出现重试积压：立即处理，先做超时隔离和通道分流。；报表口径不一致导致的"假延迟"：先对齐口径，再判断是不是真的延迟。。
接下来的动作建议按这个顺序走：确认延迟来源，算转化密度和延迟比值，按排查顺序定位，最后做对照验证。定位没清楚之前别去调出价系数，那样只会把问题盖住。
常见问题
回传延迟和模型不稳定之间，有没有一个通用的时间阈值？
没有。阈值取决于模型学习窗口、转化密度和出价策略激进程度这三个条件。同一个延迟值，在高密度、温和策略的账户上可能完全无感，在低密度、激进策略的账户上就可能引发明显波动。判断时优先看延迟与学习窗口的比值，别盯着绝对时间。
不一定。按事件价值分流更实际——高价值转化走实时，低价值走批量。全部改实时会增加接口压力和成本，收益未必对等。
转化周期本身很长，回填延迟无法消除怎么办？
这类延迟消不掉，只能对齐口径，并且在评估模型表现的时候把归因窗口考虑进去。别用短窗口的报表去评价一个长周期转化的账户。 把回传延迟当成一个链路指标来管，别当成出价策略问题来解，大部分模型波动都能找到可操作的落点。
