Myth busting: Header bidding

When it comes to header bidding, it can be a confusing landscape out there. Before I dive into some of the most common myths doing the rounds, if you need a quicker refresher on the basics of header bidding, check out this handy crash course by my colleague Marcus Pousette, Country Manager GCK and SEA.

Myth 1: All wrapper solutions cost a fortune

While wrapper solutions can get expensive for publishers, with some ad tech providers charging publishers a revenue share on the revenue generated by all demand partners in their wrapper, this is not true of all solutions. PubMatic don’t.

With some wrapper solutions, like PubMatic’s Prebid-based OpenWrap, there are no hidden fees for publishers. This is something we believe strongly in: publishers know exactly what they’re signing up for and what the costs are upfront.

Does this mean they charge buyers instead? 

As a wrapper provider, you don’t collect fees from buyers and advertisers. This is done by each partner within the wrapper. It is essentially up to each partner — as part of their business model. 

Myth 2: Integrating a wrapper solution is really complicated

Any SSP worth its salt has a dedicated customer success team to do all the heavy lifting for publishers. They will guide the publisher through the integration process, doing all the technical work on the back end, including troubleshooting.

For a publisher, adopting a new wrapper solution can be as easy as deploying one line of code in the header of their webpage. 

That said, when evaluating a potential SSP partner, it is important for publishers to do their due diligence. They need to be asking the right questions, such as ‘Where is your customer success team based?’ and ‘Are they in my time zone — will I get real-time support?’ 

While most SSPs have dedicated teams, there can be a lot of nuance in terms of how effective those teams are. 

Myth 3: Maintaining a wrapper solution is painful  

But not if you’re working with the right SSP partner — one that makes code deployment simple. 

Some wrapper solutions require publishers to deploy updated code every time they want to make a change such as adding or removing partners or ad units. This means making changes can be arduous and time consuming. Every time a publisher needs to deploy new code, their quality assurance team first needs to ensure the new code doesn’t break anything on the webpage or slow down page load times. Because this process takes time, many publishers will wait until they have multiple code changes to make and then set them to go live at the same time, for example at the end of the quarter. The result is that with some wrappers, something as simple as adding a new demand partner can take months.

However, maintaining a wrapper is easy if you’re working with the right partner. Solutions like PubMatic’s OpenWrap come with persistent code that does not need to be updated, can be deployed and is ready to go. Every change a publisher wants to make can be done via an easy-to-use UI, such as updating to the latest version of Prebid, changing timeouts, or adding and removing partners, ad units and ad sizes. 

Myth 4: Wrappers are biased towards an SSP’s own demand 

While there are some bad actors out there who engage in shady practices like biasing auctions, transparency is built into the DNA of leading SSPs. These SSPs will have wrapper solutions built on open-source code that is available on platforms like GitHub for publishers to download and vet themselves. GitHub is a software development and version control platform where most tech vendors store code; and this stored code — like the code for PubMatic’s OpenWrap — is public.

In addition to the code itself being easy to check, with the right wrapper solution, publishers can keep an eye on things in real time. Publishers can see the bids from all demand partners running on the wrapper via the console on their browser, so they can be sure there is nothing untoward happening.

There has been some chatter recently about publishers needing to access log files from SSPs in order to be assured of true transparency. While log files are the best way to access very granular data — these files are huge, and reading and analysing them can be a drain on publisher resources. Log files contain bid-by-bid data for every partner and every impression, and trawling through them requires an expert in-house team and a lot of resources.

If you’re working with a reputable SSP, all frequently used analytics are made available via the UI and can be checked in real-time. This data will usually be aggregated to an hour or a day level, so it is more useful and doesn’t require specialist skills to interpret. If your SSP partner has ticked the boxes above (namely their code is freely available and you can monitor all bids in real-time on the console), accessing log files is simply unnecessary.

But again, it is important for publishers to be asking the right questions. Transparency should be table stakes for all SSPs. 

Myth 5: Header bidding is only good for publishers

Header bidding is a great thing for publishers — it brings increased demand, lower latency and better yield — but it is also a great thing for buyers. 

By flattening the waterfall and giving all demand sources the opportunity to compete in one unified auction, header bidding democratises access to inventory for buyers. It means buyers are free to choose their preferred path to inventory, rather than having that dictated by the publisher ad server. Buyers can choose their pipes, leaving them free to take advantage of supply path optimisation initiatives or other relationships they may have in place.

And because all demand competes in one auction, buyers know that they’re paying fair market value for each impression.

Myth 6: all wrapper solutions are created equal

Not all wrappers are created equal and there can be big differences in the monetisation publishers can obtain through different wrapper solutions. 

This is true even with wrapper solutions built on Prebid, where you’d expect very similar results in terms of gross revenue. For more on this, check out this case study on how premium Hong Kong Publisher, 9GAG, put three wrappers to the test and found that despite running the same adapters, for the same ad units, in the same markets, there were big differences in the monetisation that was delivered. 

Publishers can leave money on the table by basing decisions about which wrapper to integrate purely on an RFI or even worse, gut feeling. It is not yet common practice for publishers to A/B test different solutions, but it should be. RFIs are useful for initial research, but without objective testing it is impossible to predict real life performance. Would you buy a new car without taking for a test drive?

If you’re thinking about a new wrapper solution, don’t just ask the right questions. Put your options to the test.