Cookie mapping技术

摘要：

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技术

首先通过一些关键词解释普及或者回顾一下背景，

ADX：Ad exchange的简称。一般特指Ad exchange平台模块

DMP：Data Management Platform的简称。DMP存储了流量、受众的各种特征信息。

DSP：Demand Side Platform的简称。可以看做流量的购买方，为广告主服务。广告主可以通过DSP购买流量，达到营销的目的。DSP可以接入ad exchange中，参与cpm竞价，购买所需要的受众流量。

SSP：Supply Side Platform的简称。可以看做流量的供应方，为网站主服务。网站主可以通过SSP实现其流量变现，达到流量变现的目的。

Cookie mapping：DSP提供的一个平台cookie到DSP cookie的映射服务。

 

 

RTB中cookie mapping究竟是什么？

 

首先要明确一下cookie的重要性，RTB允许DSP在的Ad Exchange平台上做交易，在接入Ad Exchange的流量曝光上，针对每一个PV，每一个用户的属性进行分析以及竞价，从而购买到ROI最高的流量，所以RTB的核心在于“人”，在于人群的分析技术。

 

互联网上关于网民作为一个实体必须存在唯一标识，这个标识就必须依赖cookie，标识的产生通俗来讲就是“种cookie”技术。例如，访问neoremind.net，则可以在neoremind.net下种一个USERID=ABC123的cookie，该网民的身份证就是ABC123，而网站子域名，例如test.neoremind.net也可以共享使用此cookie。下文中USERID与用户标识混用，表示同一个概念。

 

像百度、google、淘宝等大站，本身其Ad Network覆盖庞大，加之其自身的人群分析技术，会积累了大量的关于网民用户的特征数据，这也就是说其自身已经是一个DMP，其分析出的访客特征数据对于DSP决定是否购买流量非常重要，当然DSP也可以利用自己的技术或者第三方DMP平台的数据自行灵活分析该用户。而其定义网民实体也是靠cookie，例如百度域下面的cookie BAIDUID就是百度所利用的标识。这个标识本身属于各个公司的重要数据，因此绝对不会暴露给第三方。

 

在RTB的一个重要环节——竞价中，bid request中一般会含有一个Ad Exchange平台提供的访客标识，这个标识可以理解为类似于USERID的cookie，但是绝对不会是Ad Exchange系统内部的ID，一般会利用非可逆加密算法做一次hash再给DSP，经过加密后的USERID我们叫做USERID’。而DSP一般需要针对bid request中的各种维度数据，包括PV信息，用户特征信息，广告位信息等决定是否购买此次曝光，还有现今流行的“再营销(retargeting)”技术必须依赖用户标识，所以这个USERID’是DSP需要的，DSP需要自行维护一个USERID’的matching table，就是该USERID’与自己定义的用户标识的一个映射。

 

cookie mapping发生在竞价成功之后？？？？两种情况。参考下面的例子。第一种生成映射表，第二种使用映射表竞价。

 

一般cookie mapping如何实现？

（1）用户请求  以下网址

 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-guide

Cookie 匹配的工作原理

要在匹配表中建立关联，合作伙伴必须投放一个由 Google 提供，名为“匹配标记”的标记。匹配标记可以随合作伙伴的广告一起投放，也可以放置在广告以外的网络媒体资源上。其结构如下：

 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) 的顺序进行。在该图中，每个请求后面的括号中都会包含与请求一起发送的信息。

您可以视情况在请求中设置额外的网址参数。这些参数将会在重定向时传送到您的服务器：

 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 像素。

这个空白的像素是种cookie时的副产品。不发挥作用。

第 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 根据所掌握的信息向小丽投放与其兴趣相符的广告。

在第五步，FinestDSP 竞价的决定因素是掌握的信息。这些信息除了ad exchange网址带过来的一些关于ssp的参数，还有FinestDSP以前展示的广告被小丽点击的情况，还有的信息包括FinestDSP从ssp那里收集到的关于小丽的信息。

但是它的信息会非常不完整，尤其是像广告被点击的情况，这个很稀疏。所以说关于用户小丽的信息很少。

这就是dmp可以发挥作用的地方。

以下转载自：http://blog.csdn.net/sunmenggmail/article/details/8763460

应用示例：

第一个例子：

1. 广告主网页向dsp发送加载请求

2. dsp发送含有之类的beacon, 但是需要注意的是，这里的src指向的是adx的域名

3. 用户浏览器解析到标签，就向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就返回这个用户标签等等

转载于:https://www.cnblogs.com/catkins/p/5270582.html