Ben

Author Archives: Ben

Alternatives to AdMob (and MoPub) for 2020

AdMob Alternatives

Is your app not producing as much ad revenue as you think it should?

Do you feel like you could make a lot more money from your app if you could just find a better alternative to AdMob? 

That might be the case, but let's dig a little deeper and find out...

First...Do You Really NEED to Replace AdMob?

AdMob is one of the oldest mobile ad networks still in existence. After it was acquired by Google, it was turned into Google's consolidated source for in-app advertising. It is one of the very largest supply side platforms (SSPs) in the world and benefits from integration with Google's other very deep sources of demand like Google AdX.

Does that mean it's the best out there? No, not necessarily. 

That said, there are certain problems that cannot be fixed by replacing AdMob. Let's talk about those for a minute.

Low Inventory

The biggest problem that I see developers having with regard to ads is simply that they don't have enough traffic to be running ads in the first place. 

ALL systems that automatically optimize performance need a lot of data to make good decisions. That is certainly true of AdMob and it's also true of the advertisers who buy AdMob's inventory. They all use machine learning algorithms which need to be fed enough data to make decisions. 

So if you only have 1,000 impressions per month, AdMob will never be able to optimize that inventory very well. BUT, neither will any other SSP, so swapping AdMob for another platform won't make any difference. 

Focus on growing your user base until you have around 30,000 MAU. That should produce 100,000+ monthly ad impressions, which is a general minimum that I think makes sense to monetize. At a $3 CPM, that's $300+/month in revenue.  

Poor Ad Placement

In short, you have to place ads where they will be seen and users can tap them. This is less of a problem in apps than it is on the web, but you can still make mistakes here. Always take time to think of the ad placement from the perspective of the advertiser. If you were advertising your app in this spot, would you be happy?

Choosing the Wrong Ad Format

Depending on what your app does and how users move through it, some ad formats may work a lot better than others. This is something to test before swapping platforms, because poor ad performance won't be rewarded on any other platforms either. 

Is Running Ads the Best Way to Make Money?

This is a very basic issue, but one well worth raising. There are a LOT of different ways to monetize an app. Running ads is one of the easier methods to set up, but it's definitely not always the most lucrative. This is particularly true if you have a very small user base. Take the time to explore all your options before running ads.

Tiers and Types of AdMob Competitors

There are a couple tiers and several different types of competitors to AdMob. 

In terms of tiers, I think of the market as dominated by AdMob and MoPub. Those are the exchanges that are owned by huge public companies (Google and Twitter, respectively) and they have a very deep well of demand. Even if you don't use either of them as your SSP, you should be tapping into their demand through mediation. Those two are tier one, all else is tier two.

In terms of types of competitors, there are some that are focused primarily on video or native ads. There are also some who focus on serving gaming apps and others that don't own an exchange and focus on mediation. We'll explore all these below. 

Alternatives to AdMob

Here are the main alternatives to AdMob divided into tiers based on scale:

Tier one:

  • MoPub
  • Amazon Publisher Services
  • Facebook Audience Network

Tier two:

  • Verizon
  • Smaato
  • Fyber
  • MobFox
  • InMobi
  • AdColony
  • Rubicon
  • AppNexus
  • Pubmatic
  • OpenX
  • Chartboost
  • Unity Ads
  • Vdopia
  • IronSource
  • Adtoapp
  • AdinCube
  • Appodeal
  • PubNative

The Big Dogs

MoPub

MoPub is the another industry-leading SSP option. It was an early entrant in the space and it was acquired several years ago by Twitter. Since then it has continued to develop and it runs one of the largest exchanges for mobile app inventory, tapping into the advertiser base of Twitter. 

MoPub

Amazon Publisher Services (APS)

Amazon Publisher Services is one of the newest options available to mobile app developers. Amazon has been rapidly developing their advertising capabilities and they have their own massive demand source because of all the merchants advertising on their platform. They also run a product called Transparent Ad Marketplace (TAM) that allows you to mediate other demand sources as well. It's not as easy to use as AdMob, but it's a very potent competitive option.

Facebook Audience Network (FAN)

Facebook is the only other demand source that truly rivals Google AdMob in sheer size. FAN is not a mediation service, but it is so large that many apps wouldn't need anything else, so it is an AdMob alternative. It is possible to use it as a demand source in other mediation solutions and if you can, you should.

Other Large SSPs

I’m sure that every company on this list would resent this "other" designation, but here are some SSPs that are not as large as the major ones but still deserve consideration.

Verizon (aka Nexage and Oath)

The name of this one keeps changing. It was originally known as Nexage, which was another older exchange and SSP. Nexage was acquired by Millennial Media, which was acquired AOL and marketed as a product called One Mobile, then AOL was acquired by Verizon

Verizon deals in all digital ads, whether desktop, mobile web or mobile app. They have a full-featured SSP option and they are also providing header bidding to publishers. 

Smaato

Smaato has traditionally been more internationally focused but has started to perform well in the US too. They have a sizable exchange of their own.

Fyber

Fyber is a roll-up of a few different companies, one of which was Inneractive which has a good sized ad exchange for mobile app traffic. Fyber is a game-focused SSP but they can and do operate on a variety of other types of apps. The mediation platform HeyZap was also acquired and rolled into Fyber. 

Fyber

MobFox

MobFox is the in-app monetization arm of the Matomy group.

InMobi

InMobi has long been a large ad network in international markets and a while back they acquired Aerserv. Aerserv is a video-focused SSP with a mediation platform and exchange that performs well in the US, making it a great addition to InMobi.

AdColony

Many of these SSPs were formed through acquisition, and AdColony (formerly known as Opera) is a successful public company that was created through a number of acquisitions. Their SSP offering is underpinned by a mobile ad serving and mediation layer called AdMarvel. That platform is augmented by demand from a performance network formerly known as Moolah Media and a brand network formerly known as Mobile Theory. All of this has been combined and they’ve created their own proprietary exchange as well under the brand AdColony (which was also a company they acquired). 

Web SSPs that Handle In-App Traffic

There are several SSPs that got their start long ago on desktop and mobile web traffic but have started to deal in mobile app inventory as well. 

Rubicon

