Author Archives: Ben
Author Archives: Ben
There’s something I still love about an old-fashioned, paper insertion order. It hearkens back to a now-distant, simpler time in the advertising world. You know…like 5 years ago.
Insertion orders (IOs) are usually digital but you still see them once in a while, and they still represent the easiest and usually most profitable way for a developer to sell ads.
In case you’re not familiar with the term, an insertion order is just an agreement between a buyer of ads and a seller of ads. It defines the relationship between the two for the flight of a given campaign. IOs are fairly standardized and the official version sanctioned by the IAB can be found here. That one is the foundation of most IOs you’ll see these days.
Insertion orders govern the terms of a direct sale. That means you need to go out and source a deal. The advertisers that you would reach out to on your own would be the end advertiser, the company ultimately paying the bills or their agency. That’s what would get you the highest payout, because you’re cutting out all the middlemen. The downside is that those deals are very hard to find and assemble.
The companies that would reach out to you for a direct deal are—you guessed it—middlemen. That doesn’t mean that the deal is bad though. Middlemen can often bring you deals you couldn’t very easily get on your own, so you just have to look at them in the proper light.
There are a number of ways these deals can fall apart, so you have to know what to look for.
In general, the better the deal seems, the more suspicious you should be. In an extreme example, I’ve seen companies send over a completed IO in the very first introduction email that has a value of over a million dollars. The odds of that panning out are roughly the same as winning the lottery. So let’s talk about what can go wrong.
I put this one first because unfortunately it’s an issue in advertising and should be in the front of your mind. Be sure to do some diligence on the company making the proposal. Check out their site, check their references, check how well funded they are if they are a start up. But most importantly, ask around among your peers. Look for any indication that they are in any kind of trouble or are too small to work with.
A related problem to #1 is payment terms. It is common for the developer to get paid 45 or 60 days after the close of the month (i.e., net-45 or net-60 payment terms). However, you’ll sometimes see companies requesting net-90 terms. Do you really want to be paid a full quarter after the impressions were delivered?
Another issue to keep in mind is the “pay when paid” provision. The exact language varies a lot but this allows the company not to pay you until they’ve been paid themselves. They often give themselves a cushion after that, such as paying you net-30 from when they get paid. Small developers may not be able to avoid those provisions and they are inherent in the standard IAB insertion order so they are fairly standard. There's not much to do about this one, it's just something to be aware of.
Every IO will usually have an out-clause that allows either party to cancel the agreement with short notice, usually 24-48 hours. To some extent, this is a formality because in practice it is almost a moot point. If you as the developer don’t want to participate any more, you can just stop flighting the ads. If the advertiser wants to stop spending, they can just say so and you have the one or two days to stop, which is almost an absurd amount of time because it only takes a few minutes to stop a campaign.
What you as the developer seek to avoid is going through the effort of putting up a campaign for it only to run for a day or two and then stop. Then you’ve gone through all the work of bringing the campaign live and you have to go through the work of sending out an invoice for $75 and collecting it to close out the deal. There are plenty of companies that will put you through that process because it allows them to test for very low risk.
If you have some clout or you just want to minimize this risk, you can ask the company to pre-pay a portion of the IO and make that portion non-refundable. That way they have some skin in the game. Smaller developers just have to be very choosy about the deals they run. Make sure that you see a clean fit between the type of ads the company is proposing to run and your app(s). You need to believe there’s a high probability of it working and you making a substantial amount of money, whatever that means to you.
To new publishers, this is probably the least obvious problem but it has killed many a deal. Almost without exception, any demand source will want to use their own impression counts as the ultimate record for payment purposes. The IO will usually say that their own internal numbers “control.”
If their numbers are close to your numbers, that’s no big deal. But if they are paying you a $2 CPM rate and there’s a 25% gap between the impressions you see and the impressions they see, your effective CPM is now $1.50. Discrepancies are so common that they are considered completely normal (10% to 20% discrepancies are usually considered within the normal range). So to some extent you will just suffer this issue but you need to limit it as much as possible and ensure that it doesn’t kill deals for you.
To this point, I’ve assumed that we’re talking about selling impressions. However, many IOs are for performance deals. The terms will specify that the publisher gets paid not for impressions, but for clicks, leads, sales, installs, etc.--some action by the user.
This is a completely different animal in terms of your responsibilities as the ad seller. If a company is buying ad impressions from you, then your responsibility is to make sure you do it correctly (with the correct targeting, flight dates, etc.). It is their responsibility to make sure that they make money from those impressions.
If you accept a performance-based campaign then the responsibility for ensuring that it works shifts to you. That might not be so bad if the action is a click (though the ad creative affects this a lot). But if the action is a conversion of some sort, it can be a real pain to optimize the campaign. And if you don’t optimize the campaign, then the deal is almost certain to fail.
The ideal scenario is running a truly direct ad where you host an image and URL for the end advertiser. In this case, your own numbers often control and the discrepancy is zero. It also avoids any problems with bad ads. If an advertiser gives you ad tags to run, your app is immediately exposed to potentially bad ads. Screen them before you run them.
This is a broad category so there are many ways for it to go wrong. In all cases though, the issue is that the advertiser wants impressions that you don’t have or that you don’t have enough of.
Advertisers often want geo-targeted impressions that are only from a relatively small area. They may also want only impressions from one gender, from certain devices or carriers or operating systems or app versions. It goes on and on and on. They may only want certain ad formats or certain ad positions within your app.
All this must be specified within the IO, but there’s a huge difference between a national campaign with little targeting and a campaign that is only for Hispanic female New Yorkers on Android devices between the hours of noon and 8pm EST. The latter will pay WAY better, but you have to know you can deliver it before you accept it. Even more important than that, you have to know it will end up making enough money to be worth it.
Even with all its warts, I still love to transact ads with an IO. As long as you pay close attention to all the various ways they can fail, you can only do deals that will make you—and your advertising partners—happy with the results.
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.
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.
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 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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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).
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).
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.
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.
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.