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.