作者：Emilia Szymanska

我将通过本文和你们分享有关手机游戏广告的一些建议。这是根据我们在Tabasco Interactive执行过的各种解决方法。其中要特别感谢Karol Drzymala分享了自己的一些看法。

《星辰幻境》和《颠球冠军》

Star Horizon(from appdp)

Tabasco Interactive工作室发行的第一款游戏是《星辰幻境》。这款游戏花了我们18个月，如果从手机游戏的市场标准来衡量的话，这有点太长了。在手机游戏领域中，我们可以将其称为AAA级制作。它也获得了一些不错的评价，即多数人都表扬了游戏的高质量3D图像和有趣的故事线。游戏售价3.99美元，但是销量并不可观。

1.

工作室成员在完成了这个大项目之后想要先休息下（《星辰幻境》后续作品的初稿已经在制作了），所以他们便决定先发行一款较小型的游戏。3个月后，名为《颠球冠军》的游戏的第一个版本便诞生了。其游戏玩法是基于合适时间和节奏去敲打屏幕以控制男孩颠球并执行各种技巧。这是一款典型的休闲游戏，也就意味着它拥有简单的规则且没有那些复杂游戏所需要的各种承诺。

2.

除了规格外，这两款游戏的区别便在于运营模式。《颠球冠军》利用了微交易和广告的优势。也就是玩家可以先免费游戏，但是之后需要承担广告的骚扰。玩家可以在游戏中通过游戏或花真钱去购买货币，并使用货币去获取衣服和球。

让人惊讶的是，发行后的前两周《颠球冠军》便赚回了本（游戏邦注：具体来说是在获得AppStore的推广的第一个周末后），甚至在发行一个月后赚到了和《星辰幻境》持平的收益。

结论就是广告虽然是合理的，但是通过广告去创造利润却并不简单。

手机游戏广告规则

从自己的角度来看，你自己会关注多少广告？就我个人来讲，如果不会有突然弹出来的内容，那么我最多可以连续观看两个广告—-实际上这也是广告供应者所清楚的情况。所以前几个广告的报价往往会高些，随后的广告价格便会逐渐下降。此外，广告留也不是无限的，如果用户观看了特定数量的广告，广告供应商便不会在特定时间段内再提供给他们广告了。提供广告的总查询率叫做供应比例。所以最让我们感兴趣的内容的供应比例便是100%。

所以当供应商拒绝发给我们广告时我们该怎么做？我们需要去咨询其它供应商！幸运的是我们并不是被束缚在一个小小的鱼缸里，我们可以不用局限于一个广告供应商所提供的服务。实际上这也是《颠球冠军》在发行时所犯的一个错误，即如果我们能够考虑到更多广告供应商，这款游戏将获得更高的收益。

随机顺序

这一方法非常直接，即将供应商置于随机顺序中。当有人停止提供广告时，马上询问其他人。我们可以通过持续的广告呈现获取利益，但是在最初的观看后我们便会掉进支付率下降的循环中。

循环

对此最简单的解决方法便是在供应商列表中进行循环。如此我们将不断获得广告并且不同广告可以轮流出现在广告列表前面。不过广告供应商关于每则广告的收益也具有很大的差别。

手动配置

这一方法需要每天为广告模块执行全新配置文件的下载功能。每个早上我们可以浏览每个广告供应商的网站并审查前天的eCPM（每一千次展示可以获得的广告收入）并基于这一数值进行排序。这能够帮助我们评估之前所有排序的弊端，但是你却需要每天去执行这一乏味的工作。

AppAnnie

如果你希望这一工作能够轻松些，你可以使用AppAnnie网站，它能帮助你收集收入信息，创造表格并去分析这些数据。但你仍需要手动创造配置文件。虽然这并不是什么难事，但如果你的应用用户分配在世界各地，那么你的收入将受到另一个要素的影响，即供应商在不同国家拥有不同的报价，所以你如果你想最大化利用广告价格，你就需要为每个国家创造各自的配置文件，这是AppAnnie不能帮到你的地方。

