SSP cookie ID和 DSP cookie ID 的匹配过程与广告 serving 过程同时进行，这个过程英文名为: cookie-syncing。 作为一个标准安全过程，任何类型的web 服务器只能设置指向它们自己域的cookie，而在一次实时广告竞价过程中 SSP 处于用户与DSP连接的所有广告商之间， DSP 需要一种方式去标识当前的用户，因此cookie-syncing 过程是非常必要的。
下面我们用一个简单的某商店重定位(retarget)它的用户的例子对cookie-syncing的过程进行一个介绍。假设你在运营storeABC 商店， 用户user123 来到了你的商店并将一双价值150美元的鞋子放进了他的购物车，但是并没有结算。你希望重新定位到这个用户并给他提供一个广告，该广告会将他重新带回到你的商店并有可能促使他完成购物。此时你正和名为DSP456 的DSP进行合作，你有一个1*1的像素设置在你的购物车页面，这给DSP456 一个给user123 创建cookie的机会。这个cookie ID 假设是DSPcookie789. 现在，用户user123 正在上网， 并在浏览awesomesite.com网站，而awesomesite.com网站正在和名为SSP123 的SSP 合作来售卖它的广告位。awersomesite.com 提供第三方重定向到SSP123, 这使得SSP123 能够为user123 创建一个SSP123的cookie ID 来标识user123, 我们假设这个cookie ID是SSPcookieXYZ。现在SSP123 发送一个竞价请求到与它合作的所有DSP上（这其中包括DSP456），希望为SSPcookieXYZ用户正在看的页面的广告位请求一次广告展示。但是，DSP456怎么能知道SSP123 的cookie ID：SSPcookieXYZ 和 它自己的cookie ID：DSPcookie789是对应同一个人呢？在SSP123 发第一次广告请求的时候，DSP456是不能知道这两个cookie ID之间的关联的，所以DSP456不会参与第一次的广告请求竞价。很可惜…
当SSP123以它自己定义的方式选择了一个获胜的竞价者后，它会运行一个javascript程序强制让user123用户向少数常规的竞价者发送一个重定向请求，这其中包括发向DSP456. 在这个重定向请求中包含了用户user123在SSP中的cookie ID（即SSPcookieXYZ）。现在用户向DSP456的web 服务器发送了请求，于是DSP456能够为user123设置自己的cookie ID，这个过程业界称为”piggybacking”。好的，现在DSP456就能知道原来 SSPcookieXYZ就是DSPcookie789, 这两个cookie都对应user123. 其中，SSPcookieXYZ是从重定向请求中获得。DSP456会将SSPcookieXYZ与DSPcookie789这组对应保存下来，当下次还有来自SSP123的竞价请求时便于查询使用。下一次，当用户user123访问一个由SSP123负责打广告的页面时，DSP456就会知道当前这个用户就是放了一双鞋到购物车但还没下单的那位，从而能够进行及时的竞价。
这个过程听起来有点复杂，但它最主要的意义是对于每一个通过实时竞价（RTB）打出的广告，有大概10倍多的技术公司参与了cookie-sync 的过程。cookie-sync发生在竞价之后而不是之前的原因主要是考虑到时延和用户体验。如果用户user123 需要访问10个DSP， 等待所有的DSP为自己创建cookie并将SSP cookie ID 和 DSP cookie ID的映射保存到DSP自己的数据库中，然后在开始广告竞价，这将显著地延缓整个竞价过程。如果一次cookie-sync失败，没关系，还有很多机会再次进行cookie-sync。
如果你感兴趣，这里有一些对每个主要的SSP运行piggyback脚本的URL链接，这些页面看起来是空的，你需要通过’view source'来查看页面源码。
Pubmatic: http://ads.pubmatic.com/AdServer/js/syncuppixels.html (使用vcode字段来传递cookie ID)
Rubicon Project: http://tap2-cdn.rubiconproject.com/partner/scripts/rubicon/emily.html (使用nid字段来传递cookie ID)
下面我们用一个简单的某商店重定位(retarget)它的用户的例子对cookie-syncing的过程进行一个介绍。假设你在运营storeABC 商店， 用户user123 来到了你的商店并将一双价值150美元的鞋子放进了他的购物车，但是并没有结算。你希望重新定位到这个用户并给他提供一个广告，该广告会将他重新带回到你的商店并有可能促使他完成购物。此时你正和名为DSP456 的DSP进行合作，你有一个1*1的像素设置在你的购物车页面，这给DSP456 一个给user123 创建cookie的机会。这个cookie ID 假设是DSPcookie789. 现在，用户user123 正在上网， 并在浏览awesomesite.com网站，而awesomesite.com网站正在和名为SSP123 的SSP 合作来售卖它的广告位。awersomesite.com 提供第三方重定向到SSP123, 这使得SSP123 能够为user123 创建一个SSP123的cookie ID 来标识user123, 我们假设这个cookie ID是SSPcookieXYZ。现在SSP123 发送一个竞价请求到与它合作的所有DSP上（这其中包括DSP456），希望为SSPcookieXYZ用户正在看的页面的广告位请求一次广告展示。但是，DSP456怎么能知道SSP123 的cookie ID：SSPcookieXYZ 和 它自己的cookie ID：DSPcookie789是对应同一个人呢？在SSP123 发第一次广告请求的时候，DSP456是不能知道这两个cookie ID之间的关联的，所以DSP456不会参与第一次的广告请求竞价。很可惜…
当SSP123以它自己定义的方式选择了一个获胜的竞价者后，它会运行一个javascript程序强制让user123用户向少数常规的竞价者发送一个重定向请求，这其中包括发向DSP456. 在这个重定向请求中包含了用户user123在SSP中的cookie ID（即SSPcookieXYZ）。现在用户向DSP456的web 服务器发送了请求，于是DSP456能够为user123设置自己的cookie ID，这个过程业界称为”piggybacking”。好的，现在DSP456就能知道原来 SSPcookieXYZ就是DSPcookie789, 这两个cookie都对应user123. 其中，SSPcookieXYZ是从重定向请求中获得。DSP456会将SSPcookieXYZ与DSPcookie789这组对应保存下来，当下次还有来自SSP123的竞价请求时便于查询使用。下一次，当用户user123访问一个由SSP123负责打广告的页面时，DSP456就会知道当前这个用户就是放了一双鞋到购物车但还没下单的那位，从而能够进行及时的竞价。
这个过程听起来有点复杂，但它最主要的意义是对于每一个通过实时竞价（RTB）打出的广告，有大概10倍多的技术公司参与了cookie-sync 的过程。cookie-sync发生在竞价之后而不是之前的原因主要是考虑到时延和用户体验。如果用户user123 需要访问10个DSP， 等待所有的DSP为自己创建cookie并将SSP cookie ID 和 DSP cookie ID的映射保存到DSP自己的数据库中，然后在开始广告竞价，这将显著地延缓整个竞价过程。如果一次cookie-sync失败，没关系，还有很多机会再次进行cookie-sync。
如果你感兴趣，这里有一些对每个主要的SSP运行piggyback脚本的URL链接，这些页面看起来是空的，你需要通过’view source'来查看页面源码。
Pubmatic: http://ads.pubmatic.com/AdServer/js/syncuppixels.html (使用vcode字段来传递cookie ID)
Rubicon Project: http://tap2-cdn.rubiconproject.com/partner/scripts/rubicon/emily.html (使用nid字段来传递cookie ID)
Admeld 使用与本文描述的方法不太相同的策略，由Admed挨个的将SSP cookie Id 发送到每个合作的DSP上。
原文地址：http://www.adopsinsider.com/ad-exchanges/ssp-to-dsp-cookie-synching-explained/
780
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
