每天我们无数次拿起手机，每次唤起应用的3秒钟，一个开屏广告则有可能映入眼帘。我们不知道它什么时候出现，什么时候消失……它究竟是如何展现在我们面前的呢？本文将从广告展示的流程，以及背后的请求与缓存机制，来揭开媒体广告的奥秘~

01 广告的展示流程

在打开应用的一瞬间，媒体是如何控制广告的出现呢？短短的几秒钟，广告究竟经历了哪些流程？

1. 广告请求

作为媒体方，当用户打开应用的一瞬间，各种请求条件的过滤就已经开始，并最终决策其是否能构成广告请求，寻求广告源的响应。

值得一提的是，由于媒体方规模的不同，其接入的广告源大概会分为以下几类：

（1）SDK

大部分中小媒体会接入变现渠道SDK，例如今日头条SDK、广点通SDK；或者直接与聚合类的SDK对接，省去分渠道对接的烦恼，常见的有Mopub、Ironsource等平台。

（2）DSP

对于规模较大的媒体方来说，为了拓展收入源，一般会接入竞价量级较强的第三方DSP平台，进行长尾流量的变现，增强变现的效率。

（3）直客/ADX平台

中大型的媒体方，通常会自建商务团队，并提供对应的广告投放平台，以服务于直客群体。

另一方面，也会接入ADX平台，通过将流量分层售卖，并结合多种交易模式（如rtb、pdb等），获得更高的媒体收入。

2. 广告加载及展示

媒体方对于接入的广告源进行询价后，在控制时间内，如有广告源进行响应，则挑选最高的ecpm广告，进行资源加载；如无广告源响应，则加载媒体的打底广告，或者放弃展示。

而在广告加载过程中，会分为2种情况：

• 情况一：本地有广告缓存。此种情况下广告可以直接加载，既能节省带宽资源，又能够加快广告的展示时间，提升用户体验。在用户驻留时间内，广告得到有效曝光，媒体的收益得以最大化。
• 情况二：本地无广告缓存。此种情况下，需要在限定的时间内完成资源的下载、加载动作。你可能会问限定时间是指什么？通常情况下，限定时间=用户驻留时间-1s，即资源下载、加载动作总耗时，应小于用户驻留时间。

当广告终于加载完成，以为可以“闪电登场”的时候，此时用户小手一滑切入别的页面，那么这只辛苦加载的广告只能是无缘再见~

需要注意的是，除了资源的下载、加载耗时，其它情况的出现同样会导致无法曝光。比如，资源下载/加载过程中断网、资源下载失败、资源下载后必填内容不全……这些都会影响最终广告展示的成功率。

因此，除了能否触发请求、是否有广告响应，加载展示也是关键一步，堪称百米冲刺的“最后1米”。

02 广告的请求机制

不知大家有没有留心观察一个现象：我们每次进入应用，一定会看到广告吗？

其实答案是 no ，因为媒体方也会去平衡用户体验，毕竟过多的广告干扰一定会影响用户留存，一旦应用的DAU降低，后续的广告曝光自然也无从谈起~

因此，用户进入应用后，一般会根据媒体方设定的请求机制，来决定是否触发广告请求。

一般请求机制会包含以下几个方面：广告请求的控制条件、触发时机、触发次数、一次请求的广告数量以及请求的方式。

1. 广告请求的控制条件

一般媒体方可通过服务端设置请求的过滤条件，常见的控制维度有：

1. 广告源/广告位：通过是否开启或关闭，来决定是否需请求广告，以及可以向谁请求。
2. 网络类型：通过用户的网络状态来决定是否需要请求广告，以避免无效的广告请求浪费。
3. 地理位置：如可以指定IP范围、国家/地区不进行广告请求展示。
4. 用户群体：比如会员免广告，则不触发广告请求。另外，出于测试等需求，一些设备的品牌型号、产品版本号、系统版本号的也可以设定请求过滤，避免广告展示。
5. 请求的时间间隔：同样是出于用户体验的优化，以及必要的成本考虑，基本上媒体方也会设置一定的请求间隔时间或者展示次数限制，避免在短时间内为用户带来太多的广告干扰。

2. 广告请求的触发时机

依据各广告位不同，广告请求触发时机不同。如开屏广告，可以通过检测应用切到后台再切回前台的行为时，触发广告请求。

另外，需根据产品实际情况判断广告是否要提前加载请求，注意不要过多请求，导致请求浪费。

常见的用于控制广告位预加载的维度有：平台类型、起止时间、资源类型、具体资源等。另外，预加载请求广告的触发时机可以是：后台启动/刷新/进入某一页面，WiFi状态下载或设定时下载。

3. 请求的广告数量

一般情况下，广告请求的触发次数为单次。一次请求可以只请求一个广告，也可以请求多个广告。比如，信息流广告，可以一次请求多个广告按设定的广告位置填，也可以每个位置都请求一次。

