When header bidding became the de facto route for publishers looking to go beyond Google, the number of companies offering the wrapper (also known as “header bidding wrapper”) proliferated. On the flip side, open-source frameworks like Prebid were gaining popularity and traction, especially among the premium publishers.
Ultimately, publishers had several options to go with. But that’s not the case anymore.
Let us make the case.
a) With header bidding, a publisher can connect to a handful of SSPs, and in turn, reach a DSP via multiple routes. Earlier, it wasn’t a problem. But with the huge influx of duplicated bids, DSPs are implementing Supply Path Optimization (SPO) in full-swing.
This forces SSPs to cut down the duplicated bids from their end. For instance, PubMatic, OpenX, etc. use their own bid throttling algorithms to send only the selected requests to DSPs that are likely to win. If SSPs help DSPs to handle the QPS and duplicated bids problem, they can have a successful long-term partnership. Of course, publishers will be benefitted as well. Imagine having an SSP with a better win rate.
But this begs a question – Why should publishers send the bid requests to all the partners they’ve connected to? If a publisher has an SSP connection to access a specific demand (say to sell impressions from Japan), wouldn’t it be better to send the request only when a user from Japan visits the site?
“One German sales house we spoke with recently, mentioned that a buyer might only see 70% of their supply if they were only accessing it via one SSP.”
– Cadi Jones, commercial director EMEA, Beeswax (Src).
That’s just one example. Publishers tend to have SSP partnerships to sell specific sets of impressions, ad formats, etc. And, it’s not just about reactive changes. As a publisher, you’ll also want to proactively experiment with your bidder setup to optimize page speed and revenue.
b) Speed. Mid-sized publishers who want to implement header bidding and see the true market value of their impressions typically find it difficult to directly go to SSPs and build their own wrapper. But that shouldn’t stop them from experiencing the speed and ability to leverage the new techniques/formats available in the market.
If you think about it, a publisher with header bidding setup, should have both – Control over the bidders participating in an auction and ability to execute new techniques without worrying about the development work.
We believe that the wrappers in the market fail to ensure both to publishers. But not us. In this piece, we’ll see how Automatad is helping hundreds of publishers to not only run efficient header auctions but also continually optimize revenue and experience for the end users.
Sidenote: Automatad’s Header Bidding Wrapper is a part of our Full-Stack Programmatic Monetization Platform. We’ll dive deep into our platform in a different post. Here, we are focusing on our wrapper.
Let’s get started.
With the tens of bidder partners connected to the wrapper, when a page loads, you are sending out the bid requests to all of them. But there’s a high chance that you have connected to a bidder who performs well in a specific geography (because of the nature of demand). In such cases, it’ll be better to send requests to a bidder only from certain geographies.
Well, we can enable/disable bidders on specific geographies on the go. Want to send bid requests to OpenX only for the U.S. users? Done.
Not just countries, you can enable/restrict bidders on certain devices. For example, if you have partnered with an SSP for selling mobile impressions, then it doesn’t make sense to send bid requests from desktop to that SSP. It adds unnecessary weight to the page latency.
Just send mobile ad requests. And, what if you have an SSP that performs better on 728*90, but not on other sizes? Simple, only enable the bidder on the specific ad size.
Tip: If you’re using Prebid, you can leverage some of the features discussed here.
Every site will have its own page layouts. From home page to listing page to search page to article page, they all tend to look different from one another. This means,
a) Publishers have to create and maintain different ad layouts.
b) Customize the ads on the layouts seamlessly.
At Automatad, we can include/exclude bidder partners or completely stop running ads altogether on certain layout pages at once. By leveraging meta tags, a publisher can, for instance, stop running ads on listing pages.
Publishers typically want to keep certain pages including about us and contact us — ad-free. So, we let them block all the ads on certain pages with a simple URL submission.
Don’t want to run ads on a specific page, just submit the URL and block the ads. During the current crisis, this comes in handy. They can block non-brand safe content and let advertisers run ads on regular content.
Introduce New Ad Units:
You can introduce new ad units on selected layouts and devices in a few clicks. Want to include a new ad unit on all the article pages on mobile devices? Just define the ad spot (position), select devices, and the layout. You’re done.
When you take a new ad unit live, you’ll always have something to improve the ad experience.
You might want to add padding around the unit to avoid double click penalty or add a Z-index to keep it at the top of the stack. We let publishers add custom CSS at the ad unit-level.
Instant Sticky ads:
Sticky ads have become one of the most common ads on websites. As they stand to have 100% viewability and better engagement rate, publishers have flocked towards it. As a full-stack platform, we know our publishers would want to explore sticky ads as well.
So, we designed the easiest way to make ads sticky — Select the layout where you want to run sticky ads (say article page). Select the ad spot (for example, sidebar). Now you can select the start point and endpoint to define when the ad should become sticky and how long it should stay so.
Else, just set a timer. That is, you can make an ad sticky for X seconds.
Apparently, you know what lazy loading is and what will be the impact on the bottom line and page load speed. In case a publisher is interested in lazy loading certain ad units (let’s say BTF units), all it takes is a simple tap.
Dynamic ad loading:
If there’s one thing we learned after working with hundreds of publishers, the depth of the content varies a lot. One story will have higher engagement (scroll-depth) and the other story will have comparatively lesser engagement.
So, it is best to enable ads dynamically. We help publishers to dynamically load ads based on the scroll-depth and content. In case you’re wondering, yes, it works great for infinite scroll sites.
As the user scrolls, we can send ad requests, sell the impressions, and render the ads. Your readers will see an ad, not whitespace.
Header Bidding Restriction:
Similar to how we can enable bidder partners/ad units on specific layouts, geographies, and devices, you can enable/disable/restrict any of our products. Want to run header auctions on the desktop? It is possible.
Enable/disable header bidding for traffic from India only on mobile devices.
Automatic GAM Setup:
This is perhaps the most tiring part of setting up header bidding on Google Ad Manager. You have to create advertiser, placement, key-values, and orders & line items for the bidder partners.
Well, no more. With a click, we automatically create advertiser, placement, key-values, and orders & line items (based on the bidders).
Unified Analytics Dashboard:
What’s the point of offering all the granular customization, if publishers can’t see the impact clearly. We provide a unified analytics dashboard that pulls in data from all the bidder partners and presents them in one place. You can see ad impressions, revenues of the bidders among other actionable insights.
If you are still asking – “is that all your wrapper can do?”, then let us know what you are looking for in the comments. Because, we likely have the feature in our platform (I haven’t listed each and every feature in this article). After all, we’ve been serving hundreds of sites and if we see a consistent requirement, it’ll turn out to be a in-built feature soon.