Header Bidding Pain Points

At SpringServe we were excited about this concept called Header Bidding.  Everyone was talking about it, but there was not a ton of information out there on how it worked.  We wanted to be able to offer a solution to our existing publishers, so we started digging in.

What we found was that there were three big pain points for publishers:

  1. The set-up with DFP and each demand partner is very confusing
  2. Integrating header bidding into a site takes significant engineering resources
  3. Changing configuration or adding a demand partner requires custom code and a full-site deployment

Below we will explain in detail the cause of these pain points and what SpringServe has done to mitigate these problems for our publishers.


Set-up Confusion:

To get started, let’s take a look at the overall workflow of a header bidding impression.

Figure 1: The full header bidding work-flow


Makes sense right??

We haven’t even gotten to the most fun part yet though.


As you can see in step 4, there is a significant amount of information left out.  Mainly:

  • How do the demand partners know what slots they are bidding on?  
  • How does DFP know what their bids are??  
  • How do you load a creative into DFP so that when a demand partner wins the proper creative is rendered???

The first thing to remember is that header-bidding is NOT a feature of DFP, but uses existing features (and really good naming conventions) to make it possible.  Those features are Key/Value targeting, Line-items with specific rates, and Creative rendering.

Let’s just look at one aspect, how to pass in your prices for each demand partner into DFP.  For each demand partner you must create a key/value pair for every price bucket that demand partner is going to be bidding on.  

ec2308dc16deb715ae0f946ce6709447Figure 2: Price buckets defined as key-value pairs in DFP


Now, for each of these demand partner price buckets, you need to set-up an associated line-item.  You then target a key value pair and set the Rate to be equal to the price bucket.  This will allow it to compete with dynamic allocation on a price basis.


You also need to make corresponding creatives to make sure the a demand partner’s creatives render correctly… and now you are done with 1 demand partner and 1 price bucket.  

What SpringServe does:

Integrations with major demand partners:

SpringServe has already done the integration work for the major demand partners in header bidding.  The list includes:

  • AppNexus
  • AOL
  • Criteo
  • CPXi / bRealtime
  • Sovrn
  • YellowHammer
  • PubSquared
  • Yieldbot

The best part of it all is that we have a fully scripted pre-configuration for all of you demand partners, line items and creatives.  All you need to do is give us temporary credentials and the set up is done in minutes.  It’s really that easy!

Integration Takes Significant Engineering Resources:

If the diagram above didn’t prove it, just take a look at some code in the wild. If you know of sites doing header bidding, you can just view their source and look for yourself.  

One of the better header implementations we found in the wild with an open-source header wrapper took over 700 lines of code, all written and customized by this publisher’s in-house development team.

You will find in almost every existing header bidding setup, hundreds of lines of hard-coded javascript and configuration are required to support all of these different demand partners.

What SpringServe Does:

With Header Bidding by SpringServe, everything is created within our user interface, and rather than building your own custom JS header, you can simply pull it from the UI:


Get Header Code

Changing Configuration Requires Deployment:

Now that you have ALL of that code and configuration in your <head> you now have a new problem…what happens when we want to change it.  

With a standard set up, each change requires new code to be written and/or old code to be removed, and tests to be run to ensure functionality.

With SpringServe, this process is quite different.

What SpringServe Does:

Why is the code AND the configuration hard-coded on the page?  Answer: It’s harder to deliver custom configuration per page while still ensuring speed and high-availability.  This is exactly the problem we have solved.  Your configuration is rendered for YOUR page based on what you have input into our UI.  

Let’s say you want to add a new slot to your existing configuration… normally, this will require you to code numerous lines of JS to add new bid entries, sizes, etc, while also requiring you to test your new code to make sure it doesn’t break the current setup.

With SpringServe, all you have to do is create a new tag in the UI:

You just give it a name, DFP slot id, and tell it the sizes/mobile sizes you want us to bid on.

What if I want to add or remove a demand partner from one of my ad units? I simply check/uncheck a box in the UI under that tag’s list of demand partners:

Demand Partners Tags

In summary, Header Bidding by SpringServe provides publishers with an elegant yet powerful solution that does away with the headache of integration, grants immediate access to robust demand sources, and allows publishers to easily adjust their configuration so they can scale efficiently and their dev team can focus on other important things.

David “Dave” Himrod


Leave a Reply

Your email address will not be published. Required fields are marked *