这里，主要考虑请求的成本与展示体验。另外，对于媒体方分析来说，则看其如何定义广告位，我们可以将广告位拆为槽位，从广告位、广告位下属槽位的维度来看召回情况。

4. 广告请求的方式

广告请求主要分为串行请求、并行请求，选择何种方式主要考虑自家接入的广告源层数和可接受成本即可。

另外，大部分开发者为了一次接入更多广告源获得更多收益，一般会接入mediation聚合平台，mediation请求主要有3种模式：

（1）WaterFall模式

首先去访问SDK1,如果SDK1没有广告返回，就访问SDK2。依次访问，直到有广告返回。

（2）Fan Out模式

一次请求所有的SDK，选最短时间返回的广告。

（3）Hybrid模式

一种混合模式，即一次全部请求，选最高ecpm广告。

03 广告的缓存机制

用户打开某一应用后，愿意等待加载的时间总是短暂的。

受限于用户的场景停留时长，网络情况、广告资源的类型及大小，如果仅通过下载展示资源，广告的成功展示率将会大大降低。

因此出于提升广告展示率的目的，在请求机制中针对部分广告位提前预加载和使用缓存广告展示已经成为业内常规操作。

1. 广告缓存的控制条件

• 广告源：通过是否开启或关闭，来决定哪些广告源渠道可以展示广告缓存。
• 广告位：确定哪些广告位需要开启进行广告缓存，如开屏广告位。
• 广告创意：指定某类型某资源需要缓存，如视频资源。
• 广告缓存的时机：广告被完整展示后，进行缓存。
• 缓存条数：限制某广告位的缓存数量，减少不必要的缓存累积。
• 对应有效时长：设定缓存自动清除时间，一般为x个自然日或x个小时。

2. 缓存广告展示的触发时机

广告缓存在本地，一般会有以下4种情况触发展示缓存的广告内容：

• 预加载广告：例如，首页列表广告，在开屏广告展示后，触发预加载缓存，进入首页触发展示。
• 命中缓存广告：如某广告源竞得本次广告展示机会，且缓存池已有该广告，则触发展示。
• 打底缓存广告：如无广告源进行广告响应，则优先展示缓存的打底广告。
• 未到请求时间间隔：未到请求时间间隔的情况下，则默认展示上一次曝光的缓存广告。

值得注意的是，一般一次请求对应计一次有效展示和点击，在未请求下基于缓存的内容展示不计入有效展示。因此，对于媒体方来说，可以分别记录统计原始展示、有效展示2个事件的数据。

另外，一次请求对应的曝光，收费最多只收一次。出于评估广告位价值、CTR预估的需求，则可提供统计重复的曝光/点击数据作参考。比如，信息流广告在未重新请求下的重复曝光，同一用户对同一曝光中的频繁点击等。

04 机制的优化

最后，谈一下广告请求与缓存机制的优化。从某种意义上来说，机制是达成目的一种手段，广告机制自然也不例外。

因此，广告背后的请求与缓存机制优化是一个动态的过程，这主要与当前媒体的广告目标有关。比如，当前媒体量级较小，流量质量缺少核心优势，此时目标可设定为提升广告填充率。那么，在请求机制中，将部分流量倾斜分配给填充率稳定的广告源，而非“唯ecpm”论会更合适。

而在实践广告机制的优化中，健全的数据埋点机制比不可少，通过层层过滤分析，我们才能定位问题点，从而寻找对应的优化思路。希望以下2个数据漏斗可提供一定的参考意义：

1. 请求过滤漏斗

根据请求漏斗，我们可以结合媒体整体流量、单广告位流量等维度进行层层刨析，定位流量流失的关键。

比如，因为某类型人群占比过多，请求已被先行过滤，可建议放宽一定的人群限制。比如，我们发现某广告源渠道返回超时现象严重，可先暂停开启某渠道，待渠道优化后再调整等等。

2. 展示过滤漏斗

根据展示漏斗的数据，我们也可以通过优化缓存机制，从而提供广告展示的成功率。

比如，如果缓存过期的流量比重过高，我们可以调整缓存的失效时间范围；比如视频资源，经常出现未下载完的情况，那么我们可以对涉及该资源的部分广告位启动预加载的缓存机制等等。

至于优化的标准终点是什么？这个没有统一的答案，它是基于理想态的永无止境的产品循环。我们需要不断的尝试-验证-优化，以尽可能靠近理想态（当期设定的指标数据）。

我们看见过“无数个”广告，又有无数广告从未有机会展现在眼前。为了用户体验（为了媒体有机会赚更多的 ¥ ），广告展现背后的请求与缓存机制之路，也必将路漫漫其修远，且行且优化~

本文由@Iris 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于CC0协议。