When it comes to header bidding and wrapper solutions offered by sell-side platforms (SSPs) – it can be a pretty confusing landscape out there. The technology itself is complex, and this is further compounded by a lot myths doing the rounds. In this piece, PubMatic customer success manager ANZ Rachel Dam [pictured] busts some of the biggest myths around ad tech.
Before we start, if you need a quick refresher on the basics – what header bidding is, what a wrapper is, etc. Then check out this handy Crash Course from PubMatic’s country manager, GCK and SEA Marcus Pousette.
Myth 1: All wrapper solutions cost a fortune
While wrapper solutions can get expensive for publishers – some ad tech providers charge publishers a rev 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’s 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. She or he will guide the publisher through the integration process, doing all the technical work on the back end and 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?’
Because 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
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, lots of publishers will wait until they have multiple code changes to make and then set them all live in one go, 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 or removing partners, ad units or 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 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.
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 it 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.
