Audience
Engagement
Monetization
Platform
Resources
Careers
Docs
Get a demo ›
Monetization
Go to the resources ›
Marfeel Team 2020-03-04

What is header bidding and how does it work?

6783.png
There is a reason why header bidding is one of the top buzzwords in the ad tech and publishing worlds. As soon as a user visits a web page, an ad impression is generated to give value back to the publishers providing content for their audience. However, despite ad tech having a huge industry to help streamline digital advertising, it is still plagued with inefficiencies, fragmentation, and unfair competitive advantages for major players such as Google. For publishers, the ad inventory needs to be seen by a larger number of advertisers and exchanges simultaneously to provide publishers with a fair value for their inventory. With the publishing and advertising communities both needing a solution, header bidding was born. And since then, it’s evolved…

What is header bidding?

Header bidding (also known as pre-bidding, tagless or advance bidding) is an advanced programmatic technique where publishers offer inventory to multiple SSPs (Server-side Platforms) at the same time before making a call to the ad servers. The idea is that by letting multiple demand sources bid on inventory at the same time, publishers can ensure the highest paying bid is served and they make more money, no matter the SSP or ad server the bid came from.

A short history of header bidding 

The goal of header bidding has always been for the good of publishers: to even up the playing field and offer up their valuable audiences and inventory against behemoth platforms such as Google and Facebook. But how and when did this technology begin, and shape into the publisher monetization solution we know today?

  • 2017: AppNexus and Rubicon Project launch Prebid.org in a “collaborative industry effort” to make the marketplace a more even ecosystem, delivering “unbiased programmatic monetization solutions” for premium publishers. To date, Prebid is the most widely-used header bidding wrapper in the world.

  • 2019: Marfeel becomes part of Prebid.org to help dictate the standards that the publishing industry follows for header bidding.

  • 2019: Marfeel launches MBid - server-side header bidding technology dedicated to matching publishers with unlimited demand sources without impacting their page speed and performance.

  • 2019: Header bidding is widely adopted across the ecosystem. Among the internet’s most popular 1,000 sites that sell programmatic ads, 79.2% used header bidding in March 2019.

Header bidding adoption 2017 to 2019 
Source: Emarketer - Five Charts: The State of Header Bidding  


How does header bidding work?

So we now know about why header bidding was required for publishers, and how it came to fruition and who was responsible. But how does it work, in practical terms, to deliver a programmatic ad to a website visitor?
  1. A mobile phone user visits a website, for example, Elconfidencial.com.
  2. Header bidding javascript code gets executed in the header of the web page, for example, Prebid JS.
  3. This code, either executed on the browser or on a server, makes an auction call to ad exchanges or supply-side platforms (SSPs) simultaneously.
  4. An auction is held in milliseconds to fill the ad slot. The highest bid is passed into the ad request and calls the Publisher Ad Server.
  5. The Publisher Ad Server compares the highest bid with the concurrent auctions that are taking place in the Ad Server, and passes the highest bid to the Marketer Ad Server.
  6. The Marketer Ad Server compares the highest bid with the different lines that have been set up in DFP and also AdEx. If DFP wins, it will display the ad. If not, DFP will return a signal to the Prebid JS, and it will display the winning ad.
Before the advent of this process, ads were served in a manner known as the waterfall auction. 

Header Bidding vs Waterfall

The waterfall auction – also known as daisy-chaining – is a process where a publisher passes its inventory from ad network to ad network in descending order until their impressions are sold. But the waterfall auction had some major drawbacks…

  1. Favoritism: One major issue is that ad networks are usually ranked according to the average historic yield produced for the publisher. If the first network does not produce a satisfactory bid, the next ad network is called upon to bid… and the inventory continues to move down the ‘daisy-chain’.
  2. Passbacks: In the milliseconds an auction takes place, one advertiser might be willing to bid a much higher price for the inventory, but is cut out as they are not seen as a favorite earlier on in the process. This is known as a “passback,” and it leaves publishers with lower prices for their inventory.
  3. Negative user experience: These passbacks also lead to ad latency. Advertising code is already too heavy on the publisher page and leads to slower websites and lower lighthouse scores, but if the ad call goes to each ad network one by one, this can slow down the page damage the user experience.
Header bidding was developed as a powerful alternative to provide a more democratic auction:
  1. Increased revenue: By flattening the waterfall, publishers can increase competition for inventory. With less reliance on a single SSP, overall yield and fill rates increase as there's more competition between ad networks.
  2. More control: When demand sources bid at the same time, publishers can control which sources can participate in the bidding.
  3. Fewer lost impressions: As impressions are passed down the chain in waterfall set-ups, a few impressions are lost at each step, eroding inventory.
