DSP广告系统架构及关键技术解析(转)

广告和网络游戏是互联网企业主要的盈利模式

广告是广告主经过媒体以尽量低成本的方式与用户达成接触的商业行为。也就是说按照某种市场意图接触相应人群，影响其中潜在用户，使其选择广告主产品的概率增长，或对广告主品牌产生认同，经过长期的影响逐步造成用户对品牌的转化。

一个好的DSP系统须要知足：

拥有强大的RTB(Real-Time Bidding)的基础设施和能力。

拥有先进的用户定向(Audience Targeting)技术。

首先，DSP对其数据运算技术和速度要求很是之高。从普通用户在浏览器中地址栏输入网站的网址，到用户看到页面上的内容和广告这短短几百毫秒以内，就须要发生了好几个网络往返(Round Trip)的信息交换。

Ad Exchange首先要向DSP发竞价(bidding)请求，告知DSP此次曝光的属性，如物料的尺寸、广告位出现的URL和类别、以及用户的Cookie ID等；DSP接到竞价请求后，也必须在几十毫秒以内决定是否竞价此次曝光, 若是决定竞价，出什么样的价格，而后把竞价的响应发回到Ad Exchange。

若是Ad Exchange断定该DSP赢得了该次竞价，要在极短期内把DSP所表明的广告主的广告迅速送到用户的浏览器上。整个过程若是速度稍慢，Ad Exchange就会认为DSP超时而不接受DSP的竞价响应，广告主的广告投放就没法实现。

其次，基于数据的用户定向(Audience Targeting)技术，则是DSP另外一个重要的核心特征。从网络广告的实质上来讲，广告主最终不是为了购买媒体，而是但愿经过媒体与他们的潜在客户即目标人群进行广告沟通和投放。

服务于广告主或者广告主代理的DSP，则须要对Ad Exchange每一次传过来的曝光机会，根据关于此次曝光的相关数据来决定竞价策略。这些数据包括本次曝光所在网站、页面的信息，以及更为关键本次曝光的受众人群属性，人群定向的分析直接决定DSP的竞价策略。DSP在整个过程当中，经过运用本身人群定向技术来分析，所得出的分析结果将直接影响广告主的广告投放效果。

这次分享主要针对如下几个方面，描述DSP广告系统架构及关键技术：

广告系统概念介绍

广告系统业务流程

DSP系统架构

RTB竞价引擎结构

点击率预测

DMP数据处理架构

受众定向划分

用户画像与广告系统反做弊

程序化购买的特色

下图是在DSP产生以前和产生以后广告行业的两种最多见产业链

 

 

传统的广告投放模式的产业链是广告主经过广告代理，以广告网络/联盟为渠道在媒体网站展现广告，达到接触受众的目的的过程。

这种模式的好处是媒体网站能够经过经过包段或CPS的模式能够售出本身的广告位，可是这类售出是偏粗放型的，长期同类型的广告投放，受众会视觉疲劳，点击率会降低，转化也会随之降低。为了可以得到更多的收益，媒体必须经过差别化销售细分本身的广告位和受众。而事实上显示广告领域最初的定向投放的最初动机是供给方拆分流量以得到更高的营收。好的位置，经过包段一般会供不该求，可是对于长尾流量一般是会无人问津，即使是对于广告主来讲同一个潜在客户在大媒体出现会有广告主包段进行购买，可是在小网站出现就会没人买。事实上潜在客户在哪里出现对于广告主都是同一我的，若是能显示与客户需求相吻合或接近的广告就有可能产生转化。在将优质广告位包段售出后，若是对用户有足够的认识，有足够多不一样类型的广告主，在流量能够拆分到单次展示的购买粒度，就有可能依据不一样的受众定向为每一个广告主找到合适的人群和流量。

程序化购买颠覆了原有广告产业链，造成了全新的产业链。

鉴于群里有不少人不是作广告系统的，为了可以在后续的介绍过程当中更容易理解介绍的内容，这里先介绍一些广告行业中常见的一些概念。

