关于几个主流广告聚合（AdMob.Mopub.ironSource）的一

小提示：您能找到这篇{关于几个主流广告聚合（AdMob.Mopub.ironSource）的一}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的关于几个主流广告聚合（AdMob.Mopub.ironSource）的一内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

< ">广告聚合（Ad mediation）是使用广告做流量变现必须具备的工具，是networks和（游戏）前端的桥梁，游戏发出的请求，会通过广告聚合发给各家networks，并且确保按照运营对networks的排序展示对应network的广告。首先，聚合需要让开发者对networks进行排序；其次，需要安装顺序去尝试请求network，展示返回广告中优先级最高的。

< font-size: 16px;">聚合就像一个广告的云控，因为需要配合让开发者排序的功能，所以配套会有运营操作的后台和报表功能。

< font-size: 16px;">笔者认为可以从以下几个方面评估聚合：

< font-size: 16px;">支持的平台< font-size: 16px;">：< font-size: 16px;">ios，Android，unity

< font-size: 16px;">支持的Ad format：< font-size: 16px;">video,banner，native，interstitials等

< font-size: 16px;">技术接入难度

< font-size: 16px;">广告请求逻辑和缓存数量：< font-size: 16px;">决定了聚合对广告的使用效率，和对产品展示需求的响应能力。目前请求有串行，并行和混合，之前平台为节约服务器成本，多数使用串行（或者控制waterfall的层数），目前有的开始转向混合。

< font-size: 16px;">支持adaptor的数量和稳定性：< font-size: 16px;">network和聚合通过adaptor链接，聚合对接的network越多，对cp梧州小程序m的提升帮助越大。adaptor的升级周期和稳定性，也需要考虑。一般大平台支持的比较多，由于技术实力好和商务合作广。

< font-size: 16px;">BI后台设置：< font-size: 16px;">运营需要在BI后台配置值network的顺序，BI后台的易用性和容错性很重要。由于市场波动，有些大产品的配置是每周甚至每天都需要调整的。

< font-size: 16px;">BI后台报告：< font-size: 16px;">是否可视化，可以细分到哪些数据维度，会影响数据波动时运营对数据的回溯。比如如果能看当天的分小时数据，可以很快查运营的效果，及时避免金钱损失。

< font-size: 16px;">聚合向前端回传的事件：< font-size: 16px;">前端向聚合发出的请求数，聚合向network发出的请求数，请求结果（错误提示细分），请求耗时，loading耗时，展示，展示结果，点击，视频开始播放，视频结束播放。聚合回传事件，有助于troubleshooting。

< font-size: 16px;">是否支持header bidding。

< font-size: 16px;">是否支持S2S广告，支持哪些广告format。

< font-size: 16px;">其他特殊功能。< font-size: 16px;">the last but not the least，特殊功能已经成为聚合近几年产品的重要考虑方向了，也是市场占有率较小的聚合的卖点。特殊功能会增加一些和买量或者产品方面数据联动，帮助开发者更加全面的考虑商业化这件事。

< font-size: 16px;">在游戏开发者中，目前出海几个主流的广告聚合包括：admob，ironsource，mopub，applovin。这几家聚合都支持ios，Android，unity。广告样式也都只支持的很全。

< font-size: 16px;">

< font-size: 16px;">Admob by Google.Admob是谷歌的广告聚合，技术接入较为简单。广告用串行请求，激励视频新出了双例，可以缓存多个广告，或者区分激励广告场景缓存广告。

< font-size: 16px;">支持的adaptor很全，因为有自定义事件（custom event），对于不支持的network，开发者可以自行开发。这个功能十分有用，因为聚合很难覆盖到不同领域，不同地区的所有重点networks。支持的adaptor链接：https://developers.google.com/admob/android/mediate

< font-size: 16px;">BI后台设置较为简单，逻辑简明，不容易出错。报表可以分小时，一些数据可以可视化。肯定不如in-house的报表，但是已经基本够用。回传事件很全面。

< font-size: 16px;">有admob open bidding。

< font-size: 16px;">支持s2s直销广告，视频支持h5，插页支持video等。

< font-size: 16px;">最大优势：< font-size: 16px;">支持network最全面

< font-size: 16px;">其他特殊功能：

< font-size: 16px;">自动优化。通过获取network的reporting api，可以自动排序。但是对于一些渠道，自动优化不是很准确

< font-size: 16px;">智能细分

< font-size: 16px;">如果使用firebase，firebase可以获取admob数据，把产品数据和商业数据对接上

< font-size: 16px;">

