优酷 DSP 广告投放系统架构实践

导读：随着 RTB 网络在线展现广告交易模式的兴起，各大公司都纷纷搭建自己的 DSP ( Demand-Side Platform ) 广告投放系统进行获客。优酷在近几年也搭建 DSP 系统，并且在持续迭代。在这一过程中，经历哪些技术探索？趟过哪些坑？有怎样的技术方案沉淀？下面我将从技术视角分享出来，希望对大家有启发。

——业务目标——

DSP 的核心目标就是用户增长，通过广告拉新和召回，提升用户留存和活跃度。从月活跃度的维度，我们将用户进行分层：新用户、低活跃用户、中活跃用户、高活跃用户和流失用户。

具体活动度的指标，可以根据业务的具体情况进行定义。人群划分好之后，就可以针对各分层人群进行召回承接。我们的重点是要召回当月新用户、低活用户、中活用户、流失用户。

• 高活用户：即使不采取召回，也会主动来；

• 流失用户 ( 30天没来过的用户 )：召回难度最大。因为有可能用户已经卸载或者转移到其他 APP。从数据上看，流失用户的转化 ROI 也是最低的。

所以我们的召回策略就是要把召回阶段前置，在低活和中活这两个阶段就开始进行召回干预。因为这个阶段用户获取成本相对较低，ROI 比较高，让这部分用户不断触达召回，提升留存，把他们往高活上去迁移 ( 当然这部的用户体验也要跟的上，让用户形成使用习惯和心智很重要 )。

——系统架构——

明确了业务目标，接下来介绍下我们的系统的架构。

我们将从渠道能力、策略能力、算法能力、实时监测，数据等几个维度来介绍下 DSP 系统的架构实践与思考。

❶ 渠道能力

召回获客首先要有强大的渠道能力做支撑，这样才能获取和覆盖到足够多的我们想要的用户，本文只涉及到支持 RTB 竞价广告相关的渠道，市面上有很多 ADX 比如百度 ADX、网易、广点通、tanx 等等，那么这么多渠道，我们也不可能全部接入，流量压力也是可想而知的。

首先要思考和评估我们要重点接入哪些渠道，哪些渠道的获客体量大，哪些渠道的成本低，每个渠道的用户分层是怎样的，我们需要对渠道有一个渠道质量的洞察。

从以下指标进行洞察：

需要分析：

• 媒体下发流量中有多少是安装优酷的用户，用户分层占比；

• 多个媒体间的用户重合度，控制跨媒体曝光频次；

• 每日最多可触达多少优酷用户，并分析未被触达的原因；

• 媒体的点击率、转化率 ( 对应优酷的换端率、播放率 )，预算分配等；

• 实现最佳的媒体组合进行投放；

• 优化网盟渠道，如广点通。

广点通渠道我们主要对接的是网盟，广点通网盟可能包含上万家的 APP 媒体资源位，每个媒体的效果和表现都不同。这加大了优化难度，且广点通的流量下发多是根据 ( 竞价成功 PV/流量下发 PV ) 的占比，比例越大，流量下发越多。这就带来一个问题，如果要获取精准用户，势必参与竞价的 PV 会减少，占比降低，最终导致流量下发降低，覆盖不到更多的用户，需要进行权衡。

❷ 策略能力

在 DSP 广告的投放过程中会涉及到很多的投放策略，下面介绍几个比较通用的投放策略。

1. 频次控制

这里说的频次控制包括：参与竞价频次控制、展现频次控制、点击频次控制、换端频次控制等几个维度。

一般说频次控制主要是说展现频次控制，优酷又增加了三个维度的频次控制。

• 参与竞价频次控制： 这个是分媒体的，在有些媒体效果会很好，有些媒体则不需要，由于有些媒体参与竞价和展现之间的延迟时间比较长，导致一直没有展现，这个时候展现控制就失效了。

  用户可以一直参与竞价，然后集中或者分散开去展现，这种情况展现控制就失效了，有可能一个用户要展现上百次都有可能。

• 点击频次控制： 对于当天点击过广告的用户，则不在购买，可以防止疲劳。

• 换端控制： 对于当天唤起过优酷的用户，不在继续购买，由于用户主动或者被动已经来过优酷了，就没必要在进行购买了。

下面举例说明下不同媒体频次控制的次数，不同媒体的效果差的也比较大，尤其是网盟渠道会和头部媒体渠道差别比较大。

2. 素材赛马策略

在投放素材的时候，一个广告计划可能会配置多套素材进行投放，如果没有赛马机制的话就会随机投放。

赛马机制主要解决的是把点击率高的素材给到尽可能多的曝光，点击率低的素材减少曝光或者不曝光。

这个非常类似推荐系统里面的两个经典问题： EE 问题 ( 从探索到应用 ) 和冷启动问题。

下面介绍一个简单的赛马逻辑实现，具体策略如下：

假定投放方案 A，下面有广告位 M，符合 M 条件的素材 X 套 ( X>=2 )

素材 CTR=素材点击数/该素材展示数

冷启动过程：

第一，在 15min 时间范围内，广告位 M 符合投放方案 A 流量对于 X 套素材流量平均分配。

第二，计算上个 15min 内 X 套素材的 CTR 结果 [CTR1,CTR2,…,CTRx]，并进行排序，假定 CTR 最高的为素材 N。

