RTB撕开黑盒子 Part 0:Pacing: is everyone doing it wrong?
曾尝试为我们的RTB客户解决过Pacing问题,Pacing问题要解决的问题是:如果一个客户给你一笔预算,让你去运营一个广告推广计划,在一定的时间内投放广告,将这笔预算在指内的时间内,比较均匀地将预算消耗完。如果把预算消耗超出了,那就要自己贴钱了。如果没消耗完,这对于下次和客户合作的时候会有点丢脸。并且如果你不是均匀地进行消耗,你会发现自己面对着一堆愤怒的客户。比如几分钟就烧完客户50美元的预算。听起来很显然,是吧?但这问题比听起来要困难的多。
Doing it wrong
当Datacratic第一次将头伸进RTB时,控制预算消耗的主要工具就是一个日限额。我们用了48个小时才发现下面的方法是不可行的:我们设置了几种类型的过滤来决定何时对所有请求进行竞价。但结果是或是我们没有消耗完日预算,或是很快就烧完了预算,通常是后者。在实践中,我们是从0点开始购买展示,并在早晨晚些时候消耗完。

在日限额达到后就不再竞价
如果客户要求投放的时间是30-60天,采用上述的投放方式,看起来似乎还不算太糟:因为是按要求的时间将预算消耗完,并且每天消耗相同的金额。但我们有一点很不开心的是,每天有一大段时间我们是没有进行任何竞价的。于是我们加了一个小特性,对X%的流量进行竞价,当这个特性发布后,我们发现结果中有个非常有意思的现象:我们以前所购买的流量,实际上是一天之中最贵的流量!下图是一个流量较多的推方计划的平均胜出价格,它有一个很明显的规律:如果是从中午开始购买流量,CPM的价格是逐渐下降的,一直到午夜突然陡升近40%,CPM随后有些波动,然后在早晨下降后又上升,到中午达到峰值。然后又是一天新的循环开始。

可以看到每天午夜都会有价格的陡升
那么为什么会有午夜的这种价格陡升呢?按理说这应该是个充分竞争的市场,但午夜后的1分钟的流量真比2分钟前的流量多值40%吗?我们也没彻底搞清这个问题!我们当前的猜测是:竞争环境中一定有很多的DSP和我们刚开始一样:每天设置一个日限额,并在午夜重置日限额。这就意味着在午夜时对流量有很大的需求,因为如此,价格一下被抬高(也可能是其中一个DSP重置日限额后,它的出价比之前出价最高的DSP还高,使得这个小的流量价格陡升)。并且因为DSPs有着不同的日限额和流量控制策略,所以它们是在一天中不同的时间点消耗完的,这样就使得需求下降,进一步引起价格下降。从上图有一个规律不明显,但将多天的效果叠加,就得到了下图,可以看出在3点钟还有一个类似的陡升,3点钟是西海岸的午夜。

八月聚合平均后的每分钟的胜出价格
现在对于这种陡升也有一些其它的可能解释。可能是我们处在东北方这个位置,所以我们这个地区的请求流的组成有变化,所以这或许仅仅是一个地区的规律?尽管3点钟的陡升的现象让这种解释听不来不太可靠。午夜也恰好是我们开始竞价的时候,但我们的量是逐量的,并且我们的量不足以说明这种陡升。也可能是一些大的站点在午夜有一些最低出价的限制。或是其它DSPs很聪明地发现了午夜之后的点击率比午夜前几分钟高很多。我对这些解释充满了怀疑,读到我这篇文章的任何人有什么想法,我非常欢迎来与我讨论。但不管是什么原因,下面的结论都可能是成立的:如果你只想在一天中的几小时内投放广告,不要选择凌晨开始投放,10AM结束。
译注:不知道国内的DSP开发有没有做这个数据分析,我分析出来的结果和Datacratic的不太一样,但我现在还在爆流量的阶段,可能统计的量上不太够,但还是有些规律的。有机会大家一些讨论一下。
Closed-Loop Control to Rescue
我们先假设这一篇文章,在RTB圈子里引起了极大的关注,而这种凌晨的价格陡升现象消失了,或是你也许只想将预算均匀地在每天消耗,如何去做呢?上面提到过,我们可以每天对X%比例的流量进行竞价。最简单的办法就是,将日限额除以不加限制的每日消耗,得到竞价比例,这原则上能在凌晨消耗完日限额。但在实践中,只对固定比例的流量竞价,每天的曝光量会差异非常大,有时候会超出预算消耗(如果你没设置日限额)有时候会消耗不完预算。也许某些天你会得到一个变化量非常大的请求量,也许是因为你上流的SSP在做修改。(译注:如果你的请求量在在9点后是一条直线,这是因为google的QPS限制,这个可以让google的support team的人支持一下,这个曾经搞的我很困惑为什么请求量这么均匀)。也许SSP出了故障。而且竞价流量会有很大的变化,比如,突然间有大量增加(或大量减少)来自你定向地区的请求。(译注:这个现象很明显,我现在考虑了广告位的影响,请求的流量有时候会有大量的某个广告位的垃圾请求过来,导致我的出价曝光产生剧烈的变化)。也许是你的竞价逻辑本身会使消耗速度不一致。所有的这些因素都会造成你的消耗额是随时间变化而参差不齐的:

