A man holding a cell phone while working on his laptop in an office

5 Key Differences Between An Ad Network And SSP In The App World

Paulina Klimenko headshot
By Paulina Klimenko, Chief Growth Officer
December 6, 2018

The app economy is thriving with 197B apps downloaded in 2017 and that number is projected to grow to 350B in 2021. Additionally, eMarketer (October 2018) estimates more than $77B will be spent on in-app advertising in the US in 2019, representing nearly 83 percent of US mobile ad spend. Of that 83 percent, that means we could see $37.9B in programmatic mobile display ad spend in 2019, with the programmatic in-app display ad market worth more than $30 billion in the US alone next year. It is a growing area in the programmatic landscape and for many developers, to be able to create and distribute high-quality and engaging apps, they rely heavily on advertising as their main – and oftentimes single – source of revenue.

Historically, apps have monetized their users using one or more mobile advertising networks which would be called sequentially (in a waterfall set-up) from the app until an ad was served. In the last 5-7 years, we have seen programmatic monetization and header (parallel) bidding having disrupted digital advertising starting with the in-browser environments. Both options are now rapidly penetrating the mobile app world.

Here we will examine the roles traditional mobile ad networks vs. programmatic SSPs play in the advertising business of app developers, namely focusing on their differed offerings, and the future of both.

1- SDK vs. server-side implementation:

Legacy ad networks require app developers to deploy their SDK, which gets called for an ad and is responsible for ad rendering and analytics. Depending on how many ad network partners they want to work with, an average app developer installs and manages up to 20 SDKs. This can create latency and a negative user experience (such as an app crash) which strains already stretched developer resources.

A programmatic SSP offers a server-side implementation where an app developer deploys one “gateway” SSP SDK which calls numerous monetization partners server-side. This avoids latency concerns and gives an app developer access to more demand.

2- Waterfall vs. parallel bidding:

Legacy ad networks are called in a sequential order (as a waterfall) until an ad is delivered. As we have learned from the in-browser environments, waterfalls are inefficient for both the publisher—causing them to leave money on the table—and the bidders as they see fewer ad opportunities when placed further down in the waterfall. SSPs bring parallel bidding into the app world, where monetization partners are called at the same time, driving buyer competition and CPMs and maximizing the revenue opportunity for app developers.

3- Performance vs. brand demand

Traditional ad networks represent largely performance-oriented demand, such as app install campaigns from other developers looking to promote their apps and generate downloads. An SSP partner provides app developers access to incremental brand demand activated exclusively through the programmatic channel. As brand spend is increasingly moving into programmatic, the ability to tap into these budgets will be critical for app developers looking to grow their ad revenues.

4- Ad quality and brand safety:

Managing the quality of ads being served to the app users and the safety of the ad environments for advertisers is a critical function of an SSP. An SSP typically deploys a broad variety of both internally developed and 3rd party tools to safeguard the users and advertisers. Ad networks tend to have a spotty track record here as evidenced by recently uncovered fraud schemes.

5- Flexibility:

Your SSP and their parallel bidding SDKs can work within a publisher’s existing ad stack and alongside the waterfall of ad network partners, without disrupting existing revenue, while generating incremental demand.

Future Growth

Developers may wonder if their current SDK ad network partners will be completely displaced by programmatic and parallel auctions. The simple answer is it’s unlikely to happen in the near future given that (a) they still represent a large share of an app developer revenue and CPI budgets which have not yet moved to programmatic; and (b) many currently lack dynamic bidding capabilities, making it difficult for them to participate in a parallel auction.

For the foreseeable future, we will see a “hybrid” bidding scenario with the traditional waterfall and programmatic models co-existing within the stack. However, we expect more and more ad networks going server-side to take advantage of the programmatic parallel auction.

What’s Next?

To learn more about our mobile offerings and solutions, check out our solutions page or contact us.