In the first part of the series I’ve outlined several reasons to consider advertising as a monetization option for your mobile apps and games. Today I wanted to cover some of the basic terms used in the mobile advertising industry. Let’s start with ad types.

Ad types

There is quite a variety of ad formats that you can place into your apps and games, but here are the most common ones:

Banner ads

 

The most widespread and “old school” type of ad is a banner ad. They probably don’t need an explanation, but if you don’t know what they are, you can see one on the right.

Pros:

• widest choice of ad providers
• don’t interfere with natural app’s/game’s flow
• can be easily used as an incentive for an in-app purchase to remove them (break the IAP ice)

Cons:

• take up real estate on the screen
• annoy “allergic” users

Interstitial ads

Ads occupying most (all) of the screen and usually displayed during natural pauses in app’s flow, thus mostly applicable to games. For the purpose of this discussion I will group video ads and playable ads (mini demos) into the same category.

Pros:

• Good user engagement (high click-through rates)
• Don’t take up screen real estate during gameplay
• Usually pay better than banners

Cons:

• require a natural pause in game or app’s flow, thus not universally applicable
• can’t show too often (for the same reason)
• can be “heavy” in terms of file size/network traffic

Offer walls

Offer walls usually display a number of ads on the same screen and occupy the whole area(hence the name).

Pros:

• often displayed in response to voluntary user action (click on a special button, etc.)
• show multiple ads – more choice for the user (potentially higher click-through rate)

Cons:

• multiple ads displayed simultaneously dilute the value and attractiveness for best advertisers

Native ads

Native ads are almost indistinguishable from app’s content. Think promoted tweets or court-side ads in a sports game.

Pros:

• non-intrusive in the context of the app

Cons:

• hardly accessible to indie developers
• can cause frustration on the user’s side when “nativity” goes too far

Ad providers

You can obviously spin out your own ad sales and serving operations, but for most indie developers and publishers this would be a huge overkill. So most of the time your ads will come from some 3rd party ad provider or a set of them. Ad provider market is a busy place, so almost every ad company tries to invent a new term for who they actually are. You will work with ad networks, ad exchanges, ad mediators, DSPs, SSPs, direct deal marketplaces, and a combination of those words in various order with a word “performance” mixed in.

As far as publishers are concerned you mostly care about the returns they can provide you, quality of their SDK (you don’t want your game to crash because of the ad SDK), and the quality of ads they deliver (you don’t want your users to be disgusted by what they see).

We will talk about getting the best returns in a future part of the series. And in case you care about all of these provider types, check out this presentation or this blog post.

Basic terms

We will cover more terms in the future parts, but here are few very basic ones:

• Impression – every time an ad is displayed to a user is called “ad impression”.
• Click – every time user clicks (or rather taps in case of mobile) on an ad
• CTR (click-through rate) – percentage of ad impressions resulting in clicks on the ad. CTR=Clicks/Impressions. For example, if an ad was displayed 1,000 times and was clicked 20 times you have a CTR of 2%.
• IR (install rate) – this is app specific and means a percentage of clicks resulting in app installation. For example, if 20 clicks from the previous example result in 2 app installations, you have an IR of 10%.

Ad pricing models

When advertisers order advertising campaigns there are various way they will be charged for it. As an advertiser pricing model may influence the type of creatives you use. As a publisher quite often you are not directly exposed to the way actual advertiser pays for their campaign, but, if you are, this may affect your ad placement strategy.

Here are the most common pricing models:

• CPM (cost per mille or 1 thousand impressions) – advertiser pays for a number of ad impressions. This is the most fair model for publishers. After all you sell space in your app and you don’t want to be responsible for whatever advertiser decides to advertise. Unfortunately for you in a buyer driven market it’s not always that advertisers would want to pay for impressions. This was especially true in the last couple of years, but recently I’ve started hearing savvy advertisers admitting that pricing model doesn’t really matter as long as they can assess key performance indicators on their end.
• CPC (cost per click) – this is probably the most popular pricing model, popularized by Google on the web and expanded to mobile later on. While it is wide spread, I think it is one of the most unfair models on mobile to both parties. It’s no secret that the number of accidental clicks on mobile is quite high and someone is paying for them with the CPC model.
• CPI (cost per install) – this is one of the most popular models with app advertisers. While advertisers pay for some sort of desired outcome (app install) the methods to track these conversions rely on quite a lot of “magic” and, as a publisher, you bear the penalty for the quality of advertised product.
• CPA, CPL, etc. (cost per action, cost per lead) – while install is some sort of outcome, more often than not it’s not the final goal of the advertiser. In an ideal case for the advertiser they would only like to pay a share of the money they make from users you bring them. Luckily for you these models are not as widespread in the in-app advertising. However, if your app is highly targeted at some lucrative niche, this could be a good way to get referral fees from the companies working in the same space.

That is it for this part. In the next part we will talk about the KPIs advertisers care about and what it means for you as a developer/publisher.