把广告聚合做简单，为什么对开发者很重要？

计算广告

2年前

【摘要】：移动互联网的开发者们还是大有可为的

上文书说到，即使在行业低迷的今天，只要找准赛道、善用变现平台，移动互联网的开发者们还是大有可为的。

不过今天的流量变现，傍着一家平台靠天吃饭，已经远远不够了。开发者都会脚踩几只船，把常用的SDK都集成起来，以获取最大的收益。这就是大家都熟悉的“聚合”模式。

聚合多家的SDK，除了繁重的开发测试，还有一大堆压力山大的优化等着你：要给用户看广告，是让A平台出，还是让B平台出，我挣的钱更多呢？由此展开的一套复杂的Waterfall流程配置(见后文)，对变现者的开发能力与运营经验，挑战都很大，甚至令人望而生畏。

于是，市场上又出现了SDK向媒体实时出价，以价高者得的方式决策的Bidding模式。从工程上更便捷、使用门槛更低的角度来看，Bidding是大势所趋。可是如何科学地从原有稳定的瀑布流模式向Bidding模式过渡，这对变现者提出了新的挑战。

总结起来，开发者使用聚合模式的两大挑战：一是Waterfall的运营配置相当复杂；二是新的Bidding模式从了解到熟练掌握的过程。

市场上也出现了帮开发者解决这些难题、实现丝滑变现的“聚合平台(Mediation)”。我观察这个市场，已经有一段时间了，一直想找一些典型产品，跟大家聊一聊。

大约一年前，穿山甲发布了自己的聚合平台GroMore，以开放的模式支持开发者聚合多家SDK，提升变现水平。GroMore经过一年的运营，接入的帐户数一年翻了6倍。这个产品的核心理念之一，就是让零基础的开发者也可以顺利使用到聚合。GroMore是如何做的，值得说一说。

独具特色的半自动瀑布流运营

瀑布流模式是怎么回事，配置起来又为什么这么复杂，咱们先得多说两句。

假设一个开发者想找好几个平台给自己的广告流量变现，所以他用SDK方式接入了A、B、C三个广告网络，那么先向A发请求，如果A没有返回，再向B发请求；B没有再找C。由于无法直接比较各家的广告价值，这种一层层要广告的流程，就叫做瀑布流(Waterfall)模式。

A、B、C三个平台的排序谁先谁后？一种排序的办法是看历史数据，过去谁给的钱多谁就在前面，另一种办法就是做“分层”，像过筛子一样把流量按照底价做区分，然后一轮一轮找下去，最后找到价格区间内出价最高的那一个。

瀑布流优化的矛盾点在于：如何追求效率与效益的综合最优解，既要能找到出价最高的广告平台，同时要让找的过程尽可能的短。而这一过程依靠的不只是经验，还有对广告平台历史出价、自身流量特征和广告价格变化的熟悉程度，变量多，自然难度大。

因而多层瀑布流的聚合优化模式，对一个专业的游戏或应用开发者而言，除非团队很大人力充沛，否则自然会望而生畏。这就解释了咱们说的第一个问题：为什么瀑布流模式的聚合，需要更自动的工具

GroMore的产品体系在这方面是下了很大功夫的，拿出了一套半自动瀑布流配置的运营流程，分为三个部分：初始化、诊断和测试。

在开发者接入了GroMore以后，不用担心瀑布流运营经验，系统会根据是相关行业的数据积累，自动推荐初始的配置方案。这主要用于应用或广告位冷启动时，可以大大减少人工配置的经验成本和失误成本。

GroMore提供标准版和精简版两种初始配置，其中标准版适合有一定聚合平台使用经验、追求更高变现水平的开发者，而精简版则做了代码位精简，进一步降低技术门槛，特别适合新手开发者。

把瀑布流配起来，才是长征走完了第一步。如果数据不好呢？这时候没有经验的开发者，可能会一头雾水，不知道从何下手来优化。对此，我特别推荐大家使用一个好用的功能：诊断工具。我用下来的体会，这个工具提供了非常便捷的自动诊断能力。

这个工具，对瀑布流的填充率、展示率、设价提供问题诊断，并给出相应的改善建议。比如说，系统发现某个位置的展示率<60%，那么常见的问题有两种，一是层超时时间过短，二是没开预缓存。根据数据上的预警和环境的检查，系统可以给开发者可能的改进方案。大家看看下面这张图，可以对问题诊断功能有直观的感受。在跟开发者的交流中，我发现这个功能给他们的变现优化提供了巨大的便利。

有了问题改进的建议，也不能贸然上线。在科学的工程原则下，要通过分流量实验得到可信的结论。而实验框架，对自研聚合产品的开发者来说，往往是个过不去的坎儿。如果用GroMore的话，事情就简单了：上面一步给出了问题诊断和建议，开发者做出调整的决策后，可以一键进行A/B测试，得到结论后再推到全量。这个功能不用多说，有经验的变现变现负责人，自然了解它的巨大价值。

