TopOn唐子丹：善用数据分析，把握游戏赛道广告变现良机

由 hreo_123 · 2021年1月20日

12月10日，由罗斯基联合TopOn、钛动科技共同主办的《游戏赛道新机会》主题系列沙龙在武汉举办。活动邀请了国内外多家业内知名公司的负责人到场分享，现场嘉宾分别从自己擅长的领域出发，通过数据分析，案例复盘等多个维度方向进行讲解与经验分享。

在活动上，TopOn CPO唐子丹带来了《解析关键数据指标，提升游戏广告变现价值》主题分享。广告变现正在逐渐被更多开发者所接受并使用，那么影响广告变现的因素有哪些？如何解决这些问题呢？

一、游戏赛道广告变现规模预期与分析

下图数据是2019年1月-12月，全球下载量和月活用户排名前1000的游戏中，广告SDK的安装份额从83%增长到89%，可见越来越多开发者开始使用广告变现。

在用户支出排名前1000的游戏中，有67%安装了广告SDK，广告已成为内购之外最主流的变现方式。

那么加入广告后会带来怎么的影响呢？下图黑色部分为下载量，红色是月活数。横轴是时间线，纵轴是安装广告SDK前后3个月的对比数据。可见，游戏在首次安装广告SDK后，下载量和月活都有明显增长。

此外，安装广告SDK后，游戏的用户使用时长也有明显提升。

可见，良好的游戏内广告设计，不会造成用户反感，还能提升用户的使用时长。国际数据分析公司IDC指出，2019年全球移动游戏内广告收入近 200亿美元，比2018年增长40％。移动游戏广告变现收入以每年26％的增速增长，是IAP和付费手机游戏的支出增速6.2％的四倍。

二、评估广告效果的关键指标

填充率和eCPM是评估广告效果的两个关键指标。填充率 = 广告返回成功数 / 广告请求数，eCPM = 广告收入 * 1000 / 广告展示数。这里有几个需要注意的点。

不同平台统计数据的方法不同。比如激励视频的展示，有些平台是以视频开始播放为统计节点，有的平台以视频结束播放为统计节点。这两者大概有1%-5%的差异，这种情形下直接对比广告平台变现表现就不太公平。TopOn采用一种相对中立的做法，激励视频通常支持查询广告状态，通过在播放前检查一下广告是否可播，如果能则正常播放，并记为一次展示。这样就不用完全依赖广告平台提供的展示回调，实现所有平台统计口径的统一，数据对比也相对公平一些。

关于广告填充率，每个广告位置设几个无底价广告源，有助于整体填充率的提升。另外可以用交叉推广做兜底填充。

最后是提升eCPM。这里有一系列优化策略，后边会详细介绍。

第二组要说的指标是渗透率和人均展示。渗透率 = DEU / DAU，即观看过广告的设备占比，人均展示 = 广告展示数 / DAU，或者广告展示数 / DEU。

这两个指标经常会一起谈论，有两个注意事项。一是良好的广告场景设计非常重要，可以大幅提高渗透率和人均展示。二是如果用户进入到广告场景，那就要想尽一切办法让广告能展示出来。

先说一下广告场景设计。游戏中最常用的广告样式是激励视频，插屏视频和banner。我重点讲一下激励视频，这里给两点建议：

1、激励视频的观看入口不要太深，因为它是用户主动触发的。用户不点的话，广告是不会展示的，因此得让用户很清晰的看到点击入口，并且UI最好符合游戏本身的风格，不要过于突兀。

2、广告场景要尽可能合理。激励视频是带有激励性质的，用户知道看完广告可以获得奖励，所以奖励的内容要对用户有吸引力，用户没有兴趣就不会看了。介绍一些常见的激励视频广告场景，如奖励翻倍，复活，解锁关卡等。良好的广告场景可以提升用户体验和使用时长。

对于插屏视频和banner来说，通常是强制弹出，所以用户触达率很高，但要控制展示频次，避免过多干扰用户导致留存下降。

接着是广告展示成功率，简单来说就是让广告在用户观看之前能够加载成功。一些游戏的广告展示频次非常高，尤其是一些网赚游戏，可能人均观看20-30次，甚至更多。并且用户观看广告的间隔很短，那如果用户想看广告但广告还没有加载好，这就错过了展示机会。此外，waterfall层数越多，加载时间往往越长，错过展示的可能性越大。

下面是一个合作开发者的示意图，可以看到有40层广告源，整体的填充率达99%。但是我们发现，广告展示成功率只有70%+。我们分析后发现：产品的广告加载时间特别长。从游戏向SDK发出请求，到广告返回成功，这个过程在40秒以上。

这是什么原因呢？我们发现开发者头部的广告层填充率很低。从SDK发出请求，到广告平台反馈回调，告知没有填充，整个过程耗时一般在几百毫秒到几秒不等。可以想象，如果到20层才有填充，可能20秒已经过去了。在这20秒期间，用户想看广告，广告是展示不出来的。

针对这种情况我们有一些优化建议。

第一，撤掉填充率很低的层。这种广告源的填充率很低，所以展示会很少，带来的收益也少，但会增加广告请求的耗时。

