白鲸公开课32期丨广告变现收益最大化开发者必须关注的几个数据

pridecheung • 2020-07-09 21:05

近年来，由于开发者需要接入越来越多的广告平台，对效率的要求也越来越提高，结果导致聚合 SDK 逐渐成为开发者广告变现的重要选择。但是现有的部分聚合 SDK 无法帮助开发者掌握详细数据，这让开发者始终面对数据黑盒，反而容易导致效率降低。对此，本期白鲸公开课请到了飞书深诺战略合作伙伴 TradePlus CEO 王秋实先生，来讲一讲如何利用好聚合 SDK 数据漏斗模型实现广告收益最大化。

广告变现发展的三个阶段

广告变现的发展经历了三个阶段。第一个阶段中，最优先的流量会分给 Facebook、Google 等大型广告平台，然后是 SSP、AD Exchange、DSP，最后会将流量分给网盟。第二个阶段与第一个阶段最大的区别就是除了 Facebook 等大型广告平台以外还出现了很多中型的广告平台。

第一、二阶段广告变现流程

从二、三阶段可以看出整体的趋势是广告平台不断增多，一个开发者想要将流量充分变现就需要接入很多个广告平台，而这给开发者带来了更大的工作量。在这种情况下出现了聚合 SDK，它是一种偏工具性质的广告业务，目的是方便开发者接入到各个广告平台和 SSP 平台中去。

广告变现发展的第三阶段

众所周知，影响广告变现效果的有广告场景数、广告填充率、CPM 三个主要因素，其中广告场景数受到开发者的影响，而聚合 SDK 的作用主要集中于提高广告填充率和 CPM 两个指标。聚合 SDK 之所以能更有效地提高广告填充率和 CPM，是因为聚合 SDK 具有多平台一站式接入、分别运营和自动优化广告源配置的核心能力。

但现有的聚合 SDK 漏斗模型仍存在短板。

聚合 SDK 的出现提高了效率，但是目前来看仍然有一些问题无法解决。从开发者的角度来看，在其变现典型工作流程中的前四步（设计广告场景、制定广告变现的用户范围、申请三方广告平台账户、接入聚合广告平台并配置 waterfall）中，由于开发者无法得到行业内变现效果比较好的产品的数据，所以开发者无法确定采取的变现方案是否是最优的，这是开发者遇到的最大困难。在开发测试阶段，也存在无法确定是否正确调用了广告 SDK 的问题。这个问题很多开发者会忽视，因为广告 SDK 不像工具类 SDK 那样使用周期比较短，广告 SDK 的生命周期伴随着 App 的整个使用周期，所以即便出了问题也不容易测出来。而如果没测出来，则很有可能错失了后面广告展示的机会。

另外，从现有的漏斗模型来看，开发者只能从第三方平台得到请求、填充、展示的数据，数据量少导致很多开发者只能在出现问题后猜测原因，所以现有的部分漏斗模型的结果不准确。而在猜测原因后进入 A/B test 时，开发者也不能对结果准确归因。

现有的聚合 SDK 漏斗模型有较多不足，那么下面看一下更详细的聚合 SDK 漏斗模型是怎样的。

聚合 SDK 数据的影响因素有哪些？

以下是 TradePlus 的聚合 SDK 的框架。可以看到整个过程中要关注的数据指标有用户覆盖率、请求成功率、广告填充率、广告 Ready 率、广告触发率、播放完成率、退出率、点击率。下面对每一个数据指标分析下，去看看影响这些指标的因素有哪些。

TradePlus 聚合 SDK 漏斗模型框架

用户覆盖率

首先是从 App 启动到 App 请求 SDK 的过程中，影响的指标是用户覆盖率。针对用户覆盖率，首先要看一下各个国家的用户覆盖率是否与这个国家的广告投放量成正比。其次就是请求广告的时机是否正确，如果请求过早可能会降低展示率，但是过晚又会导致用户在需要广告时却无法展示广告。还有一个影响用户覆盖率的因素是广告的缓存数，如果缓存数过多的话会降低广告的展示率，从而降低 CPM，但是如果缓存数量过少也有可能影响广告加载的时长。

在 App 请求 SDK 的过程中，也会有几个因素可能造成请求失败，除了可能没联网和没获取 Config 文件以外，还有可能是因为缓存池已经满了，比如已经加载了 5 个广告，但是在这 5 个广告还没使用的时候又加载了 5 个一样的广告，这就造成了重复调用，这样的反复调用可能会导致请求出错。

请求成功率

聚合 SDK 向第三方广告平台的请求成功率受到配置策略的影响。目前主要有串行和并行两种配置策略。在成熟的 waterfall 配置中，为了获得高价的广告填充，高层的底价往往比较高，所以填充率不高，大概在 5% 到 20% 左右。这种情况下如果采用串行的策略，可能会增加广告获取的时间。

