The role of a supply-side platform has evolved alongside the programmatic industry over the past decade. While an SSP’s primary function as the technological connection to advertising demand for publishers remains, the strategic value an SSP provides has changed. And buy-side initiatives like The Trade Desk’s OpenPath could threaten SSPs’ value proposition even further.
As header-bidding technology has become commoditized and buy-side priorities have shifted, four new trends in SSP value differentiation are emerging:
- Curating inventory for buyers to differentiate from open-market inventory
- Increasing efficiency of auctions for buyers
- Scaling inventory to maintain relevance in a crowded ecosystem
- Introducing data management platforms and first-party data solutions
These trends have been in reaction to the changing priorities of the buy side. It has become clear that SSPs’ business priorities have increasingly shifted to buyers, as that is where they have the least impact.
As SSPs evolve, so should the way publishers work with them. SSP technology and buy-side paths are commoditized, and the revenue sharing model does not lead to meaningful partnerships with SSPs.
So it might be time for SSPs to abandon revenue sharing with publishers in favor of a software-as-a-service (SaaS) model.
Problems with revenue share fees
Revenue share fees should align performance incentives between SSPs and publishers. However, due to the introduction of auction mechanisms, such as volume-based discounts, post-auction discounts and variable rev-share per auction rates, revenue shares are no longer straight forward.
In each of these auction mechanisms, the SSP take rates – or the fees an SSP charges on every transaction performed – are used as a lever to win more business from the buy side, which creates complexity for a publisher’s understanding of mediation.
A revenue share also implies that the revenue brought to the publisher should be credited to the SSP. However, most, if not all, programmatic demand is accessible through all major SSPs. Why should a publisher pay the same revenue share fee for some of its most expensive inventory when an SSP did nothing different to buy it?
The biggest problem with revenue sharing is that it does not encourage meaningful partnership. Revenue share structures create a dependency on short-term thinking. An SSP depends on winning publisher revenue at meaningful scale, and there are few levers outside of take-rate and unique formats that can change this. As a result, partnerships with SSPs are becoming purely operational instead of being strategic, making it difficult to differentiate value between SSPs.
Moving to a SaaS model
A SaaS relationship between SSPs and publishers would encourage meaningful partnership, value differentiation and transparency.
A SaaS fee model would include:
- Fees for technical service to enable demand path connections, RTB auctions and reporting.
- SSP-built programs that add value to publishers.
- Revenue share agreements for demand uniquely sourced by the SSP.
- Strategic investment in a partnership that encourages renewal at the end of each contract term.
A SaaS model is beneficial for SSPs as SaaS contracts are easier to forecast and lead to higher revenue valuation, which enables long-term investment.
But, inevitably, this model would result in fewer SSPs, since publishers would only need one or two platforms. This could, however, benefit buyers looking to reach their supply-path optimization goals.
As for publishers, they are hungry for meaningful partnerships, and the current path that publishers and SSPs are on doesn’t offer that. The commoditization of header bidding has made SSP relationships transactional and undifferentiated, but a SaaS model could provide the change that both parties desperately need.
It is time to rethink our relationships if the sell side wants to gain momentum in the marketplace.
“The Sell Sider” is a column written by the sell side of the digital media community.
Follow Chegg and AdExchanger on LinkedIn.
For more articles featuring Samuel Youn, click here.
