Header bidding has been in the headlines nonstop in the past couple years. Header Bidding was introduced in early 2009, and today, it is estimated that approx. 70% of publishers have adopted this technology. It makes sense that there are several myths surrounding its implementation. Let’s discuss those myths and the pros and cons of header bidding.
High latency/load time since the additional code is implemented at the header, which affects the user experience and viewability.
Implementation at the impression level is not easy.
The high yield is short term, since header bidding results in a lower-quality impression. This may then cause the advertiser to block publishers that are not performing for them.
Multiple header bidders lead to poor performance.
Data security needs to be addressed, as header bidders also load tracking pixels even if they don’t win the bid.
Auction time on mobile devices is longer due to slower Internet speeds.
There is no standard defined yet!
Multiple line items have to be made in the publisher’s ad server mentioning the bid cost, i.e., the same will serve only if the demand is met.
The Myth: “It Helps Serve Ads”
Header bidding does not help in serving the ad, but only in deciding which ad will be served.
The header bidding script only helps to pass the key value to the ad server on which the decision is made.
This means that in the end, the ad server decides which ad will be served, and any comparison between different SSPs or between an
SSP and a network or direct is made by the ad server.