3.

广告介质

如果我们真的觉得为每个国家创造不同的配置文件能够有效提高收益，我们便应该着眼于广告介质。即我们必须决定哪个供应商的广告能够最大化收益。有时候你需要支付这样的服务，但有时候你却可以免费获得。使用广告介质拥有许多优点，例如我们只需要将一个SDK与应该整合在一起而不需要为所有广告供应商使用不同的SDK，我们不需要担心每天创造配置文件，等等。

广告介质并不会分享有关选择顺序的算式等信息，所以这里也会存在一些潜在的漏洞。我们也需要为供应商的账号分享一些访问细节。最后，我们需要为此买单。如果不是以钱为代价，那可能需要以我们的应用及其用户的信息为代价。

所以如果我们拥有一些自由时间并希望能够完全控制排序算法，我们最好能够自动化整个过程。即我们可以创造自己的广告介质工具！同时你还要记得，你可以在所有应用中重复使用这一工具，如果你已经在制作一些应用或者正在计划基于该运营模式发行一些游戏，那么创造自己的解决方法将更有益。

创造自己的工具

首先，这需要你消耗一些时间，特别是当你是对服务器和数据库并不熟悉的游戏开发者。工具需要托管与监视，因为供应商的API会随着时间的改变而改变。但不管怎样学习一些全新技术对你来说总是有帮助的。

这种工具的功能需要你去查询所有供应商前天的收益API，分析它并生成配置文件。你会觉得这好像不需要去设置数据库，但事实并非如此。根据我的经验，你并不需要收集所有供应商前天的数据，有时候你可以两三天收集一次，如此你便需要一些早前的信息作为支持。

此外，如果你是根据eCPM去排列供应商，那便有可能出现访问量较低的供应商获得更高收益的情况。这便是为何我们会设置最低访问量门槛—-也就是如果供应商前天的访问量不能得到满足，我们便会去计算一些历史数据。当然了，将这些数据储存于数据库也能让我们创造一些更加一目了然的表格，从而帮我们更轻松地分析系统对于收益的影响。

4.

技术堆（样本）

从根本上来看你可以使用你喜欢/知道/想要学习的任何技术去创造这样的工具。就我个人而言，面向服务器我使用了所谓的MEAN堆，即MongoDB数据库，Node.js和Express.js，而面向用户面板则使用了Angular.js。

我觉得MongoDB非常适合这项工作—-我们的数据大多数是不相关的，但包含许多个体文件。Node服务器和Express中间件很容易设置与编写—-你只需要几行代码变能够拥有一个可行的服务器。例如Angular。当我致力于面板时，这便是最突出的技术，但现在我认为React更有效。所以你只要选择自己想要的工具便可。

5.

免费的托管选择

计算文件并不需要过于繁琐的计算机运行，并且通常是一天执行一次，所以服务器并不需要依赖于超快的机器。这便是为什么我们可以使用一些免费工具去托管它。

本地主机

我认为我们甚至可以不用去托管它，即只要每天运行应用并上传文件到某些地方即可（我们一直都在使用Wordpress）。这种解决方法既可行又是免费的，但主要缺陷便在于我们必须手动操作且每天都必须记得这一任务。

云端服务器的免费选择

一些云端服务器便拥有免费但却有限的选择。例如Amazon Web Services便免费提供了微实例，而这对于该任务来说就绰绰有余了。如果我们并不想与AWS分享我们的信用卡信息，我们便可以尝试使用Heroku，它便拥有很好的配置方法。但是我们也必须记得在经过一个小时后如果未收到任何请求，Heroku实例也将不再发挥作用。如果你只是一名学生并只是想要进行试验，你还可以使用Dreamspark订阅，它能够帮助你设置一些最基本的机器。

如果你并不想费心去设置数据库或不想将其置于和服务器同样的机器，我便会建议你使用MongoLab服务器的免费选项。在此你唯一需要担忧的便是最大的数据库规格（不能超过500兆）。

（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转发，如需转载请联系：游戏邦）

