概述：广告平台架构师，用系列文章分享广告平台业务逻辑，设计开发及运营维护
DSP 算是广告平台业务逻辑最复杂的组件了，它有如下几个职责
广告投放
广告主通过 DSP 来创建广告；查看广告效果及预算消耗情况
运营系统
广告平台的运营工作人员，对广告主创建的广告进行审核；设定广告投放的相关规则，比如曝光频率控制；查看各项业务指标数据；以及和广告主的资金往来相关的业务
实时竞价
在接受到一次广告请求时，从符合条件的候选广告里选择出 eCPM 最高的广告进行填充
行为上报
跟踪用户对广告所采取的行为，包括曝光、点击、下载、安装、激活、视频播放/停止等
计费
当一个广告被在媒体端被曝光，或者被用户点击、安装等行为发生时，根据广告主选择的计费方式，实时扣减广告主的预算资金
简单的图示如下
投放平台
为了便于广告主的操作，一般将广告抽象为计划、单元、创意的三级结构，各级别之间是一对多的
广告主需要先创建计划，在计划下可以创建多个单元，而每个单元下又可以创建多个创意
- 计划用来管理广告投放的起止时间，预算等信息
- 单元管理的是定向数据，平台能提供哪些定向能力，取决于平台拥有的数据，比如，如果广告平台能获取到用户已安装的应用，那么就可以向广告主开放已安装/未安装定向
- 创意就包含了广告主的出价，计费方式，购买的关键词，广告主的监控地址，及广告的物料，比如图片/视频，文案，落地页，应用的下载地址等等
运营平台
运营平台首先是广告的审核，广告必须要合法合规，符合公序良俗，并且广告的宣传材料必须要真实，还要符合平台方的价值观，比如有的平台不接受网贷类广告，有的平台就来者不拒
同时，运营平台还会对广告设置一些过滤逻辑，来影响最终胜出的广告
举个简单的例子
如果你不停的刷新某个应用的同一个页面，你会发现每次刷出来的广告都不一样。这就是频率控制，在一定的时间间隔内，不会把同一个广告多次曝光给同一个用户
实时竞价
简单的描述下竞价逻辑
创建一个候选广告池
根据本次竞价的广告位、用户、设备、网络环境等信息对候选广告池进行过滤
比如说，请求广告的是一个横幅广告位，那么所有非横幅的广告都会被过滤掉；又或者，用户当前的网络环境是 WIFI，那么会过滤掉定向投放到移动网络的的广告
调用 CTR 预估服务，获取本次广告请求各候选广告的 CTR，并计算出 eCPM
根据 eCPM 进行排序
根据运营设置的规则进行广告填充，广告平台还会生成各种行为需要上报的地址和参数，作为广告数据的重要组成部分
这里就要考虑频控等规则，一个 eCPM 最高的广告可能刚刚曝光给当前用户，那么这一次就不会再用这个广告来填充
已填充的广告再根据价格设置（一般设置为二价）来计算出扣费价格
行为上报
广告抵达媒体端后，相对应的行为发生时，媒体就调用对应的上报地址进行上报
在后台，需要能识别出本次上报是初次上报还是重复上报
计费
在实时竞价的填充广告步骤，已经计算出来广告的扣费价格，并拼接到广告上报地址中，所以计费模块只要解析出上报参数，并按参数里设定的计费方式和价格进行扣费就行了
一般扣费涉及到广告主的钱包余额、当前广告的预算余额的变动，同时还要保留扣费流水，在数据库的操作上需要保证事务完整性，所以对于数据库的压力还是比较大的
如果采用消息队列的方式削峰平谷，数据库的压力是降低了，但这也会导致广告主的预算不能得到实时的更新，发生预算超支的问题
广告平台的实时竞价模块，是典型的高并发场景，对性能要求极高，同时也依赖大量的第三方服务，以我司的广告平台为例，其依赖着如下的外部服务
- CTR 预估服务
- 用户画像服务，该服务返回用户的性别、年龄、学历、兴趣爱好、所在地等信息
- 用户安装的应用信息
- 应用信息服务
- 长尾应用
对于开发人员是个比较有挑战性的工作
今天就和大家分享到这里，对广告平台感兴趣的小伙伴请关注我，后续带来更多相关原创
写的真好👍