当Web端流量主们尝试将他们网站的流量变现时，依照传统媒体的模式，他们直接与广告主们洽谈合作，按时段出售网站内的广告位，这种与纸媒广告、电视广告类似的广告模式被称为

  然而随着网络快速地发展，流量主们很快就发现“品牌广告”模式并不能完全承担网站流量的规模，网站内仍然有大量可用的广告库存没有售卖：品牌广告主更偏爱购买网站内显眼的头部广告位置，而对浏览量较少的尾部广告位置兴趣不大；除此之外，从广告交易的效率来看，品牌广告买断制的交易模式在注重数据精细化管理的互联网下也略显武断。

  种种背景下，一种运用网络技术的全新广告交易方式应运而生——程序化广告。

  基于互联网海量用户数据，广告主能够在不同媒体中追踪用户，有了目标用户的流量动向，广告主们就开始希望可以购买精准流量而不是捆绑广告，从而以数据驱动广告，Ad Network就成为了这种方案的解决办法。

  Ad Network作为广告主与流量主之间的桥梁，从流量主处收集广告资源，然后将广告资源与广告主的流量采买需求相匹配，依靠赚取差价盈利。

  对于流量主，Ad Network能够有效售卖广告库存，尤其是头部广告主不愿意购买的长尾流量；

  对于广告主，Ad Network可以帮助其匹配到适合其预算和受众的广告资源。衍生到移动网络中，Ad Network依然承担如上的中介角色，并且在应用内广告中承担着基石一般的作用。

  应用开发者们将他们的产品接入各家Ad Network的SDK后，使用Ad Network买量的广告主们就能够最终靠这些应用投放广告，来获取他们的目标客户，实现移动应用生态的良性发展。

  一方面，它们扩大着广告覆盖面：各个Ad Network各自的媒体资源组合起来能够覆盖到全球任意一个角落；

  另一方面，它们竭尽全力促成流量主与广告主之间的广告交易：假如没有Ad Network，流量主们就必须与大量广告主们一一协商交易，继而造成巨大的成本浪费，也会极大的降低交易效率。

  一家Ad Network并不能覆盖到全部有匹配广告投放需求的广告主，而这就使得流量主的广告售卖可能并没有匹配到愿意出最高价的广告主，甚至由于没有匹配的广告，发出的「广告请求」也没办法得到有效填充。

  同一个「广告请求」，发送给Ad Network A可以匹配到一条eCPM $20的广告，发送给Ad Network B可以匹配到一条eCPM $30的广告，然而流量主的应用如果只单接了Ad Network A，这次广告展现就只能交由eCPM $20的广告填充，错失了通过这次广告展现获取到更多广告收益的机会；

  更糟糕的情况是应用发出一个激励视频广告请求，Ad Network A收到请求后，由于匹配不到任何广告内容选择了不填充，那这次广告展现的机会就白白浪费掉了。从玩家的视角看，自己明明反复点了观看广告按钮，却迟迟没办法进入广告页面获得奖励，糟糕的体验也许会直接或间接导致玩家的流失。

  意识到了上面讲述的情况的存在，为了逐步提升自己的广告收益，一些开发者开始尝试在应用内集成不止一家Ad Network SDK，通过代码控制向这些Ad Network发送广告请求、接收填充情况以及加载展现广告，从而提升广告整体填充率和eCPM，在提升广告收益的同时也优化了玩家的游戏体验。这就是应用内广告聚合工具的雏形。

  随着越来越多的开发者开始了解并尝试搭建聚合工具，一些互联网公司敏锐的抓住了需求，推出了自己研发的聚合产品供广大开发者使用，聚合工具逐步成为了移动互联网广告行业的新子类。发展至今，全球移动互联网市场上已经有数不胜数的聚合工具供开发者选择，聚合工具也持续为移动互联网广告的良性发展起着积极正向的作用。

  我们先来了解一下聚合工具是如何实现高效广告管理的？这就不得不提到Waterfall（瀑布流）。

  正如它的名字，Waterfall（瀑布流）是指应用在售卖广告时，依照一定顺序（一般为eCPM）由上至下向多家Ad Network请求广告的售卖方式。

  当需要填充广告时，开发者能够在一定的等待时间内，让高价值的Ad Network优先获得填充机会，提升广告eCPM；同时相比传统单一Ad Network的模式，多层请求能够让广告请求触达更多的潜在广告主，提升广告整体填充率。

  了解了Waterfall的逻辑，那么聚合工具是如何通过聚合SDK以及服务器协助大量开发者的呢？

  首先聚合SDK收到指令，需要发送广告请求（指令一般为定时指令或者用户点击触发） ，向聚合服务器发送请求。聚合服务器根据请求内包含的信息，来判断本次请求命中的Waterfall规则，并将该规则顺序返回给聚合SDK。聚合SDK收到Waterfall规则后，按照规则顺序通过各个广告单元向广告平台SDK发出请求。广告平台SDK向广告平台服务器发送广告请求。广告平台服务器收到广告请求后，根据请求内包含的信息判断是否进行广告填充。若广告平台服务器确认填充，则向广告平台SDK返回广告内容。广告SDK通知聚合SDK，广告已准备完成，可以进行广告展示。

  根据聚合工具的开发来源，可以将其划分为「自建聚合工具」「与SaaS聚合工具」两种。

  是由应用开发者根据自身需求，通过内部团队搭建的高度定制化的聚合工具。如前文介绍，这也是聚合工具最初期的模式。

  由于绝大多数广告平台都开放了数据拉取API接口，使得自建Mediation的开发者在广告平台的选择上有很高的自由度，当然这也需要开发者技术团队实力过硬。

  自建Mediation的另一个好处是能实现高度定制化：一方面在广告请求逻辑上可以有更多自定义空间；一方面开发者可以根据自身业务需求制作专属的数据报表，技术能力强的开发者可以将变现数据与其他用户数据直接打通，实现更加精细化的数据管理。

  此外，如果开发者担心自己的变现数据有泄露风险，那么自建Mediation会是更好的选择。

  不少SaaS Mediation都是由Ad Network推出的衍生产品，方便开发者在接入其Ad Network的同时可以有聚合工具来统一管理其他Ad Network的广告变现。

  SaaS Mediation一般都会支持接入市面上的主流Ad Network，并且在接入方式上会方便很多，Mediation平台会提供其支持的Ad Network SDK和适配器的下载支持，也会提供相应的配置文档。

  各家SaaS Mediation的产品功能会尽量满足大多数客户的需求，因此在易用性的方面不用担心，但如果开发者在产品功能上有特殊需求，SaaS Mediation不一定能够拓展满足。成本方面，绝大多数SaaS Mediation都可以免费使用，相比自建Mediation的时间、财务和人力成本，这是其巨大的优势。

  总的来说，自建Mediation适用于开发能力强、对聚合产品的功能有较多定制化需求、关注数据隐私的中大型开发者；而SaaS Mediation则适合没有以上需求或顾虑的各类开发者。

  考虑到出海App绕不开Google Play，建议出海的开发者至少有产品使用AdMob的Ad Network，有助于建立与Google间的合作关系。AdMob还有一个优势是接口开放，任意广告平台只要开发了AdMob Adapter都可以实现聚合。

  Max是由AppLovin Ad Network推出的聚合工具，AppLovin还收购了聚合工具Mopub，并合入Max中。作为一家旗下还拥有Lion Studio等游戏工作室的公司，其Ad Network在游戏类广告的表现很亮眼。个人觉得MAX报表功能的设计学习成本较高，有时看数据的报表项要摸索很久。

  ironSource聚合产品的操作逻辑简单易懂，不需要太大学习成本，即使有疑问它的帮助文档也能解决大多数问题。就中文文档而言，目前不太全。

  Appodeal是一家俄罗斯公司（Logo上的红星就能看出来），主要客户也是中东欧的开发者。

  优点是提供的plugin工具比较全，另外Appodeal也提供部分广告平台的账户，支持直接从Appodeal收款（并且支持虚拟货币收款）。

  中国公司AdTiming推出的聚合产品，主要面向国内出海的开发者，有自家的Ad Network。

  并且OM已经将Mediation代码全部开源，可以帮助开发者快速搭建一套私有Mediation系统。他们的优势是会免费为开发者出海提供相关内容、技术和人员上的支持，并且还会有专属运营全流程服务。

  也是中国公司，主要做国内的聚合产品，出海聚合算是衍生。TopOn的中文文档比较详尽，报表数据维度比较全面，但对于刚使用的新手来说，可能需要花费一定的学习时间去摸索如何查找数据。

  TopOn的优势是做国内聚合起家，在国内出海的市场也占有一定份额，因此有比较成熟的流程体系。

  对各个SaaS聚合平台有了基础认识之后，一个新的问题产生了：如何找到适合自己的SaaS聚合平台呢？作为开发者，应该先从自身的需求出发，判断自己的应用业务是否看重广告收入。

  在如今的海外移动互联网应用内广告市场中，头部AdNetwork们占据了绝大多数广告主的投放预算，尤其像AdMob/Facebook Audience Network，基本能够保证在全球都有不错的eCPM和填充率表现。因此如果你的应用有广告变现的需求，但不看重聚合工具对广告收入的提升，那么单接一家Ad Network已经足够满足你的变现需求。

  相反，如果你看重自己的广告收入，那么挑选适合自己产品的Ad Network以及聚合产品就很有必要了，接下来会以多个维度对常见的海外聚合平台进行分析。

  由于各家Ad Networ对接的广告主不同，在同一个地区，不同的Ad Network的广告表现差异可能会大相径庭。

  因此理论上一个聚合平台支持对接的Ad Network越多，开发者就越有可能通过聚合匹配的Ad Network来提高个人的广告收益。另外，随着慢慢的变多Ad Network推出了Bidding实时竞价功能，是否支持Ad Network的Bidding也成为了一个重要的衡量点。

  A/B Test在聚合广告变现中应该算是一项如虎添翼的功能了，在有多个广告单元的情况下，聚合工具的Waterfall方案可以有无数种排列组合，要去验证一种Waterfall调整方案是否有效，最基础的方式只能是观察调整前后的数据对比效果，但这种没有控制变量的对比方法显然是不严谨的。

  交叉推广指在产品内展示自己其他产品的广告，从而形成产品矩阵内的客户交叉转化。

  玩过Voodoo发行的各类超休闲游戏的话应该对交叉推广不陌生：Voodoo很多产品在首页都有一个固定广告位用于展示旗下其他产品的广告，而不会展示其他Ad Network的广告，这是交叉推广的一种形式，即固定广告位交叉推广，这种形式的好处是能够让产品矩阵获得大量曝光，有更大机会向其他产品导量，但同时也牺牲掉了这个固定广告位创造直接广告收益的机会。

  另一种交叉推广形式则是让交叉推广广告作为常规广告位的广告源之一，即类似于让交叉推广成为一个Ad Network向自己产品的常规广告位填充广告，这样开发的人能自己控制交叉推广内容的展现比例。目前ironSource、Appodeal、OpenMediation、TopOn都已具备这项功能。

  聚合平台的核心功能是提供广告变现相关数据，一般来说用户数据是由三方监测平台或者客户BI进行统计，但前文提到的国内两家聚合平台OpenMediation和TopOn为了方便出海开发者，都提供了不少的用户数据作为参考，例如留存、人均展现频次等。

  用户级展现数据顾名思义，是指聚合平台可以提供具体到单用户每一次广告展现的相关数据，如用户Device ID、用户位置、预估eCPM、预估收入等等，其中预估的收入数据实际上是来自于广告单元在对应地区的历史收入数据，虽然与最终的真实收入会有区别，但能够在一定程度上帮助开发者实现用户的精细化管理，例如评估买量渠道的广告变现质量、与内购数据打通来分析不同玩家的综合变现价值等等。

  在上述我们介绍的聚合平台当中，能够实现用户级展现数据的包括MAX、ironSource、Fyber、Appodeal、OpenMediation和TopOn，而AdMob当前仅支持获取到位置层级的汇总数据。

  如今的应用内广告变现，考虑到In-app Bidding的行业趋势以及聚合产品的变现优势，绝大多数开发者都趋向于选择一款对自己最合适的聚合产品来聚合多家Ad Network，选择单接Ad Network的开发者越来越少。

  各个聚合平台为了抢占优质流量，也纷纷优化着自身的产品功能和服务，这对于开发者来说无疑是好事儿，开发者在选择聚合工具时，也可以多多体验和尝试，并不一定固定在一款工具上，希望以上的内容能够对还在纠结用哪款聚合工具的你起到一定的帮助。