OKO Digital

The ad optimisation people

  • Home
  • Publisher Solutions
    • Website Monetization
    • Header Bidding
    • AdX – Google Ad Exchange
    • App Ad Monetization
    • WordPress Monetization
  • About us
    • OKO & the OKO team
    • Careers
  • Blog
    • Latest blog posts
    • Ad Blocking
    • Ad Exchange (AdX)
    • Ad Optimisation
    • Ad Performance & Page Speed
    • Ad Publishing Landscape
    • AdSense
    • DoubleClick For Publishers (DFP)
    • Exchange Bidding
    • Google Ad Manager
    • Google Certified Publishing Partners
    • Header Bidding
    • Privacy & GDPR
    • Program Policy
    • Open Bidding
    • Traffic
  • Contact

Google Exchange Bidding, Header Bidding . 30th April 2019

What is Server to Server Bidding?

How it works, how it's implemented and the advantages of a hybrid approach.

One of the most effective ways for publishers to drive up CPM rates is to ensure that enough good demand partners are bidding on their inventory. There are a number of ways to do this, each with it’s own benefits and drawbacks, but publishers are increasingly turning to Server to Server bidding, AKA S2S Header Bidding.

For much of the history of programmatic advertising this was largely achieved through ad waterfalls, which did the job but were far from efficient as only the SSP at the top of the chain gets the opportunity to bid on every impression. More recently Header Bidding has become the favoured approach.

Header Bidding offers huge advantages over waterfalls, largely by giving all involved SSPs a near equal opportunity to bid, but brings it’s own problems. As the auction is run client-side in JavaScript, every partner introduced adds loads to the page and there are real limits on how many bids can be requested before user experience is impacted. Server to Server bidding aims to solve this issue by removing the auction from the page header and running it on high-speed ad servers.

How Server to Server Bidding Works

“Server to Server” refers to the ad-server and the demand partner’s server communicating directly. When an ad request is made, the ad-server connects directly to each SSP to get their bid. Because this process happens in well connected data-centres rather than in the user’s browser, this can happen very quickly.

S2S benefits from faster processing, being able to request and receive more bids at once and in being able to transfer information far faster than most users connections would allow. The benefits of this are two fold: firstly, it happens very quickly, secondly there is no additional load or delay for adding more exchanges to the process. Server To Server Bidding

How to implement Server to Server Bidding

Large publishers looking for a Server to Server solution have the option of developing their own wrapper, or building on a solution such as Prebid Server. This is not a simple undertaking though, either in terms of the technical challenge or even in getting SSPs involved. For most publishers, S2S means implementing either Google’s Exchange Bidding or Amazon’s Transparent Ad Marketplace.

Google Ad Manager Logo

Header Bidding vs Server to Server Bidding

Server to Server bidding is often seen as an alternative to Header Bidding. This isn’t always the best way to utilise S2S, but it is useful in terms of understanding the differences. The main advantage that Server to Server bidding offers is speed. Delivering ads to the user’s screen more quickly not only increases revenue by getting more ads seen, but it improves user experience and therefore encourages users to venture further into the website. This can increase impressions per session even further. However, S2S bidding is not without it’s drawbacks.

The biggest issue with S2S Bidding is the problem of Cookie matching. Advertisers bid more when they know more about the user behind the impression that they are bidding on. This usually translates to the user having information in a cookie (such as that they recently visited the advertiser’s store and viewed an expensive product). With client-side Header Bidding, this is simple as the auction runs in the browser, each bidder can look for any of “their” cookies on the user’s system. S2S bidding can’t leverage these cookies as it runs on the server not in the browser, and it is far more difficult to find that targeting information.

The advantage of a hybrid approach

The best solution at this time seems to be a hybrid approach. As S2S bidding can be run without additional latency, it can be added into a Header Bidding set-up without impacting user experience. This can allow the Header Bidding set-up to be slimmed down, with high performers remaining, and S2S bidders added to bring more bids at high speed.

This approach is one of our favourite approaches when managing website monetization for our clients. We manage ad inventory on behalf of publishers, introducing top performing SSPs through Header Bidding, Exchange Bidding and non-banner formats. Because we manage both the technical set-up and the day to day management, our publishers are free to focus on developing their business whilst we increase their programmatic ad revenue. Find out more about how we help publishers here.

Google Exchange Bidding, Header Bidding . Analysis

About Abbey Colville

SEARCH

TOPICS

  • Ad Blocking
  • Ad Exchange (AdX)
  • Ad Optimisation
  • Ad Performance & Page Speed
  • Ad Publishing Landscape
  • AdSense
  • DoubleClick For Publishers (DFP)
  • Exchange Bidding
  • Google Ad Manager
  • Google Certified Publishing Partners
  • Header Bidding
  • Open Bidding
  • Privacy & GDPR
  • Program Policy
  • Traffic

Could the ads on your site be earning more?

Find out how OKO help publishers earn more from their ads.

LEARN MORE
Insticator

OKO Digital, The Cake Shed, Manor Farm, Manor Road, Hayling Island, Hampshire, PO11 0QW

Google Certified Publisher Partner Logo

OKO is a registered trademark and trading style of OKO Digital Limited. Registered in England company number 03867231. © OKO Digital Limited 1996-2018. All Rights Reserved.

  • Privacy Policy
  • Cookie Policy
Manage Cookie Consent
We use cookies to optimise our website and our service.
Functional Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes. The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
Manage options Manage services Manage vendors Read more about these purposes
View preferences
{title} {title} {title}