开发者如何实现应用内广告变现收益最大化？
13001广告变现收入一直是维持多数应用和非重度游戏商业可持续的一项重要收入来源，对于所有出海企业都非常重要。
这一期公开课， Chartboost 亚太区变现总监耿钰琳老师通过广告变现历史梳理、头部平台经济模式及优缺点比对等角度来指导出海开发者如何进一步提高自身应用的变现收入。
应用变现历史梳理及当前问题
从 2008 年移动 App 开始变现，当时的变现很简单，能够对接的广告平台也只有 3 家，所以开发者只需要对接广告平台的 SDK 就可以了。之后，每一阶段都由新技术推动。
2013 年，因为 App 对接广告平台的 SDK 越来越多，出现了简单聚合，通过瀑布流来管理广告请求；再后来，在瀑布流上加“分层”功能提高填充率，也就是大部分开发者的现状；到了 2019 年，header bidding 技术在移动端的应用，实现了统一拍卖，让变现收入得到再一步的提升。
简单的瀑布流聚合，就是按照广告平台的历史出价（eCPM）对瀑布流进行排序，然后按照这个顺序向各个平台分配流量，举个例子，广告请求从广告平台 1 到平台 2，再到平台 3，最理想的状态就是广告平台 4 结束之后，App 的广告填充率能到 100%。
2017 年出现了新的配置方式——瀑布流分层。目的也是为了能够尽可能多地获得广告请求。与简单聚合的最大一个区别就是，一个广告平台可以出现在多个不同位置，主要是因为广告平台的出价不会总是相同、也和广告位是否同步等因素有关。FAN 也是“三明治”的架构。就是允许广告平台出现在瀑布流的高中低 3 个位置。
现在多数的开发者都处于复杂聚合的阶段。
虽然相较于第二阶段，复杂聚合能够多次询问同一个广告平台来提高填充率，卖更多的广告库存出去，但是还是有很多问题。
首先开发者无法得知用户层级的价值，虽然使用瀑布流时会对每个广告平台设置一个底价，但这个底价和用户层级关系不大。
其次就是缺少一个统一的行业标准。目前行业内存在三种标准，第一种是设置底价，广告平台的出价一定超过底价；第二种是固定 eCPM，即无论广告展示之后的转化怎么样，这个风险由广告主承担；第三种是 target eCPM，因为没有数据支撑，所以广告平台也不知道流量的确切价值，所以出价就会相对保守。
所以，在 2019 年广告变现进入了第四阶段，应用内实时竞价。和一层一层地去询问广告平台不同，App Publisher 直接把广告库存同时展示给不同的广告平台，由他们同一时间出价。这种方式更公平，同时也需要更多的技术支持。
应用内实时竞价有什么不同？
1、快。因为同时展示广告库存，多个平台一起出价，交易一般在 300 ms 内完成，广告变现的效率也更高，同时省去了竖向瀑布流管理的成本。
2、出价逻辑是不一样的。支持应用内实时竞价的平台，一般都有大量的数据积累，他们甚至知道不同设备的广告价值，也就是实时按照用户的价值来出价（by device）。不支持的广告平台则按照预估的 eCPM，一般是过去 24 时流量的 eCPM 来出价，也就是上面说的出价会相对保守的问题，那也就会影响开发者变现。
所以这两个特点也决定了如果真的能够支持实时竞价，能够最大化自动程序购买（不用去费力设计瀑布流的顺序和广告平台的底价）、最大化竞价规模（竞价更充分），然后第 2 个出价逻辑，也决定 ARPDAU 有可能成为变现标准。
当然新技术的应用和普及肯定是会面临很多问题。
应用内实时竞价技术的普及首先面对的就是市场上熟悉新技术的运营人员不多。其次，目前可参与的竞价者还不够多，即便是市面上一些支持应用内实时竞价的广告平台其实并不具备实时竞价的能力。此外，几家聚合之间的对接计划还没有确定，每个聚合之间其实是具有排他性的，比如说开发者接了一个广告平台，可能发现自己拿不到其他的聚合平台的竞价了。最理想的状态是将所有广告平台放到一起参与竞价。
现阶段开发者如何配置混合模式竞价？
因为技术相对较新，面对一些不确定性，一些开发者会使用混合竞价模式。
其实就是开发者在原有的瀑布流的基础上又加入了应用内实时竞价的模式，然后通过聚合，同时比对两者的出价，价高者得。这是使用第三方聚合。
也有一些开发者会使用自己的聚合，in-house 聚合，通过切流量，也就是一边一半流量来看变现的情况。
在这里，耿钰琳给开发者提出了一些建议。
在使用混合模式竞价的过程中，需要掌握一些要点来更有效地进行配置。首先，要接入所有可以支持实时竞价的主流广告平台。因为只有这样才能将 eCPM 提升到最高，实现收益最大化。其次要保持目前的瀑布流配置，第三并专注于使用 SDK 广告平台来变现，游戏卦广告收入 90% 以上来自 SDK 广告变现。最后可以通过操作 A/B test 来比较不同模式下表现的差异，这时候不要像以往一样看 eCPM，可以看下整体收益。