尽管设置的出价概率是个常数,消耗速度还是可能不均匀
那么解决方案是什么呢?对我们来讲这个问题是一个控制论的问题,并且我们从无反馈控制换成了反馈控制。如果你是想用概率来控制竞价,那么如果你设置完请求概率,然后竞价一周后分析结果后,这基本是无反馈控制。如果每天早晨你看一下前一天消耗是多少,然后相应地调整当天的竞价概率,那么这就是反馈控制的做法,反馈控制即是将输出的信息反馈到输入中去。这种方案很容易自动化,并且很自然地可以将反馈周期变短,将周期从天调整到几分钟。我们的RTB系统按这个方案重新设计了出价速度的实现,我们可以将与目标出价速度的差异控制到1-2%,我们只使用了简单的反馈机制:每2分钟,参考前2分钟的出价速度,设置下2分钟的‘正确出价速度’。所以,无论什么原因,我们假设少了20%的请求,比如在晚间,那么竞价概率会上升,使用消耗速度保持近似相等。还有一些更复杂的反馈控制方案,但这种基本的方案已经不错了。

上图是我们反馈控制的结果。注意,无反馈控制的输出看起来像Mordor的山(魔戒),而反馈控制的输出像是Shire的平原。

上图为真实的数据,进行了一点平滑以揭示深层的变化,Pace(蓝色,概率 * 1000)会在晚间流量下降时上升,消耗速度(绿色)会与目标消耗速度(红色)几乎保持一致。
和任何好的优化算法一样,它要做的就是完全按你的要求来做:它努力将消耗速度和目标消耗速度的差距降到最小。但是如果系统出现了一个严重的故障,导致一段时间不能竞价,当故障恢复后,这种方案将不会调整目标消耗速度来补偿前一段不能竞价造成的影响:

故障后,消耗速度没有进行补偿(斜率和以前的目标消耗速度斜率是一样的)
为了处理故障造成的影响,还有一些因为系统不完美,使得错误积累造成的超出预算,未到预算的问题,我们需要动态地调整消耗速度目标。我们重新定义一下我们反馈控制的优化目标:消耗速度始终保存与剩余消耗在剩余时间同一水平。这就意味着如果有一天或是一小时出了故障,无需人工干预,就可以在故障后调消耗速度目标进行补偿。这个系统还有一个很好的性质,它会在剩余消耗为0时,准确地自动停止。

