，各种请求条件的过滤就已经开始，并最终决策其是否能构成广告请求，寻求广告源的响应

广告的展示流程

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

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. 请求的时间间隔：同样是出于用户体验的优化，以及必要的成本考虑，基本上媒体方也会设置一定的请求间隔时间或者展示次数限制，避免在短时间内为用户带来太多的广告干扰。