DSP（Demand Side Platform），是广告需求方平台，DSP为广告主提供跨媒介、跨平台、跨终端的的广告投放平台，经过数据整合、分析实现基于受众的精准投放，而且实时监控不断优化。

RTB（Real Time Bidding）实时竞价是DSP、广告交易平台等在网络广告投放中采用的主要售卖形式，会在极端的时间内（一般是50~100毫秒之内）经过对目标受众竞价的方式得到该次广告的展示，RTB的购买方式不管在PC端或是移动端都可以实现。

程序化购买（Programmatic Buying）根据广告主定义的指望受众，系统帮助其找出优选的媒体来购买受众，为广告主提出最优媒介采买计划，经过程序化购买的方式执行，并按照指望的周期反馈监测结果，并对后续投放进行优化。包括但不只限于RTB购买。

最多见的DSP行业中的供需业务流，广告主做为需求方，潜在客户是最终的受众，中间穿插着代理机构，DSP，AdNetwork，AdExchange,SSP和供应方也就是媒体。

下图是DSP平台的广告投放流程，投放过程当中涉及到广告受众，媒体网站，adx和dsp，分别标注了广告投放各阶段伴随发生的事件。从1~7步之间只容许100ms以内的延时，不然广告受众就会以为网页加载速度太慢而选择离开。

在线广告的核心问题

 

须要在特定用户，在指定上下文的环境下，找到最合适的广告，进行投放，并尽量产生转化。

在线广告的挑战

大规模

百万量级页面，十亿量级用户，须要被分析处理

高并发在线投放（天天处理百亿次广告交易请求）

时延要求严格（adx一般要求竞价响应时间在100ms完成）

用户定向动态变化

用户的关注点和购物兴趣变化会比较频繁，须要可以及时更新用户画像

上下文条件变化频繁

用户和上下文多样化的环境一块儿用于广告候选检索

DSP系统架构

 

上图是主要模块的流程图涉及到的角色包括广告主网站，媒体网站，广告网络和DSP，以及DSP内部的相关模块，如：RTB引擎，业务平台，日志收集系统，DMP，CM和反做弊系统。

投放前DSP会要求在广告主网站布码，同时在DSP的业务平台中录入广告投放的需求，如投放金额，投放排期，投放定向（如地域，兴趣，年龄等），最高限价。

当访客（即潜在的消费者）从左上角访问广告主网站开始，访客在广告主网站上的行为会被收集，同时DSP会与ADX和SSP进行Cookie Mapping，造成日志进行处理，造成回头客相关的行为数据标签。

当访客完成对广告主网站的访问，去其余媒体网站进行访问时，相应的媒体广告位根据事先嵌入的广告代码向广告网络发起广告请求，广告网络会将广告请求封装成http头 pb体的格式向多个DSP发起竞价请求。

当DSP接到竞价请求时会根据与广告网络约定的pb格式进行解包，拆解出相关的字段进行匹配，根据以前相关媒体积累的点击率结合点击率预测模型对出价进行预测，找出平台内在这次竞价请求能让平台利益最大化的广告主的创意进行投放，返回给广告网络出价与广告代码

广告网络会在特定时间内（一般是50~100毫秒）根据多个DSP的出价高低，以第二名价格多一分的价格让出价最高的dsp胜出，并将广告代码中的展示宏和点击宏进行替换（替换过程当中会根据事先与dsp约定好的公钥对价格进行加密，以防止第三方篡改和窃听）

广告网络将广告代码返回给媒体，媒体会将广告代码放置在js对应的位置进行展示，展示和点击的过程当中会前后触发广告网络和胜出DSP的展示代码，广告网络和DSP分别接收到展示请求会对相应的展示进行计费操做（月底会相互进行对帐）

DSP内部会根据收集到的展示和点击进行计费操做，造成相应的报表；而浏览、展示、点击的记录会分别进行收集造成日志，通过ETL由DMP进行抽取和分析，造成媒体数据，用户标签，CookieMatch数据以及回头客用户标签数据，这些数据会在投放过程当中做为RTB竞价的参考依据。

