图文广告引擎系列1：闪屏广告投放技术概览

1闪屏广告概述

闪屏广告是在应用开启时加载，展示一定时间后自动关闭并进入应用的一种广告形式。闪屏广告在整个屏幕展示，广告素材内容丰富。

Figure1腾讯新闻客户端闪屏广告示意图

目前腾讯品牌广告旗下的闪屏广告同时支持CPD与CPM模式售卖。在CPD模式方面，我们将闪屏广告位的库存拆分为多个轮播，广告主可以购买闪屏广告位的一个或多个轮播的库存。同时，为了保证用户体验，我们尽量降低相邻两次展示相同订单的概率。在保证了CPD订单播放的前提下，我们同样支持订单的CPM售卖。基于一整套曝光反馈、库存预估和实时决策的机制，我们很好地保证了CPM订单的准确播放。

图文广告投放引擎在这一复杂系统中，承担着订单检索、过滤、概率决策与实时反馈的任务。我们在实现闪屏订单的投放过程中遇到了一系列问题，我们通过梳理这一系列问题的解决方法，能够基本阐明闪屏广告投放中的主要技术。

随着目前智能手机的屏幕尺寸越来越大，闪屏广告素材所支持的分辨率也越来越高，导致广告素材体积显著增大，并且闪屏广告支持静态图片、动态视频、flash动画等多种素材，导致下载广告素材的耗时显著上升。然而为了保证用户体验，APP对启动速度要求很高。

我们采取了提前下发订单素材，播放阶段实时决策的方式，既为广告素材下载提供了充足的时间，也保证了APP的迅速启动。但这种机制存在几个问题：

1）预加载广告用户覆盖率不足。例如，一部分用户在广告订单A的预加载时间内并未打开APP预加载该订单，那么这部分用户在订单播放时间内的库存就是不能被利用的。换而言之，如果订单预加载的覆盖率不足，就有可能导致广告订单不能达到其预定的曝光量，面临着违约的风险；

2）CPD订单轮播计算。在预加载的情况下，如果要保证CPD订单的按量播放以及轮播性，需要生成CPD订单循环播放的序列，同时需要按用户当前播放进度决定当前下发用户的子序列；

3）CPM预加载量控制与实施决策。保证CPM订单按预订量播放的前提之一是，实时监控播放进度从而精确控制CPM订单下发的概率。然而在预加载环境下，订单下发的时机在播放之前，也就意味着在订单下发阶段不能得到播放进度的实时反馈。

我们在解决上述三个问题时，1.首先研究了预加载时间与用户覆盖率的关系，确定了合适的预加载时间，以保证预加载覆盖率能够满足订单按量播出；2.参考负载均衡领域的加权轮询算法，通过用户本地或云端存储的用户轮播值，实时计算CPD订单轮播序列；3.缓存用户当前加载订单的状态，根据有效预加载量的实时反馈对订单的下发进度进行控制，同时在实时决策阶段根据曝光量反馈，对播放进度进行精准控制。

2预加载时间与用户覆盖率关系研究

2.1问题描述

假设，我们决定在订单投放时间D的前k天对订单进行预加载。如果用户在这k天内都未能预加载订单，则该用户在D的首次曝光就是一次无效曝光。根据我们对历史数据的统计研究发现，某些APP的日PV/UV较低，这就意味着用户每日的首次曝光在每日的库存中占了较大的比重。所以我们有必要研究如何确定一个合理的预加载天数，让用户每日的首次曝光转化为有效曝光。

2.2建模分析与数据验证

我们从简单出发，假设用户每日能否成功预加载订单是独立且同分布的。设用户每日能成功加载订单为随机变量X, X服从如下概率分布。

即用户每日未成功预加载的概率为q。则用户在k日内皆未成功预加载的概率是

。则设k日内成功预加载的用户数为随机变量N，服从泊松分布

令总用户量为M，则。

Figure2预加载时间与覆盖率关系(q=0.5)