Maximizing profits from advertising in mobile games and apps

by Emilia Szymanska

Hi guys! In this blog post I’m going to share with you some tips on the topic of ads in mobile games. It will based on our experience with implementing such solutions in Tabasco Interactive. Special thanks for Karol Drzyma?a for sharing most of these thoughts!

Star Horizon and Kickerinho

The first game released by the Tabasco Interactive studio was “Star Horizon”. Works on this title took eighteen months – which by the standards of the market for mobile games is quite a big number. We can even call this a AAA production in the world of mobile games. It gathered great reviews – it was praised mainly for its high quality 3D graphics and an interesting storyline. It costs only $3.99, but the amount of sold copies wasn’t so big.

1

Members of the studio wanted to take a rest from creating large productions (first drafts for the successor of “Star Horizon” were already in progress), so they decided to release a much smaller game. After just three months, the first version of the game called “Kickerinho” was created. The gameplay involves tapping the screen at the right time and pace so that the boy bounces the ball well and can perform various tricks. This is a typical casual game, which means that is has simple rules and lack of commitment required in contrast to more complex productions.

2

What distinguished both of these games, besides the size, was the business model. Kickerinho utilizes the power of microtransactions and ads. You can play for free, but every now and then an ad appears (frankly, in Kickerinho these appeared quite frequently). There are some clothes and balls that you can buy for coins and these you can either earn by playing or buy for real money.

Surprisingly, Kickerinho payed for itself after the first two weeks (to be specific – after the first weekend of being promoted on the AppStore…), and after the first month caught up in revenues with Star Horizon.

The conclusion – ads are ok! But making profit from ads is not that simple…

Mobile games ads rules

Think about yourself – on how many ads are you able to focus? I, personally, have a chance of watching at most two video ads in a row without starting to look the other way when the pop up appears – and that fact is well known for the ad providers. First few ad views for the user have the best price – then the rate significantly drops. Additionally, ad stream is not infinite – if the user watches a certain amount of ads, the ad provider will simply not provide further ones for a specific period of time. The rate of provided ads to total queries is called the fill rate. You can easily guess that what interests us the most is having the fill rate of 100%.

So, what can we do when the provider refuses to send the ad? We need to ask the other provider! Fortunately, there are many fish in the sea, so we do not have to be limited to the services of just one ad provider. Actually, this was the mistake at the moment of Kickerinho’s launch – if there were many ad providers configured, the revenue would be even bigger.

Utilizing ad providers to the maximum

You may ask what the best number of providers that should be implemented is. The answer is really simple – as many as you can! However, you need to remember one thing – the more foreign code, the more bugs in the project and SDKs of these providers can heavily increase your app’s size.

The more complex question concerns setting them in order. There are many ways of doing that, which I will present now. Remember – simply using more than one ad provider is already making a great difference. These methods will be presented in order of implementation complication, so you have to measure the resources that you’re willing to sacrifice for this task accordingly to your own studio’s capabilities. Otherwise, the profit of using more advanced method may not be enough to repay for the implementation cost.

Random order

This approach is pretty straightforward – just put the providers in a random order. When one stops providing the ad, ask another one for it. We get the benefit of always having the ad shown, but fall into the trap of significant pay rate drop after the first few views.

Rotation

The simplest fix that I can think of is simply rotating through the list of providers. We always get the ad and we fall into the first rate tier. However, differences in ad provider’s revenue per ad can vary greatly.

Manual configuration

This method requires implementing the functionality of downloading new configuration file for the ad module every day. Every morning we can scan through each ad provider’s website, check the eCPM (effective cost per mile) for the previous day and order them by this factor. This will help eliminate all of the previous drawbacks, but will force you to perform a tedious task every day.

AppAnnie

If you’d like to make this task little easier, you can use the AppAnnie website, which allows to aggregate the income information in one place, create charts and analyze this data in a convenient way. You still have to create the configuration file manually. This wouldn’t be so bad, but if your app’s users are spread all around the world, there is another factor that can have an impact on your income – providers have different prices for each country, so to utilize the ad price to the maximum, you would have to create a manual configuration for each country – and AppAnnie doesn’t even display such data for every provider.

