摘要:
RTB竞价中的cookie mapping技术解决DSP的cookie跟ad change的cookie匹配问题。
Cookie mapping分为两步:(1)google ad exchange等在网站主网站上种cookie,记录用户信息,生成google_customer_nid (2)用户在网站主网站上浏览时,有广告请求; google把请求302重定向到dsp,并携带加密过后的google_userid。这样dsp就在用户电脑种cookie,并且建立映射表:google_userid---->dsp_user_cookie
RTB竞价中的cookie mapping技术
首先通过一些关键词解释普及或者回顾一下背景,
RTB中cookie mapping究竟是什么?
一般cookie mapping如何实现?
(1)用户请求 以下网址
<img src="http://cm.g.doubleclick.net/pixel?google_nid=1234&google_cm" />
(2)google返回google user id和 重定向网址
http://ad.network.com/pixel?google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1(3)用户浏览器请求以上网址。 ad.network.com是dsp 的网址。
(4) dsp得到cookie,建立与google user id 的映射
以下来自: https://developers.google.com/ad-exchange/rtb/cookie-guideCookie 匹配的工作原理
要在匹配表中建立关联,合作伙伴必须投放一个由 Google 提供,名为“匹配标记”的标记。匹配标记可以随合作伙伴的广告一起投放,也可以放置在广告以外的网络媒体资源上。其结构如下:
<img src="http://cm.g.doubleclick.net/pixel?google_nid=1234&google_cm" />
其中的 1234
需要替换为合作伙伴标识符(由 Google 提供)。
合作伙伴只有在还没有为此用户创建匹配条目(或该条目已过期)时才应投放此标记。
Google 会在收到用户浏览器的标记请求后,将 302 重定向传送给合作伙伴。此 302 重定向会在网址中加入 Google 用户 ID 和版本编号,并会在请求标头中加入合作伙伴 Cookie。合作伙伴负责提供网址,Google 则会添加额外的网址参数。举例来说,如果合作伙伴提供以下基准网址:
http://ad.network.com/pixel
Google 就会重定向至以下网址:
http://ad.network.com/pixel?google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1
通过 google_gid
参数传送的 Google 用户 ID 是一个非叠加网址安全 base64 编码字符串。如果您在匹配表中存储了二进制(以 base64 解码)值,则需要在解码之前叠加该值(请参阅 RFC 3548 的第三部分)。建议您将 Cookie 匹配服务返回的确切字符串存储在匹配表中。
请注意:BidRequest
协议缓存中的 google_user_id
字段与 Cookie 匹配服务返回的 Google 用户 ID 相对应。
google_cver
参数可指明 Google 用户 ID 的数字版本编号。Google 可能会不时更改 Cookie 的模糊配置,并在每次更改时调高 google_cver
的值。
合作伙伴必须在收到此重定向(其请求标头包含合作伙伴 Cookie)之后,更新匹配表以添加此合作伙伴 Cookie 与 Google 用户 ID 之间的关联。合作伙伴随后需要在用户的浏览器上投放一个隐藏的 1x1 图片像素。
条目添加到匹配表中的速度与匹配标记向唯一身份用户投放的速度相同。
下图说明了这一过程。请求会按照 (1) 到 (4) 的顺序进行。在该图中,每个请求后面的括号中都会包含与请求一起发送的信息。
您可以视情况在请求中设置额外的网址参数。这些参数将会在重定向时传送到您的服务器:
<img src="http://cm.g.doubleclick.net/pixel?google_nid=1234&google_cm&extra1=xx&extra2=yy" />
所有不以 google_ 作为前缀的参数都会被复制到重定向网址中。参数传送到 Cookie 匹配服务中的顺序并不重要。同样,我们也无法保证额外参数在重定向网址中传送的顺序。
http://ad.network.com/pixel?google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1&extra1=xx&extra2=yy
您可以使用这些参数来传送与展示有关的额外信息。额外参数的长度不应超过 1KB。
此外,您也可以向 Cookie 匹配服务发送 https
(而非 http
)请求。在这种情况下,重定向将会链接到相同的网址,但该网址的协议将会是 https
(而非 http
)。
示例情况
对于常规的网络用户,Cookie 匹配功能会如何在后台运作?我们来看看以下两种情况。
第 1 种情况:清除 Cookie
小丽清除了缓存中的所有 Cookie。随后,她访问了 ExampleNews.com 的首页。
对整个过程的说明如下:
- ExampleNews.com 将会显示并调用 Google (DFP) 的广告。
- 广告单元符合动态分配资格,因此 Ad Exchange 会调用 FinestDSP(以及其他 DSP)。
- FinestDSP 在其出价引擎中处理此调用。
- FinestDSP 赢得竞价,并将广告和匹配标记(像素)传送至 Ad Exchange。
- Ad Exchange 向小丽投放 FinestDSP 的广告和匹配标记,并设置她的 DoubleClick Cookie。
- 匹配标记调用 Google 的 Cookie 匹配服务。
- Cookie 匹配服务读取小丽的 DoubleClick Cookie,并将设好 google_user_id 的重定向传送至 FinestDSP。
- 浏览器加载 FinestDSP 的网址。
- FinestDSP 生成 Cookie,并将此 Cookie 存储在其匹配表中与小丽的 google_user_id 相对应的位置。
- FinestDSP 将其 Cookie 放到小丽的浏览器中,并在响应中提供一个空白的 1x1 像素。
![](https://developers.google.com/ad-exchange/rtb/images/cookie-matching-schematic.png)
第 2 种情况:买方和 DoubleClick Cookie
一个星期后,小丽再次访问了 ExampleNews.com。现在,小丽的电脑上同时存有买方和 DoubleClick Cookie,我们来看看匹配功能的运作方式。
- 小丽会看到网页,同时,html 代码会包含向 Google 请求广告的调用。
- 在广告竞价期间,DoubleClick Ad Exchange 会向实时出价合作伙伴 FinestDSP 发出调用请求,让其选择是否要对展示进行出价。
- 买方收到包含展示信息和 google_user_id 的广告调用。
- FinestDSP 在其匹配表中查找 google_user_id,以找出一周前创建的 Cookie(第 1 种情况)。
- FinestDSP 利用与其 Cookie 相关的信息,对展示进行出价并赢得这次展示机会。
- FinestDSP 根据所掌握的信息向小丽投放与其兴趣相符的广告。
第一个例子:
1. 广告主网页向dsp发送加载请求
2. dsp发送含有<img src**>之类的beacon, 但是需要注意的是,这里的src指向的是adx的域名
3. 用户浏览器解析到<img>标签,就向adx发送请求,包含的请求消息是(adx id, dsp id, dsp cookie)
4. adx收到请求, 返回消息(adx id , adx cookie), 并将对beacon的请求,从定向到dsp
5. dsp 收到用户adx cookei,将adx cookie和dsp cookie放入映射表,并向广告主网页返回一个透明的一个像素的beacon
6. 广告主网页收到beacon,就继续解析html代码
第二个例子:
网站想了解访问自己网站用户的更多消息,或者用户的分类,标签等等,所以需要向dmp询问
网站自己存自己的用户cookie和dmp cookie的映射
如果网站想了解用户,就先查表,获得dmp cookie,然后向dmp发送这个用户的dmp cookie,dmp就返回这个用户标签等等