Learn How MittMedia Increased its Revenue Thanks to Server-side Header Bidding

MittMedia implemented a server-side header bidding a year ago. At the end of this article, you will find an interview with Håkan Hamrin, Head of AdTech at MittMedia. He shares valuable insights with us.

As most publishers know by now, the header bidding is an excellent way to increase digital ad revenue. In just two years, header bidding has gone from a matter for only the most tech-savvy publishers to becoming an industry standard. Today, more than 70% of publishers have adopted header bidding. Server-side is slowly catching up. Why? It’s simply much better, although it is trickier to develop.

So far, most publishers have utilized client-side header bidding – i.e the auction takes place in the header of the web page. Client-side header bidding has some clear advantages, as it lets the demand partner access the web page directly, facilitating user matching and minimizing cookie loss.

However, there are some distinct drawbacks with client-side auctions.

Mainly, the more partners you add to the client-side auction, the slower the page load will be. Usually, you can work with 8-10 demand partners without slowing down the page too much, but beyond that, the user experience will suffer. Mobile browsers are especially sensitive because they can handle fewer simultaneous connections, especially if there are several connections to the same URL (as it would be the case if several demand partners use Rubicon as an SSP, for example).

Client-side auctions are also dependent on the internet connection of the device. A slow internet connection could slow down the page and ads even further. Demand partners may not be able to respond in time, reducing both the user experience and monetization.

Do you like what you’re reading? Subscribe our newsletter for more content like this!

[mc4wp_form id=”407″]

Advantages of server-side header bidding 

With server-side header bidding, the auction takes place on an external server, so instead of running multiple calls from the web page, you just make one call – to the header bidding server. The server then makes the call to all connected demand partners.

This approach has a number of advantages compared to the client-side auction. It enables the site to work with an almost infinite number of demand partners. It is also not dependent on the user’s internet connection, and since you would normally call it before the ad server, the response time of the demand partners will not affect page load.

Overall, the latency of both the web page and the ads will be much lower with server-side auctions compared to the client-side.

Also, S2S (server to server) enables publishers to integrate directly with DSPs, thereby bypassing the SSP and its revenue share.

The other side of the coin is, of course, that demand partners may place lower bids and on fewer impressions due to difficulties with user matching.

Hybrid header bidding offers the best of both worlds

Fortunately, publishers don’t have to choose between client-side and server-side. It is entirely possible (and recommended) to run both C2S (client to server) and S2S (server to server) at the same time in a so-called hybrid setup. You simply run your most important partners on the client-side and the “long tail” on the server-side, with everyone competing in the wrapper. 

In fact, we see very good results with our publisher running its main partners both C2S and S2S. One might expect that adding an extra server-side request should just split the existing revenue between the server-side connection and the client-side connection, but usually, it doesn’t happen. Instead, the revenue from C2S seems to be largely unaffected when adding an extra server-side request, and the server-side auction just adds more revenue from the same SSP.

“We see an increase in their programmatic revenue by around 25-50% from the same SSP by running both C2S and S2S. I´m actually not sure why this is the case. One theory is that the DSPs just listen to a fraction of the traffic from a particular publisher, and by adding an extra request, you force them to listen to a larger portion of the traffic.” Fredrik Johansson, LiveWrapped.

Interview with MittMedia, that implemented LiveWrapped header bidding one year ago.

I spoke with Håkan Hamrin, head of AdTech at MittMedia, the largest local news publisher in Sweden with 20+ sites and 100m+ impressions per month.

1.    Tell us about your current setup.

Håkan: We have a setup with two wrappers for header bidding. One on the server-side and one on the client-side. The server-side one sends in the winning bid to the client-side wrapper, then the ad with the highest bid from both server- and client-side is rendered by the client-side wrapper. If we don’t sell the impression through header bidding, we have an ad server catching up the remaining impressions and we can have some internal ads booked there.

2.    Why did you move into server-side header bidding?

Håkan: With our ad platform, Reacher, we moved all our local sales to a DSP, and with the server-side header bidding, we could connect the DSP straight into the wrapper. We also saw a lot of advantages from a technical perspective with a server-side solution. Faster loading of ads and, by that, better viewability. The possibility to add more demand sources than on client-side was another important factor for us that also has contributed to higher revenue.

3.    Have you seen any impact on ad-loading times due to header bidding?

Håkan: Yes, we have decreased the load time by many percent. If we compare it to the solution we had before with an ad server and a waterfall, we have less than half the loading time

4.    Can you tease us with some revenue numbers before and after the header-bidding launch?

Håkan: We have seen higher revenue than the same month the year before. And from 2017 to 2018 we raised the revenue from other sources than our local sales with more than 20%. And that with a declining inventory because of the reader´s business

5.    What do you see for the future of server-side header bidding?

Håkan: We hope to be able to move our whole demand to the server-side in the future. Currently, we are too dependent on cookies, but when it will change, we won’t see any obstacles in moving all demand partners to the server-side.

In the future, will header bidding move into video and apps?

Because of the positive revenue impact of header bidding for display, I foresee a future where header bidding accounts for a larger share of app inventory.

It might take some time due to the difficulties with server-to-server setups and software-development-kit (SDK) integrations keeping in-app header bidding.

Enabling header bidding for video ads is possible, but trickier than for display. Prebid.js already supports video in its specs. For now, most publishers are selling out their video inventory via IO or PMP, so the need for header bidding is less than for display.