How to Choose an SSP for Your Mobile App

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

That's the one you have to choose carefully. 

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

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

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

Prominence

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

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

Geographical Strengths 

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

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

Ease of Use 

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

Ad Quality 

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

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

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

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

Reporting

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

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

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

Support 

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

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

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

Demand Integrations 

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

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

Programmatic Features 

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

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

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

Fees

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

Always. Always ask for lower fees.

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

Getting Paid

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

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

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

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

SDK

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

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

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