But header bidding was not perfect. Publishers today still have latency issues that damage the experience of users who are increasingly after premium, fast, engaging websites. This means it had to change shape and evolve. 


Server-side vs client-side header bidding

So far, there are three wrappers for publishers to run header bidding: client-side, server-side, and hybrid solutions. The most common, and the current industry standard, is client-side header bidding: The main differentiator for client-side header bidding is that header bidding is run directly in the browser of the website. 

It involves adding a piece of JavaScript to a publisher’s website, which begins every time a page loads, sending an ad request to a number of demand partners. Then the bid begins, and the highest bidder wins the auction. Running header bidding directly in the browser can result in a number of issues. Because scripts are added to the page header, latency can occur, impacting the number of ad impressions loaded and slowing down the page. There are also only so many requests a browser can make at one time, meaning a limited number of ad requests from the client-side header-bidding wrapper. That’s why header bidding has evolved to make way to hybrid solutions, and the new standard - server-side header bidding.  You’ll see that, instead of header bidding being run in the browser, with server-side, it’s done on a server instead.  

Why? One issue is the impact on latency: that latency is significantly reduced by moving the header bidding process into a server. We’re possibly talking about just a few milliseconds, but these milliseconds are enough to make a complete impact on the user experience as well as introduce more bidders to ramp up competition and yield. Due to this vast improvement on the user experience, server-side works better for video and rich media, introducing a mix of ad formats and types. 

As user behaviors change, and video and more progressive ad types become more the norm, server-side will be even more essential. There’s no restriction to the competition introduced for inventory - with server-side, you are virtually limitless to receive bids from a more varied range of demand partners. The result is better ad yield, higher fill rates, and scale for advertisers. As Google AMP becomes more of an industry standard, and essential for publishers to ramp up their traffic, monetizing AMP web pages can be a real challenge for publishers. Google AMP has deprecated support for remote.html, and therefore server-side is now the only header bidding option to monetize Google AMP pages.

The future of header bidding

Prebid leadership summit
In 2019, Marfeel held the Prebid Leadership Summit in our office to discuss and strategise the future of header bidding technology. Within this summit, we learned that although server-side header bidding is developing into a better solution for publishers, it is still in the early adoption phase. But in the words of former Prebid chair, Alexandra Smith, ‘Prebid Server is not just Prebid.js without its latencies. It’s an opening door to many more improvements and making crucial steps towards getting out of the browser.’ 

But that doesn’t mean it can’t be adopted right now. Through a deeper development through collaboration, and thanks to Prebid’s open-source tech, Marfeel has been working alongside publishers and industry figureheads to ensure header bidding is making more impact for publishers. 

Latest Articles

‹ Back to Blog Home
Article
2022-04-22

Google analytics real-time issue

Alexian Chiavegato
Article
2022-02-01

Marfeel’s Response to Confiant’s Privacy Policy Violation Allegations

Alexian Chiavegato

Get the headlines

Sign up to get the best headlines direct to your inbox

Your name
Your email
Join the Newsletter
\n
    \n \t
  • 2017: AppNexus and Rubicon Project launch Prebid.org in a \u201ccollaborative industry effort\u201d to make the marketplace a more even ecosystem, delivering \u201cunbiased programmatic monetization solutions\u201d for premium publishers. To date, Prebid is the most widely-used header bidding wrapper in the world.

    • \n \t
  • 2019: Marfeel becomes part of Prebid.org to help dictate the standards that the publishing industry follows for header bidding.

    • \n \t
  • 2019: Marfeel launches MBid - server-side header bidding technology dedicated to matching publishers with unlimited demand sources without impacting their page speed and performance.

    • \n \t
  • 2019: Header bidding is widely adopted across the ecosystem. Among the internet\u2019s most popular 1,000 sites that sell programmatic ads, 79.2% used header bidding in March 2019.

    • \n
\"Header 
Source: Emarketer - Five Charts: The State of Header Bidding  


How does header bidding work?

So we now know about why header bidding was required for publishers, and how it came to fruition and who was responsible. But how does it work, in practical terms, to deliver a programmatic ad to a website visitor?
  1. A mobile phone user visits a website, for example, Elconfidencial.com.
  2. Header bidding javascript code gets executed in the header of the web page, for example, Prebid JS.
  3. This code, either executed on the browser or on a server, makes an auction call to ad exchanges or supply-side platforms (SSPs) simultaneously.
  4. An auction is held in milliseconds to fill the ad slot. The highest bid is passed into the ad request and calls the Publisher Ad Server.
  5. The Publisher Ad Server compares the highest bid with the concurrent auctions that are taking place in the Ad Server, and passes the highest bid to the Marketer Ad Server.
  6. The Marketer Ad Server compares the highest bid with the different lines that have been set up in DFP and also AdEx. If DFP wins, it will display the ad. If not, DFP will return a signal to the Prebid JS, and it will display the winning ad.