Rubicon is a long-time player on web inventory. They grew rapidly and ultimately went public a few years ago. Rubicon operates a large exchange and they have an SSP offering for in-app inventory but their roots are definitely in web inventory.

AppNexus

AppNexus runs a large exchange that traditionally was focused on web inventory. Again, their roots are definitely web but they are moving aggressively into app inventory as well. AppNexus is a more robust platform than other SSPs, which is a pro and a con. It can be used as a platform to run a whole ad network. However, that large scope of features can make it daunting to use as an SSP. As part of that platform, it has a very robust direct ad serving offering.

AppNexus

PubMatic

PubMatic is a large company running their own exchange. PubMatic acquired mobile ad network Mojiva a while back and Mojiva's ad serving counterpart Mocean, so they do have a robust direct ad serving system that can be used to operate a whole network, like AppNexus. That acquisition also gave them some technology that was developed specifically for mobile.

OpenX

Yet another large SSP from a private company with web roots. OpenX operates an exchange that is large and worth accessing. OpenX started as a direct ad serving platform and that is still one of their core offerings. They are one of the few SSPs that has a robust direct ad serving option.

Game or Video SSPs

Many of the large app developers—especially the ones that make really big money—are game developers. So some SSPs are built specifically for game developers. They have feature sets that cater to games and in the case of Chartboost, they specifically declare that they only work with games.

Chartboost

Chartboost focuses exclusively on game apps. They run interstitial and video ad formats only, and offer cross promo and a direct deal marketplace so you can coordinate with other app developers.

Unity Ads

The Unity platform for game development has an ad platform called Unity Ads woven into it. This makes it very easy for apps developed on Unity to use, but it focuses on rewarded video units exclusively.

Unity Ads

Vdopia

Vdopia runs an optimization platform and video ad exchange called Chocolate.

IronSource

IronSource is a full-featured platform with a variety of ad units available, but they tend to focus on game apps and on rewarded video. If most of your inventory is rewarded, do NOT skip over this one. It's one of the leaders in that space. 

Mediation/Optimization Partners

There is a breed of SSP that deals in optimization only. By that I mean they don’t have direct ad servers and usually don’t operate their own exchanges. They just mediate ad networks and exchanges. Some of them have received funding but all are relatively small, typically targeting small to medium-sized developers. There are differentiators here, though you have to really dig in to figure out what they are.

Adtoapp

20+ demand sources and monthly payouts.

Appodeal

60+ demand sources and flexible payout options.

AdinCube

Ogury acquired this product and turned it into their publisher solution. 

Ogury

Native Ad SSPs

Native ads are truly different from standard display ads in terms of how they are delivered, so it’s often not an easy bolt-on feature for existing SSPs. The companies listed below focus on providing native ads though they are really mobile ad networks, not SSPs. But if you need native ads, this is where you can find them.

PubNative

Native ad network and good mediation add-on for other SSPs.

PubNative

The Secret Sauce

These above are the options that are available to most app developers. However, if your app has users primarily from tier one countries and has a robust volume of impressions (say 50,000+ DAUs), then you have better options available to you. Join my email list for more info on those options. 

How to Monetize an App in 2019

There are numerous how-to articles on app monetization but as I reviewed them I found most lacking in some way. 

Some are very thin in terms of content, others are just a list of ad networks, and many are a couple years old which in this space means they could just as well be written with charcoal on a cave wall. Still others reach too far for content, adding in items like watching your user retention. That’s solid advice, but it’s not direct monetization advice.

So I decided to keep a list here that is intended to be a living document, updated as needed to keep it current as the industry changes. This article is positioned as app monetization, but all of these methods can be used (with greater or lesser degrees of difficulty depending on the method) on mobile web sites as well.

This post is intended to be exhaustive, so if I’ve missed a method drop me a note and I’ll remedy that.

Paid Apps

By far the simplest monetization model is to charge a user for downloading your app from the app store. Because of that simplicity, it was the very first business model that powered the app economy.

Pros: Simple, easy to execute

Cons: ​Places a huge burden on the app store listing to convert users, limits your user base, can be a limited monetization method unless combined with other methods

The app world has changed dramatically since then and today relatively few apps use this monetization method. Most apps are free these days and the vast majority of app downloads are of free apps.

The reasons for this are pretty simple. Given the choice, users prefer to look at ads than pay even $0.99 for an app. The consideration process for an app purchase is also very short and littered with competition. If you as an app developer want to sell your app, that sales process usually starts and ends with your one-page app store listing. If you don’t seal the deal with that listing, you don’t make the sale.

That last point is why the freemium model has flourished. By removing all monetary risk and making the app free to download you can significantly increase your downloads and give users a free trial before they later purchase in the app.

There are still cases where developers find it logical to charge for apps (though there’s a solid case to be made that you should never charge an upfront fee for your app). Those cases are premium/VIP versions of an app and niche apps that provide a high functional value that isn’t easily substituted.

Premium App Versions

There are still many examples of apps that either offer a separate version of the app with more functionality or a zero-ads experience for a fee. This is really just a different—and less elegant—technological solution that largely amounts to freemium.

High Utility Apps

The other case that remains viable is niche apps that offer a lot of utility. In certain categories like Productivity, Medical, and Business you can still charge for apps because of the value on offer. A super-niche example at a high price is this app for piano tuners. Another is catering to people for whom a $1,000 app is a bargain.

However, even with high utility niche apps, developers are moving toward freemium. This bar exam prep app used to be paid and it’s now free, though you can see on the left that the in-app purchases are on the pricey side.

All in all, collecting an upfront fee for your app is a dying monetization model. Freemium is just a much more flexible monetization model and it offers a huge benefit to the marketing of your app.

Freemium

Freemium means that the user can download the app for free and the monetization happens later, inside the app experience, through in-app purchases.

Pros: Very flexible, no cost barrier for new users, allows heavy monetization of the best customers, premium features can keep expanding, pricing can change on the fly

Cons: Requires support of free customers, you have to come up with features people will actually pay for, requires a lot of conversion rate optimization to work well

Freemium can take many forms and it is constantly evolving. Below I’ve listed some of the versions that are common right now.

In-app purchases of virtual goods

