概述：广告平台架构师，用系列文章分享广告平台业务逻辑，设计开发及运营维护

需求方平台 DSP

DSP 算是广告平台业务逻辑最复杂的组件了，它有如下几个职责

广告投放

广告主通过 DSP 来创建广告；查看广告效果及预算消耗情况

运营系统

广告平台的运营工作人员，对广告主创建的广告进行审核；设定广告投放的相关规则，比如曝光频率控制；查看各项业务指标数据；以及和广告主的资金往来相关的业务

实时竞价

在接受到一次广告请求时，从符合条件的候选广告里选择出 eCPM 最高的广告进行填充

行为上报

跟踪用户对广告所采取的行为，包括曝光、点击、下载、安装、激活、视频播放/停止等

计费

当一个广告被在媒体端被曝光，或者被用户点击、安装等行为发生时，根据广告主选择的计费方式，实时扣减广告主的预算资金

简单的图示如下

dsp整体组成

投放平台

为了便于广告主的操作，一般将广告抽象为计划、单元、创意的三级结构，各级别之间是一对多的

广告主需要先创建计划，在计划下可以创建多个单元，而每个单元下又可以创建多个创意

计划用来管理广告投放的起止时间，预算等信息单元管理的是定向数据，平台能提供哪些定向能力，取决于平台拥有的数据，比如，如果广告平台能获取到用户已安装的应用，那么就可以向广告主开放已安装/未安装定向创意就包含了广告主的出价，计费方式，购买的关键词，广告主的监控地址，及广告的物料，比如图片/视频，文案，落地页，应用的下载地址等等运营平台

运营平台首先是广告的审核，广告必须要合法合规，符合公序良俗，并且广告的宣传材料必须要真实，还要符合平台方的价值观，比如有的平台不接受网贷类广告，有的平台就来者不拒

同时，运营平台还会对广告设置一些过滤逻辑，来影响最终胜出的广告

举个简单的例子

如果你不停的刷新某个应用的同一个页面，你会发现每次刷出来的广告都不一样。这就是频率控制，在一定的时间间隔内，不会把同一个广告多次曝光给同一个用户

实时竞价

简单的描述下竞价逻辑

创建一个候选广告池

根据本次竞价的广告位、用户、设备、网络环境等信息对候选广告池进行过滤

比如说，请求广告的是一个横幅广告位，那么所有非横幅的广告都会被过滤掉；又或者，用户当前的网络环境是 WIFI，那么会过滤掉定向投放到移动网络的的广告

调用 CTR 预估服务，获取本次广告请求各候选广告的 CTR，并计算出 eCPM

根据 eCPM 进行排序

根据运营设置的规则进行广告填充，广告平台还会生成各种行为需要上报的地址和参数，作为广告数据的重要组成部分

这里就要考虑频控等规则，一个 eCPM 最高的广告可能刚刚曝光给当前用户，那么这一次就不会再用这个广告来填充

已填充的广告再根据价格设置（一般设置为二价）来计算出扣费价格

行为上报

广告抵达媒体端后，相对应的行为发生时，媒体就调用对应的上报地址进行上报

在后台，需要能识别出本次上报是初次上报还是重复上报

计费

在实时竞价的填充广告步骤，已经计算出来广告的扣费价格，并拼接到广告上报地址中，所以计费模块只要解析出上报参数，并按参数里设定的计费方式和价格进行扣费就行了

一般扣费涉及到广告主的钱包余额、当前广告的预算余额的变动，同时还要保留扣费流水，在数据库的操作上需要保证事务完整性，所以对于数据库的压力还是比较大的

如果采用消息队列的方式削峰平谷，数据库的压力是降低了，但这也会导致广告主的预算不能得到实时的更新，发生预算超支的问题

实时竞价 RTB

广告平台的实时竞价模块，是典型的高并发场景，对性能要求极高，同时也依赖大量的第三方服务，以我司的广告平台为例，其依赖着如下的外部服务

CTR 预估服务用户画像服务，该服务返回用户的性别、年龄、学历、兴趣爱好、所在地等信息用户安装的应用信息应用信息服务长尾应用

对于开发人员是个比较有挑战性的工作

今天就和大家分享到这里，对广告平台感兴趣的小伙伴请关注我，后续带来更多相关原创

广告平台系列内容

广告平台系列一：竞价逻辑和一价二价 广告平台系列二：广告平台整体构成