整个投放过程当中其实还有一些其余的模块出现如CookieMapping、反做弊，动态创意、网站分析系统。只不过这些系统不是在主干流程上，后续单独进行描述和分析。

为了保证投放，DSP系统实现了多机房部署的结构，南北方机房分别在杭州和北京部署RTB引擎、点击率预测与相关的展示点击收集节点。投放活动相关数据经过Redis进行缓存，多机房进行准实时同步，媒体展示点击数据经过kafka队列进行推送，经过Consumer进行消费统计，最后经过媒体数据分发集群分发到多个机房进行使用。

RTB投放引擎的架构

 

RTB引擎是DSP系统的核心，是实现高并发实时反馈的关键，RTB对外以HTTP服务形式暴露接口，当媒体上的js被触发，adx/ssp收到js请求后会将请求封装成http头 pb体(protocol buffer,谷歌定义的序列化数据交换格式)的方式做为客户端链接RTB，RTB对http消息按照事先约定解包在内部依靠相关数据进行计算，最终返回pb或json格式的出价和广告代码给广告交易平台。RTB 须要支持高并发（天天百亿级别请求）和低延时（50ms以内须要反馈）。

当时咱们的RTB采用Linux C 开发，经过Adapter适配器层解耦适应不一样的SSP/adx，算法池内部拆分红五层，五层之间相互正交，算法模块容许热插拔，编译完成的动态连接库可根据配置文件的变化实时进行加载和卸载，容许多算法链并行拆分流量进行A/B测试，流量处理过程当中会对流经不一样算法链的流量打上不一样的算法标签，并在后续展示，点击过程当中持续带上此标签用于后续效果的跟踪和分析。

下面说一下在针对RTB进行架构设计过程当中涉及到的一些技巧：

因为一个dsp要接触到尽量多的流量和用户才有可能找到符合广告主定向的目标受众，那dsp必定要对接不少的adx和ssp，来接受尽量多的流量。设计适配器层的目的就是将不一样adx之间的流量格式差别消灭在适配器这一层，对于进入系统内部的流量都一视同仁，简化了rtb系统的复杂性。RTB系统在设计之初就考虑了AB测试的环节，让算法的效果可以进行横向比较，方便算法进行优化。RTB自己是不带状态的，也就是说，它只能依靠外部的辅助系统提供的信息，如点击率预测，人群定向和反做弊这类模块提供的数据才能实现快速反馈的同事能正确反馈。

DMP

对于RTB的设计在后续提问和讨论的环节咱们再作进一步分析，下面讲一下DSP系统中除了RTB以外的另一个核心：DMP

首先须要定义一下广告投放过程当中关键的一些数据：

 

 

广告系统DMP数据处理的架构

 

跟大多数的大数据相关的系统很类似，基本上逃不开那几样东西Hadoop，storm，redis等等:

数据处理部分结合了Hadoop的离线计算、Spark的批处理和Storm的流式计算。

HBase和MySQL用于最终结果落地用于前端查询。

ElasticSearch 有准实时索引，用于明细数据实时查询和时间序列历史回溯统计。

Spark内置的机器学习算法库MLLib主要使用分类，聚类KMeans，协同过滤，决策树，逻辑回归。

因为以前在群里的分享中,王新春@大众点评 ，王劲@酷狗音乐 讲了不少storm实时处理和大数据架构的内容，他们二位都是大数据领域的大佬了，我在这里就不班门弄斧了，简单提一下广告行业里是怎么作的，基本上大同小异，你们用的东西都差很少。

对于广告投放要投放的目标，落实在dmp中就是须要找出相应的受众定向，下面简单分析一下几类受众定向：

 

上图是广告有效性模型根据受众定向的定性评估表，水平方向是定向技术在广告信息接受过程当中所起做用的阶段，垂直方向是大体的效果评价（从下往上效果依次升高）。

按照计算框架不一样这些受众定向能够分为三类：

用户标签t(u)，即在时间序列上用户历史行为为依据，为用户打上的标签。

上下文标签t(c)，即当前用户联系上下文在当前的访问行为达到的即时标签。

