Wednesday, 23 November 2011

Comparing some mobile advertising services - part 3

Continuing my look at the various Mobile advertising services that are out there, I next decided to investigate MoPub. This follows on from the previous article, which looked at LeadBolt.


MoPub is another ad service from whom I recently received some publicity information, and decided to find out a bit more about them. They were apparently founded by former AdMob and Google employees, presumably they hope this will give them additional credibility among the Android developer community.

In addition to having their own "Marketplace" for ads, MoPub also offers an ad mediation service, whereby you can connect your accounts from other ad service providers, and in theory, MoPub should automatically deliver the highest earning ad. It's worth noting there are other ad mediation services available, for example MobClix (which I looked at previously), AdWhirl, and others.

The SDK integration for MoPub was straightforward. Their source code is available from a git repository, so you can pull the source directly using git, or download as a zip file. The fact that the source code is available is a nice bonus.

Although primarily an AdMob user, I had previously set up accounts with MobFox and InMobi for previous trials. So I decided to link these to my MoPub account, using their web-based administration console. MobFox and InMobi ads can then be served via MoPub via a direct server-to-server request. This method can't be used in the case of AdMob however (I believe this is due to AdMob's terms of use), so instead, the API must be called from within the app via an adapter that MoPub provide. This does also mean it's necessary to include the AdMob SDK in your app, but as a pre-existing AdMob user, this was not a major problem for me.

What I like about this ad mediation approach is once set up, the ad networks and their priorities can be adjusted in the console area and any changes will take effect in real time. So in the event that one network is performing badly, or you want to add in a new service, you can do this dynamically without re-releasing your app.
Illustration of a possible MoPub setup

My initial impressions of MoPub are positive. The MoPub marketplace is giving me eCPM values of around $0.70, which is significantly higher than other services I have looked at. The fall-back to the other ad services seems to be working, with MobFox being the most likely service chosen. MobFox is returning eCPM values of around $0.20, with AdMob a little lower. InMobi continues to give me too low a fill rate, as was the case in the previous trial, so I fairly quickly stopped using them.

On the downside, some of the ads in MoPob marketplace may be considered annoying by some users - some are animated and others include adverts for age-sensitive content that publishers may want to exclude, such as gambling or dating-related. Going forward, I would like to see MoPub allow publishers to exert more control over what kinds of adverts can be shown, and I believe such features are in the works. You can create a MoPub account here.

What to conclude?

As a result of these tests, my current preferred setup for ad services has changed. I will be looking to use MoPub as my primary service, with AdMob and MobFox configured as additional networks. I have switched some of my apps to this configuration and initial results are suggesting improved performance. Let's hope that continues. I will continue to monitor the situation and keep my eye out for other services that may be of interest, and keep you informed of my findings.

Monday, 21 November 2011

Comparing some mobile advertising services - part 2

In this second look at Mobile advertising services, I decided to investigate LeadBolt. This follows on from the previous article, which looked at MobClix, MobFox and InMobi.


LeadBolt caught my attention because they offer more than the traditional mobile ad service of simply providing an ad to fill a 320x50 pixel space. As well as a variety of ad sizes, they also offer a number novel features, such as:
- Ads as notifications
- Interstitial ads
- Content unlocking

I was a little skeptical about the ads as notifications, thinking some users may find them annoying. The interstitials (full screen ads between pages in the app) may have some uses when used appropriately. But for me, the feature of most interest is the ability to allow users of unlock content by interacting with ads.

Many developers have opted for an approach where they release a free "lite" version and also a paid "pro" version of an app. The free version intended to encourage users to upgrade to the paid version. I have tried this approach in the past with moderate success - but the number of users willing to upgrade is often a very small proportion - rates of 1 sale per 1000 free downloads are not uncommon.

The promise of the content unlock approach then, is that if users are to be rewarded with "free stuff", they are more likely to engage with the ads. Your premium content can reach a potentially larger audience while still ensuring you can generate income, thanks to the greater response rate to these kinds of ads. That's the theory, anyway.

So I decided to trial LeadBolt in one of my apps. But pretty quickly I hit the same dreaded problem that I had hit previously with MobClix: The SDK requires the android READ_PHONE_STATE permission. It seems to be becoming almost a pattern than my attempts to implement SDK from third parties are frustrated due to excessive permission requirements. For details on this permissions issue, see my previous article.

So what to do?