通过泊松分布的假设检验，我们认为当前统计到的数据服从泊松分布。从而针对不同的APP，通过历史数据，拟合泊松分布，得到多个APP对应的q值，进而得到了多条类似图1的曲线。

根据分析上述模型，可以得出当覆盖率大于某个值时，即可提供足够的有效库存。于是我们既可以划定一个固定的预加载时间，满足各个APP的预加载覆盖率需求，也可以根据不同的APP灵活调整预加载时间。

3CPD订单的序列计算与轮播控制

3.1问题描述

CPD（Cost-Per-Day）模式售卖的订单是以固定价格买断一段时间内某个广告位的展示。通常为了降低广告主的推广成本，我们会将闪屏广告位划分成多个轮播，广告主可以购买一个或多个轮播。为了进一步优化闪屏广告的展示效果，我们在闪屏广告位推出了轮播CPD闪屏广告，即，尽可能地轮流播放不同的广告订单，维持较好的用户体验，提升闪屏广告展示效果。

这就面临两个问题：1.计算由多个不同包断比例订单构成的订单播放序列；2.订单播放序列可能超出了前端存储容量，需要记录播放进度来计算本次下发子序列。

3.2加权轮询算法

同一个广告位可能会被多个广告主购买，每个广告主购买的轮播比例也不尽相同。我们借鉴了负载均衡领域的加权轮询算法，利用该算法计算订单的播放序列。

该算法原理如下：

假设该闪屏广告位上有N个订单，对每个订单都有两个权重变量：

，每个订单的播放权重，这个值是固定不变的；

，每个订单当前的权重。初始化为0。

(1) 每轮计算时，遍历数组中所有订单权重。对于每个订单，让它的；同时累加所有订单的，并保存为total。

(2) 遍历完所有订单之后，选取最大的这个订单作为本轮计算选中的订单填入播放序列。然后把该订单的减去total,。

(3) 循环执行(1)(2)，直至所有订单的均为0.

例如，有三个订单a，b，c，其播放权重分别为4，2，1。执行一遍该算法的过程表示如下：

得到的播放序列为[a, b,a, c, a, b, a].该序列既保证了按订单权重进行了播放，同时也保证订单之间的轮播性。

3.3轮播控制机制

由上一节计算出的播放序列，其长度取决于轮播划分精度以及订单权重的最大公约数。但由于前端APP存储的限制，在播放序列较长的情况下，我们不能向前端下发完整的播放序列。如果我们能够记录当前用户的播放进度，理论上我们仅向其加载下一次播放所需的订单即可。但是考虑到离线播放、网络失败等原因，我们还是会向前端下发一个长度固定的订单序列，这个序列是完整播放序列的子序列。

用户的播放进度可以由一个整数playround来表示，每当播放一个订单时，playround自增1. 在决定下发的播放子序列时，先计算出播放序列的完整长度len，再对playround以len求余数rot，rot即为播放子序列的起始位置

playround可以由前端维护，在每次请求时告知后台，也可以将轮播值存储在云端，由后台进行维护。

Figure 3 playround控制播放子序列起点

4CPM订单播放控制

闪屏广告在支持CPD售卖方式的同时，也支持更为灵活的CPM（Cost-Per-Mille）售卖方式。为了保证CPM合约按量执行，在投放引擎一侧的核心要素就是按照预定量和预估库存联合计算出的播放概率进行广告投放。而对于采取预加载模式的闪屏广告，情况就更为复杂。由于订单的下发时间在播放时间之前，不能通过曝光反馈对订单的下发概率进行实时控制。我们通过采取以下几种措施对CPM订单的播放进行控制。

4.1预加载的反馈控制与播放阶段的实时决策

对于常规CPM订单的播控流程：首先由算法实时控制模块根据当前订单的执行进度以及剩余库存计算出订单当前的播放概率并分发至投放引擎，然后投放引擎根据播放概率下发订单，订单发生曝光时由曝光服务进行收集后上报数据服务，数据服务将订单的曝光情况实时反馈至算法实时控制模块，由此形成一条反馈控制闭环。如下图所示

