我看到的在线广告解决方案演化-DSP骨架

2.DSP骨架

 

 

2.1 名词说明

 

demand-side platform (DSP)-就是需求方平台,如果你有丰富的广告来源,例如4A广告公司就有可能需要这种平台.定义可以参看http//.wikipedia.org/wiki/Demand-side_platform.

 

supply-side platform或者sell-side platform (SSP)-就是拥有媒体展示的平台,国内这种平台业务有很多变体,定义可以参看https://en.wikipedia.org/wiki/Supply-side_platform.

 

data management platform(DMP)-有自己业务模式能积累大量数据的公司适合做这个业务,在线广告行业就需要这样的平台,具体的定义就不细说了.

 

IAB-美国互动广告局,英文全称是Interactive Advertising Bureau,可以视为广告行业的标准机构,管理和发布在线广告标准,其中就有OpenRTB标准v2.2,v2.3,v2.4等等.

 

Real-time bidding (RTB)-实时竞价机制,从系统设计的角度来理解就是广告交易的两方(需求方和提供方)建立一种保障实时竞价机制.

 

 

2.2 DSP平台关键性难点

a .tmax问题,我们当时使用的OpenRTB v2.2是这么解释的” Maximum amount of time in milliseconds to submit a bid (e.g.,120 means the bidder has 120ms to submit a bid before the auction is complete). If this value never changes across an exchange, then the exchange can supply this information offline”.这个需求就定义DSP系统重要的高性能指标, lowest latency response或者lowest response time(最少响应时间),也就是从auction server的角度从发出请求开始计时,通过网络传送到bidder,bidder内部有一个计算过程得到结果,再通过网络传回给auction server,所有的时间小于tmax指定的值.那么tmax在实践中指定的值是多少呢?从我后来对接过的系统要求来看,tmax值范围大概是100毫秒200毫秒之间。

 

b . high-volume of request问题,系统需要支持多大的请求量(QPS)。移动广告行业有自己的特点,一天24小时的流量(请求量)不是均匀的,大部分正常流量都产生于晚上7点到11点之间,可能的每小时流量是多少呢?这样来计算,一个号称每天有2亿请求的流量平台,一天平均每小时为2亿请求/24小时=833万请求/小时,那么在高峰时段会是可能是3000-4000万请求/小时.如果业务要求接入10个这样的栏位拍卖平台,系统要能支持4亿/小时请求能力,如果是要求接入100个这样平台,对系统要求也是相当恐怖的。

 

c . high-volume of data,很显然,前面巨大的请求量必然产生海量的数据这些数据需要被存储,被分析(有可能实时计算,也有可能是异步计算),然后产生业务价值.例如,客户的impression和click事件肯定用于计算广告的费用等等.

 

所以,如果要构建这样的DSP骨架就需要面对这三个最大难关, lowest latency response, high-volume of request和high-volume of data(在内部,我们称为LHH问题).

 

 

2.3 DSP构建DSP骨架

 

 

2.3.1 DSP运行原理

 

 

 

图2.3.1.1 运行原理

 

通过结合OpenRTB规范,我们抽象设计了DSP运行基本过程

[1.request an ad],广告栏位拍卖方(RTB auction server可以视为SSP平台方)发出广告栏位请求要求填充广告。当然这里有一个前提,拍卖方一定是向多个DSP发出请求。

[2.request an ad],RTB bidder是我方的广告栏位请求接收系统,它把外部广告请求转换为内部广告请求后传给decision supporter.

[3.if matched audience],decision supporter会首先会尝试判断用户是否有偏好,这个有一个背后的过程就是例如某个用户被计算为对化妆器有兴趣的客户,在这里就会被选择出来.当然,第一次访问的用户就无法有这种偏好数据.

[4.select optimum campaign && bidding price],这一步就根据请求的栏位数据,如果有用户偏好,加上最佳的广告活动和出价确定广告栏位的填充广告结果.

[5.resp bidded ad],内部填充广告.

[6.resp bidded ad],转换为外部可以接受填充广告格式.

 

 

2.3.2 描述DSP decision supporter核心逻辑

 

 

图2.3.2.1 DSP decision supporter说明

 

DSP decision-maker是入口部分,它带有4大主要功能:

根据定向条件选择合适的多个广告活动.

删除选择的广告活动中没有headroom的广告活动,例如,某广告活动针对客户每天的impression最多3次,如果某个客户已经产生的3次impression,这个广告活动就不适合了要从匹配广告活动中删除.

如果还有多个广告活动就进行排序,选择排序级别最高的广告活动作为填充广告.

 

根据广告栏位价格的设置,对填充广告进行定价,最终这个价就是RTB的栏位出价.

 

 

2.3.3 打包广告活动的受众用户

 

这里需要解释广告活动是指什么.通常广告主会设置(自己或者通过平台代理人)广告素材,大家在广告栏位看到flv或者jpg广告资源,广告活动的起始和结束时间,广告预算等等。在我们系统里,有一类选择的元素就是涉众用户。具体业务操作如:广告主根据我们内部计算的分类选择用户特征是身高在1.8米以上,20-30这个年龄段,或者年收入在40w以上的高富帅投广告.我们把这部分的受众用户ID会打包在广告活动中,这个过程就下图所示:

 

 

 

图2.3.3.1 广告活动的受众用户产生

 

这里dmp plumbing负责接入外部和内部dmp系统来获取分类涉众用户。proprietary dmp指的是公司专有的DMP系统.

 

 

2.3.4 DSP主要部署方式和关键组件协作

 

 

 

图2.3.4.1 部署方式

 

 

在部署中,我们考虑三个Auction(这个系统不是DSP组件,是对方系统)分别位于Shanghai,Beijing,India三个地区,对应每个地区,也就是理论上我在Shanghai,Beijing,India三个地区分别部署三套RTB bidder,Auction和bidder之间使用OpenRTB或者它的扩展。

 

ad content management system(ACMS)是一个广告主或者广告主代理操作的平台,打包所有的广告活动异步传给不同地区的RTB bidder.

 

ad performance collector负责把业务需要的一些实时计算数据收集过来,而ad dashboard负责友好的方式展示这些实时业务数据。到了后面ad dashboard会并入ACMS,因为它是服务广告主或者广告主代理的业务平台。

 

这种部署方式避开了集中在一个点架构bidder的问题,通过与auction的one on one近地协同工作,减少了网络传送时间,我们最后实际只需要在Hong kong和Shanghai两地建立Bidder平台,加上异步机制成功的解决了tmax问题。

 

 

2.3.5 开发使用到的设计

 

下面的部分主要用来指导开发人员和对于DSP实现进行路线图设计,就不多解释了,仅提供参考。

 

DSP底层运行机制

 

 

2.3.5.1 运行机制图

 

DSP的开发模块分解

 

 

2.3.5.2 模块