01 什么是In-APP Bidding
首先，在文章最前面，先解释一下什么是In-APP Bidding。
我在之前的文章中有简单提到过这个概念，应用实时竞价的说法除了In-APP Bidding，还有/Advanced Bidding/Header Bidding/Open Bidding等等。
瀑布流和应用实时竞价的区别基本可以用下图来描述：
总结来说，瀑布流模型（Waterfall）开发者需要预先给各个广告平台设置预期eCPM出价，并进行优先级排序。当用户触发广告时，优先给出价最高的广告平台展示机会，如果该平台不填充则会流至出价第二的广告平台，通过漏斗的方式，直到有广告被展示。
应用内竞价（In-App Bidding）通过统一的实时竞价机制，所有的需求合作方在同时间竞价，出价最高的合作方获得该广告位的展示机会。
其实，个人认为总体的差别在于从人工设置竞价策略到由自动化算法直接设置竞价策略转变。
02 应用实时竞价的优劣势由于现在各个广告聚合都在推行应用实时竞价，阐述了它很多优点。个人认为其最大的优点：
瀑布流需要根据历史价格的平均值来设置分层请求的机制，同时伴随季节性变化，需要人工进行定期维护。对于缺少经验的运营人员来说，瀑布流优化可能耗费大量精力，同时也无法实现最佳变现效果。因而对于出海小厂来说，应用实时竞价更利于他们减少人力成本。
相反来说，对于经验较为丰富的运营人员来说，应用实时竞价可能不如瀑布流的效果或者基本持平。
至于有人提出来，手动设置的机制与间隔请求会影响广告的回传速度，而瀑布流中的广告联盟层数越多，广告延迟和无广告返回的发生概率也就越高。这个角度上，主要影响的是50层以上的瀑布流情况，针对层级本身就比较少的瀑布流来说，其本身的效率应该与应用实时竞价相差不大。
此外，应用实时竞价的劣势也是比较显而易见的。当前不是所有的广告源都可支持竞价，比如部分在中低价位表现较好的广告源如Unity。至于长期来看，是否能够推动这些广告源参与竞价可能仍有待于观察。
03 是否需要使用应用实时竞价既然是行业新的变现趋向，所以要不要使用也不能由我们个人选择。比如Facebook Audience Network，IOS系统当前必须使用竞价模式，才可以继续通过 Audience Network进行变现；安卓端5/31日起，新版应用必须使用竞价模式；9/30日起，旧版应用也必须使用竞价模式。
目前从行业趋势来看，未来1~2年来，应该还会以瀑布流+应用实时竞价的混合变现模式为主。
04 使用建议目前各家聚合都在推行自己的竞价模式，每家聚合能够支持竞价的广告源各不相同。Max是最早推行应用实时竞价的聚合平台，相比其他几家，能支持较多的广告源，且技术也相对成熟；而Admob Mediation的特色在于是唯一能支持Admob进行应用实时竞价。选择哪个聚合开始尝试In-APP Bidding，个人还是建议基于自己收入贡献最高的几个广告源及综合成本进行选择。
同时，使用In-APP Bidding还需要注意：
1. 如果广告聚合SDK版本较老，可能会出现不支持Bidding的情况，需要优先升级SDK版本
2. 每个广告平台在不同广告聚合中使用Bidding的操作方式有所差别，具体需要遵循文档
3.如果已经配置了Bidding，就不需要在瀑布流中配置相同广告平台，因为这些广告平台会优先曝光Bidding区域的展示
4.部分广告平台如Unity、Vungle尚不支持Bidding，所以需要参考其历史价格、Bidding区域各广告平台价格，进行瀑布流优化
参考：ARPDAU提升30%，应用内竞价正在成为流量变现的新宠儿