Figure 4实时反馈控制闭环

而对于预加载模式的广告，订单曝光的时机是在订单下发时间的多天之后，无法进行实时反馈控制。一种解决办法是在订单预加载时下发该用户的所有可能播放订单，在播放阶段将已预加载的订单集合上报至投放引擎，由投放引擎进行实时决策。这种模式在理想情况下是可行的。但是在工程实现过程中出现了几个问题：1.对于某用户的可播订单集合可能过大，前端不能支持存储这么多的订单素材；2.由于网络失败、用户离线播放等因素影响，前端上报订单集合至投放引擎的实时请求，在全局存在不可忽略的失败率。目前前端的逻辑是，如果实时请求失败，前端就会在目前已加载的订单中顺序选取一个进行播放。在这种情况下，如果预定量较低的订单与预定量较高的订单以相同概率进行预加载，将导致预定量低的订单的播放概率被扩大。

于是我们在订单预加载阶段，也采取了一套基于订单下发的反馈机制。首先我们维护所有用户当前预加载订单的情况，并记录每个订单的预加载量。如下图所示

Figure 5订单预加载情况记录

因为前端在每次预加载后，就会更新存储的订单序列，这就要求每次向用户下发订单后更新用户-订单这一个表中用户对应的订单集合，同时根据每个订单的增减维护订单-计数这一表中订单的计数。通过这种方法得到准确的订单预加载量，根据订单预加载量转化至曝光的比例，合理控制预加载量。

而在前端展示闪屏广告之前，会将当时可播的订单集合上报至投放引擎，由投放引擎对订单的投放进行实时决策。而这一实时决策过程可以由曝光实时反馈的数据进行控制，与Figure3中描述的控制过程类似。这样，闪屏的播控流程就由两个控制环路进行控制。

Figure 6预加载与实时控制

4.2上报订单决策过程诊断信息

以上这一套控制机制，就可以基本保证闪屏广告CPM订单的准确执行。为了衡量与监控这一套机制的运行情况，我们上报了一系列的诊断信息，形成几个关键的监控指标进行衡量与监控。

订单的预加载量

因为订单的预加载量与订单最终转化为曝光的曝光量在全局上有一个较为固定的转化率。如果在订单播放后发现订单发生超播或者缺量，从预加载量就可以看出是因为预加载阶段的控制存在问题还是实时决策播放阶段出现了问题。

2. 预加载有效率

在实时决策过程中，如果前端上报的预加载订单集合中所有订单在当前条件下均不可播放，投放引擎会告知前端不播放订单，并上报一个空单。那么导致空单的原因就有两种：一、当前对于该用户无可播订单；二、预加载订单集合中无可播订单，但有可播订单并未在预加载阶段下发。第一种情况即为该用户的库存未被预定，那么上报一个空单记录库存即可。但第二种情况则表示我们在预加载阶段下发订单过程中存在不合理因素，导致这一个用户的库存发生了损耗。我们需要优化各个阶段的流程与算法，提升订单预加载的有效率。

4.3A/BTest实验及结果

我们对闪屏流量进行了A/BTest试验，实验组为采用上述实时反馈控制逻辑的流量，对照组为未接入实时控制的流量。观察指标为这两组流量的空单率以及预加载有效率。如下图所示

Figure7 A/B Test空单率与预加载效率（蓝色实验组，黄色对照组）

综合全部实验时间来看，实验组的空单率比对照组降低了24.8%，预加载有效率提升了26.3%。

可以看出闪屏CPM订单播控采取实时反馈控制逻辑，能够有效降低闪屏空单率，提高了预加载效率。

5结语

我们在提出并实现闪屏广告的解决方案的过程中，基本解决了在预加载情况下投放广告的问题，保证了CPD、CPM模式广告的投放。我们还可以进一步精细分析用户的行为，对用户行为合理建模，更精细化地定制预加载方案，以求提高预加载的效率。同时尝试下发更少的订单，以减少用户流量的消耗，减少对设备内存空间的占用。