在这样的情况下，并行的配置策略似乎更合适。虽然并行的策略对手机性能的消耗稍高一些，但除非处于非洲这种网络环境比较差的地方，否则消耗可以忽略不计。另外很多人担心并行策略下低层展示率低，但其实每个广告会有多次展示机会，所以即便是低层广告也会有不错的展示率。因此，业内会采用“基于缓存数量并行”的策略来请求广告，比如每 5 个广告为一组，这样既不会出现广告过多的情况，也能更加充分地利用好广告数量来降低广告请求的时间。

广告填充率

在三方广告平台返回广告这一步，广告的填充率是衡量指标。三方广告平台经常会有没填充广告的现象，这可能有以下几个原因，首先可能是底价过高导致广告主没有填充；其次就是第三方广告平台出现错误信息的频次过高，这种情况下就要调查一下是程序中存在问题，还是用户本身的行为带来了一些错误。另外，网络超时和未正确集成第三方的广告 SDK 也有可能造成第三方平台没能填充广告。

当然，不论请求成功还是失败，都要关注请求的时长。如果请求成功的话，广告出现的时间点很重要。例如在东南亚这种地区，大量广告要 5 秒才能返回，所以在第 2、3 秒设置广告位就没有意义，反而会给用户增加干扰，所以在这些地区不如把广告出现的时间滞后一些。而如果广告没有成功填充，也要关注请求的时间，因为填充失败所花费的时间会阻碍后续的广告请求，这会对一轮填充所花费的时间产生比较大的影响。

广告Ready率

广告 Ready 率反映的是用户进入广告场景的这一刻，广告准备就绪的比例。这个指标是前面几个指标优化后的结论性指标，所以开发要重点关注。影响广告 Ready 率的因素主要有请求广告的时机、三方广告平台的加载速度、缓存数量、聚合三方平台的数量以及底价是否合理。这里单独说一下缓存数量为什么影响 Ready 率。比如有很多情况下，用户在广告加载完成 1 分多钟之后才进入广告场景，但是随后用户进入广告场景的频率却又很高，这时广告平台来不及加载新的广告，所以第一分钟内缓存好的广告就可以起到作用。

而且广告场景分为两类，这两类场景在准备广告的策略上是完全不一样的。首先是用户停留时间比较短而且错过之后无法返回的场景，比如信息流、复活、签到等，对这种场景如果想要提高广告的 Ready 率，就要采取速度优先的原则，即从限定时间内先返回的广告中挑一个 CPM 最高的展示出来，同时还应该增加缓存广告的数量，让广告的选择多一些。总之，对这种广告场景要采取的原则就是“有总比没有好”。

用户停留时间较短的广告场景

另一种情况，用户在广告场景中停留时间比较长，这种广告场景有充足的加载时间。所以在这种广告场景中，要充分地将 waterfall 跑一遍，选出 CPM 值最大的之后再把广告引导按钮放出来。这种场景最典型的就是战争类和宫斗类等中重度游戏，这类游戏经常会出现激励视频的引导按钮。这些按钮往往不会立刻出现，而是在广告完全准备好之后才出现。

中重度游戏中的广告引导按钮

广告触发率

用户触发广告分成两种，一种是主动的一种是被动的。如果是主动的触发，有以下几个影响因素。首先是用户对广告的喜爱程度。有一小部分用户就是没有看广告的习惯，所以如果能长期观察到用户的这类行为，就可以直接不对这些用户做广告的引导。其次，在使用中对用户的引导是否合理。比如有的时候设置一个很模糊的引导按钮，加上本来操作的选择就比较多，反而会让用户忽略掉引导按钮，这样可能会错失一些真的会对广告内容感兴趣的用户。最后就是激励视频这种形式，激励的金额是否有足够吸引力。因为激励这种模式比较复杂，如果激励金额太多可能影响整个大盘，但是激励太少可能用户又不感兴趣，怎样把控这个平衡点非常关键。

如果是被动的触发，广告的触发率往往跟广告的 Ready 率紧密相关，所以要保证真正有广告的时候才去吸引用户看广告，否则引导用户进入场景之后却没有广告会降低用户的体验。

至于广告播放完成率、退出率、点击率这三个指标，开发者可控制的因素不多，但是也有一些做法可以尝试一下。比如开发者可以在三方广告平台设置黑白名单，对媒体、分类等等做一下设置，便于广告平台的学习。在广告出现时机上，开发者也可以让广告尽量出现在用户使用疲劳的时候，而不是在用户正投入的时候打断他们的使用体验。

32-长图.jpg