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/