Category Archives for "How-to"
One question that I hear from developers 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 miss when the app has a well-defined theme.
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. Seems like a perfect fit if you could just force the ad network to show relevant ads.
It Can Be Done
It is possible to do this. All ad creatives (meaning the actual image that you see when the ad displays) are categorized according to the standardized Internet Advertising Bureau (IAB) categories. You can see an example of these categories here [https://dev.twitter.com/mopub/marketplace/iab-categorization].
Because there are certain categories of ads that many developers may want to specifically exclude such as dating or gambling (listed as “Card Games”), all SSPs and some ad networks will allow you to block IAB categories. 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!
Don’t Do It
Now that you have the know-how to do it, I’d strongly advise you not to do so. There are a lot of reasons why a given user may not see ads that are contextually relevant to the site. The goal of an ad network or an SSP is to show the most profitable ad at any given moment, not the most contextually relevant ad. And as the person who receives most of that money, it’s in your best interest as well.
Here are some of the reasons that you might see ads that appear irrelevant:
· Retargeting – Even if you’ve yet to run your first ad, you’re probably familiar as a consumer with retargeting. 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 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 for other people, retargeted ads generally look irrelevant because they’re personalized.
· Short attention spans and varied interests – If you go to the Huffington Post and click on an article in their politics section, on the right hand side you get recommendations for other articles on their site. Do this and you’ll notice that you get some suggestions for other political articles but you also get suggestions from their entertainment, business and other categories on their site. News sites have figured out that people have short attention spans and varied interests so they show articles from other categories. It’s the same with ads. Just because someone is using a fitness app doesn’t mean that the best course of action is to pummel them with Nike ads.
· Frequency capping – this is the ad tech term for only showing a given ad to a given user a certain number of times. This is done to increase performance of the ads. So early in an app session on the 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 pool.
· Contextual relevance isn’t the only targeting concern for advertisers – In fact, it’s not even the primary concern when targeting ads. Advertisers can choose from a wide range of targeting options when they buy ads. They could target 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 you’re in the small target audience they’ve defined—the 50 year old male model train enthusiast from El Paso, TX—then they will show their ad and they won’t really 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 looking for is good-looking, high-quality ads that detract as little as possible from your user experience. You can block a few categories to make sure no ads appear that are offensive in some way. But aside from that you should let your ad network—or better yet your SSP—do what they need to do in order to make you the most money from your ad space.
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.
Pros: Simple, easy to execute
Cons: Places a huge burden on the app store listing to convert users, limits your user base, can be a limited monetization method unless combined with other methods
The 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 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 anyway.
You distribute a free app and you then upsell your paid app to those users. Maybe a few random people will pay for the premium version straight out of the gate, but mostly you’re letting people try a free app and then upgrade for a fee to a different app that does the same thing, only better.
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.
Pros: Very flexible, no cost barrier for new users, allows heavy monetization of the best paying customers
Cons: Requires support of free customers, free experience has to be enticing, can be complex to optimize
Freemium can take many forms and it is constantly evolving. Below I’ve listed some of the versions that are common right now.
In-app purchases of virtual goods
Aside from advertising, this is the model that is driving the app economy right now. It’s the monetization engine of the freemium strategy. You make the app free to download and use in its entirety. Users have the option to experience the whole app without ever paying at all and in fact, it’s typical for the vast majority of them to do just that. But the small number of users who buy virtual goods fund the whole operation. And within that pool of paying users will be a small slice of “whales” that pay large sums for virtual goods. There are different categories of virtual goods that you can offer in your app:
Currency – The process usually starts with the app user buying some amount of a “hard” currency, that is, a currency that was exchanged for real world dollars. Once that happens, the real world dollar value has been transferred to the virtual world of the app and cannot be extracted. It must all remain within the app from that point forward. That “hard” currency can then be spent within the app on other “soft” currencies used to advance the app experience or spent on other kinds of virtual goods.
Upgrades – This can be any feature that improves the app experience, though commonly it would be something like improving the strength of a game character.
Items – This can be anything within the app that is persistent once purchased and you can look at it. Players in some games are willing to spend a lot of money to get very rare items that can be seen by other players, status items basically. It’s also common for items to confer an upgrade as well, making them worth the money to players.
Consumables – This refers to any benefit within the game that disappears once used. The most common example is anything that speeds up the game play. Time is the most valuable commodity anyone has, so paying to advance a game more quickly is a very typical mechanic and one that some games rely on as the only real monetization mechanic.
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 (http://www.iabuk.net/about/press/archive/new-iab-uk-research-reveals-latest-ad-blocking-levels#v51rAm6AvjFQGEdB.99). 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.
This is really more of a payment method than a monetization tactic, but it’s different enough that it’s worth mentioning. 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. Signing up for Netflix used to be a very common example, though money doesn’t have to change hands. Filling out a lead form, installing an app or watching a video are also very common forms this can take. In order for this to work, there has to be some desire for the virtual currency/goods in the first place. Then you can get the user to earn it for “free” by completing an action. This used to be known as “incentivized” actions but that has become a bad word and it has been replaced with the euphemism “value exchange” which sounds more elegant 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 (www.sessionm.com) is a company that can drop a whole reward system right into your app. Another one with a charitable angle is CauseMo (www.causemo.com), the user completes an action in exchange for a donation to the charity of their choice.
As with the internet in general, advertising in apps is one of the main ways of monetizing your app. Because ad blockers have not yet made their way to apps, apps are an especially attractive platform for advertising at the moment. There are many types of advertisements you can run in your app, but they will largely be some version of one of the types below.
Pros: Easy to implement, money starts flowing immediately, requires no direct payment from users
Cons: Cost to user experience, requires a lot of users to make real money, can be complex to optimize
Sponsorships – A sponsorship is when an advertiser works with an app to deliver an ad experience that is richer than a standard banner campaign. That could simply mean that on a given day, all of the standard ads in the app are for that one advertiser (that’s called a “takeover”). It could also mean 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. Those last two examples could also be considered native ads so there’s some crossover here. But 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. That is changing somewhat but whatever you have heard about the demise of banners is probably overstated. However, the standard 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. Now, once you get into 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 probably the second most common unit. Because it takes up the full page, it usually performs far better for the advertiser (higher click-through rates and conversion 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 right now. 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. 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
So 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 don’t stick out, they 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 (http://www.iab.com/wp-content/uploads/2015/06/IAB-Native-Advertising-Playbook2.pdf):
1. In-feed units – Like Facebook’s
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...
Selling Physical Goods
Increasing common and popular is selling physical items within apps. Shopping apps have been appearing left and right lately. There are also ways to add this method to existing apps.
Pros: Clear value to users,
Selling your own inventory
If you’re selling your own inventory, this was probably the original intent of your app, but it could be added on later as well. This is what many shopping apps currently do, and it’s definitely a proven method for monetizing. The downside is that there are a lot of moving parts in a physical products business (shipping, returns, inventory, etc.) that don’t usually apply to an app business.
Selling merchandised items (Amazon Merch)
Quite a bit easier is just merchandising your app. Programs like Amazon Merch allow you to pretty easily create items that are branded however you’d like and sell them, then you just pay the fees and collect the profit without actually touching any merchandise. To merchandise an app you need either a loyal following or you need to get creative in terms of offering merchandise that users would actually want.
Affiliate sales of physical goods
One step further away from the sale and easier yet is to become an affiliate that pushes users to the storefront and collects a small percentage of the sales generated. Amazon’s Associate program is a great example of this.
Selling Digital Goods
This is a method that is so broad that it could really belong in any category. Other companies have products, goods, services, software, whatever. The users of your app might need these things. You refer your users to the products they need and you collect a commission for each sale—simple as that. A common example is Amazon’s affiliate program. They don’t pay much per sale, 4-10% or so, but they are masters at getting people to buy stuff so it pans out in the end. There are other examples (usually info products) where it is common for product owners to pay 75% or more of the initial purchase price. 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 stuff they don’t want (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. Worth mentioning because many apps can do this as a bolt-on monetization method.
OTHER MONETIZATION METHODS
Sell user data
This is one of my favorite methods, and it’s not nearly as creepy as it sounds. I’m going to massively over-simplify this here and go into greater detail elsewhere. A handful of dominant tech players (Google, Facebook, Twitter and others) have their own proprietary data on...nearly everyone. That gives them HUGE advantages in selling advertisements. All companies in the space who are not one of those leading companies also desperately needs that data to execute effective ad campaigns, and they are willing to pay to get it. Now listen carefully, that data is not personally identifiable, they can’t link that data to specific users. That would be illegal. The industry acronym for that is PII (personally identifiable information), and advertising companies are not allowed to collect that info. And as an industry veteran I can tell you with certainty that all legitimate advertising companies are completely uninterested in PII. They only want information that allows them to show better (more relevant) ads. Users want that as well. In general, people don’t hate ads. They hate irrelevant ads. And targeting data (like the fact that you’re currently in the market for a car) is the key to delivering those ads. Now back to the monetization opportunity. Your app has data on users that can be sold into this data marketplace, all apps do. The value of that data depends on scale (you need a lot of users to make serious money) and quality (essentially the legitimacy and completeness of the data). In my opinion, if you have a decent size user base and you’re not doing this, you’re just leaving money on the table.
White label your app
If your app fulfills a need that is generalizable to a broader industry, you can potentially white label (their technology, your branding) the platform or even the user base and charge for it. An example of this is dating apps. The technology that allows people to meet and flirt with one another is repeatable in infinite variations. Additionally in this case, the database of users of the app can also be used to create other apps.
Say you want to create a dating app. Instead of writing all the code from scratch you could purchase a white labeled dating app and immediately offer an app full of flirting features like chat and people search. Furthermore, you could offer access to your database of users, filtered to fit the needs of the app. You want to create a dating app that puts tech geeks in touch with other tech geeks? (already exists(https://play.google.com/store/apps/details?id=com.cuddli.cuddli&hl=en)...don’t get excited) 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. (http://readwrite.com/2013/04/24/api-gold-rush)
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 immediately obvious to users, then you’re just begging and you should choose some other option from this article.
Sell your app
This is a very straightforward method of monetizing although it’s obviously a one-time deal. I mention it both in an effort to be comprehensive and also because many developers probably don’t really consider it as an option and there are a variety of circumstances in which simply selling your app is the best option. It’s also a much easier option than in the past. There are a few things to know about selling an app. One is that your app is probably worth less than you think. Everyone reads the stories of apps selling for huge money, like Instagram selling to Facebook for a billion dollars. 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. 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’re reading this article?
Choosing an SSP
First, the sub-heading above makes the assumption that you choose only one SSP. I think that makes sense if you have a modest amount of ad inventory. If you have fewer than a million impressions per month, one SSP is plenty and you should stick with that. If you have millions though, you should start thinking about using more than one and at the tens or hundreds of millions it becomes a no-brainer.
Each ad exchange will have a mix of demand. Many advertisers use multiple exchanges but many 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.
Even if you use multiple SSPs, there has to be one at the top that is your main SSP, essentially the traffic cop that directs all the other demand sources including other SSPs. There are a number of factors to consider when choosing an SSP.
Prominence – I like 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 might have more downtime (which can be ugly when a company is in charge of your revenue), 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.
Geographical strengths – I view this primarily as a US vs. non-US question but I’m sure there are folks with more experience and finer-grained preferences for other countries. Some exchanges will be better equipped to monetize ads in the US or internationally. All SSPs probably aspire to be global, but only a few really are and even then they’ll likely perform better where their business originally started. Choose an SSP that is strong in the area where most of your impressions originate.
Ease of use – Some SSPs are much easier to use than others. You can get used to anything, but running ads is a case where even a small operation might have to work with 10-20 different interfaces to collect data and manage the ads. You don’t want your SSP adding to that complexity if possible. The only way to know if a given system works for you is to try it out but that is usually pretty easy if you’re seriously in the market.
Ad quality – Another very important aspect of an SSP is ad quality and that has a couple of meanings here. One is the ad quality of the exchange. Some exchanges are higher quality than others. Generally speaking, the larger exchanges are going to have higher quality ads, and more big brand advertisers as opposed to direct response advertisers. While there are plenty of excellent direct response advertisers, roughly 100% of serious ad problems will come from this segment. Larger exchanges will have more stringent rules about who can advertise on the exchange and more rigorous policing of the ads transacted there. So this first point is just a reinforcement of the fact that you should work with large partners in programmatic advertising.
The other meaning 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.
Reporting – The data that you receive back from the SSP about your ad performance is critical to your ability to improve your yield from advertising. And between direct ad serving, exchange volume 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 probably always be some discrepancies here, so this is a differentiator among SSPs. Most have pretty robust reporting in general, but you have to constantly question the validity of the numbers you’re seeing and cross check them. To whatever extent they can help minimize this, the happier you’ll be.
Support – The importance of good support can’t be overstated. It’s woven into a number of the other items here. You need a well-trained support contact that can help you resolve any issues you encounter. That main point of contact can draw in more technical members of their team or escalate issues to other departments if needed. The contact at your main SSP is someone with whom you should have regular meetings to discuss any issues, get updates and so you can always push them on how to improve your performance. Your contact should have a very thorough understanding of their own systems so they can help you squeeze every penny out of your demand set and even advise you on broader monetization strategies. There are truly wide differences in this area. Different SSPs have different cultures and some are more focused on great support than others. You also need some kind of support access that is available 24/7 because ad issues can happen at any time. A general support email is fine for this purpose, but it needs to be responsive.
Demand integrations – SSPs may offer pre-configured ad integrations with key demand partners outside of the exchange. Certain partners will be common to the mediation set up of many different apps, so it makes sense for an SSP to just work with them right “out of the box.” The more of your demand partners that have official integrations with your SSP, the better off you’ll be. It will be much easier to integrate them, you’ll likely have fewer reporting discrepancies, and if there are issues with the integration, the SSP will view them as their own problem to fix. Conversely, while it’s fine to set up officially unsupported network partners, when there are issues with those integrations the SSP will largely regard that as your problem.
Programmatic features – There are different ways that advertisers and app developers can interact on the exchange. The standard method of just making your inventory available and allowing anyone to bid on it is called the “open exchange.” However, 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 exchanges, where you’re giving certain key ad buyers priority access to your inventory in exchange for higher rates. There can be other permutations as well. However you want to sell your inventory, be certain that your SSP can facilitate it to make it accessible and ideally, easy for you.
Fees – As you might imagine, there are always fees for using SSPs. I’d be suspicious if there weren’t. 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.
SDK – For an SSP to function, you’ll need to install at least one SDK (though probably several). You want to make sure that SDK is as light as possible, frequently updated and well documented. If your app is non-standard in any way—a prime example would be a hybrid app—then you’ll want to check the forums and see what difficulties other developers have had in integrating and maintaining the SSP’s SDK. Though using a very large SSP is generally advisable, one drawback is that they may be reluctant to make any changes to their SDK to suit your situation. Similarly, some SSPs package up commonly used SDKs from demand partners such as Facebook with their own standard SDK. If you don’t want to use the pre-packaged demand partners be sure they can give you a version that is unbundled because you’d be adding extra weight to your app that you have no intention of using.
And there you have it, a comprehensive checklist of items to check before committing to an SSP partner. Setting up an SSP properly requires some significant effort on your part, so the switching costs can be high. Inspect your options closely and put them through the wringer before making your choice.
SSP is an acronym for Supply Side Platform. It is a technology platform that allows app developers to sell their ad inventory at the highest possible rates. You may have heard of DSPs, or Demand Side Platforms, as 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 programmatically and DSPs allow advertisers to buy programmatically.
There are hundreds of DSPs in existence and only a relative handful of SSPs. The reason for that 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 go. 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 and to compete, an SSP needs a lot of functionality that truly works to hang on to those developers. Also, with no exceptions I can think of, SSPs also run the exchange. So there is a lot of technology that must be built to become a competitive SSP.
Generally speaking, there’s a 3 step process to clearing an ad impression in an SSP. The first step is to see 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 sales people 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 2.
Step to is where the inventory is cleared on the exchange. You can easily set floor prices via your SSP so that impressions cannot be sold unless they are above a certain price. This allows programmatic buyers on the exchange to take a look at any inventory you don’t sell directly and determine what they’ll bid for it. If their bid is above your floor rate and/or above what step 3 offers, the impression will clear at this point.
The third step is ad network mediation. Often called a waterfall or a daisy chain, this is a process of offering the impression to a string of demand sources and decreasing rates until someone takes it. If no one wants the impression or if it takes too long in total to get the responses back, then the impression goes unfilled.
The execution of this process is much more complicated and not as linear as I’ve described it here. But any given impression is offered first to direct buyers and then 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 only 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, the next article shows you how to choose an SSP that suits your product.