• pacing算法 广告预算 浅谈广告系统预算控制(Budget Pacing)


    https://www.lizenghai.com/archives/42609.html  

    浅谈广告系统预算控制(Budget Pacing)

    文来自OPPO互联网技术团队,转载请注名作者。同时欢迎关注我们的公众号:OPPO_tech,与你分享OPPO前沿互联网技术及活动。

    1. 背景

    在实际广告投放过程中,我们常常会碰到一个问题:媒体流量比较大,广告主预算消耗过快,有些中小广告主甚至在开始投放的几分钟内就把预算消耗完。这会导致广告主早早退出后续流量的竞争,不仅会影响广告主体验(无法触达到更多的优质用户),也导致整个广告不平稳(竞争都集中在早期,而后期又竞争不足)。

    预算控制(Budget Pacing)的作用就是平稳花掉广告主的预算,并帮助广告主优化转化效果。所以我们预算控制要完成如下目标:

    • 广告匀速播放:通过广告日预算、当前消耗以及日曝光曲线来控制广告投放速度

    • 提升广告主ROI:帮助广告主以更低的价钱拿到更多优质曝光量。

    2. 问题分析

    预算控制的做法目前可分为两大类:Probabilistic throttling 和 Bid modification,其中 Probabilistic throttling 通过一个概率值来决定是否参竞来控制预算花费速率,而 Bid modification 则通过直接改价的方式来控制花费速率。

    对比这两个方案的差异点:

     
    1. Probabilistic throttling 是通过调整参竞概率调整预算消耗速度,而 Bid modification 则是通过改变bid,控制竞价胜率来达到影响预算消耗速度,这种方式有可能导致预算消耗波动较大

    2. bid landscape(竞价环境) 一般会随着时间变化而变化;另外对于那些快耗尽预算的广告,bid 可修改的幅度很小,且bid一般存在着保留价,可调整的幅度很小,而且往往bid的变化与实际曝光量不成正比;以上两点使得通过 bid modification 来达到预算匀速消耗比较困难

    3. 实际工程实践中,我们希望广告投放量(delivery的部分)与竞价逻辑(uction的部分)是分开的, 使用 Probabilistic throttling 时能够将 pacing control 与 bid optimization 解耦,能够分别进行优化

    对我们来说,广告主最基本的诉求是让广告预算能够均匀的消耗完,在这个基础之上才考虑优化转化成本。所以我们首选了Probabilistic throttling方案来实现匀速播放,在结合Bid modification来优化成本

    3. 方案实现

    3.1 阶段一:实现广告预算能够均匀的消耗

    为了这个目标我们参考了论文【1】,LinkedIn 在 2014 年发表的一篇论文,提出的预算控制策略并不复杂,并且具有很强的实践性和工程性。

    接下来介绍下我们的这个算法,其主要思想跟LinkedIn算法比较类似。我们的主要思路就是将推广计划的消耗趋势与大盘曝光趋势保持一致,以天为时间单位,推广计划为预算控制单位。

    首先根据历史数据,预测出当天大盘总曝光数。然后基于其曝光情况,在当前时间片,假如已消耗 / 当天预的比例大于大盘已曝光 / 大盘总曝光的比例,则说明预算已经消耗过快,需要减小消耗的速度,反之则要加快消耗的速度。

    下面为算法原理:

    对于某个campaign i,记其出价为b_i,当天预算为d_i。一天的时间被划分为T个时间窗口,s_{i,t}(0 le tlt T)表示截止到第t个时间窗口时的累积预算,f_{i,t}s_{i,t}对应,表示截止到第t个时间窗口开始的累积曝光(f_{i,t}是预测出来的,下式的f_{i,T}表示预测出来campaign i 在当天的总曝光)。则在时间窗口t开始时,有

    a_{it}:={f_{i,t} over f_{i,T}}d_i

    根据上面的比例,在每次竞价开始时,为campaign i 算出其参与这次竞价的概率p_{i,t},论文称这个概率为PTR (pass through rate),计算方式如下:

    上式中的r_t(0lt r_t lt 1)称作调整速率(adjustment rate)。

    上面算法得到的PTR,即实际项目的参竞概率,我们通过这个概率可以控制曝光速度。

    3.2 阶段二:实现预算均匀消耗后,尝试优化成本

    前文介绍的预算均匀消耗实现方案本质上是随机丢弃,这个虽然可以满足需求,但对成本优化上没有任何考虑。所以这个方案一完成我们就在想,该如何做些优化?

    我们做优化主要思路是:我们在放弃请求的时候可以选择性放弃一些低质量(点击率较低)的请求,而对应高质量的请求我们提高参与竞价的概率,从而提升转化率。

    其实业界对这个问题成熟的优化方案有很多, 其中最直接方式是通过修改bid来优化,但这种方式挑战比较大,工程实现比较复杂,与我们最初思路也不一致,我们后续介绍。再查找资料时我们看到yahoo的一篇论文【2】,该方案实现与我们思路类似,刚好给了我们很多启发。

    下面介绍下我们的算法实现:

    (1) 首先我们会把每个广告计划的所有请求会被分成 L 层,则在第 t-1 个时间片内各层的参竞率记为:

    各层消耗记为:

    每一层的单次点击成本在这里记为:

    一天的总预算 B 会根据时间片划分成 K份小预算,即:

    但是实际投放中不能保证每个时间片的消耗都刚好达到分配的预算值,因此如果前面的时间片中出现了少投或超投情况,就要把少投或超投那些部分均摊到后面的时间片中,所以每个时刻的预算需要根据前面的花费来调整,调整后的消耗记为:

    上式中的B_m表示经过了 m 个时间片后剩余的实际预算,分子B_m-sum{^K_{i=t}B^{(i)}}表示当前预算花费是否超过了预期(<0)或者不满足预期(>0),并通过分母均摊到后面的 K−m 个时间片中。

    则调整各层参竞率的控制算法如下图所示,图中的R=hat C^{(t)}-C^{(t-1)}, 表示如果按照前一时间片的参竞率投放时,当前时间片的预算能否花完。则当 R>0 时,需要提高当前时间片的参竞率,反之需要降低 这一时间片的参竞率。

    上面算法还有几点细节需要注意:

    • L层表示参竞率最大的层,l^'层表示参竞率为非0的最小的层

    • 当需要提升参竞率最时,是从第 L层到l^'层进行的;而需要降低参竞率时,是从第l^'层到第 L层进行的,其目的都是优先提升ctr高的层的参竞率,优先降低ctr低的层的参竞率,从而达到最小化成本的目的

    • trial rate 的目的是让参竞率非 0 的最小层的下一层以一个很小的参竞率进行参竞(参竞率会随着层数增加而增加),本来这一层的参竞率应该是 0 的,但是这里给了一个很小的 trail rate,目的是为了方便后面加快预算花费做准备(代码实现上也不用特殊处理)

    超参选取

    上面提过的算法的流程中涉及到多个超参数,如层数 L 以及 trial rate,下面介绍如何选取这两个超参。

    yahoo论文中给出决定其层数 L 的方法是,首先找到与这个新计划最相似的老计划 a, 并找到这个老计划最合适的参竞率r_G, 则新计划的层数可计算为L=lceil {1 over r_G}