很明显,你不会想在任何时间总是采用相同的消耗速度,事实上我认为你是肯定不会的。一个反馈控制系统可以支持几乎任何你想要的消耗速度的曲线。你可以采用竞价概率外的变量去控制(比如:真实的竞价价格,或是定向条件,或是任何你能想出来的方式)。最后,思维敏捷的读者可能发现一个问题,上面描述的方法只有当请求流量大于你的限额可以买的量的时候才有效,如果你的竞价概率设置到了100%也得不到你的日限额,甚至当你赢得所有的流量也不可能达预算,甚至对所有流量你都胜出也到不到预算。那上面的方法是无效的。
RTB撕开黑盒子 Part 0:Pacing: is everyone doing it wrong?的更多相关文章
- RTB撕开黑盒子 Part 2: Algorithm Meets World
Part 0介绍了RTB的胜出价格会在凌晨陡升.我们还介绍了一个Pace系统,如果这个系统所有的DSPs都用,那陡升的问题就会消失.Part 0中的系统中含有一个隐式的假设:任何两个请求都认为是相同的 ...
- RTB撕开黑盒子 Part 4: Shady Bidding
在这篇文章中,我将告诉你"真实的出价"比你想的微妙,并且你可以使用基于ROI的pacing策略,不需要构建一个期望扣费的模型,你就可以得到完美的期望扣费模型. Same Same ...
- RTB撕开黑盒子 Part 3: Beyond Surplus
在本文中,我将解释如果要对整个推广计划最大化利润,决定是否应该出价的应该是期望回本率(ROI),而不是期望利润,这与我们以前介绍的有所不同.在Datacratic,我们已经在2012年底切到了基于RO ...
- RTB撕开黑盒子 Part 1: Datacratic's RTB Algorithms
这篇文章是讨论Datacratic所用的统计和经济理论的一些内容.我们开发了real time bidding算法s.为了实现广告主的目标,我们的算法自动地利用其它广告主的次优策略,并再查看广告的底价 ...
- IP路由配置之---------配置PPP
实验设备:两台华三路由器,两台PC,一条V.35线 PPP是数据链路层的协议,链路层的协议有很多如帧中继fr等 实验一,PAP验证(是一种以明码传送用户名和密码的验证方式) 步骤一,在主验证方设置一个 ...
- 2018-12-25-WPF-如何在-WriteableBitmap-写文字
title author date CreateTime categories WPF 如何在 WriteableBitmap 写文字 lindexi 2018-12-25 09:13:57 +080 ...
- H3c实验室-(OSPF,Nat,STP,Dhcp,Acl)v.1)
实验声明 本实验纯属学习记录性质,如有错误,请大哥帮忙提出,马上改正谢谢~还有学习H3c心态要好,他有超级多的bug!!!! 实验介绍 实验条件 实验开始 把图设计好 先说明一下RTA-RTB的线路是 ...
- ZAM 3D 制作简单的3D字幕 流程(二)
原地址:http://www.cnblogs.com/yk250/p/5663907.html 文中表述仅为本人理解,若有偏差和错误请指正! 接着 ZAM 3D 制作简单的3D字幕 流程(一) .本篇 ...
- ZAM 3D 制作3D动画字幕 用于Xaml导出
原地址-> http://www.cnblogs.com/yk250/p/5662788.html 介绍:对经常使用Blend做动画的人来说,ZAM 3D 也很好上手,专业制作3D素材的XAML ...
随机推荐
- 【高德地图API】从零开始学高德JS API(六)——坐标转换
原文:[高德地图API]从零开始学高德JS API(六)——坐标转换 摘要:如何从GPS转到谷歌?如何从百度转到高德?这些都是小case.我们还提供,如何将基站cell_id转换为GPS坐标? --- ...
- Swift中文教程(二)--简单值
原文:Swift中文教程(二)--简单值 Swift使用let关键字声明常量,var关键字声明变量.常量无需在编译时指定,但至少要被赋值一次.也就是说,赋值一次多次使用: var myVariable ...
- WebView无法放大缩小解决方式
先看看我们之前所写的代码 1) 加入权限:AndroidManifest.xml中必须使用了许可"android.permission.INTERNET" 2) 使用了一个WebV ...
- csu 1503: 点弧之间的距离-湖南省第十届大学生计算机程序设计大赛
这是--比量p并用交点连接中心不上弧.在于:它至p距离.是不是p与端点之间的最短距离 #include<iostream> #include<map> #include< ...
- 【设计模式】Abstract Factory模式
抽象工厂模式是工厂方法模式的进一步强化.当工厂函数仅仅须要产生一种类型的产品(全部产品都继承自同一抽象基类)时,使用工厂方法模式就可以. 可是.当用户程序须要创建多种类型的产品,而这些产品又有一定的内 ...
- boost进程间通信经常使用开发一篇全(消息队列,共享内存,信号)
本文概要: 敏捷开发大家想必知道并且评价甚高,缩短开发周期,提高开发质量.将大project独立为不同的小app开发,整个开发过程,程序可用可測,所以提高了总体的质量.基于这样的开发模式和开发理念,进 ...
- 备份IIS httpd.ini 重写规则,兼容大部分版本号IISserver
IISserver已经非常少,差点儿要退出市场了.nginx成为市场的主流. 备份一个httpd.ini,全部内容例如以下: [ISAPI_Rewrite] # 3600 = 1 hour Cache ...
- angularJS之站在jQuery的肩膀上
jQuery:用更少的代码,实现更强悍的功能 托互联网日新月异发展的福,浏览器变成了人们接入互联网的入口,而JavaScript 这个曾经的小语种,终于成功地站到了舞台的中央,唤起了开发者的兴趣. 浏 ...
- 通过扩展改善ASP.NET MVC的验证机制[实现篇]
原文:通过扩展改善ASP.NET MVC的验证机制[实现篇] 在<使用篇>中我们谈到扩展的验证编程方式,并且演示了本解决方案的三大特性:消息提供机制的分离.多语言的支持和多验证规则的支持, ...
- 优秀个人免费私有云OwnCloud 8.0终于发布 - 亮眼新功能初探简介
OwnCloud是一个基于Linux的私有云开源项目,用户可以免费使用它来搭建自己的私有云来进行文件和多媒体等的分享. 本人有幸在大概一年多前因为项目需要而接触和使用到OwnCloud,但不幸的是当时 ...