有了自动初始化、问题诊断和A/B测试这三板斧，各种复杂的瀑布流运营和优化问题，基本上被一一化解了：开发者只要跟着系统的建议，鼠标一步步点下去，偶尔做一下选择判断，就可以吃着火锅唱着歌，把聚合变现玩转起来了。这样的易用性，让我印象深刻，也是决定写文章介绍一下的最初动机。

说个我知道的例子：Ohayoo休闲游戏矩阵采用瀑布流模式变现，通过高频调整分层和设价，提升变现水平。但是，探索不同配置策略并验证效果，一来极其耗时耗力，二来很快遇到天花板。这时， GroMore的诊断工具给他们带来了惊喜。

诊断工具发现，Ohayoo某款游戏的广告填充率明显下滑，并且直接定位给出了明确错误码，还提供了推荐的配置。这使Ohayoo团队排查问题的成本大大降低，甚至无需技术介入，就找到了解决方案，并用一键A/B测试上线实测效果。

在综合应用GroMore提供的系列辅助工具以后，Ohayoo广告变现的ARPU值提升了14%，收益提升30%。

Bidding模式的引入与效果

前面咱们说了，瀑布流是传统聚合模式，相应的复杂配置也是无奈之举。而市场的大方向，毫无疑问是Bidding模式。

Bidding模式的关键改变，是聚合中的各SDK要在每次请求时不仅给出广告，还要给出出价。它的流程如下图所示。不用多说，就拿这个图的简洁程度跟上面比一下，就知道它的运营难度会大大降低，同时变现水平也会稳步提升。

相比传统的瀑布流模式，Bidding 有一些比较明显的优势：

收益最大化：Bidding模式中，“实时价高者得”可以保证每个广告请求的价值最大化。从行业数据看，它比传统瀑布流收益可提升3%~19%；

填充率更高：一次性实时返回价格，填充耗时更短，大大降低超时导致的流量浪费。据测试，使用 Bidding 模式后，整体填充率普遍达到90%以上，超时时长缩短10%以上；

运营更高效：实时竞价交易，免去了日常高密度的瀑布流调优工作，减少了运营人工投入，帮助开发者节省更多时间来开拓和优化产品，提升整体业务成效。

凭借高人效、高填充和最大化收益等优势快速成为业内领先移动开发者的重要变现手段，从开发者利益最大化的角度来说，bidding将是未来广告变现的大势所趋。

这个模式虽有诸多好处，挑战也很清楚：一是要实时处理各SDK的出价，并完成比价；二是很多开发者并不能接受一夜之间从瀑布流全部切换到竞价，这也不符合灰度上线的工程原则，于是瀑布流和Bidding并存的优化，会长期存在。

GroMore对Bidding模式的产品态度，认为Bidding自然是未来的大势所趋，但也清晰的认识到了「两种模式共存」的长期市场现状。一方面，以对开发者透明的方式提供Bidding模式的选择，支持接入各家变现平台的基础能力；另一方面，提供瀑布流+Bidding混合的产品模式，并提供相应的运营辅助能力。

在Bidding模式上，GroMore的最大长处仍然是易用性。除了操作上的便捷性，它的产品特色是可以在不改变原有瀑布流配置的情况下，直接增配一个Bidding代码位，这样用极低的操作成本，就可以快速把Bidding功能用起来。

而且，这样配置起来的瀑布流+Bidding混合模式，可以通过灵活调节两者的流量占比，无缝地从旧模式向新模式过渡。当然，如果某些开发者有顾虑，无论是出于收入规模还是自身发展的打算，都可以随时调整混合模式的占比。当然，这一切都是在A/B测试框架的支撑下，根据数据作出的结论。

应该说，在GroMore的支持下，开发者完全不必把Bidding看成一种全新模式，如临大敌，只要把它看成原有瀑布流模式的一次自然进化就好了。

比如我知道一家游戏厂商，微鲤科技，一直用的是GroMore的瀑布流模式变现，经过长期磨合，变现水平比较稳定。然而，随着他们旗下的游戏越来越多，情况原来越复杂，瀑布流的运营成本和优化难度越来越高。在Bidding模式推出以后，他们很快在线上以瀑布流+Bidding的方式开始尝试，并且非常顺场地找到了两者的最优结合点。从整体数据上看，广告的填充耗时降低76%，填充率提升89%，ARPU和整体收益分别提升26%和27%。而这一切，只在GroMore的后台点几个按钮，就做到了。

其他

除了半自动的瀑布流优化和混合Bidding模式这两大特色以外，我还注意到，GroMore建立了相当完备的自助服务体系。比如，完备的帮助文档，有大量视频课程的成长中心，特别贴心的是，平台还提供了入门级的checklist，提供全局的新手引导，并在关键操作界面配备相应视频教学。我跟了一下整个流程，基本上可以在无人指导的情况下，自主完成整个变现体系的搭建。