I contacted LeadBolt about the permission requirements, and they were at least responsive and replied they would look into it so see if it the READ_PHONE_STATE permission could be made optional. Until then I won't be implementing LeadBolt. However, because the features they offer are still potentially interesting to me, I will keep it on my list of possible services to look at again in the future. If this permission issue does not affect you, then you can create a LeadBolt account here.

I the next article, I'll be taking a look at MoPub.

Wednesday, 2 November 2011

Comparing some mobile advertising services - part 1

Mobile advertising is important for developers because it is one of they key methods of monetising apps. However, choosing the best one is not that simple as there are so many ad services available nowadays. So what in-app ad services are available? What are the relevant factors when choosing? How do different services compare?

As mentioned in my previous entry, I have been using Admob for nearly a couple of years now. In recent months though, I have noticed that for some of my apps, there has been a trend of (i) declining CTR (click-through-ratio) and (ii) declining eCPM (earnings-per-thousand-impressions). To illustrate this here are the figures for one of my games, Block Rampage

Admittedly Block Rampage is not one of my most downloaded games and so the figures are not based on a large data set. Also, not all my apps show this pattern. But it does nevertheless illustrate a trend, for which there may be a number of possible explanations:

1. Users are becoming accustomed to ads are less likely to click on them.
2. With an increasing proliferation of apps (and thus more available ad slots), advertisers are paying reduced amounts for their campaigns.
3. Admob becoming less competitive versus other players in the in-app ad market.

I regularly get emails from companies promoting their ad services. Not having the time to investigate, I tend to ignore most of them. That said, I decided it would be worth taking a look at some other ad services for comparison. I was interested in looking at how easy to implement the SDK is, what sort of income (eCPM) could be expected, and any other issues such as payout schedule and minimum payment threshold.

I started off by looking at MobClix, MobFox, and InMobi.


MobClix provides a mediation service with ads being obtained from multiple ad networks. This is attractive as it would allow testing of numerous ad services without having to implement multiple APIs. So I jumped right in and attempted to implement MobClix, but fairly quickly hit a problem. Although technically simple to implement, the SDK does require the app to have the READ_PHONE_STATE android permission. None of my apps currently use this permission, and I was reluctant to add it just to serve ads. The change of permissions would mean auto-updating of the app would no longer work, as users would be required to manually accept the new permissions. Also, as this permission gives the app access to the phone's IMEI and phone number, many users may be suspicious of why a simple game would need this permission.
The MobClix documentation states:
Required Permissions: android.permission.INTERNET - Used to retrieve ads. android.permission.READ_PHONE_STATE - Used to obtain a unique device identifier.
This justification - needing to obtain a unique identifier - is contradicted by the advice from Google on this page:
Android Developers Blog: Identifying App Installations
I raised this issue with MobClix support, and asked if they could at least make the READ_PHONE_STATE permission optional. However, they have not replied to my query. Therefore, my experiment with MobClix ended there!

MobFox and InMobi

I trialled MobFox in one of my games with a fairly low usage rate, Block Rampage. MobFox has a nice feature called "eCPM control", whereby unfilled requests can be passed on to another network. So I made use of this feature to also try out InMobi. This is similar to the setup suggested here by Project Journeyman.

The account creation, setup and implementation in the app was simple enough, so no complaints there. The payment threshhold for MobFox, $50 is pretty reasonable, but the schedule is NET 60 (i.e. 60 days after the end of the accounting period), is twice that of AdMob. After a few weeks, I took a look at the stats I was getting, and this is what I found:

1. The MobFox CTR and eCPM stats were similar to those I was getting from the same game when using Admob. I would describe them as satisfactory but not exciting. Anecdotally, I did happen to notice the same ad seemed to be appearing frequently, which did give me some concerns over the size of MobFox's range of available ads.

2. The InMobi stats were very poor, mainly because of a very poor fill rate, typically 10-15%. The eCPM was actually comparable to MobFox and Admob when the ads actually appeared, but that's not much use when the fill rate is so low. Maybe I would have got better results by using InMobi's SDK directly, rather than via MobFox, but these initial results didn't give me cause for thinking it would be worthwhile trying.

Which Service?

So, my conclusion was that although MobFox may have some potential, none of the services tested so far seemed to significantly improve on the offer from Admob, at least for me. So, I have decided to stay with tried-and-tested Admob for now. I will be looking at some other services, e.g. LeadBolt and MoPub next.