摘要：

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如何实现？

<img src="http://cm.g.doubleclick.net/pixel?google_nid=1234&google_cm" />

http://ad.network.com/pixel?google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1

Cookie 匹配的工作原理

要在匹配表中建立关联，合作伙伴必须投放一个由 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 的首页。

对整个过程的说明如下：

1. ExampleNews.com 将会显示并调用 Google (DFP) 的广告。
2. 广告单元符合动态分配资格，因此 Ad Exchange 会调用 FinestDSP（以及其他 DSP）。
3. FinestDSP 在其出价引擎中处理此调用。
4. FinestDSP 赢得竞价，并将广告和匹配标记（像素）传送至 Ad Exchange。
5. Ad Exchange 向小丽投放 FinestDSP 的广告和匹配标记，并设置她的 DoubleClick Cookie。
6. 匹配标记调用 Google 的 Cookie 匹配服务。
7. Cookie 匹配服务读取小丽的 DoubleClick Cookie，并将设好 google_user_id 的重定向传送至 FinestDSP。
8. 浏览器加载 FinestDSP 的网址。
9. FinestDSP 生成 Cookie，并将此 Cookie 存储在其匹配表中与小丽的 google_user_id 相对应的位置。
10. FinestDSP 将其 Cookie 放到小丽的浏览器中，并在响应中提供一个空白的 1x1 像素。

第 2 种情况：买方和 DoubleClick Cookie

一个星期后，小丽再次访问了 ExampleNews.com。现在，小丽的电脑上同时存有买方和 DoubleClick Cookie，我们来看看匹配功能的运作方式。

1. 小丽会看到网页，同时，html 代码会包含向 Google 请求广告的调用。
2. 在广告竞价期间，DoubleClick Ad Exchange 会向实时出价合作伙伴 FinestDSP 发出调用请求，让其选择是否要对展示进行出价。
3. 买方收到包含展示信息和 google_user_id 的广告调用。
4. FinestDSP 在其匹配表中查找 google_user_id，以找出一周前创建的 Cookie（第 1 种情况）。
5. FinestDSP 利用与其 Cookie 相关的信息，对展示进行出价并赢得这次展示机会。
6. FinestDSP 根据所掌握的信息向小丽投放与其兴趣相符的广告。