第二，采用并行请求策略。串行请求是先请求第一层，没有填充后，再请求第二层，依此类推。并行可以几层一起请求，比如前三层同时请求，若这三层都没有填充，再请求后三层，这样可以大幅提升加载的效率。当然并行条数并不是越多越好，并行数量过多可能会影响网络加载带宽，一般不建议超过5层。

第三是缓存的处理，可以结合并行请求一起使用。举个例子，同时请求两个广告源A和B，A和B都返回了，我们可以把他们都缓存起来，等用户想看的时候，挑选优先级最高的A来展示。这时B虽然没展示，但通过缓存可以在用户下一次进入广告场景时展示，比如第二次A没有加载好，可以快速展示B，这样提升广告展示成功率。

最后是Header Bidding实时竞价的方式。它不需要像waterfall那样一层一层去配置，运营会更简单，同时加载时间也会缩短，有利于提升整体的展示成功率。

第三组指标是ARPU、LTV和ROI。ARPU = 广告收入 / DAU，即人均广告收入，很多客户会用ARPU看广告效果，但实际上只用ARPU是不够的。在商业化领域，变现和买量是两个非常重要的维度，一般要结合一起来看。ARPU实际上是新老用户加在一起的平均收益，买量一般买来的是新用户，所以ARPU用来衡量买量效果是不太够的。

而用LTV算就合理多了。LTV 表示用户在生命周期内产生的价值。用LTV除以CPI可以得到ROI，用于衡量投入产出比。ROI是很重要的指标，ROI做正就能赚钱。很多开发者知道ROI很重要，在分析衡量买量效果的时候，最好有清晰的数据来佐证判断。但是LTV和ROI的计算比较麻烦，LTV需要计算每个新用户进来后，每次展示广告的价格。ROI更麻烦，要打通买量、变现、归因数据，并且还要设备层级的数据，把这些全部串起来才能算出ROI。

下图是Topon的ROI报表和LTV报表。相对来说比较清晰，可以看到应用、广告平台、广告组、计划层级的数据。

三、提升广告收入的实用功能

首先是广告分层。所谓广告分层就是设置eCPM底价，将广告平台的offer分成很多层。如右侧示意图，开发者接入广告平台后，通常会按照广告平台的表现做排序。这里的示意是A的表现比B好，那么就把A排在前面。但这种方式是有弊端的，虽然B的整体变现差一点，但B也有好的offer，B的头部offer大概率好于A的尾部offer，但是排序是在A后边。

那怎么做优化呢？广告分层可以一定程度上改善这个问题。分层之后，我们对A和B都设置底价。A分为两层，即A头部offer和A尾部offer。B也分两层，B头部和B尾部。那排序就是A头部offer>B头部offer>A尾部offer>B尾部offer。这种方式相对合理一些。

关于广告分层也有一些注意事项。

第一是eCPM底价不要设置太高，会导致填充降低，填充率一般控制在5%以上，最低不少于1%。

第二是平台之间的分层最好做交替排序。

第三是设置兜底层，不要设置底价，用于提升整体填充率来吃尾量。

最后是展示顺位对eCPM是有影响的。理论上曝光越靠前的展示，其广告效果越好。对于不支持设置底价的平台，可以通过控制展示频次来实现分层。

再来是流量分组。流量分组即根据一定规则对流量做划分，常见规则有性别，年龄，国家等。在不同分组下，用户行为和广告平台的效果是有差异的。基于这种差异做精细化waterfall排序，可以提升整体eCPM。

这里说两点注意事项。

第一是国家。基本上所有广告平台都能提供分国家的数据，并且在不同国家的表现差异也很大。建议重点国家单独拎出来做waterfall排序。如果游戏发全球，国家很多，可以对一些国家合并，比如东南亚合并为一个组。

第二点是有无设备ID时，广告平台表现差异很大。广告平台很多会基于设备ID做用户画像、算法排序。我们发现有的平台在设备ID为空时，是没有填充的。针对这种设备ID为空的流量，可以做差异化的waterfall设计。并且后续iOS14普及后，ID为空的设备占比会大幅增加。

接着是AB Test，就是对两组同质流量实行不同方案，基于数据分析看哪个方案表现更好，再到全部流量实行这个方案。

这里有一些注意事项。

首先是不同实验组之间应该规避数据干扰，否则影响实验结果。

第二是基于设备分流时要考虑IDFA或GAID为空的情况，可使用 IDFV，Android ID或内部ID代替。

第三是即使是对广告位进行AB Test，也需要关注应用维度的数据分析。

借助TopOn ADX。TopOn客户可以通过ADX接触更多广告源，提升收入。ADX就是广告交易平台AD Exchange。很多广告主会在大媒体买量，很多预算花在Facebook，头条，腾讯等大媒体平台，但是还有部分广告主选择用DSP买量，TopOn搭建ADX后，TopOn的开发者可以通过ADX链接到更多广告主，广告主增加，填充率自然上升，收入也会增加。

TopOn ADX采用Open RTB协议，采用实时竞价方式，确保价高者得。开发者、Topon、DSP均能从中获利。

ADX功能开通权限以后，开发者可自由控制是否使用。