3

Ad mediators

If we really feel, that having a separate configuration for every country would greatly increase the income (we can deduce that from analyzing data for providers on their websites) we should take a look at ad mediators. These services take care of deciding, which provider’s ad should be shown to maximize the income. Sometimes you have to pay for such service, sometimes it has some free, limited plans. Using ad mediators has many benefits – we need to integrate only one SDK with our application instead of the SDKs for all ad providers (at least that’s what they claim… but I heard that’s not always true), we don’t have to worry about creating the configuration every day and generally, we don’t have to worry about anything. But on the other hand…

Ad mediators do not share the information about the algorithm that chooses the order, so there’s room for a potential fraud (some kind of an agreement with providers). We also have to share access details for the providers’ accounts. And finally – we have to pay. If not with money, probably with something else, for example the information about our application and its users.

So if we have some free time and are willing to have full control over the ordering algorithm, and would like to fully automate the whole process… We can create our own ad mediation tool! Also remember, that tool will be totally reusable between all of your apps, so making your own solution is more profitable if you already have several applications in production, or you’re planning to release many future games in that business model.

Creating your own tool

First of all – it is time consuming, especially if you’re the kind of a game developer that’s not familiar with servers and databases. The tool will require hosting and monitoring, because the providers’ API can change over time. However, learning new technologies is always beneficial.

The functionality of such tool would require querying all of the providers’ API for data about the revenue for the previous day, analyzing it and generating the config file (it may also provide its own API for downloading the file). It may seem that this doesn’t even require setting up a database, but that’s not entirely true. From my experience I can tell, that you will not always gather the data from all providers for the previous day – sometimes it takes them two or three days until they make this data available, so you will need the older information to back you up.

Additionally, if you order providers by the eCPM, it may happen that very few views from one of them got paid well, so the eCPM would be enormous, but the revenue would not. That’s why we have the minimum views threshold set up – if the provider’s views from the previous day don’t satisfy it, we try to count also some historical data. And of course – having this data nicely stored in the database allows us to create some kind of a dashboard panel that would display this data in a human readable format, which can help us analyze the impact of our system on the revenue.

4

The technology stack (sample)

Generally, you can create such tool using any kind of technology you like/know/would like to learn. I personally utilized the so called MEAN stack – MongoDB database, Node.js and Express.js for the server, and Angular.js for the user panel.

I feel that MongoDB is a perfect candidate for this job – our data will most likely be not relational, but consisting of many individual documents. Node server and Express middleware are quite easy to set up and start writing – you need only several lines of code to have a working hello world server. In case of Angular… When I was working on the panel this was the top notch technology, but now I guess React is fancier. Just choose the one you’d like to get to know.

5

Free hosting options

Calculating the file doesn’t require heavy computing and is performed usually once a day, so the server doesn’t need a super-fast machine to be reliable. That is why we can use some free options to host it.

Localhost

I think that we could even not host it at all, just run the app every day and upload the generated file to some place available for the game (we used WordPress for a long time). This solution is totally free and reliable, but the major drawback is that we have to run this manually and remember about this task every day.

Free options in cloud services

Some of cloud services provide free, limited options that we can use. For example, Amazon Web Services allows having one micro instance for free, which is totally enough for this task. If we do not want to share with AWS our credit card info, we can also try using Heroku, which additionally has a very nice deployment method. However, we need to remember that free Heroku instances “go to sleep” after one hour without receiving requests. And if you’re a student and just want to experiment a little – there is also an option of utilizing the Dreamspark subscription, which allows to set up some most basic machines.

If you do not want to bother with setting up the database, or simply would not want to host it on the same machine as the server, I can recommend the free option in the MongoLab service. The limitation concerns maximum database size (500 MB which is more than enough).

And remember – if your game turns out to be bad, you can always become the backend programmer! (source:gamasutra)