Aside from advertising, this is the model that is driving the app economy right now. It’s the monetization engine of the freemium strategy. You make the app free to download and use in its entirety. Users have the option to experience the whole app without ever paying at all and in fact, it’s typical for the vast majority of them to do just that.

But the small number of users who buy virtual goods fund the whole operation. And within that pool of paying users will be a small slice of “whales” that pay large sums for virtual goods. There are different categories of virtual goods that you can offer in your app:

Currency – The process usually starts with the app user buying some amount of a “hard” currency, that is, a currency that was exchanged for real world dollars. Once that happens, the real world dollar value has been transferred to the virtual world of the app and cannot be extracted. It must all remain within the app from that point forward. That “hard” currency can then be spent within the app on other “soft” currencies used to advance the app experience or spent on other kinds of virtual goods.

Upgrades – This can be any feature that improves the app experience, though commonly it would be something like improving the strength of a game character.

Items – This can be anything within the app that is persistent once purchased and you can look at it. Players in some games are willing to spend a lot of money to get very rare items that can be seen by other players, status items basically. It’s also common for items to confer an upgrade as well, making them worth the money to players.

Consumables – This refers to any benefit within the game that disappears once used. The most common example is anything that speeds up the game play. Time is the most valuable commodity anyone has, so paying to advance a game more quickly is a very typical mechanic and one that some games rely on as the only real monetization mechanic.

Gated features

This is a freemium model in which you charge for extra features that are not included in the base app. Probably the most common example is an ad-free experience, though relatively few people (~4%) are willing to pay for that. There are more innovative examples though, and it’s a good way to monetize an app.

You can set the gate at any point in the experience, so the user gets to try out the app and hopefully get addicted to it before you ever show them the pay button (potentially). It also gives the app time to create a need for those features that you’ll later charge for.

Gated content

Another riff on freemium where you’re gating content instead of features. Publishers charging for article content is a good example, so are added levels in games. My favorite example of this, which was super lucrative for the developers, is the Walking Dead game.

It had a model that was very different from most games, you viewed the content in episodes and had to pay for bundles of episodes past the first few. I admit to having bought them all, at a cost of $20, and I did so in one purchase because it was clear after the first couple that I’d want them all. $20 per person starts to add up to real money after a while.

Incentivized/Value Exchange

For many years, there have been offer walls that grant users virtual currency or virtual goods in exchange for doing something of value to the advertiser. There are a few forms of this that are common within apps.

Pros: Very flexible, free for users, far more profitable per unit than standard advertising

Cons: The inventory is more limited than standard ads, can be harder to integrate than ads, requires more of the user's attention than standard ads

Video

The most common form of value exchange is for users to watch a video or play a short game demo in order to earn virtual currency. It's easy to inject watching a video into the app experience and there is plenty of demand for this type of ad format. 

The downside is that the user has to watch the full video (or get even farther down a funnel) for you to get paid and the payout--while higher than standard banners--isn't as high as the other options below.

Polls

Paying users virtual currency to complete polls is a fast growing option for monetization. I think it hits a sweet spot in terms of payout versus user requirements. Polls tend to pay less than offers but far more than rewarded video views. The user never has to enter credit card info so the barriers to completion are lower than for offers. The user is essentially being paid for their data and their opinions. This is another fun and easy option for monetizing users who want virtual currency.

Offers

The last and least common method is offers. With videos and polls, the user is basically getting paid for their attention. In this case, they are getting paid to be a lead. Signing up for a free trial of Netflix used to be a very common example of this, though users don't always need to give out credit card details. Filling out a lead form for a high value purchase can also work. Offers usually pay very well but it's much harder to get a user to do that than watch a video or take a poll.

These methods used to be known as "incentivized" actions but that has become a bad word. It has been replaced with the euphemism "value exchange" or "rewarded" which sounds less sketchy but means exactly the same thing. And there’s nothing wrong with this at all, it’s exactly the same idea as credit cards issuing membership reward points for using their card.

There are now easy ways to add a rewards system to your app, SessionM is a company that can drop a whole reward system right into your app. 

Advertising

As with the internet in general, advertising in apps is one of the main ways of monetizing your app. In-app advertising is often more profitable than mobile web advertising for the same number of impressions so it's an even better opportunity than advertising on web sites. There are many types of advertisements you can run in your app, but they will largely be some version of one of the types below.

Pros: Easy to implement, money starts flowing immediately, requires no direct payment from users

Cons: There is a cost to the user experience, requires a lot of users to make real money, can be complex to optimize, bad ads like redirects can be a horrible user experience

Sponsorships 

A sponsorship is when an advertiser works with an app to deliver an ad experience that is richer than a standard banner campaign. That could simply mean that on a given day, all of the standard ads in the app are for that one advertiser (that’s called a “takeover”) or that a virtual branded item is given away in a game or a branded location is made available in a game. It could also mean that an article is published in the app that was written by the advertiser. 

As you can see, the parameters of a sponsorship are limited only by your imagination and technological abilities. Sponsorships also tend to pay far better than other forms of advertising. However, you’d typically need a direct sales force to sell sponsorships and a lot of users to see them in order to execute them.

Banners

Standard banners are still the fuel that powers the digital ad economy. Whatever you have heard about the demise of banners is probably overstated. However, the standard 320x50 mobile banner probably will be the first format to die just because it’s a small, awful branding tool.

It remains the case that by far the easiest way to start earning money from your app tomorrow is to drop a standard banner at the bottom of the screen in your app. Unless your app gets a ton of usage you won’t get rich this way, but it is a very easy way to go from making zero dollars to making something. Once you start optimizing the performance of these banners the world suddenly gets very complicated, but you can cross that bridge when you come to it.

Interstitials

Interstitial is the ad industry term for a full-page, interruptive ad unit. After standard banners it’s the second most common unit. Because it takes up the full page, it usually performs far better for the advertiser (higher click-through rates). There is much more space to explain the product being advertised and convince the user to click through.

It’s also fairly easy to accidentally click through, which accounts for some of the higher click-through rate. As a result of all this extra performance, they also tend to pay a lot better than standard banners. Most apps will only be able to show a small fraction of their total ad inventory as interstitials because they are a relatively aggressive unit. It’s a very valuable fraction though.

Video

