RTB广告中的Cookie Matching

原文:https://developers.google.com/ad-exchange/rtb/cookie-guide 2014年2月14日最后更新

译文:刘佳明@百川广告

Cookie匹配(Cookie Matching)是什么?

简单说来,就是DSP域的cookie与Ad Exchange域的User ID的关联。Ad Exchange提供Cookie匹配服务(Cookie Matching Service),这使得流量购买方(DSP)能够关联如下两类数据:

  1. DSP域的用户Cookie,以标识DSP域的用户。
  2. Doubleclick.net域的用户Cookie,以标识Google用户。(针对每个用户,Google为各DSP提供经加密过的专属于该DSP的Google User ID, 以便该DSP来匹配这一User ID。)

DSP用来维护这两类数据的关联的数据结构,就是匹配表(Matching Table)。DSP负责构建和维护各自的匹配表,而Google则可以为之提供托管。

对一个RTB应用来说,对于某个由Google User ID标识的具体用户,DSP可以对针对这个用户的印象展示(Impression)进行竞价(使用跟这一Google User ID相关联的信息作为竞价依据)。谷歌宣称如果交给它托管匹配表,会简化这一整合过程,减少延迟,blablabla。

背景知识
浏览器cookie通常是由拥有该cookie所属域的域名的一方设置的。该Cookie就标识了在该域名下的这个用户。浏览器安全模型(Browser Security Model)限制了一方不能读取由另一方设置的cookie,即使他们双方同意这种交换(我读你的,你读我的)。流量购买方通常使用第三方广告网络平台(DSP)域的cookie来识别用户,并为此建立从这一cookie到用户信息的数据库索引。

Google自己使用自己旗下的doubleclick.net域的用户cookie来识别用户。对各DSP来说,Google使用专属于该DSP的Google User ID来识别用户,这一ID是取自doubleclick.net域的用户cookie并经过加密后的派生版本。Google将这一Google User ID传给对应的DSP(原始的DoubleClick cookie是绝不会外传的)。

当第一次接收到某个Google User ID的时候,DSP中没有与该Google User ID相关联的用户信息(竞价请求所揭示的用户信息除外)。DSP这时可以将该Google User ID与自身的域的Cookie建立关联,并在后续针对该Google User ID做决策时利用该用户信息。这无论对再营销(remarketing campaign),还是精准人群定向(targeting),或者是使针对印象展示的竞价更精确,都是有用的。

Cookie匹配服务,以匹配表作为数据结构,提供了广告购买方网络(buyer network, 即DSP)所需的DSP cookie与Google User ID之间的关联信息。并且,DSP还可以提供额外的数据让Google来存储并应用到后来的竞价请求中。

匹配表托管的好处

Google说选择让它托管匹配表的DSP享有如下优势:

  •  DSP自身所需的基础设施支持更少
  • 将Google User ID映射到某一有用格式不再需要查表
  • 在预定向(pre-targeting)阶段,有一个选项是说,是否以该Cookie的对应的匹配的有无来进行过滤。

Cookie匹配是如何工作的?

要在匹配表中建立某一关联,DSP必须提供由Google提供给它的标签,叫做匹配标签(Match Tag)。匹配标签可以和广告一起提供,也可以在广告之外单独置于其页面属性(web properties)上。其结构如下:

此处的 1234 就是由Google提供的DSP标识。

DSP应该只在不具有该用户的匹配信息(或者该匹配信息已失效)时才提供匹配标签。

每当接收到用户浏览器发来的带有DSP标签的请求时,Google会以要用户跳转到DSP的302重定向(302 redirect)作为应答。这一重定向的URL中包含了Google User ID和版本号,请求的头部(request headers)则包含了DSP cookie。DSP提供基础 URL(作为跳转入口,译者注),而Google则在此之上添加URL参数。

比如,DSP提供如下基础URL:

Google就可以重定向用户的浏览器到如下URL:

通过google_gid参数传递的Google User ID是一unpadded, URL-safe的base64编码字符串。Google建议,将由Cookie匹配服务返回的该字符串存到匹配表中。

注意:Protocol buffer中的BidRequest类的google_user_id字段就是对应由Cookie匹配服务对应的Google User ID的。

至于google_cver参数,则表示Google User ID对应的数值版本号。Google可能偶尔会改变其cookie模糊方案(cookie obfuscation scheme),那时就会增加google_cver的值。

DSP接收到这条在请求头部包含了DSP cookie的重定向请求之后,更新匹配表以建立DSP cookie与Google User ID之间的关联,然后必须提供一1×1像素的不可见的图片给用户浏览器, 或者返回一204 无内容(204 No Content)的应答。

往匹配表(Match Table)中添加条目跟将匹配标签(Match Tag)提供给用户是以相同的速率进行的。

这一过程可以用下图来说明,所有请求或响应用箭头来表示,而伴随请求或响应的数据项则在括号中标明。

cookie_matching

DSP可以在请求上设置额外的URL参数,它们最终会在重定向时传给DSP的Cookie Mapping服务器。

所有不以google_前缀开头的参量都会直接被拷给重定向URL。传给Cookie匹配服务的参数的次序无关紧要,而额外阐述传给重定向URL的顺序也不能保证。