广告主定制化标签t(a,u)，是根据特定广告主提供的特定用户群在其网站上的访问行为数据加工所得。

其中：地域定向、频道定向和上下文定向属于t(c)的定向方式；人口属性定向、行为定向属于t(u)的定向方式；

而重定向和Look-alike则是t(a, u)的定向方式。

地域定向主要用于商家销售目标局限于特定区域的状况下；

人口属性主要包括年龄，性别，收入，学历等；频道定向主要是针对媒体侧特色，对相应受众进行划分；上下文定向主要是根据当前网页的内容上下文推送相关广告；行为定向是根据用户历史访问行为，了解用户喜爱，进而推送相关广告；精确位置定向是在移动设备上根据精确的地理位置投放广告，更聚向与地域性很是强的的本地生活类广告主；

重定向是对特定广告主必定时间段内访客投放广告以提高效果的广告投放方式，人群规模由广告主固有用户量和媒体重合量共同决定；新客推荐是在重定向规模过小，没法知足广告主接触用户需求的状况下，以重定向用户为种子，根据广告平台数据积累，为广告主找出行为类似用户的定向条件。

用户画像的方法

接下来基于上面提到的积累受众定向介绍一下用户画像的方法

 

咱们可以看到用户画像其实也就是对于用户特征的提取，涉及到人口，设备，运营商，位置以及用户的浏览，点击购买等行为数据。用户画像是经过对用户特征的提取对用户行为进行定性和定量的描述，造成：【用户ID:用户标签：标签权重】形式的用户画像标签，在广告投放过程当中，根据提取流量对应用户权重较高的若干个标签反向对广告主进行筛选，找出适合流量特色的广告素材。 用户标签用于广告主对于受众的选择，而权重用于在海量用户标签里选取重点的标签进行投放。

同时要注意用户的画像随时间的推移会有衰减，须要在用户画像的过程当中考虑时间衰减的因素，由于用户的爱好和习惯会随着时间变长而有变化，同时数据的时效性也决定了用户画像的准确程度，进而影响广告的投放。

事实上在广告平台中收集到的最多的数据是用户的浏览数据，在拿到这么多的浏览数据的状况下，想要分析出用户的爱好和兴趣以及需求，那就须要对网页的内容进行分析和抽取，下面介绍一下用户画像中很是重要的行为标注部分的架构：

用户在浏览一系列网站的过程当中是多少会带着一些目的性进行浏览的，即使是没有明确目的，也会带有一些我的喜爱，有了这些目的和喜爱，就会进一步缩短咱们在推送广告过程当中对于用户定向的选择难度。上图就是在上下文定向中对网页关键字提取的子系统的架构。【上下文定向】能够经过网页关键字提取，创建一个cache，根据URL创建对应标签，当广告请求到来时，命中相应URL则返回cache的命中内容，若是URL未缓存则返回空集合，同时将URL添加到后台抓取队列，在URL被抓取，并打上标签存入cache，为cache设置TTL，当长期不访问则将该URL的记录清楚，而热点内容URL的关键词是始终被缓存的，运行较长的时间则大多数热点URL大多会被缓存。在抓取到内容以后，须要对网页内容进行内容挖掘，在挖掘的过程当中有如下几个方案能够被选取：

 

网页文本内容经过扩展语境，引入更多文本进行挖掘；利用语义分类树；创建主题模型。

咱们在上面提到了在线广告的核心问题实际上是找上下文，用户，广告三者之间的最恰当的匹配。

在展现类广告中比较重要的一个核心考核点就是点击率，所以点击率预测模块在DSP中是很是重要的部分

 

 

 

CTR预估涉及到三种角色：受众用户，媒体，广告主

预估的目标是为特定的受众用户再给定的媒体环境下找到最合适的广告，对媒体来讲实现收入最大化，即按照eCPM排序的基本原则来排序。

最简单的CTR预估的模型，根据历史日志，统计出三个维度的CTR对照关系，预测过程当中，当一个user访问特定url时，查询词典若是存在的CTR，则返回CTR最高的ad，如不存在，则随机返回ad，积累后续数据。

