多彩编程 多彩编程MZPH · CODE BLOG
ARTICLE DETAIL

文章详情

深耕前端与后端开发技术的一线实战笔记与踩坑复盘。

级联延迟反馈建模:破解展示广告CVR预估的两段式延迟难题

级联延迟反馈建模:破解展示广告CVR预估的两段式延迟难题 展示广告的CVR预估做久了你会发现有两件事最让人头疼一是样本极度稀疏二是转化反馈总是迟到。市面上解决延迟反馈的模型已经不少但多半是把“曝光到转化”当成一个整体延迟来建模。阿里妈妈在WWW 2026上提出的这篇级联延迟反馈建模框架把问题粒度又往下钻了一层——它明确指出延迟不是一段而是两段曝光到点击的延迟以及点击到转化的延迟这两段叠在一起才是展示广告的真实反馈链路。这篇内容很适合正在做广告算法、推荐排序或者被转化延迟和样本拼接折磨的同行参考看完你至少能厘清三个问题传统单点延迟模型到底错在哪、级联建模的概率框架怎么搭、以及落到工程上需要处理哪些细节。1. 为什么“延迟”会变成级联的展示广告里的两段式时间账1.1 曝光到点击再到转化中间隔着两个时钟先说一个我在实际业务里反复遇到的场景。一个用户在某App的信息流里看到一条商品广告当时没点两天后通过另一个渠道的推送想起来这个商品点进详情页又过了几个小时才完成下单。如果只统计“曝光到转化”的总时长那是“两天零几个小时”看起来像一个长尾延迟。但这个总时长其实是两个完全不同性质的随机过程拼起来的曝光到点击的决策过程和点击到转化的决策过程。这两个过程的驱动因素差别很大。曝光到点击更多受创意吸引力、广告位置、用户当下是否在逛等因素影响点击到转化则受商品价格、详情页内容、竞品对比、用户购买意愿强度影响。一个用户可能因为“广告图好看”很快点击但货比三家拖了三天才买也可能反复看了广告好几遍最后点进去立刻下单。如果强行把两段合并成一个延迟分布等于默认这两个阶段的时间特性是同质的这个假设在展示广告里基本不成立。这也是为什么标题里要强调“级联”这个词。级联的含义就是下游事件转化的发生以上游事件点击的发生为前置条件两段延迟在概率上存在天然的先后依赖。忽略这个依赖而直接回归总延迟相当于把一条生产流水线上的两道工序合并成一道来估算工时看似简化了问题实际会带来系统性的偏差。1.2 传统单点延迟模型在多重延迟场景下的三个翻车点现在业界常见的延迟反馈建模思路比如早期FTC那类方法核心是给曝光样本一个正样本的延迟分布假设然后用生存分析处理观察窗口内未转化样本。这类方法在“曝光即代表有效触达”的场景里问题不大但放在展示广告里会遇到三个非常尴尬的情况。第一样本身份定义混乱。展示广告的点击率往往很低大量曝光根本没有产生点击。传统模型把“曝光后未转化”统一当作删失样本处理但其中“未点击”和“已点击未转化”其实是两种完全不同的删失状态前者可能压根没有进入购买意愿阶段后者已经进入了却被价格或体验劝退。把它们混在一起估计延迟分布等于把两种性质完全不同的数据混在一个桶里训练。第二观察窗口的选择进退两难。如果按曝光时刻起算观察窗口为了覆盖转化延迟的尾部窗口往往要拉很长但点击延迟在窗口内的占比会被稀释如果按点击时刻起算又会丢掉大量“始终未点击”的曝光样本导致模型完全没有机会学习曝光侧的延迟和转化率。第三预测校准不自洽。线上推理时单点模型通常直接输出一个“曝光后多久会转化”的期望。但展示广告的真实链路上用户要先点击才可能转化未点击的曝光根本没有资格进入转化概率的计算。单点模型把这个过程折叠了输出值容易偏高尤其当点击延迟比较大的时候校准误差会比较明显。这三处痛点合在一起就是阿里妈妈这篇工作想要解决的“多重延迟”问题。而它的破局思路也很直接既然延迟是两段的那就把模型也拆成两段。2. 级联延迟反馈建模从单一延迟分布到联合生存模型2.1 核心思想用概率链把两段延迟解耦级联延迟反馈建模通俗讲就是不再直接对“曝光到转化”的总时长做一个回归而是把转化事件分解成两个子问题事件A 曝光后发生点击事件B 点击后发生转化。两者的延迟分别记为T_c和T_v目标概率P(转化|曝光)通过链式法则写成P(点击|曝光) × P(转化|点击)并且每个环节都携带各自的延迟信息。妙在哪妙在每个环节现在可以用独立的生存分析模型来刻画而且可以共享一部分特征却不必共享延迟分布。点击延迟分布和转化延迟分布可以有各自的参数、各自的形态。你可以假设点击延迟服从一个快速衰减的分布因为用户在浏览场景下的点击决策通常很快而转化延迟则拖着一个更长的尾巴因为下单前要比价、要犹豫。这在单点模型里是做不到的。从数学形式上看训练目标会变成一个双重积分对点击发生的时刻和转化发生的时刻做积分且积分域满足转化时刻大于点击时刻。这个约束很关键它把“级联”这个业务直觉直接编码进了概率结构只有点击先发生转化才可能出现。模型本质上就是在拟合两个事件在时间轴上的联合分布而级联约束让这个联合分布退化为一个条件分布和一个边缘分布的乘积大大简化了参数的估计难度。2.2 训练样本的三种状态与似然构造实际训练时面对的都是带截断和删失的数据。对一个曝光样本我们通过日志能观测到的状态无外乎三种曝光后没有任何点击有点击但在观察窗口内没有转化点击和转化都发生了且有对应的时刻。第三种是完整样本前两种分别是不同层级的删失样本。级联模型在构造似然函数时需要为每种状态分别写概率。完整样本贡献的是点击延迟密度和转化延迟密度的乘积已点击未转化贡献的是点击延迟密度乘以转化延迟的生存函数也就是点击后到窗口截止都还没转化的概率未点击贡献的是点击延迟的生存函数。这三个部分的加总就是整个训练集的对数似然。这里有个容易被忽略的点未点击样本的似然不是直接对P(转化|曝光)取对立面而是只对点击延迟的生存函数做积分。换句话说模型从“未点击”这个事实里学到的是“点击延迟超过了观察窗口”而不是“这个用户永远不会转化”。这样处理的好处是即使观察窗口很短模型也能从大规模“尚未点击”的曝光里学到点击延迟的分布形状而不是简单地把它们当负样本丢掉。这对展示广告这种低点击率场景来说是至关重要的。2.3 推理阶段的期望计算与校准线上推理时模型需要输出一个可供排序使用的标量。级联框架天然给出了一个更合理的形式把点击延迟的密度函数和转化延迟的条件生存函数做积分算的是“在给定时间范围内预期转化率”而不是某条固定时间路径下的点估计。实际实现中一般会做数值积分或者离散化求和将时间轴切成桶每个桶算一下条件概率再累加。还有一个很实际的问题校准。延迟反馈模型最常见的坑就是预测值整体偏高或偏低因为训练标签的观察窗口和线上请求的环境不一致。我的建议是在推理层增加一个分桶校准器用最近一段时间内实际观察到的转化数除以预测期望数作为校准因子乘上去。分桶维度可以按广告主的行业来分因为不同行业的延迟特性差异很大一个统一系数往往不够用。这样调完线上的预测CTR/CVR漏斗会更加对齐出价稳定性也会好不少。3. 工程落地细节从论文到广告系统的最后一公里3.1 样本拼接与观察窗口设计论文里的框架设计再好落到工程上第一关永远都是样本。级联模型对样本拼接的要求比单点模型更高一张训练样本需要同时关联曝光日志、点击日志和转化日志并记录曝光时间、点击时间、转化时间三个时间戳。这一套逻辑在离线数仓里通常会写成多表join但真正容易出问题的是归因口径。我的实操经验是曝光和点击之间按session内去重归因一个点击只归因到最近一次有效曝光点击和转化之间继承业界的常规归因方式比如7天或30天窗口内最后一次点击归因。注意这里“最近一次”和“最后一次”的口径不能混。如果两个口径混用会导致同一个曝光出现在多张样本里标签互相打架模型学到的概率分布会变得非常不稳定。观察窗口方面级联模型打开了一个新选项可以为点击延迟和转化延迟分别设置窗口。比如点击延迟窗口设为1天转化延迟窗口设为7天。因为点击决策通常很快窗口拉太长只会引入大量噪声而点击后的转化则需要更长的观察期。这里要注意的是两段窗口的结合处会产生一段“等待区”用户已经点击但还在转化延迟观察期内。这个区域的数据在流式训练里要特别小心不能因为暂时没有转化就立刻当作负样本打标否则会把高潜用户误伤成负样本。3.2 特征体系与模型结构怎么搭特征方面级联模型最值得投入的是两阶段各自的特征分离。底部共享特征可以包含用户画像、广告素材类目、上下文场景、时间特征但点击延迟分支要额外加入“曝光位置”“创意尺寸”“是否首刷”这些影响注意力的特征转化延迟分支则要加入“商品价格带”“店铺评分”“历史复购率”这些影响购买决策的特征。两类特征有交叉但又各有侧重硬塞进同一个tower里会让梯度互相干扰。模型结构上推荐双塔加共享底层的设计一个共享embedding层上面分叉成两个小网络分别输出点击延迟分布的参数和转化延迟分布的参数。分布可以选Weibull或者分段指数前者参数少、好调后者表达能力强、更贴数据。我的建议是先用Weibull打底因为它只需要两个参数训练稳定等线上验证效果之后再考虑换成更精细的分段模型来压尾部误差。3.3 离线评估与线上AB的配合延迟反馈模型的离线评估是个容易自欺欺人的环节。常规的AUC和GAUC只能反映排序能力反映不了延迟分布拟合得好不好。我见过的团队踩过不少坑离线AUC涨了线上成本却飘了。原因是模型把延迟预测得过于集中导致出价频率异常。所以在离线阶段除了排序指标还要加两个维度的度量一个是延迟分布的拟合度可以看测试集上完整样本的经验延迟分布与模型预测分布的KL散度或者KS统计量另一个是校准误差按预测概率分桶看每个桶内实际转化率与预测期望的比值。这两个指标过关了才能把模型推到线上。线上AB时不要只盯7日CVR的均值还要看两个辅助指标转化时间的中位数是否被拉低以及分行业的成本稳定性。级联模型最大的收益往往不是CVR暴涨而是整个漏斗的节奏更一致点击和转化之间的等待时间被更准确地估计从而让调价系统对“这条流量值多少钱”的判断更稳。4. 常见问题与避坑实录4.1 条件独立性假设什么时候会失效级联框架默认点击延迟和转化延迟在给定特征后是条件独立的但真实场景里这两个延迟经常会因为同一个隐藏因素一起变化。最常见的就是新用户新用户既可能因为不了解品牌而延迟点击也可能因为信任度低而延迟转化这两个延迟正相关。如果模型完全忽略这种相关性会把转化概率的方差估计偏大导致排序结果在冷启动流量上偏激进。我的一个处理建议是在共享底层加入一个用户活跃度向量把“用户和广告主的熟悉程度”作为一个连续的隐变量塞进去。这样模型可以通过这个隐变量间接捕获点击与转化之间的相关性而不需要强行改变概率结构。实测下来这种折中方案比单纯硬套条件独立假设要稳。如果数据量足够也可以进一步扩展成带共享随机效应的层次模型但工程成本会明显上升属于后续的锦上添花。4.2 双重删失带来的数据稀疏问题级联模型要估计两个延迟分布对数据量的要求比单点模型高不少。尤其是在点击率很低的广告位上第一段延迟的完整样本本来就少第二段再乘以转化率完整样本就更加稀疏。训练时很容易出现延迟分布的尾部参数拟合得特别差线上对长尾流量的预测时好时坏。我的经验是用分阶段训练来缓解先用全量曝光数据训点击延迟分支让这一层的参数收敛再固定住它用点击后的数据训转化延迟分支最后解冻全部参数做联合微调。这个流程比端到端一把梭收敛得稳定得多而且调试起来也方便哪个分支出了问题可以单独定位。如果还嫌尾部数据不够还可以在抽样时对长延迟样本做加权强制模型看到更多“迟到但发生了”的尾部样本。4.3 一个容易被忽略的分桶细节训练时做时间分桶桶的粒度不要定得太细。我见过有人把延迟按时长精确到小时分桶结果尾部桶里的样本量寥寥无几噪声很大模型在那些桶上学到一堆异常尖峰。更合理的做法是前段用小时级、中段用天级、尾部直接合拢成一个“超过N天”的桶这样既保证了短延迟场景下的精度又避免了尾部过拟合。线上推理时还有个性能问题双重积分如果实时计算QPS会很难看。建议离线把点击延迟和转化延迟的分布参数在每个特征分桶下预先算好存成查找表线上只需要查表做几次数值累加。对生存函数也可以离线生成时间-概率映射表线上用二分查找取值可以显著降低单次请求的延迟这在大规模展示广告流量的场景下是必须做的优化。5. 我个人在实际操作中的体会与后续扩展这套级联框架真正打动我的不是它把延迟拆成了两段而是它把“延迟是什么”这件事想得更符合业务本质了。做广告算法久了你会有一种感觉不少模型其实是在用一个统计近似掩盖业务结构比如把所有“过了很久才发生”的事都塞进一个延迟分布里。而一旦把业务结构显式建模很多之前模糊的问题就会变得清晰。比如你可以明确地回答运营同学这个广告位点击来得快不快、转化来得慢不慢而不是笼统地解释“用户要过很久才买”。这套框架还有一个很自然的扩展方向把多触点归因也纳进来。现在的级联是“曝光→点击→转化”但实际链路里可能存在多次曝光、多次点击。如果未来要把“多次曝光对转化的延迟贡献”也建模进来这个级联框架的积分形式可以继续往上叠加变成更一般的多级漏斗模型。还一个方向是跟出价联动——既然能预测每个阶段的期望延迟就可以在广告主预算有限的情况下优先去争取那些“点击快、转化也快”的流量而不是只看最终的预估转化率。最后分享一个我们在迁移这套框架时反复强调的原则不要一上来就追求复杂的分布形式。先用最简单的参数化把链路跑通确认线上收益再逐步增加复杂度。延迟反馈建模本质上是跟时间赛跑先把流程建好后面换模型结构其实是水到渠成的事。
返回列表