Video is an interesting space. It can take a lot of different forms, fitting into different sized boxes and different user experiences, but it’s still hard to fit it into most apps in a way that isn’t annoying to users so it often runs inside the aforementioned interstitial units. Along with that supply constraint you have an incredible tidal wave of demand for video inventory. There are a few reasons for the huge demand for video ads:

1. Companies that run TV ads already have lots of video assets and would like to re-purpose them for mobile ads.

2. Video is a great format for making a brand impression, which is why TV ads have long been so popular.

3. Video is also a great mechanism for drawing high-quality users into new apps, which means all the big gaming companies are also interested.

There’s currently a massive imbalance in supply and demand, which means you can make a lot of money if you can figure out how to show video in your app.

Native Ads

Native ads are ads that match the form and function of the page. They are not interruptive; they are designed to blend in, and hopefully even offer some utility to the user that they wouldn’t get otherwise. The ads you see in the Facebook news feed are a great example and they make billions for Facebook.

Outside of Facebook, Google, etc. they are becoming increasingly popular though they haven’t reached the same critical mass point yet because they are harder to standardize outside of a single platform. The IAB (the governing body of the digital ad industry) defines 6 types of native ads:

1. In-feed units – Like Facebook’s ads.

2. Paid search units – These have been around for a very long time. The way Google presents their paid units—i.e., looking exactly like non-paid listings aside from a slightly different background color—is a classic native implementation.

3. Recommendation widgets – Those “you might also like” ads you see virtually everywhere on the internet. They are considered native.

4. Promoted listings – Product ads placed on a site like Amazon are also considered native. People are there shopping, so showing product ads is native to the experience.

5. In-Ad – These are standard banner ads that contain content that is contextually relevant to the surrounding content of the page. The advertiser gets a guaranteed placement and knows exactly where the ad will show so they can match ad content to the page. If you ask me, this isn’t really native at all, but no one asked...

6. Custom/Can’t be contained – This is a catch-all category for ads that are so native to the app/site experience that the ads can’t easily be categorized. If some native ad purist were to point out that this is probably the only category of truly native ads, I would not object very loudly...

mCommerce

Increasing common and popular is selling physical items within apps. Shopping apps have been appearing left and right lately. There are also ways to add this method to existing apps.

Pros: Value to user is crystal clear, can be more profitable than many other methods

Cons: Requires fulfillment, higher user support requirements, higher potential for refunds, not a great fit for many apps

Selling your own inventory

If you’re selling your own inventory, this was probably the original intent of your app, but it could be added on later as well. This is what many shopping apps currently do, and it’s definitely a proven method for monetizing. The downside is that there are a lot of moving parts in a physical products business (shipping, returns, inventory, etc.) that don’t usually apply to an app business.

Selling merchandised items (e.g., Amazon Merch)

Quite a bit easier is just merchandising your app. Programs like Amazon Merch allow you to pretty easily create items that are branded however you’d like and sell them, then you just pay the fees and collect the profit without actually touching any merchandise.

To merchandise an app you need either a loyal following or you need to get creative in terms of offering merchandise that users would actually want.

Affiliate sales of physical goods

One step further away from the sale and easier yet is to become an affiliate that pushes users to the storefront and collects a small percentage of the sales generated. Amazon’s Associate program is a great example of this.

Affiliate sales

This is a very broad method that cuts across other categories. Other companies have products, goods, services, software, etc. that the users of your app might want. You refer your users to the products they need and you collect a commission for each sale—simple as that.

An example of this is Clickbank where it is common for product owners to pay 75% or more of the initial purchase price (for info products usually). There are also programs for getting commissions on physical goods, software downloads, SaaS products and much more. This is a monetization opportunity that can be combined with other methods seamlessly and can be a serious driver of revenue if done correctly. 

We’re not talking about selling people irrelevant stuff (that’s pretty hard if you’ve ever tried it). We’re talking about adding value by introducing people to products they would value if only they knew about them. And if that’s the mindset you go in with, you’ll also make a lot more money.

Subscriptions

One of the oldest and best monetization methods is subscriptions. There’s really nothing quite like recurring income. A famous example of this is the New York Times site/app that allows you to read the first 20 articles per month for free and after that you have to pay a monthly fee. 

My personal favorite example is the Profit Bandit app. It’s a SaaS (software as a service) product that uses the app as the user interface. It’s for people who sell products on Amazon that they buy in their local area. It scans the UPC code of any item and then shows the price they can sell it for on Amazon, factoring in a variety of fees that can be levied by Amazon.

For Amazon sellers out scanning products at Big Lots, a smartphone app is the perfect way to interact with the software and the service it performs is very hard to replace so users are happy to pay the required monthly fee.

Another example worth mentioning is that many apps package up premium features into a “VIP” offering and charge users on a subscription basis. This is common in the dating market. It's worth mentioning because many apps can do this as a bolt-on monetization method, but the value has to be obvious to the user.

Other Monetization Methods

Sell user data

This is one of my favorite methods, and it’s not nearly as creepy as it sounds. I’m going to massively over-simplify this here and go into greater detail elsewhere.

A handful of dominant tech players (Google, Facebook, Twitter and others) have their own proprietary data on...nearly everyone. That gives them HUGE advantages in selling advertisements. All companies in the space who are not one of those leading companies also desperately needs that data to execute effective ad campaigns, and they are willing to pay to get it.

Now listen carefully, that data is not personally identifiable, they can’t link that data to specific users. That would be illegal. The industry acronym for that is PII (personally identifiable information), and advertising companies are not allowed to collect that info. And as an industry veteran I can tell you with certainty that all legitimate advertising companies are completely uninterested in PII. They only want information that allows them to show better (more relevant) ads. Users want that as well. In general, people don’t hate ads. They hate irrelevant ads. And targeting data (like the fact that you’re currently in the market for a car) is the key to delivering those ads. 

Now back to the monetization opportunity. Your app has data on users that can be sold into this data marketplace, all apps do. The value of that data depends on scale (you need a lot of users to make serious money) and quality (essentially the legitimacy and completeness of the data). In my opinion, if you have a decent size user base and you’re not doing this, you’re just leaving money on the table.

Best of all, this method can be layered on top of any of the other methods with zero conflict. It's really just free money if you bother to pursue it.