Before the advent of this process, ads were served in a manner known as the waterfall auction. 

Header Bidding vs Waterfall

The waterfall auction \u2013 also known as daisy-chaining \u2013 is a process where a publisher passes its inventory from ad network to ad network in descending order until their impressions are sold.\nBut the waterfall auction had some major drawbacks\u2026

  1. Favoritism: One major issue is that ad networks are usually ranked according to the average historic yield produced for the publisher. If the first network does not produce a satisfactory bid, the next ad network is called upon to bid\u2026 and the inventory continues to move down the \u2018daisy-chain\u2019.
  2. Passbacks: In the milliseconds an auction takes place, one advertiser might be willing to bid a much higher price for the inventory, but is cut out as they are not seen as a favorite earlier on in the process. This is known as a \u201cpassback,\u201d and it leaves publishers with lower prices for their inventory.
  3. Negative user experience: These passbacks also lead to ad latency. Advertising code is already too heavy on the publisher page and leads to slower websites and lower lighthouse scores, but if the ad call goes to each ad network one by one, this can slow down the page damage the user experience.
\n
Header bidding was developed as a powerful alternative to provide a more democratic auction:
  1. Increased revenue: By flattening the waterfall, publishers can increase competition for inventory. With less reliance on a single SSP, overall yield and fill rates increase as there's more competition between ad networks.
  2. More control: When demand sources bid at the same time, publishers can control which sources can participate in the bidding.
  3. Fewer lost impressions: As impressions are passed down the chain in waterfall set-ups, a few impressions are lost at each step, eroding inventory.
But header bidding was not perfect. Publishers today still have latency issues that damage the experience of users who are increasingly after premium, fast, engaging websites. This means it had to change shape and evolve. 


Server-side vs client-side header bidding

So far, there are three wrappers for publishers to run header bidding: client-side, server-side, and hybrid solutions.\nThe most common, and the current industry standard, is client-side header bidding:\nThe main differentiator for client-side header bidding is that header bidding is run directly in the browser of the website. 

It involves adding a piece of JavaScript to a publisher\u2019s website, which begins every time a page loads, sending an ad request to a number of demand partners. Then the bid begins, and the highest bidder wins the auction.\nRunning header bidding directly in the browser can result in a number of issues. Because scripts are added to the page header, latency can occur, impacting the number of ad impressions loaded and slowing down the page.\nThere are also only so many requests a browser can make at one time, meaning a limited number of ad requests from the client-side header-bidding wrapper.\nThat\u2019s why header bidding has evolved to make way to hybrid solutions, and the new standard - server-side header bidding. \nYou\u2019ll see that, instead of header bidding being run in the browser, with server-side, it\u2019s done on a server instead.  

Why? One issue is the impact on latency: that latency is significantly reduced by moving the header bidding process into a server. We\u2019re possibly talking about just a few milliseconds, but these milliseconds are enough to make a complete impact on the user experience as well as introduce more bidders to ramp up competition and yield.\nDue to this vast improvement on the user experience, server-side works better for video and rich media, introducing a mix of ad formats and types. 

As user behaviors change, and video and more progressive ad types become more the norm, server-side will be even more essential.\nThere\u2019s no restriction to the competition introduced for inventory - with server-side, you are virtually limitless to receive bids from a more varied range of demand partners. The result is better ad yield, higher fill rates, and scale for advertisers.\nAs Google AMP becomes more of an industry standard, and essential for publishers to ramp up their traffic, monetizing AMP web pages can be a real challenge for publishers. Google AMP has deprecated support for remote.html, and therefore server-side is now the only header bidding option to monetize Google AMP pages.


\n

The future of header bidding

\n\"Prebid
In 2019, Marfeel held the Prebid Leadership Summit in our office to discuss and strategise the future of header bidding technology. Within this summit, we learned that although server-side header bidding is developing into a better solution for publishers, it is still in the early adoption phase.\nBut in the words of former Prebid chair, Alexandra Smith, \u2018Prebid Server is not just Prebid.js without its latencies. It\u2019s an opening door to many more improvements and making crucial steps towards getting out of the browser.\u2019 

But that doesn\u2019t mean it can\u2019t be adopted right now.\nThrough a deeper development through collaboration, and thanks to Prebid\u2019s open-source tech, Marfeel has been working alongside publishers and industry figureheads to ensure header bidding is making more impact for publishers.