RTB(实时竞价)简介

此文是我在知乎上的一个回答

RTB(Real Time Bidding)是现代互联网广告行业中新兴起的一种流量交易方式,有以下几个显著的不同于传统的互联网广告的特点
1. 在用户刚打开流量的载体(App或是Wap站点)的时候,该广告位要显示的东西还尚未确定,只有当竞价结束的时候,才会最终确定实际被展示的内容(Creative)。
2. 竞价时间非常短,一般100ms之内就要完成,所以对参与各方的技术要求很高
3. 完全以CPM计价
在我自己个人的观点看来,RTB具有以下几个主要的优势
1. RTB1. 用户打开集成了SSP的SDK的App,广告即将被展示
2. SSP收到自己SDK上报的信息,然后向和SSP已经接好的Exchange发送Bid Request,让他们为这次展示机会出价
3. DSP收到Bid Request后向SSP发送Bid Response,这里所有DSP之间互相是不知道彼此出价的,Bid Response中含有一段JavaScript代码,这段JavaScript会返回实际的广告的Creative
4. SSP选取出价最高的作为胜利的DSP,然后胜利的DSP只需要支付第二高的出价的价格
5. SSP将胜利的DSP给出的JS代码下发给SDK,展示广告
6. SSP向胜利的DSP发送Win Notice,通知DSP该次Impression已经竞价成功
至此 RTB交易结束实现了流量供给方的利益最大化
2. RTB可以充分利用长尾流量
3. 通过RTB可以很容易买到世界各个地区的流量

接下来先说明几个在互联网广告行业中常用的术语,熟知这些的读者请无视
Advertiser:广告主,花钱做广告的人
Publisher:发布者,负责将广告发布出去的人,在广告交易中一般是收钱的一方
Creative:这里我暂时不知道怎么翻译好,一般指的是实际被展示出去的图/视频等。
Impression:Creative被显示了一次就是一个Impression

Click: 图/视频中通常带有链接,这个链接每被点了一次就是一个Click
Conversion / Action: 用户在点击链接之后又发生了广告主所期待的后续行为,如下载安装,将商品加入购物车等,统称为一次转化
CPM: Cost Per Mille, Mille是一个拉丁语的词汇,表示1000,CPM表示计费方式是按照每千次Impression计费
CPC:Cost Per Click,按照点击次数计费
CPI / CPA:这里的I指的是Install,A是Action,也就是按照转化计费
CTR: Click Through Rate Click数/Impression数
IR/CR: Install Rate / Conversion Rate 转化数/Click数

终于开始说RTB业务中主要的几个参与方了
DSP:Demand Side Platform 需求方平台,需求方平台可以视为是Advertiser的集合。DSP方一般有很强力的商务队伍,会去拉到很多的Advertiser来花钱做广告,国内的DSP比较大的有品友等
SSP: Supply Side Platform 供给方平台,供给方平台一般会有自己的广告SDK,他们会和很多的App的开发者合作,让App开发者去集成他们的SDK,这样集成了SDK的App里面就可以显示出广告,SSP所要供给的商品就是这些展示机会
AdExchange:Exchange是沟通需求方和供给方的平台,Exchange同时连了大量的DSP和SSP,因为RTB各方之间的集成工作还是比较复杂的,如果我和某个Exchange之间接好了,我就可以省下很多时间和精力的同时还是能获得很多流量
DMP: Data Management Platform DMP是提供数据的平台,对DSP而言,从SSP一侧获得的信息可能不足以支撑DSP做出决策,DSP可能会从DMP那里购买一些数据,DSP报一个android id或者IDFA给DMP,然后DMP返回相应的用户标签。

一次RTB的流程如下
先考虑没有Exchange的情况


1. 用户打开集成了SSP的SDK的App,广告即将被展示
2. SSP收到自己SDK上报的信息,然后向和SSP已经接好的所有DSP发送Bid Request,让他们为这次展示机会出价
3. DSP收到Bid Request后向SSP发送Bid Response,这里所有DSP之间互相是不知道彼此出价的,Bid Response中含有一段JavaScript代码,这段JavaScript会返回实际的广告的Creative,DSP在此时还可能向DMP发出查询请求
4. SSP选取出价最高的作为胜利的DSP,然后胜利的DSP只需要支付第二高的出价的价格
5. SSP将胜利的DSP给出的JS代码下发给SDK,展示广告
6. SSP向胜利的DSP发送Win Notice,通知DSP该次Impression已经竞价成功
至此 RTB交易结束

有Exchange存在时,SSP也将Exchange视为一个DSP,DSP将Exchange也视为一个SSP。对于Exchange本身,Exchange把从SSP收到的Bid Request发给DSP,然后从DSP收到Response,从中选出胜者的价格再向SSP去竞价

RTB一般采用的都是这种密封的第二价格拍卖,也称Vickery拍卖,之所以采用这样的制度是因为,在Vickery拍卖中,每个人诚实地按照自己的保留价格出价是一个Nash均衡。同时,每个人的出价又不可能比自己的保留价格更高,所以这是一个最简单的使得SSP利益最大化的策略。和第一价格拍卖相比,(假设每个人的保留价格服从相同的均匀分布)有n个人参加的第一价格拍卖最后的均衡价格会是,是比第二价格拍卖所得结果要低的。

RTB交易过程中的技术难点
1. 数据量很大,每个Bid Request的JSON文件约1KB大小,一秒钟处理2000个Bid Request,一天可以积累几TB的日志文件
2. 对于延迟要求较高,需要良好的服务端程序性能

RTB的劣势
1. 传统行业的Advertiser的对RTB广告较为陌生,不一定能够接受纯粹的按照CPM计价的方式
2. RTB大多是长尾流量,也就是没有什么知名的App


RTB交易中的套利行为
RTB交易中本身是按照CPM结算的,并不追踪后续转化情况,但是很多Advertiser选择按照CPA的方式付费,也有少量按照CPC方式付费的,如果DSP一方可以保证自己买到的展示有很高的比率发生转化,就可以从中获利。举个例子,假设Advertiser出价$0.5买一个新增安装,如果我可以花$2买到10000个Impression,这些Impression的CTR是5%,那么我有500个click,这500个click如果有2%的比率安装了这个App,那么我从Advertiser那边可以挣到$5,但是我买这些Impression只花了$2,就成功实现了套利。 能够把套利这样的事情做好的人都是DSP一侧的重要骨干。
有人尝试用数据挖掘的方法解决这个问题,比如利用转化的数据估计一个logistic regression的模型,或者是训练神经网络什么的,但是实际操作过程中,往往图和被推广的东西本身影响因素更大,我个人认为这不是一个单纯能靠数据解决的问题

你可能感兴趣的:(RTB(实时竞价)简介)