White label your app

If your app fulfills a need that is generalizable to a broader industry, you can potentially white label (their technology, your branding) the platform or even the user base and charge for it. An example of this is dating apps. The technology that allows people to meet and flirt with one another is repeatable in infinite variations. Additionally in this case, the database of users of the app can also be used to create other apps.

Say you want to create a dating app. Instead of writing all the code from scratch you could purchase a white labeled dating app and immediately offer an app full of flirting features like chat and people search. Furthermore, you could offer access to your database of users, filtered to fit the needs of the app.

You want to create a dating app that puts tech geeks in touch with other tech geeks? No problem! Just filter the larger database of users for geeks and use the same white-labeled app features. See how that’s cool? That is but one example. Really any app that has been developed from scratch to meet a specific need can be white labeled. The possibilities are endless.

APIs

Does your app create data that would be useful to other companies? If so, you can charge other companies for access to your internal data and create a robust revenue stream. What that means exactly is so broad that I can’t possibly list all the permutations. However, I can point you to this primer that succinctly describes the potential in this area. 

Donations

This is an option so I’m listing it. If you’re doing something humanitarian or truly charitable, by all means you should ask for donations. However, if that’s not the case, then you’re just begging and you should choose some other option from this article.

Sell your app

This is a very straightforward method of monetizing although it’s obviously a one-time deal. I mention it both in an effort to be comprehensive and also because many developers probably don’t really consider it as an option and there are a variety of circumstances in which simply selling your app is the best option. It’s also a much easier option than in the past.

There are a few things to know about selling an app. One is that your app is probably worth less than you think. Everyone reads the stories of apps selling for huge money, like Instagram selling to Facebook for a billion dollars (a steal for Facebook in retrospect). The apps that sell for big money are the ones with a large and rapidly growing user base. If you have an app like that, you’re likely not thinking of selling. You’re more likely thinking of getting investors, as you should.

Everyone else needs to contend with the cold, hard fact that your app will be valued as a multiple of the money it makes. Web sites are typically valued at 2-3 times the annual net profit of the site. Apps tend to have slightly better multiples, although fewer buyers know what to do with them so they can be a little harder to sell. I think both of those conditions will normalize over time, with the pool of buyers expanding and the multiples falling.

If this is of interest to you, there are brokerages that can help you with this process. It's generally worth using them because they can facilitate the process and they also have ready access to a pool of potential buyers. If your app can sell for $25k+, then some options would be Empire Flippers, FEI and Quiet Light. If it's a smaller sale then you can use a self-serve marketplace like Flippa

But here’s the thing, if your app currently makes $0, that’s what it’s worth. Doesn’t matter how cool you think it is and it definitely doesn’t matter how much time or effort you spent creating it. Buyers don’t care about that. With few exceptions, it can only be sold for money if it makes money.

Aren’t you glad you read this article?

How to Choose an SSP for Your Mobile App

To make the most money from the ad space in your app, you should try to get access to as much demand as possible. Ideally you'll have access to several large SSPs/exchanges and can make them compete for each impression. However, you can only have one main "traffic cop" that operates the auction and controls all the rest.

That's the one you have to choose carefully. 

Each ad exchange will have a mix of demand. Many advertisers use multiple exchanges but some only use one. Exchanges can also have exclusive deals with advertisers that are particularly lucrative. All this means that the demand on each exchange is different enough to warrant participating in multiple exchanges if you have enough inventory to justify the effort involved.

There’s extra effort in managing additional demand sources in any case, but SSPs each like to think of themselves as the only SSP a developer uses and thus it’s usually a bit of a pain to set up one SSP as a demand source within another SSP, but it can almost always be done.

Below are the factors to consider when selecting an SSP to run your auction:

Prominence

Generally, I prefer to choose only from the largest players in the space. There are always new upstart SSPs, and there are advantages to working with younger startups. Their support staff will tend to have more hustle and they more readily accept suggestions for improving their product.

However, it can also be the case that their SDKs have more bugs, they probably lack some features of the larger players and like any startup they have a higher likelihood of not being around in a few years, which can leave you hanging with unpaid invoices at some point. The large SSPs are pretty good at what they do so always start there.

Geographical Strengths 

This is primarily a US vs. non-US question in my view, but I’m sure there are folks with more experience and finer-grained preferences for other countries. Some exchanges will be better equipped to monetize ads in the US or internationally.

All SSPs probably aspire to be global, but only a few really are and even then they’ll likely perform better where their business originally started. Choose an SSP that is strong in the area where most of your impressions originate.

Ease of Use 

Some SSPs are much easier to use than others. You can get used to anything, but running ads is a case where even a small operation might have to work with 10-20 different interfaces to collect data and manage the ads. You don’t want your SSP adding to that complexity. The only way to know if a given system works for you is to try it out but it's usually not hard to get a demo if you're serious about implementing one.

Ad Quality 

Another very important aspect of an SSP is ad quality. When we talk about ad quality from the app publisher's perspective, we're talking about issues like ads misaligned in the space, blank ads, ads that are slow to deliver and worst of all, redirect ads. 

The degree to which an SSP monitors and removes these for you is a HUGE deal. If you run a lot of ads you can easily spend a good chunk of your day trying to capture redirects on a Charles log and figure out where they came from. I've done a fair bit of that and it sucks. You want an SSP that will be aggressive about ad quality.

Another related factor is the ease with which the SSP’s interface allows you to deal with ad problems when they arise. Is it easy to block specific campaigns, advertisers, DSPs and categories of advertisers? Is it easy to block certain types of ads (such as ads that mimic site navigation)? Is there an ad quality team that can help you resolve the issues when they arise?

It’s a good idea during the consideration process to have someone walk you through all the steps of dealing with bad ads because there’s no doubt you’ll need to do so. It's not an issue of "if" but of "when."

Reporting

The data that you receive back from the SSP about your ad performance is critical to your ability to improve your advertising revenue. And between direct ad serving, exchange ads and network mediation, there are a lot of different sources to bring together in one set of reports.

You should have some kind of view into the exchange that is real-time or nearly so, as that’s a good sanity check of other reporting if you think something is going wrong. As much as possible, the SSP should help you gather data from other networks/demand sources in their interface and reconcile it with their own request and impression figures.

