A safer bet: testing the real impact of client-side, server-side, and parallel bidding with Olli Järvilehto
BY ROB BEELER + OLLI JÄRVILEHTO (COO & PARTNER, RELEVANT DIGITAL)
For years, publishers have been caught between competing narratives about client-side, server-side and parallel header bidding, with each touted as the definitive way to increase yield, performance, or privacy. In reality, it’s a bit more complex.
As third-party cookies decline, browser restrictions increase, and page performance becomes ever more closely tied to revenue outcomes, publishers are under pressure to make decisions that balance monetization, user experience, and operational stability. And often without clear, comparable data to hand.
In this interview, Rob speaks with Olli Järvilehto, Chief Operating Officer & Partner at Relevant Digital, to unpack the results of a large-scale test comparing the three types of bidding across real web and mobile traffic. Together, they explore why the performance gaps between setups are narrower than many expect, how different SSPs behave depending on implementation, and why selective, data-driven testing is becoming the most reliable path forward for publishers navigating the next phase of programmatic advertising.
Rob: Publishers hear a lot of sweeping claims about client-side vs server-side vs parallel. Your results show the differences are far smaller than many expect. What should publishers take away from that gap being narrower than the industry narrative suggests?
Olli: The results are not as clear-cut as the industry often suggests. We’ve been implementing server-side integrations for web and mobile apps since 2020, closely monitoring performance across different environments. Over two years ago, when we shared results from similar tests, the gap between client-side and parallel was even narrower. That progression shows that server-side has continued to improve and, in some cases, already caught up with client-side in terms of yield.
At the same time, client-side still benefits from third-party cookies, which naturally gives it an advantage as long as cookies remain usable. It’s also important to note that these results reflect European inventory, where outcomes are influenced by browser market share. Safari, Firefox, and Brave all block third-party cookies by default, which affects the relative strength of each setup. But as cookies continue to decline, the long-term direction is clear: the server side will become the stronger solution over time.
Rob: Parallel and client-side performed almost identically, but parallel held a slight edge, especially on desktop. What’s behind that advantage, and why might desktop environments show more separation than mobile?
Olli: Parallel bidding combines the benefits of client-side targeting with the speed and efficiency of server-side processing. This allows it to collect more bid responses without overloading the page, which results in a small but consistent performance lift.
Desktop environments highlight this advantage more clearly. Devices are more powerful, browsers can handle more simultaneous requests, and recovery from latency spikes is faster. Mobile devices can be slower, and networks are more volatile. The browser mix also plays a role. Privacy-focused browsers are more common on mobile, reducing the relative advantage of client-side targeting. As a result, configurations that diverge on desktop may behave similarly on mobile.
It’s also worth noting that this comparison covers mobile display in the browser. In apps, the situation is entirely different, because there is no client-side option – all implementations are server-side.
Rob: Server-side was the fastest in every environment, and that boost in performance led to higher viewability, but slightly lower revenue. How should publishers think about that tradeoff between speed and yield?
Olli: Publishers need to evaluate this trade-off based on what matters most to their business and to advertisers. Server-side delivers a clear performance advantage: faster page loads and thus improved viewability. These are commercially significant metrics, especially as many advertisers optimize campaigns around viewability, attention, and reliable delivery.
At the same time, revenue remains the most critical metric for most publishers. If improved technical performance does not translate into higher yield in a specific environment, that setup needs to be reconsidered. This is why controlled testing is so important.
The balance between speed and yield is not universal. It depends on factors such as ad placement, device type, SSP configuration, and market dynamics. Server-side should be seen as part of a broader optimization strategy. It may not increase revenue immediately, but the technical advantages it provides can support stronger long-term monetization when decisions are guided by data.
Rob: One of the most interesting findings was the variability at the SSP level. How should publishers use that insight when evaluating partners?
Olli: The key lesson is that SSPs shouldn’t be evaluated as a single group. Every partner responds differently to client-side, server-side, and parallel setups. Some SSPs clearly benefit from server-side performance and faster response times, while others still perform better in the browser, particularly when they rely heavily on cookie-based targeting.
In practice, SSP management should be data-driven: test partners across different implementations, analyze where each one performs best, and use the configuration where yield and technical performance are in balance. Here, the SSP’s role is determined by its real contribution, not assumptions or results from a single environment.
Rob: For publishers who haven’t tested before, what’s the smallest, safest way to replicate a test like this?
Olli: The safest starting point is to direct a small portion of traffic to an alternative configuration while keeping the rest as a control. This allows publishers to compare client-side, server-side, and parallel setups without disrupting the production environment or causing revenue volatility.
The implementation itself can be lightweight. Creating a separate Prebid configuration and routing a small share of traffic to it is often enough. As long as ad units and logic remain consistent, the comparison stays clean.
That said, without the right tools, even simple tests can become operationally heavy. For instance, traffic splitting, configuration control, and combining metrics like eCPM, load time, and viewability often require manual effort across multiple systems. Tests are far easier when traffic management, configuration, and analytics live in one unified workflow, but the principle remains the same: start small, define the change clearly, and protect the control.
Rob: Server-side is often pitched as the future because of privacy and performance, but your results show it isn’t automatically the revenue winner. How should publishers evaluate a server-side move without buying into hype or fear?
Olli: Publishers shouldn’t adopt server-side simply because the industry says they should. The shift toward server-side is real and driven by privacy, browser restrictions, and the need for scale, but the right timing is different for every publisher. The data will tell you when. Server-side brings clear benefits – faster pages, better viewability, and greater control over data – but those benefits don’t automatically translate into higher yield today. In some environments, client-side will still outperform on pure revenue.
That’s why decisions should be based on structured testing, not driven by hype or fear of missing out. In many cases, a parallel approach is the right bridge: keep high-performing client-side partners where they work, and move others server-side where speed and efficiency add value.
Rob: You talk about enabling parallel bidding only for the SSPs that benefit from server-side connections. What does that selective, partner-by-partner approach look like in practice?
Olli: In practice, it means you don’t move your entire stack at once. SSPs are evaluated individually, often one at a time, to see whether a server-side or parallel connection genuinely improves performance. If server-side delivers measurable benefits for a partner, you keep it. If not, you don’t.
This reduces complexity and allows publishers to optimize incrementally. The result is a hybrid setup where each SSP is connected in the way that suits it best, rather than forcing every partner into the same model.
Rob: You frame the real takeaway as building a culture of testing. If a publisher wants to know whether their current setup is good enough (or if they should start testing), what’s the first question they should ask?
Olli: The simplest question is: do we actually know how our current setup performs across environments and partners, or are we relying on assumptions? If the answer isn’t a confident yes, it’s time to start testing.
Testing isn’t about rebuilding everything. It’s about validating whether the configuration you have today is truly the best fit. Even small changes can reveal meaningful differences. Ultimately, it’s about building confidence. And that begins with asking whether you genuinely know how your current setup performs.
Ready to test what actually works?
The real lesson from this study is not that one bidding model always wins, but that evidence beats assumptions. As the programmatic landscape continues to evolve, publishers who test, adapt, and optimize incrementally will be far better positioned than those who follow blanket advice.
Relevant Yield is a comprehensive platform that helps publishers manage their Prebid setups, track revenue and compare the impact of different configurations in one place. In HB Manager, configuration changes and tests are easy to apply. With Relevant Yield’s HB Analytics, you can monitor the effects in real time without having to pull data together from multiple systems.
To make it easy for publishers to get started, Relevant Yield’s HB Manager users can access Prebid Server at no additional cost. Learn more about how to test your stack by chatting to the team at relevant-digital.com/contactus.
👉 Want to stay in the loop with what’s happening in the Beeler.Tech community? Subscribe to our newsletter. If you’re interested in attending or sponsoring a future event, you can explore our upcoming events here.
This is content created in paid partnership with Relevant Digital. We only feature partners who we believe bring real value to the publisher community.