It’s an age-old question: client-side or server-side, or presumably both?
Header bidding has become an essential component of publishers’ ad monetization strategies, allowing for better inventory fill rates and higher revenue, allowing publishers to receive bids from multiple advertisers at the same time, in contrast to the traditional waterfall method of trading, in which inventory was passed to ad networks sequentially.
But, which way should a publisher go with their header bidding wrapper strategy—client-side or server-side? Client-side, while a definite improvement over the waterfall, does have its shortcomings. It increases the audience match rate, but it also increases latency. And then there’s server-side. Server-side reduces latency, but at the expense of the match rate.
We asked Evgeny Semenchuk, Publisher Integrations Specialist for IPONWEB’s supply platform, The MediaGrid, how can a publisher decide whether client-side or server-side was right for their business, especially as the third-party cookie nears its final days.
Gavin Dunaway: Many publishers have been reluctant to embrace server-side header bidding because of low ID-sync rates. Have ID-sync rates improved over the last year?
Evgeny Semenchuk: Despite continued growth in publisher adoption of server-side integrations, the average sync rate does not seem to be going up, obstinately remaining somewhere between 40% and 50% (compared to 70%+ for client-side).
As more privacy regulations come into effect around the world, including the CCPA in 2020, we’d expect this number to see additional incremental decreases until the third-party cookie goes away completely, when the point becomes irrelevant.
However, given the pressure on buyers, sellers and platforms to find an alternative identifier before the final demise of the cookie, we are starting to see more widespread adoption of vendor IDs from companies like LiveRamp and The Trade Desk.
As adoption of those IDs goes up, the end match rate also increases, which could stave off rapidly declining CPMs for a publisher’s unmatched inventory. The improvement would be seen across both client-side and server-side; however, for server-side, the uptick from adding other ID vendors is substantial as the regular ID-sync rates are much lower (45% compared to 70% for client-side).
GD: What are some of the reasons a demand partner performs better server-side rather than client-side?
ES: There are a few explanations for why some demand partners perform better when moved server-side. For example, in most cases, client-side connections impose some restrictions on the number of parameters that can be passed on in the bid request.
Server-to-server (S2S) connections, on the other hand, allow far more parameters to be included; this enables a publisher to describe its inventory in greater detail to demand partners, which in turn makes it more attractive to certain buyers. Another reason is that some demand partners may perform better when buying specific ad formats, like native or in-app. As not all formats are always available through client-side connections, making that supply available to demand partners via S2S may result in greater spend.
Lastly, some bidders have less demand in some geographical regions, or may not have their trading infrastructure deployed as effectively as it is in the US or Western Europe. This can lead to that bidder permanently timing out in those locations, which slows down the page for global users—and is a good indicator that it’s time to move that bidder server-side for that specific supply.
In addition to geolocation, publishers should also be identifying the other portions of their inventory (based on slot position, inventory type, etc) where there is no incremental revenue brought in by a given bidder on the client-side, and move it S2S.
GD: How can you best determine if a demand partner should go client-side or server-side? Is there a benefit to having them in both?
ES: This is, literally, the million-dollar question, especially for publishers looking to balance page performance, user experience, and ad revenue. In header bidding, we tend to talk about client-side versus server-side, but in reality, a demand partner could be integrated both ways. Based on performance, a publisher may wish to have a bidder client-side for US display inventory, but server-side for the rest of the world, or for in-app supply.
Publishers looking to strike the optimal balance for each demand partner can leverage an A/B testing framework. This would sequentially move each partner from client to server (potentially for just a portion of traffic, such as specific countries, or formats where time-outs are especially high) and measure the impact on key metrics, including bidder latency, page performance and revenue for the test versus the control groups.
Once benchmarks for those metrics (or others that matter to that specific business) are established, any new demand partner can be started in the A/B test bucket to determine the optimal integration pathway based on its performance against the points of reference.
At the same time, it is critical to limit the number of client-side partners to ensure page performance. While that number will vary by publisher, recent research from Adpushup suggests that magic number —the point where page performance intersects with the incremental revenue lift associated with adding a new bidder to the stack—is around seven. This allows publishers to maximize advertiser revenue while maintaining page performance metrics.
GD: Will the depreciation of the third-party cookie make client-side header bidding essentially pointless? Why would publishers keep some partners on the page?
ES: As server-side integrations already win out for publishers on most fronts, including ad formats, latency, and auction limits, it’s hard to imagine why a publisher would keep any bidder client-side once the third-party cookie disappears.
If that proves to be the case, it will then become the responsibility of server-side wrappers to ensure that all critical client-related data, such as page referrer and vendor IDs (LiveRamp and The Trade Desk, for example, as referenced above), is passed on to all demand partners plugged in via a server connection not just properly but also equally (so no one buyer is disadvantaged by not having equal access to client-side data).
At the same time, the benefits of client-side header bidding, including transparency and ease of use, might just be enough for some publishers (especially smaller ones) to keep a number of demand partners client-side. And with around a year (maybe more) until the third-party cookie disappears entirely, it’s still too early to say whether client-side header bidding will go away for good.
