HEADER BIDDING WARS: WHO DARES WINS
Updated: Oct 5, 2018
A BLOG POST BY CHLOE GRUTCHFIELD, CO-FOUNDER
I love a good hack - especially when it’s one that digs deep into
the digital minds of GAFA’s technologies.
Header bidding is one of my favourites. Simply , because it places the power back into the hands of the publisher, by moving the auction control away from the ad server (DFP).
The concept that enables this is pretty simple: a script, or series of scripts, implemented into the <head> section of a website that triggers demand sources to place bids before the ad server script and web page have even started to load.
There are two different solutions that can both coexist on a web page:
Traditional Client -side header bidding: A series of scripts implemented in the <head> section. Each script is essentially calling a “bidder” (Ad Exchanges, SSPs, DSPs) for a bid on the browser
Server-side header bidding: One “wrapper” script implemented in the <head> of a website that solicits multiple bids from multiple demand partners at the same time via serve to server (that of the wrapper and that of the bidder) requests and responses
It was also a great hack that enabled ad tech vendors to fight against Google’s traditional
waterfall ad serving methodology and later its dynamic allocation feature
that always seemed to favour Google’s Ad Exchange.
But the real magic about it (and the reason why it gets me so excited!) is down to the fact it allows us to out-smart Google. And that always makes me feel smug.
Many ad ops people are often tasked to set up hundreds (sometimes more) of line items on
DFP to accommodate the header bidding auction - something that DFP absolutely did not
intend them to do. A bit like when you use a discount offer multiple times from
a different email address (guilty!).
For the non ad-ops-y people, the header bidding solution is calling bidders (ad exchanges, SSPs, DSPs) for their price, which needs to be passed onto the ad server on the query-string. Because of the way auctions are traditionally setup on an ad server (waterfall with price floors or priorities), the bid price needs to match a line-item that earns you roughly the same amount if it serves.
Alas, Google came up with a solution to prevent that hack, an alternative to fix some of the publishers’ problems around the traditional waterfall ad serving.
Introducing Exchange Bidding, a.k.a EBDA. It’s now available to all DFP clients.
This is what it’s described as if you read the DFP Knowledge Base:
“With Exchange Bidding, publishers and exchanges optimize yield management with server-to-server real-time bidding that uses a publisher’s existing tagging or SDK implementation. The unified DoubleClick technology stack also provides simplified trafficking,
reporting and billing.”
In parallel, header bidding is continuing to gain traction,
even within GAFA in what could be best described as a header bidding 'hackathon':
Ad Tech vendors collaborate to create and maintain an open source library and community, that helps publishers implement header bidding on their websites & apps: Prebid.org
Amazon launched a header bidding wrapper last year that’s been
adopted by many publishers
More recently, Facebook expanded its support of header bidding for in-app advertising.
Wondering whether you should go with a header bidding solution
(combining both client and server side header bidding), or EBDA?
It’s actually not always a binary decision. Some of our publisher partners use both:
“We usually trial vendors in EBDA. Once the contract with a vendor is done
(which is usually the hard bit), it’s a very straight forward setup in DFP.
If they drive significant revenue within EBDA, we move them to the wrapper”.
Here are some of the key things to consider:
Let's take a look at the differences in more detail.
Control:
HEADER BIDDING:
For obvious reasons, header bidding offers a lot more control to publishers
who can select the demand sources they want to integrate with.
EBDA:
With EBDA, there’s a limited list of integrated demand sources.
Here’s DFP’s official list of partners (as per their Knowledge Base on the 21st June)
Latency:
HEADER BIDDING:
The biggest drawback with header bidding, especially in the early days,
was the pressure multiple scripts put on the browser, resulting in latency and the slowing of page loading times. But with server-side header bidding (now available via wrapper script solutions or even prebid.org’s server open source solution), that has become less of a problem.
In traditional client-side header bidding, the auction was happening in the browser.
Each bidder would have a script in the <head> section of the web page - so effectively the page wouldn’t load before all those scripts were executed. Each script would trigger a separate auction so a publisher website could have five, sometimes more auctions happening simultaneously on the browser before the page had even started loading. This, of course, caused latency on the page. Server-Side Header Bidding involves one wrapper script in the header that executes and then calls all bidders on the server; because server-side header bidding only requires one call, it dramatically reduces page latency.
Today, most header bidding solutions will be a combination of both of the above so some
latency is to be expected, but it has improved greatly since its infancy.
EBDA
On the other hand, EBDA is purely server side so latency is minimal.
Setup
HEADER BIDDING:
Header bidding involves the setup of one wrapper script (server-side) or multiple scripts (client-side) in the header of a web page. With it essentially being a hack, it also requires the implementation of hundreds of line items on DFP which is a very cumbersome process for the ad ops team.
EBDA:
EBDA on the other hand just requires the ad ops team to make changes to their DFP setup.
Also from a billing perspective, the EBDA setup is lighter with payments facilitated by Google and determined by each Exchange Bidding yield partner’s impression delivery volume.
Monetisation Potential:
The biggest drawback of EBDA (and pure server side header bidding) is to do with low cookie sync rates. Because the demand sources lose their access to the browser, they can’t drop or read cookies anymore. That means that smaller demand sources that don’t have large scale and a good sync rate with the wrapper solution (header bidding) or Google may not be able to associate a particular impression opportunity with data and therefore place lower bids.
It’s fair to say that there’s a lot of information to take in. And with benefits that lie within each solution, it makes it hard to determine what avenue to take that suits your business needs.
RedBud Partners can help you identify what solution is best for you depending on your current setup, the size of your ad ops team, the demand partners you are currently working with etc.
Get in touch with me at chloe.grutchfield@redbudpartners.com.
#headerbidding #programmatic #header #bidding #ebda #latency