Back in April, Google announced a change to its Double Click for Publishers (DFP) ad server by allowing the real-time bids of a publisher’s outside exchange partners in its Dynamic Allocation product. At the time, and in subsequent months since the April announcement, some questioned the survival of header bidding, since header bidding was ad-tech firms’ response to getting around Google’s domination.
Header bidding addressed the problem that Google only allowed its own ad exchange to compete for each ad impression, ahead of any other exchanges. It used to be that Google’s ad server would project what an outside exchange could bring in, and wouldn’t allow them to submit bids for every impression. Header bidding solved for DFP’s weaknesses by taking bids before the ad-server call, which allowed bidders to compete on actual price, not an estimate.
There are advantages to header bidding: It goes around the ad server, jumping ahead in the “waterfall” to get a first look at all the ad inventory available so that publishers and ad tech companies can bid before Google’s DFP does. In the past, DFP got a preferential look at the inventory.
But the problem with header bidding, according to at least one ad-tech vet, is that publishers have to put a tag in their header for each header bidding partner. And each tag added can cause latency and other problems for publishers. For example, tags can cause pacing and cadence issues for campaigns if the tags aren’t set up properly, resulting in direct-sold campaigns failing to deliver. “More tags equal more headaches,” as one executive put it.
I would argue against the idea that Header Bidding requires a tag in the header for each partner. This implies a sequence of script tags each operating one after the other causing latency. In fact, most Header Bidding installations consist of a single script tag which loads a container, bound by a timeout value typically 750-1500ms, that executes the callouts to each header bidding partner. Don't get a bid in before the timeout and you are out - this solves the latency problem. Yes - different header bidders have different requirements and some callout requirements are heavier for the page than others. Yes S2S integrations are the path forward, but even so, well implemented header containers are transparent, efficient and lower latency than a typically tag waterfall (given the usual client side redirects).
Tony - I'd be inclined to agree that it doesn't "require" a tag for each, but that is the implementation that we see most often. There are way too many publishers who simply aren't implementing tags well. S2S helps solve for that problem. I think we are mostly in agreement here.