Category Archives for "How-to"
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...
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.
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.
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?
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.
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.
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.
MoPub is the other industry-leading SSP option. It was an early entrant in the space and it was acquired a few 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.
I listed MoPub first because it's the number one AdMob alternative you should consider. After this though, these options are listed in no particular order.
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.
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 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 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.
MobFox is the in-app monetization arm of the Matomy group.
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.
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).
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 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 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.
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.
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.
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 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.
This was a gaming SSP called FusePowered that was acquired and rolled into a much larger enterprise solution. Ad monetization is now only one piece of what UpSight does.
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.
Vdopia runs an optimization platform and video ad exchange called Chocolate.
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.
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 and new to the market, typically targeting smaller developers. There are differentiators here, though you have to really dig in to figure out what they are.
Interstitials and rewarded video are the only format options.
20+ demand sources and monthly payouts.
60+ demand sources and flexible payout options.
Ogury acquired this product and turned it into their publisher solution.
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.
Performance native ads.
Native ad network and good mediation add-on for other SSPs.
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.
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.
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.
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.
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 means that the user can download the app for free and the monetization happens later, inside the app experience, through in-app purchases.
Freemium can take many forms and it is constantly evolving. Below I’ve listed some of the versions that are common right now.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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 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...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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:
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.
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.
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.
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."
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
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:
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.
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.
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.
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.
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.