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