For many in the Ad Tech industry, 2016 will go down as the year of header bidding. But despite the hype, popularity, and wide-scale adoption, there are still a number of questions that linger.
So for our latest edition of Insider’s View: Ad Tech & MarTech Q&A, we caught up with Greg Blackman – CEO and co-founder of Bidfluence – to talk about all things header bidding.
You can connect with Greg on LinkedIn and follow Bidfluence on Twitter.
1. Can you tell us a bit about your background and expertise in the Ad Tech industry?
I got started in online advertising by crashing one of the original Ad:Tech conferences in San Francisco. I handed out my resume at an after party at one of the local nightclubs to Ad Tech companies. It worked and I started my career working for AskJeeves before it was changed to Ask.com. 10 years later, I ended up working for some very respectable ad tech companies, including AdKnowledge and OpenX.
Then in 2016, I founded Bidfluence.
2. What specifically does Bidfluence do and how does it fit into the larger online advertising and marketing picture?
Bidfluence is an ad exchange that aggregates both server-side and client-side demand and is flexible enough to work within PreBid.js as an adapter, ad server or server-side connection. Our vision is to do our part to clean up a lot of the violations we see on both the buy and sell sides.
From an ad quality perspective, we’ve created multiple protections to seek out and eliminate endemic issues, such as auto-redirects, in-banner videos and AQ latency. This is all done in real time in a live environment and helps ease the game of whack-a-mole, which publishers are unfortunately still playing today.
By aggregating the demand and implementing these ad quality controls, we provide publishers with a very safe way of accessing demand at scale. This also helps to fill historically difficult impressions.
3. As a company that works closely with publishers, what does the adoption of header bidding look like?
The move from waterfall over to header bidding is very use-case specific.
Large publishers, specifically in the US, were the first ones to start using header bidding, but they haven’t fully committed to only using header bidding. Most of them today use a combination of header bidding and waterfalling via their ad server (typically DFP).
We’re finding that most other geographic locations that support programmatic are moving in this direction as well. Smaller publishers are also starting to leverage header bidding through a completely pre-configured 3rd-party wrapper or by reaching out directly to the players on the PreBid.js list.
4. Are publishers happy with the results they’ve seen from header bidding and do they have any concerns about moving away from the waterfall and towards header bidding?
The publishers that have adopted header bidding have been happy with the results as there has been a large revenue lift for pretty much all of them.
However, the move from the waterfall towards header bidding brings new concerns and begs some initial questions, such as – what does this new configuration look like, how long is the time out, how many players are there, who are they?
There’s a whole new world of questions that opens up when a publisher adopts header bidding.
5. Moving the bidding to a server seems to be the next logical step, but are many publishers moving towards the server-side implementation. If yes, what’s driving the change?
Revenue is still the number one value proposition driving integrations. Because server-side integrations allow for more companies to compete in a more efficient manner, there should theoretically be higher CPMs. So, yes, we as an industry will eventually move from client-side integrations to server-side ones.
However, I wouldn’t say that true server-side header bidding is here yet. Even the largest publishers are still working through the nuance of configuring their client-side wrapper configurations. Someone will create an easy way to provide effective yield management server-side in a unified auction. Today, only the most advanced publishers are building their own solutions.
The biggest thing slowing down the transition is the technical burden of creating a system that is capable of handling OpenRTB end points. Some of the other issues that haven’t been worked through yet are loss of cookies, discrepancies, and the cost of handling the influx of server requests.
6. How do you think the issues found in server-side header bidding (e.g. transparency and cookie loss) should be, or will be, addressed over the coming years?
Well, we are actually working on some products that will tackle some of the issues associated with server-side header bidding. So I’m going to reserve my right to answer that question at a later time. Please stay tuned.
Click here to read our previous Ad Tech & MarTech Q&As.