开发者广告变现对接广告平台，广告瀑布流是什么？

开发者接入多家的广告源后问题来了，流量该怎么分配呢？同一个广告请求（ad request)到底是该发给Facebook，还是google还是其他人呢？

这时候就涉及到调解平台的算法逻辑了。通常，根据各广告平台的eCPM历史数据排个排序，这个排序就是——Waterfall。

AdSet官网 | 聚合SDK广告变现平台-上海神蓍信息科技有限公司

通常，开发者可根据平台的历史表现，使用估计的eCPM对广告网络进行排名。如果一个网络表现不佳，或者无法完全消耗广告库存，则可以使用备用网络，通过逐层竞价来确保广告获得展示。

瀑布流模式的矛盾点在于平衡效率与效益：既要能找到出价最高的广告平台，同时要让找的过程尽可能的短。

这一过程依靠的不只是经验，还有对广告平台历史出价、自身流量特征和广告价格变化的熟悉程度，变量多，自然难度大。

瀑布流（Waterfall）不足

虽然传统 Waterfall 是一种有效的变现模式，在一段时间内它也为开发者流量变现最大化做出了巨大贡献。但它也存在一些不足，但是随着开发者追求成本效益最优的需求越来越强烈，它的缺点也逐渐显现。

无法选出实际最高出价

当开发者无法针对 Ad Network 的广告位设置底价时，往往会根据 Ad Network 广告位的历史平均数据来估算 eCPM 并调整 Waterfall 顺序。由于通过历史数据预估本次展示的收益，当优先级低的 Ad Network 即使当次出价高也无法得到展示机会。

广告加载耗时长

在 Waterfall 模式中，串行请求会增大广告展示耗时，平均请求一次至少在100ms 以上，多次请求会造成前端展示延迟，用户体验感较差。由于不同广告位的环境不同，用户可接受程度也不一样，需要分广告位设置整体请求次数/超时时间。

维护成本高

开发者要实现精细化的变现运营，往往针对每个广告位都需要维护一套 Waterfall 配置，同时在 Waterfall 的不同层次要设置不同的 Ad Network 广告位和低价，这样将带来运营成本的提高。且由于季节性问题，eCPM 的数值会发生变，需要运营手动维护，成本较高。

以上内容由AdSet聚合广告平台整理发布，供开发者参考～