Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
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
This blog post was previously posted at http://emi.gd/blog/ad-mediators/.
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!
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.
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.
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…
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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! ;)
Read more about:
Featured BlogsYou May Also Like