存在问题：基于统计数据，对旧广告效果还能够，但对冷启动的广告没有预测能力。

事实上，咱们在线上作点击率预测模型，使用的算法是逻辑回归，后续可能考虑会用到的广告点击率预测方法有：

机器学习方法：特征 模型 融合方案

协同过滤方法：看作推荐系统来处理

排序模型以预测结果为基础，广告排序模型有以下几种：

点排序（point-wise approach）：变成分类问题或者回归模型来处理

对排序（pair-wise approach）：比较两个广告谁的优先级高，不分类

列排序（list-wise approach）：对整个广告候选集学习排序模型

广告行业的反做弊

 

做弊背后必然有一个或者一堆的人从众有获利，好比制造垃圾站挂广告获利的老是扎堆出现的。若是你抓到了一个网站流量异常，在用工具刷量，那确定不会只是这一个网站在用这个模式在刷量；若是一我的有多个网站，若是有一个网站在刷量，那他的其余网站也应该检查一下了。

在广告反做弊的过程当中，为了找出刷量的垃圾站背后都有哪些人，这些人有哪些网站，针对DSP平台流量80%的网站域名去重，经过whois信息查询到域名注册邮箱，归类出哪些域名属于哪一个注册邮箱，发现其中一个刷量，则对同一邮箱下的其余域名进行严查。

 

上图是主要的一些广告反做弊的思路，广告做弊是有成本的，有人做弊，仍是背后有利益驱动，找出利益链条是反做弊的关键

下面对以前咱们作广告反做弊工做过程当中遇到的几类例子：

P2P流量互刷

互刷做弊有表明性的软件是：流量宝和流量精灵

均经过客户端软件向服务器提交互刷任务请求，客户端收到服务器分发的互刷任务后执行隐藏的浏览任务，天天可达到数千个IP的访问量，IP布局分散，UA随机生成，很难经过浏览记录寻找做弊痕迹。如今惟一有效的反做弊方法须要经过蜜罐主机进行跟踪和分析。下面介绍一下咱们对于p2p刷量所采用的蜜罐主机的结构：

其中虚线框中是咱们的的蜜罐系统，虚线框外面的灰色部分是咱们要寻找的做弊目标

若是是对信息安全有必定了解的人对于蜜罐系统必定不陌生，也就是系统设计上有意抛一些破绽出来，让攻击者本身跳出来，经过对攻击者行为的观摩来寻找破解攻击的思路。

因为流量宝、流量精灵一类的刷量工具多集中于windows平台下，安装windows vm并将系统代理指向nginx反向代理，经过刷量工具提交刷量任务。提交刷量任务的站点没有任何真实流量，只要是访问这个站点的IP基本上都是经过刷量工具来的流量，IP能够在RTB引擎对相关IP端进行封杀，再也不进行投放；

Nginx反向代理落详细日志经过Logstash收集、解析发送给ElasticSearch创建索引，经过kibana作可视化，统计出刷量最多的IP，域名和URL地址出来，能够做为后续模式识别的模型输入。搜集相关证据，域名能够向adx反馈对媒体进行封杀，同时能够根据筛选出的刷量做弊域名在DSP投放过程当中减小投放以免自身损失。

CPS引流做弊

咱们遇到的另一种对于DSP投放效果有很是大影响的一类做弊手段是：CPS引流做弊

引流做弊能够帮助引流网站“提升”CPC，“提升”CPS。但对广告主不产生实际有效的流量。

目前发现的引流做弊行为有3种：

做弊代理经过回帖做弊（对媒体网站无控制权）

做弊代理伙同媒体网站做弊（对媒体网站有控制权）

做弊代理伙同媒体网站经过网盟做弊

也就是说在DSP投放了广告的网站里被插入了跳转到CPS计费连接的302跳转的图片，虽然DSP花钱从adx买了流量投放了广告，可是这个页面里还有大量的CPS结算的连接跳转，若是广告主既在网盟，又在DSP投放广告的话，任何看过这类页面的人在广告主网站下的单，就有可能被劫持走。整个过程当中，用户都不知道有'广告主'的存在。可是对应的'广告主'会认为是特定CPS连接带来了一个点击，后续的cps应该是记在相应的CPS合做方名下。