< font-size: 16px;">传说Mopub聚合的开发者是前Admob员工，在整体功能和逻辑上和admob相似，但是增加了很多可以让开发者发挥的功能，开发难度也相对大一些，适合对广告技术有一些了解的开发者。mopub BI network顺序设置和admob/adx逻辑上很像，多了复制功能，可以快速复制规则。很多设置可以在list页面或者弹窗页面调整，不用进入二级详情页，个人认为比admob更加方便。但是由于多了group，line的维度，不容易被理解。

< font-size: 16px;">支持S2S,Custom JavaScript network和Custom SDK network。支持自定义S2S(pic,vast video)和online h5广告。

< font-size: 16px;">老后台的报告维度很少，因此mopub和metamarket合作，可以在meta看数据，meta是我用过最好用的报表，速度快，可视化强，方便看对比数据。新后台维度已经很细致了。

< font-size: 16px;">回传事件有到展示维度的line item的价格。这个很6，大家可以自行发挥想象优化配置。

< font-size: 16px;">特点：< font-size: 16px;">拓展性很强，适合要深度做商业，或者有一定商业技术基础的开发者。

< font-size: 16px;">最大优势：什么网站免费发布信息< font-size: 16px;">waterfall可以细分无数层；回传事件有到展示维度的line item的价格

< font-size: 16px;">

< font-size: 16px;">Ironsource聚合。IS是一家以色列公司，广告聚合很别致，有很多标新立异的地方。首先是请求方式，IS用串行加并行请求，每次请求两个广告。并且缓存两个（有一个是IS自有广告来源），包括激励视频。这样，如果你的有用户需要连续看激励视频的场景，这个逻辑可以帮助提速loading广告（同admob双例）。

< font-size: 16px;">支持的network不如前两者多，没有custom event给开发者自行开发。

< font-size: 16px;">对于BI后台设置仁者见仁智者见智，有运营说很易用，但是也有运营认为很容易出错，缺少设置失败的错误提示。并且由于network的id和顺序不在一个界面设置，配置单设置方便的同事也容易出错。对一些network必须从default开始请求，配置容易出错。

< font-size: 16px;">BI报表界面对于整体数据表现十分清晰，但是设计不太便于细分数据和数据对比。优势是有DAU维度的数据

< font-size: 16px;">活跃用户，The number of active users–this allows to optimize the ad frequency

< font-size: 16px;">The number of“engaged users”–these are users who engaged with the rewarded video(opted in)

< font-size: 16px;">不支持headerbidding，不支持S2S。

< font-size: 16px;">有uar功能，帮助在不需要开发的情况下，更准确估算用户价值

< font-size: 16px;">最大优势：< font-size: 16px;">接入简单；report到dau维度

< font-size: 16px;">其他特殊功能：< font-size: 16px;">UAR；交叉推广

< font-size: 16px;">总结。< font-size: 16px;">广告聚合没有最好的，只有最适合自己的。各家的功能有差异化，但是都不影响基本的需求，如果对流量变现有很复杂的需求，建议还是自建聚合。

< font-size: 16px;">笔者做过关于聚合在某一个产品上的同期的效用测试，产品本身广告频次较低，用户看广告间隔长。

< font-size: 16px;">在同样的配置下，在人均展示和arpu这些产品商业关注的关键指标上，没有太大区别。

< font-size: 16px;">但是由于聚合的请求机制不一样，人均请求和展示率会有所不同。

< font-size: 16px;">以下是激励视频场景的举例。a b分别代表一个聚合，a组是混合请求模式，有备胎逻辑，可以看出缓存很多，但是使用率（展示率）会折损。

< font-size: 16px;">

< font-size: 16px;">如果由于支持的adaptor不同，配置不同，b组在top level多配置了一个network，可以看出b组人均请求减少，具体是在低cpm的层级请求减少。

< font-size: 16px;">

< font-size: 16px;">

< font-size: 16px;">另外，由于聚合是通过获取network回调来判断，所以需要对比network统计和聚合统计的discrepancy。如果获取的数据不正确，waterfall的正常运行肯定受到影响。

< font-size: 16px;">性能方面也需要考虑，比如，请求-展示的耗时。

< font-size: 16px;">最重要的还是对自己产品的理解，和对产品数据的分析。

< font-size: 16px;">比如对于以下这样，展示集中在第一次，展示间隔长的产品，也没启动后就需要展示广告的广告场景，对于性能各方面的诉求不高，主要看对cpm的帮助。

< font-size: 16px;">

< font-size: 16px;">选择聚合要根据自己的产品情况和聚合的特点来匹配，对于广告场景不复杂的产品，通过了解聚合的逻辑，和产品流量变现的需求，基本可以选择合适的聚合，不一定需要测试所有聚合。同时也需要考虑自身广告技术能力，因此没必要跟随头部产品选聚合，聚合只是个工具，关键是怎么用。

< font-size: 16px;">以上均是出于产品维度的考虑。