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的模型，或者是训练神经网络什么的，但是实际操作过程中，往往图和被推广的东西本身影响因素更大，我个人认为这不是一个单纯能靠数据解决的问题