DSP

RTB竞价中的cookie mapping技术

2019-07-13 12:36发布

转载于:http://neoremind.net/2013/05/rtb%E7%AB%9E%E4%BB%B7%E4%B8%AD%E7%9A%84cookie-mapping%E6%8A%80%E6%9C%AF/?utm_source=tuicool&utm_medium=referral cookie mapping 如何知道不同网站的cookie属于同一个人? cookie mapping 目的是建立Dsp和 AD Exchange之间的cookie映射,把自己的cookie和广告平台的cookie关联起来,之后通过查询广告平台广播来的cookie对应的自己数据库的cookie,就可以判断该用户的历史行为。 首先通过一些关键词解释普及或者回顾一下背景, RTB(Real Time Bidding)实时竞价 ROI: Return On Investment 投资回报率 bid request: 投标申请 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如何实现?

1)Ad Exchange Server生成cookie mapping url,在返回给浏览器的广告JS代码中,将url置入一个img标签中。例如Google Ad Exchange中的代码如下, 广告展现时,该url向cookie mapping server,也就是cm.g.doubleclick.net发请求。   2)Cookie mapping server通过google_nid获取DSP在系统内设置的cookie mapping url(假设为ad.network.com)和token,并从HTTP HEADER中获取投放域中的cookie,如GOOLELID,将GOOLEID和token进行hash后得到google_gid,最后返回一个302重定向请求到如下地, http://ad.network.com/pixel?google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1&extra1=xx&extra2=yy 3)DSP系统会接收该302请求,并记录该google_gid,维护自己的matching table。   4)最后DSP服务器返回一个空白的 1×1 像素的图片,种自己的cookie,这样就把自己的cookie与google的cookie联系映射在一起了。   这个过程的架构图如下,

一个具体的story

小丽清除了缓存中的所有 Cookie。随后,她访问了 ExampleNews.com 的首页。   对整个过程的说明如下: 1)、ExampleNews.com 将会显示并调用 Ad Exchange 的广告。 2)、广告单元符合动态分配资格,因此 Ad Exchange 会进行call out,也就是发送bid request给各个DSP。 3)、A DSP 返回bid response至 Ad Exchange,Ad Exchange判断A DSP赢得竞价。 4)、Ad Exchange 向小丽投放 A DSP 的广告,并设置她的 Cookie。 5)、浏览器调用 Google 的 Cookie mapping服务。 6)、Cookie mapping服务读取小丽的 Cookie,并将设好 USERID’的重定向传送至 A DSP设置的cookie mapping url。 7)、A DSP 生成 Cookie,并将此 Cookie 存储在其matching table中与小丽的 USERID’相对应的位置。 8)、A DSP 将其 Cookie 放到小丽的浏览器中,并在响应中提供一个空白的 1×1 像素。   流程图如下,   第 2 种情况:买方和 Ad Exchange   一个星期后,小丽再次访问了 ExampleNews.com。现在,小丽的电脑上同时存有买方和 Ad Exchange Cookie,我们来看看匹配功能的运作方式。   1)、小丽会看到网页,同时,html 代码会包含向 Google 请求广告的调用。 2)、在广告竞价期间,Ad Exchange 会向实时出价合作伙伴 A DSP 发出调用请求,让其选择是否要对展示进行出价。 1)、买方收到包含展示信息和 USERID’的广告调用。 1)、A DSP 在其匹配表中查找 USERID’,以找出一周前创建的 Cookie。 1)、Ad Exchange根据所掌握的信息向小丽投放与其兴趣进行call out,A DSP 利用与其 Cookie 相关的信息,对展示进行出价并赢得这次展示机会。   本文参考: https://developers.google.com/ad-exchange/rtb/cookie-guide