第三，在下一个投放 ( 15min ) 范围内，对于广告位 M 符合投放方案 A 竞价返回素材时：

• 对于素材 N 分配80%的流量

• 对于剩下的 X-1 套素材，平均分配剩余20%流量

第四，投放中重复步骤2和步骤3的判断。

3. 平滑投放 ( budget smooth )

平滑投放是保证广告主在预算一定的情况下，能平滑的消耗预算，而不是在开始几分钟之内全部花完。

平滑投放可以让广告主触达更多的人，更多时间段的用户群，下面是几种消耗模式，借网络上的几张图：

之前，我们采用的是基于流量模式的平滑投放，问题是流量大时，分配更多的预算，但是转化 ROI 不一定好，所以目前我们采用的是第三种方式，基于效果的平滑投放，这里的效果主要指的是点击 CTR 效果，比如中午，刷手机比较多，效果比较好，那我们就多分配预算在中午这段时间进行投放。

4. 广告重定向策略 ( retargeting )

"重定向" 是广告领域的一个术语，又被称作 "访客找回广告"，"在营销广告"，"回头客广告" 等等，是帮助广告主有效获取目标受众的一种重要方式，比如在消费者购物的过程中，常常会因为这样或那样的原因，最终没有完成转化。重定向广告将商品展示到此类未完成转化的消费者面前，将其带回到相关网页。由于展示的商品往往也是消费者最想要的，所以重定向广告的转化率比一般广告要更高。

5. 图片视觉优化策略

为了给用户更好的体验以及更好的视觉冲击力，提升用户的点击欲望，我们对投放的图片素材进行了二次加工，取得了不错的效果。

测试中发现不同渠道的视觉不同，不能统一设计，所以我们进行了分渠道对比视觉设计实验，比如在某 feed 流中。

通过工程合图能力，我们快速实现并上线了几十套模板，线上进行 AB 实验，测试点击率效果，选择优秀的模板长期投放。

❸ 算法能力

接入算法能力主要为了实现个性化的站外广告推荐，目前接入算的架构。

1. 并行多路召回

• 基于播放记录召回：会根据用户的站内播放行为进行召回，按时间进行衰减；

• 基于热点节目召回： 比如最近新上的新热剧等；

• 基于用户偏好召回：比如明星偏好，剧集偏好等；

• 基于站内行为召回：比如收藏行为，点击浏览行为，搜索行为等。

2. 分渠道模型

由于我们接入了很多渠道，每个渠道的特征表现都不太一样，需要分渠道进行针对性的模型训练，简单的特征如下：

❹ 数据&监控能力

完善的数据分析系统对DSP的投放非常重要，通过数据分析，优化转化漏斗，降低成本。

1. 转化漏斗

首先需要定义业务的转化漏斗，见下图：

下面逐步说下这几个漏斗阶段我们可以干预的策略。

• 参与竞价

  参与竞价的量，主要受限于用户的识别能力，如果根据设备信息可以准确识别到是优酷的用户，那么参与竞价的量可以大大提升。

• 竞价成功

  竞价成功的量，主要有这几个方面的受限，第一个是出价，出价过低导致竞价失败率高，第二个是接口性能，目前 ADX 要求是 100ms 内返回，这就要求 dsp 需要不断的优化接口的响应时间，可以很明显的提升竞价成功的量。

• 展现

  展现的量，比如标题长度，曝光的次数等等。另一个是媒体自身的原因了，可能媒体本身有些复杂的频控逻辑导致展现不成功。

• 点击

  这个第一是和算法的推荐能力的准确性有关系，推荐的越准确越容易点击，另一个是和图片和标题的吸引程度以及视觉体验有关系，比如一个猎奇的短视频，可以大大激发用户的点击欲望，还有就是刚才说的视觉图片合图的优化。

• 唤起

  换端率，主要受限于识别用户是否安装了优酷 APP，用户是否是误点击，或者不像打开观看，时机不对？或者还有个原因就是系统启动太慢，有广告，提前退出了。

• 播放

  播放率，主要受限于播放页的性能和前贴广告，如果前贴广告太长，用户等不及就退出了，没有产生有效的播放，再有就是网络状态 4g or wifi 等等。

• 次日留存

  主要和产品的用户体验有关系。

2. 全方位监控

广告系统的交互各个环节都需要进行详细的监控，才能做到有问题及时发现。

比如突然的消耗上升或者降低，点击率的下降，参与竞价量的下降等等，都需要进行详细的监控，避免资损的发生。

目前建立的监控体系指标有如下：

——总结——

最后在总结下整个 dsp 的建设过程要考虑的点：

• 渠道建设，流量接入

• 投放策略沉淀

• 算法模型发挥推荐优势

• 完善的监控体系

当然本篇文章由于篇幅有限，还没有涉及到 DSP 的另一块核心，流量价值预估和出价算法，这块后续会有单独的篇幅去介绍，优酷的这套体系上线后在拉新和召回上发挥了重要的作用，为用户增长打下了坚实的基础。

参考链接：

1. https://zhuanlan.zhihu.com/p/52237643

2. http://www.swanlinux.net/2017/02/10/papers/real_time_bid_optimization/index.html

3. https://tech.meituan.com/2017/05/05/mt-dsp.html

4. https://zhuanlan.zhihu.com/p/28406017

5. https://help.aliyun.com/document_detail/59480.html

6. https://36kr.com/p/5189571