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