There will usually be some discrepancies here, so this is a differentiator among SSPs. Most have pretty robust reporting in general, but you have to constantly question the validity of the numbers you’re seeing and cross check them. To whatever extent they can help minimize this, the happier you’ll be.

Support 

The importance of good support can’t be overstated. It’s woven into a number of the other items here. You need a well-trained support contact that can help you resolve any issues you encounter. That main point of contact can draw in more technical members of their team or escalate issues to other departments if needed.

The contact at your main SSP is someone with whom you should have regular meetings to discuss any issues, get updates and so you can always push them on how to improve your performance. Your contact should have a very thorough understanding of their own systems so they can help you squeeze every penny out of your demand set and even advise you on broader monetization strategies.

There are truly wide differences in this area. Different SSPs have different cultures and some are more focused on great support than others. You also need some kind of support access that is available 24/7 because ad issues can happen at any time. A general support email is fine for this purpose, but it needs to be responsive.

Demand Integrations 

SSPs may offer pre-configured ad integrations with key demand partners outside of the exchange. Certain partners will be common to the mediation set up of many different apps, so it makes sense for an SSP to just work with them right out of the box. Some SSPs are also aggressive about getting server-to-server connections with demand partners, which are easy to set up and expand your access to more demand. 

The more of your demand partners that have official integrations with your SSP, the better off you’ll be. It will be much easier to integrate them, you’ll likely have fewer reporting discrepancies, and if there are issues with the integration, the SSP will view them as their own problem to fix. Conversely, while it’s fine to set up officially unsupported network partners, when there are issues with those integrations the SSP will largely regard that as your problem.

Programmatic Features 

There are different ways that advertisers and app developers can interact on an exchange. The standard method of just making your inventory available and allowing anyone to bid on it is called the “open exchange.”

You can also package up your inventory and set price floors on the packages, creating programmatic packages. This can be helpful if you can use your first party data to create attractive ad packages that the buyers may not otherwise know about.

You can also form private marketplaces (PMPs), where you’re giving certain key ad buyers priority access to your inventory in exchange for higher rates. There can be other permutations as well. However you want to sell your inventory, be certain that your SSP can facilitate it to make it accessible and ideally, easy for you.

Fees

As you might imagine, there are always fees for using SSPs. That said, you want to carefully comb through the contract for any fees that may apply to you and then try to get them reduced.

Always. Always ask for lower fees.

Your luck getting them lowered will be closely related to the volume of impressions you bring with you but it never hurts to ask. You also want to make sure you understand how the SSP gets paid. They can position it as "free to developers" but they are always getting paid somehow, and you need to understand how.

Getting Paid

Large SSPs like Google AdMob and MoPub will pay their bills. They are backed by huge, public companies so you can feel secure that you'll get paid. However, large companies don't necessarily pay you quickly. Having to wait 30-60 days (called net-30 or net-60 payment terms) after a month closes to get paid is pretty standard. 

Make sure this doesn't drag on too long though. Several times I've seen ad partners propose net-120 terms. That means that after a month closes they want you to wait 4 months (?!) to get paid. Don't accept that. Net-90 is the longest term you should ever consider and that's really too long. There are companies that will pay you quicker than 30 days but that involves factoring receivables, which is a topic for another day.

The other thing to look out for here is who holds the payment relationship. If AdMob or MoPub is your SSP, they'll pay you directly for ads that cleared on their exchanges but your mediated networks have to pay you separately.

I have seen some services that do all this for you. You run as many demand sources as you want and they pay you one big check. I would think long and hard before doing that. It's very convenient, but it means that one company (usually a start up, not a public company) is in charge of 100% of your revenue. If they go out of business, you are out of luck. And you won't know that until you stop getting paid, there's no advance warning.

SDK

For an SSP to function, you’ll need to install at least one SDK (though probably several). You want to make sure that SDK is as light as possible, frequently updated and well documented. If your app is non-standard in any way—a prime example would be a hybrid app—then you’ll want to check the forums and see what difficulties other developers have had in integrating and maintaining the SSP’s SDK.

Though using a very large SSP is generally advisable, one drawback is that they may be reluctant to make any changes to their SDK to suit your situation. Similarly, some SSPs package up commonly used SDKs from demand partners such as Facebook with their own standard SDK. If you don’t want to use the pre-packaged demand partners be sure they can give you a version that is unbundled because you’d be adding extra weight to your app that you have no intention of using.

And there you have it, a comprehensive checklist of items to check before committing to an SSP partner. Setting up an SSP properly requires some significant effort on your part, so the switching costs can be high. Inspect your options closely and put them through the wringer before making your choice.

What Is In-App Header Bidding?

Our kids are young and rough on their clothes, so my wife often visits what are called “tag sales.” It’s one of those things that I didn’t realize existed prior to becoming a parent. A mother’s club usually organizes a tag sale and it’s basically a large yard sale where everything is tagged with a color-coded price tag.

Because the inventory is sort of random and inherently limited, you’re far better off arriving early. So tag sales often end up looking like a Walmart on Black Friday, with people lined up early in the morning waiting to get in. All this to get the most desirable used clothes.

If you’ve been running ads you might have noticed that the competition for your inventory is a lot like that tag sale. There are many entities that want to take the first look at what you have to offer and buy it for themselves before anyone else takes a look. 

What Is Header Bidding for Apps (in-app header bidding)?

Header bidding for apps is an auction that runs before the ad server auction and produces a single winner with the highest bid for the ad impression. That bid then competes inside your normal ad server auction for the final win of the impression and delivery of the ad.

That was a mouthful. Let's break that down a bit. 

The Fundamental Conflict

The incentives of the players in the ad ecosystem are usually misaligned. Buyers want to cherry pick ad impressions at the lowest price possible, and sellers need to sell all their inventory at the highest possible price.

For ad buyers, their ideal situation is to look at every ad impression and then take the ones they want before anyone else sees them (i.e. the tag sale). However, most ad servers can only accommodate ONE buyer in that coveted position.

That's bad for the ad seller (publisher) because while they can demand that the price be above a certain level (called a "floor" price), they can't take advantage of auction dynamics to drive up the price. 

