在前两篇文章《游戏广告变现指南1 - 核心指标维度》《游戏广告变现指南2 - 如何加工流量？》我们介绍了游戏变现重点关注的数据维度指标以及如何有效的将用户流量转化为广告价值。在本文章中介绍如何有效的将用户流量进行售卖变现，分为三个方面：

• 广告变现方式

• 广告变现策略

• 广告变现平台

广告变现方式

从开发者来讲目前存在着以下几种变现实现方式，我们将分别按以下几种方式介绍各自区别以及如何组合。

• S2S

• API

• SDK

S2S

Server to Server, 即服务器对服务器。上游广告主提供带渠道ID参数的链接url2至下游，下游用该链接url2进行推广。简单流程如下：用户产生点击请求时，通过链接跳转至广告落地页；当产生转化行为时广告主回传转化信息至渠道服务器。

该对接方式常见于直客广告主或者广告代理商的对接中，对接方式简单。因为需要人工提供推广链接，所以需要商务人员对接上下游，运营人员针对资源进行优化调控。

注意事项：

• 需要下游搭建广告投放系统，针对直客Offer进行投放优化，在流量发起时筛选最优的广告；

• 回款账期：与直客广告主经常存在账期的问题，在进行资金周转时需要注意；

• 优化效果：存在多个直客广告主Offer时，按照一定的优先级规则来展示直客广告，根据广告主的要求针对点击率/转化率/Ecpm等指标进行优化；

API

媒体方按照接口协议规范规定对接，请求上游广告主服务器进行广告的获取。针对API又细分为offline API 与 online API, 顾名思义：

• Offline API : 下游渠道定时请求上游API接口，定时批量拉取可用offer库资源进行创建或者更新，常见于 Affiliate Network上下游集成中；

• Online API：下游向上游进行实时请求，上游根据请求参数，返回匹配的广告资源。

online API 的对接方式，所下发的广告和投放逻辑均由上游系统处理，下游拿到广告资源进行展示即可，对接简单；但在offline API对接方式中，上游广告主将会批量返回下游可展示的所有Offer，所以要根据用户端的请求决定下发具体的哪个广告，也就是投放逻辑是由下游自己处理的。目前Offline API 市面上相对来说较少，大部分都是实时的online API. 如webeye、Mobvista、avazu、youapi等

注意事项：

• 需要下游搭建广告投放系统，针对上游批量下放的Offer进行管理优化，在流量发起时筛选最优的广告；

• 大部分合作的上下游均为广告代理商，上游的收入来源于直客广告主，所以部分广告代理商也存在回款账期的问题;

• Offline API 对接由于是定时批量获取 Offer 推广链接，当链路中存在多层代理商时经常会出现Offer下架不具备推广条件的情况，所以在入库时需要提前或者定时验证Offer是否有效以及offer的质量等；

• Offline API 在推广时会存在kpi，需要注意Caps /定向限制等条件;

• Offline API /online api存在大量的广告代理商，所以在进行上下游对接时，需要处理好api适配结构，后续在对接时才能更为便利。

SDK

媒体通常与Ad Network 广告网络合作，如Facebook Audience Network、Google Admob、Ironsource、穿山甲等；

在与一家 Adnetwork 平台进行合作时，其请求逻辑简单表述为：SDK 向 Adnetwork 发起广告请求，Adnetwork 进行内部广告检索排序等，返回相应的广告，如下图所示：

但一家 Adnetwork 往往没有能力填充足够高价值的广告，所以需要聚合多家 Adnetwork 来进行广告变现。其请求逻辑为waterfall，聚合服务基于历史数据变现即Ecpm 对 Adnetwork 广告位 ID 进行排序，SDK 按照串行或者串并行的方式依次请求缓存，参照下图：

目前各平台在陆续推广各家的Header Bidding，Bidding为应用内竞价，广告平台会针对每次请求进行出价。

注意事项:

• 选择Adnetwork：针对出海应用来讲，头部变现渠道为Facebook Audience Network与Admob，其余填充为视频流量平台如Unity、Ironsource、Applovin等；同时也要结合自身产品地区补充一些地域性较强的变现渠道。后面将用单个篇幅进行介绍；

• 广告变现聚合系统：好的聚合平台服务可以帮助应用更好的进行变现，如支持的广告类型、A/B Test、广告位运营规则、SDK等，后续将通过单独的文章进行介绍；

• Waterfall & Header Bidding ：waterfall基于历史Ecpm进行排序，Header Bidding会针对每次请求进行实时竞价，那么在进行Bidding接入需要注意哪些问题呢？后续将通过单独的文章进行介绍；

• 无法获悉Adnetwork SDK中针对广告资源的处理，所以无法获取广告素材，但是据说Soomla可以获取除Facebook Audience Network之外的渠道广告资源。有兴趣的可以了解下。

那么在针对以上实现方式开发者进行商业模式构建时，可以根据自身情况选择相应的变现方式。另外如果团队有一定技术实力可以通过RTB 接入程序化广告平台，如AppNexus, Rubicon, Pubmatic 等。

广告变现策略

针对大部分海外开发者来讲通过与 Ad network 平台合作通过传统方式waterfall进行变现。针对 Waterfall 来讲需要针对不同广告场景、不同国家、不同用户进行分层策略，简单如下：

注意事项

• waterfall 建议服务端实现分国家广告展示，根据过去一段时间分国家分广告位ID获取数据进行ecpm自动排序，原生广告优先填充FB辅助google；激励视频以google为主第二优先级请求fb，具体通过ABTEST根据数据进行调整；google对于广告UI以及误点基础要求极高，一定遵循开发者政策 GOOGLE PLAY ：play.google.com/intl/zh；

• bidding:目前包含Facebook、Admob、Ironsource、Applovin、Tapjoy、Chartboost等；其中要使用Admob的ob需要使用其聚合，admob的聚合包含FB的Bidding。Facebook针对开发者提供BK3程序包，适合自建聚合的开发者进行接入，目前包含Facebook、Ironsource、Applovin、Tapjoy、Chartboost 五家Bidding；

• 广告请求：不要在用户进入广告场景时才进行广告缓存，会丧失广告展现时机。针对Facebook 的请求来讲会判断用户是否安装过Facebook APP并近期是否活跃，针对游戏来讲登录Facebook的用户高也会增加一定的广告填充率；

• 拉取缓存：预拉取插屏激励单次1~2次，为串并行请求，当然针对不同广告场景需要区分对待。针对缓存的保留时长不同平台不一样，Facebook建议为60分钟，具体原因可能是缓存提前进行了下放，但等待时间过长在展示时广告主的预算已消耗完毕，所以一般建议设置30分钟有效期，当广告缓存超过有效期时再重新请求；

• 广告展示：在个别广告场景中，用户存在短时间内连续看广告的请求，为了在用户观看广告结束后及时有缓存填充，需进行广告展示关闭后的自动请求；

广告变现平台

在选择合作的广告平台时，优先选择Facebook/Admob, 在补充一些视频流量平台（applovin/ironsource/unity等）进行辅助,最后可以扩充地域性较强的公司。

---    END   ---

作者简介 ：南柯，公众号“南柯say广告”出品人，多年广告系统产品经验， 专注于互联网出海以及广告相关逻辑！关注公众号让增长变现更简单透明！！长按关注！！微信号：r15010033965

博客：http://www.mobistrom.com/