Q & A

Q1：请问付总dmp数据存哪里？HBase？

数据分不一样的形式存在不一样的地方，原始日志存放在硬盘上，通过ETL后写入HDFS，结构化存放在Hive表中进行查询，cookiemapping数据通过hadoop计算事后导出成文件，存放在Tair里让RTB查询，用户行为数据存放在hdfs里，画像以后数据存放在redis供rtb查询，跑出来的统计报表存放在mysql供报表系统调用。CM的cookie对应数据有一部分也是存放在hbase的，hbase和hadoop共用hdfs，因此查询速度也会受到hadoop集群资源多少的影响。

Q2：请问 RTB算法模块热插拔大概是怎么实现的？

上面我曾经提到过RTB系统是用Linux C 开发的，若是对于Linux C 比较熟悉的人应该知道Linux下是能够动态加载动态连接库的使用的主要是：

dlopen：打开动态加载库

dlsym：获取接口函数指针

dlcose：关闭库

这三个函数就能够在程序运行时加载动态连接库了。为了达到模块准实时热插拔的目标咱们还使用了Linux下的inotify,

inotify是一种文件系统的变化通知机制，如文件增长、删除等事件，能够马上让用户态得知。咱们在RTB程序启动过程当中向系统注册了inotify事件来监控配置文件，当配置文件被修改的时候当即通知程序从新加载配置文件

Q3：请问cookiemap是离线map仍是实时map？map后数据正确率有多少？移动端map 主要根据那些key来map？

cookieMapping分在线和离线两种，一般状况下广告投放过程当中会有几个场景会发起cm

第一种，广告主网站上布码以后当访客访问广告主网站时触发js，dsp会主动向各家对接事后的adx进行cookiemapping

第二种，广告投放过程当中，当dsp的出价的同时会带上广告展示代码里面也包含有cm代码，当出价高于其余dsp的时候，广告代码会被吐到媒体网站，相应的也会触发cm

第三种，当在adx消耗金额达到必定水平，像Tanx会按照消耗比例天天向dsp发起必定比例的dsp没法识别用户的cm请求，这个时候dsp也会向其余adx发起cm

除此以外对于运营商数据的使用过程当中一般就是离线匹配的了，方法一般是运营商的浏览数据来自于路由设备的DPI信息，里面有用户的adsl帐号信息，运营商会找出必定时间内访问过dsp指定的几个域名的人，一般会在这个域名下面的全部页面都布上cm代码，经过http头就能找出dsp的cookieID，找出的这些人都会有adsl帐号标识，经过帐号就能创建与dsp的cookieID的关系，这类cm就是离线的了。

Q4：请问怎么识别是同一个用户？经过cookie，仍是有其余先进的办法？

PC端的用户识别一般是依靠cookie，这类cookie好植入，但生命周期比较短，没法直接跨浏览器/跨设备，同时容易被各种电脑管家/助手清理，因此很容易出现信息苦苦画好的用户画像，过两天这个id就不再出现了。

在PC端还会用flash cookie的方法来打通不一样的浏览器，由于flash storage是同一块存储不一样的浏览器能够跨浏览器打通。

固然还有一种叫evercookie的手段集合了包括flash cookie 以内的多种标识方式，感兴趣的能够了解一下这个网址 http://samy.pl/evercookie/

移动端的身份标识，安卓的包括android id，mac地址IMSI和IMEI，而iOS是IDFA。因为移动设备上安装的app里能够嵌入SDK，而app有可能在移动端的权限也不一样获取到的标识也会有差别，因此最终也会涉及到用户标识统一识别的问题，固然移动端的用户标识会远比PC端要强不少，移动广告化以后用户画像将会更加的准确。

做者：宿逆 连接：https://www.jianshu.com/p/0d14c0faf531 來源：简书 简书著做权归做者全部，任何形式的转载都请联系做者得到受权并注明出处。