ceil,计算的逻辑其实就是要找到这个计划最合适参竞率对应的层数。

    trail rate取值方法是:将当前时间片的预算hat C^{(t)}划分一小部分,记为 λ(e.g λ = 1%), 假设当前层为第l层,则其trail rate =r_l^{(*)}	imes {lambda 	imes hat C^{(t)} over c_l^{(*)}},而r_l^{(*)}c_l^{(*)}则是l层的历史参竞率和消耗。

    为了简化工程,我们先选取了固定值,然后通过实验的方式来确认这两参数。

    4. 后续优化

    目前的方案已经可以满足匀速播放的,但其实我们可以结合Bid modification来对广告成本做进一步优化。

    1. 从广告计划维度看,流量充足时可以通过降低出价来减少曝光量,同时也能降低成本

    2. 对各层不同ctr的请求bid应该是有差异的,高ctr的请求出价应该更高,低ctr的请求出价可以低一些

    前文也提到了Bid modification方案工程复杂度比较大,后续需要结合广告竞价,oCPX等相关模块,争取进一步优化成本。

    参考文献:

    1.Budget Pacing for Targeted Online Advertisements at LinkedIn

    http://dwz.win/xq4

    2.Smart Pacing for Effective Online Ad Campaign Optimization

    https://arxiv.org/abs/1506.05851

    3.http://wulc.me/tags/计算广告/page/2/

  • 相关阅读:
    python获取DBLP数据集
    GNUPLOT 画多组柱状图 以及 折线图 以及各种问题的解决方案
    Leetcode 1:two sum
    测试面试之如何测试一个杯子
    C++小总结
    统计‘1’的个数
    C语言小总结
    剑指offer面试题1---赋值运算符函数
    黑盒测试与白盒测试
    软件测试的原则
  • 原文地址:https://www.cnblogs.com/zhangbojiangfeng/p/12575522.html
Copyright © 2020-2023  润新知