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

1)Ad Exchange Server生成cookie mapping url,在返回给浏览器的广告JS代码中,将url置入一个img标签中。例如Google Ad Exchange中的代码如下,

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

广告展现时,该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 的首页。

对整个过程的说明如下:

ExampleNews.com 将会显示并调用 Ad Exchange 的广告。

广告单元符合动态分配资格,因此 Ad Exchange 会进行call out,也就是发送bid request给各个DSP。

A DSP 赢得竞价,并返回bid response至 Ad Exchange。

Ad Exchange 向小丽投放 A DSP 的广告,并设置她的 Cookie。

浏览器调用 Google 的 Cookie mapping服务。

Cookie mapping服务读取小丽的 Cookie,并将设好 USERID’的重定向传送至 A DSP设置的cookie mapping url。

A DSP 生成 Cookie,并将此 Cookie 存储在其matching table中与小丽的 USERID’相对应的位置。

A DSP 将其 Cookie 放到小丽的浏览器中,并在响应中提供一个空白的 1×1 像素。

流程图如下,

第 2 种情况:买方和 Ad Exchange

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

小丽会看到网页,同时,html 代码会包含向 Google 请求广告的调用。

在广告竞价期间,Ad Exchange 会向实时出价合作伙伴 A DSP 发出调用请求,让其选择是否要对展示进行出价。

买方收到包含展示信息和 USERID’的广告调用。

A DSP 在其匹配表中查找 USERID’,以找出一周前创建的 Cookie。

A DSP 利用与其 Cookie 相关的信息,对展示进行出价并赢得这次展示机会。

A DSP 根据所掌握的信息向小丽投放与其兴趣相符的广告。

参考:

http://www.tuicool.com/articles/vauiYfM

时间: 2024-08-11 05:45:39

RTB竞价中的cookie mapping技术的相关文章

cookie mapping 原理理解

Cookie mapping技术 利用javascript跨域访问cookie之广告推广 原文地址:https://www.cnblogs.com/lavin/p/10110500.html

RTB 竞价介绍

RTB(Real Time Bidding),中文名为实时竞价,是一种利用第三方技术在数以百万计的网站上针对每一个用户展示行为进行评估以及出价的竞价技术,是当前互联网广告的一种主要模式. RTB模式使得广告主能在合适的时间将合适的广告信息传递给合适的人,媒体能够讲剩余流量价值最大化,而再广告主来看,又使得用户能够通过个性化广告技术看到相关的信息. 与adnetwork不同,实时竞价规避了无效的受众到达,只针对有意义的用户进行购买.它的核心是DSP平台(需求方平台),RTB对于媒体来说,可以带 来

【转】asp.net中的cookie使用介绍

来源:http://www.jb51.net/article/30398.htm 一.cookie导读,理解什么是cookie 1.什么是cookie:cookie是一种能够让网站服务器把少量数据(4kb左右)存储到客户端的硬盘或内存.并且读可以取出来的一种技术. 2.当你浏览某网站时,由web服务器放置于你硬盘上的一个非常小的文本文件,它可以记录你的用户id.浏览过的网页或者停留的时间等网站想要你保存的信息.当你再次通过浏览器访问该网站时,浏览器会自动将属于该网站的cookie发送到服务器去,

JavaWeb之cookie缓存技术

web应用的会话技术:打开浏览器并访问网站,请求多个资源,关闭浏览器的过程. 在这个过程中,缓存用户数据常用的有两种技术: 1.cookie技术:用于在浏览器端,缓存用户的数据,可以理解为数据缓存在用户本地 2.session技术:用于在服务端,缓存用户的数据,可以理解为数据缓存在服务器. cookie技术: 1.服务器需要缓存数据,将数据发给浏览器,浏览器对缓存数据进行存储;当浏览器再次访问服务器的时间后,会将缓存信息,一起发给服务器. 2.cookie技术的原理图解: 根据上图分析如下: a

asp.net中的cookie

一.cookie导读,理解什么是cookie 1.什么是cookie:cookie是一种能够让网站服务器把少量数据(4kb左右)存储到客户端的硬盘或内存.并且读可以取出来的一种技术. 2.当你浏览某网站时,由web服务器放置于你硬盘上的一个非常小的文本文件,它可以记录你的用户id.浏览过的网页或者停留的时间等网站想要你保存的信息.当你再次通过浏览器访问该网站时,浏览器会自动将属于该网站的cookie发送到服务器去,服务器通过读取cookie,得知你的相关信息,就可以做出相应的动作.比如,显示欢迎

编写一个简单登录验证需要记录日志,Servlet中的Cookie

登录验证并记录日志 之前介绍了如何使用Server.mysql.tomcat等知识点编写了一个简单的登录验证.但是现在有了一个新的需求,我想要在登录成功的时候往数据库记录一条日志,登录失败的时候也要记录一下.这个日志要记录用户名.用户的IP地址.登录的时间.还有成功或失败的状态标识. 所以现在需要增加一个表格,用于存储日志信息,如图: 因为大部分思路和之前的写登录验证差不多,只是多了个记录日志,所以我这里就不赘述实现的思路了,直接上代码. 1. 首先需要使用html编写出页面,代码示例: CSS

nodeJS中的Cookie和Session

Cookie ● HTTP是无状态协议.简单地说,当你浏览了一个页面,然后转到同一个网站的另一个页面,服务器无法认识到,这是同一个浏览器在访问同一个网站.每一次的访问,都是没有任何关系的. 那么世界就乱套了,比如我上一次访问,登陆了,下一次访问,又让我登陆,不存在登陆这事儿了. ● Cookie是一个简单到爆的想法:当访问一个页面的时候,服务器在下行HTTP报文中,命令浏览器存储一个字符串:浏览器再访问同一个域的时候,将把这个字符串携带到上行HTTP请求中. 第一次访问一个服务器,不可能携带co

IM开发基础知识补课(四):正确理解HTTP短连接中的Cookie、Session和Token

本文引用了简书作者“骑小猪看流星”技术文章“Cookie.Session.Token那点事儿”的部分内容,感谢原作者. 1.前言 众所周之,IM是个典型的快速数据流交换系统,当今主流IM系统(尤其移动端IM)的数据流交换方式都是Http短连接+TCP或UDP长连接来实现.Http短连接主要用于从服务器读取各种持久化信息:比如用户信息.聊天历史记录.好友列表等等,长连接则是用于实时的聊天消息或指令的接收和发送. 作为IM系统中不可或缺的技术,Http短连的重要性无可替代,但Http作为传统互联网信

工作中使用到的技术和工具分享

已经很长时间没有写博客,7月份走出校门距离现在也有4个月了,没出校门之前以为自己懂得很多,真正工作了才发现自己学的东西真的已经落伍和过时了,在这里分享这四个月学习到的或者收藏的一些工作中需要使用的技术和工具,希望对还没走出校门的你们或者急需提升自己技术能力的伙伴有些许的帮助. 一.实用工具介绍 1)FQ工具:一只猫 | Jump Out Google是最好的老师,你遇到的问题和困难前人肯定都遇到过,技术资料不建议百度 2)抓包工具:Fiddler:Fiddler 抓包工具总结.charles 工