There is one entity that is in a position to see all inventory and pick off what they want...the company running the ad server. That's a very profitable position to be in, so companies like Google and MoPub have done very well for themselves by running the ad server and the auction for impressions. 

The Rise of Header Bidding

In the web environment, this has been going on for a long time. When Google bought DoubleClick, they took over one of the dominant ad servers and got access to a lot of publisher inventory. They then created their ad exchange (AdX) and gave it the first look at all that inventory. Other ad exchanges view that as an unfair advantage (and I agree that it is). 

That worked very well for Google for quite some time. In the past few years, a technology called header bidding has been gaining steam. Header bidding was created specifically to deprive Google of that unfair advantage in looking at all the inventory first.

Header bidding allows competing ad companies to bid in an auction that is run in the header of the web page, before Google gets a chance to see the impression. The winning bid from the header auction is entered in Google's normal auction as a line item and only becomes an ad impression if it also wins Google's auction. 

This allows companies other than Google to participate at the earliest stage, increasing the bid density (more bids is better for the seller, like any other auction) and producing more revenue due to the increased competition. Header bidding has been a big win for web publishers.

In-App Header(?) Bidding

This same exact situation also exists in the mobile app environment. There are ad servers and SSPs with dominant market positions--like MoPub, and again, Google--who use their optimization layer to give their own exchange the first look at an app’s ad inventory. This of course benefits those companies and aggravates competitors and app publishers seeking the highest price for each impression.

Side Note:

The question mark in the sub-heading is because apps don't have headers. There is no universal name yet for this technology in the app environment. Most people call it "in-app header bidding" because everyone knows what that means even though it is technically inaccurate.

In early 2016, AppNexus introduced their PriceCheck product. To my knowledge, that is the very first time a product was released for in-app header bidding. I'm not sure if that product is still around, but suffice it to say that it didn't catch on. Here we are years later and in-app header bidding is still in its infancy.

Why Is It So Slow to Catch On?

Someone asked me this a couple years ago and I didn't have a great answer. It seems like this is a no-brainer and the upside is huge, so why hasn't it caught on faster?

SDKs Suck

The mobile app world has an additional challenge for ad companies that want you to use their products, which is that they usually require you to install an SDK. It used to be easy to get app developers to throw in another SDK, but those days are long gone. Every SDK comes with potential problems so developers have become extremely selective about which ones to use.

One way of implementing in-app header bidding is client side, by installing the SDKs of the various bidders. That can add a lot of bloat to the app though. The other is server side, which has limitations that the buyers dislike and it requires a lot of coordination between the SSPs bidding and the company running the auction. So there's no perfect solution yet. 

Focus of App Developers

Website owners love to get under the hood and tinker with the ad monetization of their sites. App developers like to improve their apps and just plug in monetization that works without a lot of fuss. Those are broad generalizations, but there's some truth to it and the products reflect those preferences. AdMob is a much less robust and convoluted interface than DFP, for example. Header bidding has traditionally been a heavy lift from a technology and ad operations perspective so it has been slow to catch on with app developers. 

Number of Bidders

There are plenty of SSPs that websites can choose as bidders in a header bidding auction. Mobile apps have fewer choices, there aren't as many mobile app ad exchanges and there has been a fair bit of consolidation in the past few years. 

Bottom Line

My philosophy is that it’s beneficial to be plugged into as many unduplicated demand sources as possible. Header bidding for apps could be a relatively easy way to expose your app to new ad demand sources. There is a big "IF" though. IF you can use in-app header bidding without introducing a lot of new SDK headaches and it can be done fairly easily, it could be well worth pursuing. 

What is an SSP?

There are very few industries that create as many acronyms as the advertising industry. We rapidly produce new ones and knowing what they all mean is the mark of an insider. Over my nearly 20 years in advertising I've seen them all. One that has been very durable over much of that time is the SSP. 

What Is an SSP for Mobile Apps?

SSP is an acronym for Supply Side Platform. It is a technology platform that enables app developers to sell their advertising inventory at the highest possible rates by optimizing across different demand sources (advertisers). 

Now, let's dive a little deeper and see how SSPs fit into the advertising ecosystem.

Understanding the Marketplace

The advertising ecosystem is typically described in the most basic terms of a marketplace: demand and supply.

Advertisers and their entourage of assistants (trade desks, agencies, DSPs and other middle men) are the demand side. They want to buy advertising space. 

Publishers of apps or websites and their (much smaller) entourage are the supply side. They have advertising space to sell. 

The SSP is in between the two and usually pitched as an aid to publishers; they intend to help publishers get the most money for their ad inventory. In practice, it's often more complicated than that because the largest SSPs usually operate exchanges as well, so they are operating the marketplace and helping publishers monetize their ad inventory. 

There Are Many DSPs and Very Few SSPs

You may have heard of DSPs, or Demand Side Platforms, because there are a lot of them. DSPs are the technology platform that allows advertisers to more efficiently buy ads.

In the middle is an exchange where the ads are actually traded. So in the simplest terms, SSPs allow app owners to sell ads programmatically and DSPs allow advertisers to buy ads programmatically. 

There are hundreds of DSPs in existence and only a relative handful of SSPs. There are a couple reasons for that.

One reason is that the barrier to entry to become a DSP is pretty low. You can use off-the-shelf technology, get a seat on an exchange and you’re ready to start buying ads. Actually making money at it will be another matter, but getting in the game isn’t that hard compared to creating an SSP.

An SSP needs to build a base of app developers that use their technology. But to compete, an SSP needs a lot of functionality that actually works well if they want to retain that base of developers. Also, with very few exceptions I can think of, SSPs also operate the exchange. So there is a lot of technology that must be built to become a competitive SSP.

The second reason is that having a lot of marketplaces is inefficient. Each DSP is a bidder on the exchange. You need a lot of bidders (DSPs) to run an efficient marketplace, but you don't need a lot of marketplaces (SSPs). 

How Does an SSP Sell Ad Inventory?

At a high level, there is a three-step process for clearing (selling) an ad impression in an SSP.

The first step is to check whether it can be sold directly. SSPs usually allow you to insert direct deals and flight them with a higher priority level than other inventory. That ad serving functionality is typically not as robust as a traditional ad server. The targeting options might be more limited and there’s usually no ability to forecast the future availability of inventory. 

