（说明：此文转载自CSDN网站，用于自己学习）
RTB 广告简单来说，就是把访客的每次页面浏览，通过拍卖的形势卖给广告主，谁出的价高就把访客的这次浏览卖给谁，然后显示相应的广告。RTB 整个过程主要的三个参与者为 AdExchange，SSP（供给方平台）和 DSP（需求方平台）。
媒体将 SSP 代码嵌入到网站或 APP 中，由 SSP 代码来控制广告的展示。多数情况下，SSP 和 AdExchange 属于同一家公司，下面就详细说说其中的原理和流程。
RTB 流程图
注：下方的编号和上图中的序号对应
用户浏览媒体网站，媒体网站通过添加的 SSP 代码向 AdExchange 发起广告请求。
AdExchange 将这次请求的关键信息（如域名 URL、IP、Cookie 等）同时发送给多家 DSP，我们把这个请求称为 Bid Request。
DSP 收到请求后通过 Cookie、IP、URL 等信息决策是否参与竞价，DSP 可以通过 Cookie 来查询此用户在自己系统中的历史行为来推算人口属性和兴趣爱好，如果 DSP 没有这个能力，则可以通过第三方 DMP 的协助来判断用户特征，以便更合理地出价，如若出价，则向 AdExchange 返回价格、要展示的广告、跳转链接等信息，我们把这次信息返回称为 Bid Response。
AdExchange 选出出价最高的 DSP，通知这个 DSP 赢得了竞价，并告诉它此次展示的费用（由于在 RTB 中是采用二阶定价，即第二高出价，所以DSP 并不知道实际的费用，需要 AdExchange 再通知一次），于此同时，AdExchange 返回给媒体要展示广告的 html 内容。
广告的静态资源（图片、Flash 等文件）一般是存储在 DSP 的服务器，所以在加载广告代码的时候需要去 DSP 请求静态资源
DSP 返回静态资源，完成广告的渲染和展示。
以上流程的第三步中 AdExchange 向 DSP 传递的是 AdExchange 自己域下的 Cookie ID，由于和 DSP 的域名不同，所以 Cookie 不互通，DSP 无法直接使用 AdExchange 传过来的 Cookie ID，因此还需要额外的步骤建立 ID 之间的映射关系，以 Google AdExchange 为例，具体流程如下：
Cookie Mapping 流程
注：下方的编号和上图中的序号对应
SSP 会在媒体网站触发如下的代码
http://mapping.doubleclick.com/?dsp_id=123x
浏览器自动请求 img 对应的地址，其中 123x 是对应 DSP 的编号，由 Google 提供
假如 DSP 提供的重定向地址为http://dsp.com/pixel，Google 就会重定向到以下网址：
http://dsp.com/pixel?google_gid=qwebdghfe&google_cver=1
其中google_gid为 Google 的用户 ID
用户浏览器 302 跳转到第 2 步 Google 服务器返回的网址，DSP 通过 URL 中的google_gid参数得到 Google 的用户 ID， 通过读取自己域下的 Cookie 获得自己域名下的用户 ID，并将他们记录在数据库中
DSP 返回一个 1x1 像素的图片
通过以上步骤，建立起 DSP 和 Google 用户 ID 的映射关系，当下一次 Bid Request 请求过来的时候，通过查询这个映射表，来判断当前请求在自己库中是哪一个用户。Cookie Mapping 不止在 DSP 和 AdExchange 之间，也有可能在 DSP 和广告主网站之间、DSP 和第三方 DMP 之间，总之目的是为了打通不同域名下用户 ID 的联系。
当你在浏览网页看到一个广告时，不用再好奇为什么刚巧符合自己的口味，在页面加载完之前的那几百毫秒，计算机在幕后已经做了非常多的工作。
作者：耗子吴
链接：http://www.jianshu.com/p/10226fe2446c
來源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。---------------------本文来自 蜗牛爱海绵宝宝 的CSDN 博客 ，全文地址请点击：https://blog.csdn.net/wj123446/article/details/77888070?utm_source=copy