However, unless you have several direct ad salespeople on staff, those limitations shouldn’t come into play very often. The SSP checks an impression against any direct campaigns in the system and if it matches it will be cleared there, if not, it goes to step two.

Step two is where the inventory is cleared in the SSP's auction. The SSP auction is too complicated to cover here, but it often includes one or more exchanges and one or more ad networks that compete with one another for the impression. The SSP determines the winner of the auction and sends the impression to the winning partner for final display.

Step three is dealing with remnant inventory, which means no one in the auction wanted the impression. In that case it comes back to the publisher, where they can clear it using house ads, cost-per-action offers or remnant deals struck with ad networks.

The execution of this process is much more complicated and not as linear as I’ve described it here. But any given impression is usually offered to direct buyers and to one or more exchanges and ad networks at various price points until it is sold (or not).

Other SSP Responsibilities

Ad Quality

That’s only one facet of what an SSP does. Another important aspect is allowing the app developer to control the quality of the ads users see on their apps. This is an area where the capabilities of SSPs vary more widely.

It is possible to block ad campaigns or advertisers on any exchange. It’s also possible to block whole categories of advertisers, like those running ads for gambling. There are relatively few situations in which you can’t block the ads you want to remove in an exchange environment.

The issue is that you still have to monitor ad quality because bad ads will always get in one way or the other. If the impression gets to the ad network mediation level, then the problem gets harder. The SSP isn’t responsible for ads that come from the mediated networks, so if the bad ads originate there you have to track down the responsible network and block the ads within their system.

Reporting

Another facet of what an SSP does is to provide reporting so that you can analyze and improve the performance of your ad monetization. The features will vary but the SSPs reporting on direct campaigns and anything that happens on the exchange should be quite good.

Reporting on mediated ad networks is usually fraught with errors and discrepancies that have to be sorted out because different systems will always count things a little differently. I’ve worked with most SSPs in existence and have never seen any with rock solid network mediation reporting.

Above are the main characteristics of an SSP, though if you dig deeper there are many more complexities to uncover. If you want to dig a little deeper, this article shows you how to choose an SSP that suits your product.

How Can I Get Relevant Ads to Show in My App?

One question that I hear from app owners is about the type of ads they see delivered in their apps from ad networks. The ads they see are often not really relevant to the content of the app, which seems like a huge missed opportunity when the app has a well-defined theme. 

How Can I Get Relevant Ads to Show in My App?

You can do this by manipulating the categories of content that are allowed to show in your app. However, it is unwise to do that beyond the bare necessities of protecting the user experience because it will reduce the monetary performance of your ads.

That's the short answer, here's a longer one.

For example, a friend of mine has a fitness app and he wants to run ads in it that are related to fitness. Makes sense right? Health and fitness is a huge niche with a lot of money and advertisers in it.

You know the user is interested because they downloaded your app in the first place. It seems like a perfect fit IF you could just force the ad network to show relevant ads.

FYI, It Can Be Done

It is possible to do this. All ad creatives (meaning the actual image that you see when the ad displays) are categorized according to the standardized Internet Advertising Bureau (IAB) categories. You can see the IAB categories here.

Because there are certain categories of ads that many developers may want to specifically exclude such as dating or gambling, most SSPs and some ad networks will allow you to block IAB categories. This is also true for the ad buyers, who make a lot more use of this blocking capability.

If you put a block on a category, no ads from that category will appear in your app. So, if you block all categories other than the health and fitness category, then ads from that category are all you’ll see in your app!

But...Don’t Do It

Now that you have the know-how to do it, I’d strongly advise you not to do so. There are a lot of reasons why a given user may not see ads that are contextually relevant to the site.

The goal of an ad network or an SSP is to show the most profitable ad at any given moment, not the most contextually relevant ad. And as the person who receives most of that money, it’s in your best interest as well.

Here are some reasons that you might see ads that appear irrelevant:

Retargeting

Even if you haven't yet to run your first ad, you’re probably familiar with retargeting as a consumer. You go to Amazon, put an item in your cart, then leave the site. You then see the item in numerous ads all over the place because Amazon is “retargeting” you to bring you back and get you to complete the purchase.

Those ads are extremely effective because you’ve already shown a serious interest in the product. You can probably figure out why you are seeing certain ads on your device, but when you look at the ads other people see, retargeted ads generally look irrelevant because they’re personalized to other people's interests.

Short attention spans and varied interests

If you go to the Huffington Post and click on an article in their politics section, on the right hand side you get recommendations for other articles on their site. Do this and you’ll notice that you get some suggestions for other political articles but you also get suggestions from their entertainment, business and other categories on their site.

News sites have figured out that people have short attention spans and varied interests so they show articles from other categories. It’s the same with mobile ads. Just because someone is using a fitness app doesn’t mean that the best course of action is to pummel them with Nike ads.

Frequency capping

This is the ad tech term for only showing a given ad to a given user a certain number of times. This is done to increase performance of the ads.

Early in an app session on the example fitness app you might see some Nike ads, some Fitbit ads and some ads for other fitness apps. As you hang around longer and longer on the app (which developers of the app tend to do) those ads will hit their frequency caps and you’ll start to see other ads that come from deeper in the ad line up.

Contextual relevance isn’t the only targeting concern for advertisers

In fact, it’s not even the primary concern. Advertisers can choose from a wide range of targeting options when they buy ads.

They can target based on demographic data like age, gender and location, on behavioral data such as the retargeting example above, or really any other data available (which is a vast pool).

If an advertiser sees that a user is in the small target audience they’ve defined—say a 50-year-old male model train enthusiast from El Paso, TX—then they will show their ad and they won’t care that it happens to be inside a fitness app because that dude is hard to find.

Conclusion

That’s hardly an exhaustive list but it’s enough to give you an idea of why your ads don’t appear relevant to your app. What you’re really seeking as an app publisher is good-looking, high-quality ads that detract as little as possible from the user experience and pay you as much as possible. 

You can block a few categories to make sure no ads appear that are offensive in some way, that's a best practice. But aside from that you should let your ad demand source do what they need to do in order to make you the most money from your ad space.