Header Bidding setup factors to consider for maximized yield

Header bidding is the new standard for publisher monetization, allowing publishers to offer their inventory to multiple demand partners at the same time in a real-time bidding (RTB) environment. It’s designed to increase publisher revenue by maximizing competition and create an unbiased ad market, but that comes with the cost of added complexity. Let’s unwrap some of these and explore key setup factors & best practices to optimize yield, as well as streamline technical aspects.

IMPLEMENTATION

The implementation of Header bidding is conducted through a ‘wrapper’ i.e. a container. This is where demand partners are placed, rules are set and auctions occur. The biggest consideration here is how much time and expertise you have for the set up of a fully functional header bidding solution.

A header bidding wrapper is a Javascript tag inserted on a publisher’s website that makes asynchronous calls to all the selected demand partners you want to take part in the auction. Most wrappers, especially sophisticated ones, contain vast amounts of code allowing bidding to occur smoothly and in a controlled fashion. That, along with the necessary updates required on a regular basis, present implementation challenges.

Publishers are looking at two main options in regard to header bidding’s page implementation: a direct header implementation or CDN hosting. While the direct approach may seem simpler, the latter actually makes for much better operations and maintenance. Having the wrapper code hosted externally decreases the risk of breaking web pages due to error and makes it much easier to roll out updates or troubleshoot site-wide. In the alternative, you would have to go in and edit every single header template you have which creates several times the work.

Another implementation consideration is also device matching. Mobile web usually performs best with lighter setups because of bandwidth and usability conserns, which creates the need for different configurations as opposed to on desktop. To that end, it’s advisable to split the inventory at a wrapper level across device categories, so that you have complete control on how each auction is conducted.

OPEN SOURCE WRAPPER OR PROPRIETARY WRAPPER?

There are 2 main types of wrapper; open-source or proprietary. Depending on your technical capability, you may want to choose a proprietary wrapper. This is where demand partners and set up is handled by the wrapper provider. Most demand partners will have their own wrapper technology. The ease of set up, support, and reporting may offset the higher costs and limitations of relying on partners to mark their own homework. 

Alternatively, you can create your own fully customizable wrapper using open-source technology. The most widely used is Prebid.js (created by Appnexus) followed by Pubfood.js. With these technologies, you can use adapters to plug into different demand partners and set your own rules, targeting and bespoke functionalities across different platforms. The lack of support and updates requires a far more involved technical resource and investment in this area.

Overall, if you’re working with an ad tech specialist or a monetization partner, the best option by far is utilizing an open-source wrapper. In most cases this will be a customized version of Prebid.js, which allows for maximum control, technical functionalities that would otherwise be unavailable and unbiased rulesets across all demand sources.

CLIENT-SIDE OR SERVER SIDE?

The difference between the two is where the auction happens; in the user’s browser (client-side) or on a separate server (server-side). The limitations of either can influence the decision here.

If page latency is something you want to avoid, then the server-side has the advantage. However, the lower cookie match rate hands the advantage to the client-side. Likewise, avoiding browser limitations and enabling a higher number of possible demand partners is an advantage for the server-side. Whereas the lack of transparency and inability to use advanced targeting gives the client-side the upper hand.

Ultimately, it is possible to run both client-side and server-side simultaneously and this can be achieved with separate wrappers or hybrid wrappers. That is, however, not a permanent solution as you’re effectively adding twice the load for pretty much the same demand.

Currently, we recommend sticking to client-side for the most part, as it doesn’t have the technical limitations of S2S and thus delivers the highest performance. The speed boost from a server-to-server integration is just not significant enough to make up for the difference in revenue yet.

PROVIDERS/demand partners

Selecting the right demand partner is vital to get the best out of your header bidding set up. Competition is the lifeblood of header bidding, so a good mix of partners is important. 

When using a proprietary wrapper, the demand partners are usually already set up within the wrapper, so it is important to make sure there are a good number of Tier 1 demand partners in there to encourage premium competition. 

When using an open-source wrapper, demand partners need to be added using an adapter. Technically, an adapter is a unique code providing access to the demand partner and their demand sources; advertisers and agencies. The auction occurs on the demand side and is returned to the wrapper via the adapter, along with the bid request containing size, format, etc.

Each adapter provides unique types of demand and each of those will have their individual characteristics. Be mindful of what targeting they employ, whether they are stronger in specific geographical regions, whether they specialize in a particular format or if they offer a greater scale. 

Testing is vital and monitoring the percentage of impressions they bid on and how often they win are great indicators of their suitability to your site and audience. If they are not contributing to the competition, then their involvement needs to be reassessed.

Be mindful of having too many adapters that may increase your page latency, there are subtle nuances to each partner that you may be able to pick up on in your reports. Header bidding is for the most part a balancing acte between performance and latency, so the best possible setup is the one that considers both. In regard to demand partners, this means that the fewer the better, as long as you can still capture most of the revenue potential.

For example, if 12 adapters only gives you a 3% uplift in ad revenue as opposed to 8, then perhaps it’s time to clean up the stack. The speed boost you’ll gain as a result will more than make up for the difference in performance.

ORDER AND TIMEOUT

Most header bidding wrappers have options to customize not only the order your demand partners are called but also the timeout they have for them to respond to a call.

ORDER

Most header bidding wrappers will give you the option to randomize the order in which demand partners are called when you first set them up. Some can be set to alphabetical order by default. The last demand partner called can often find it difficult to return an appropriate bid before the timeout is applied, so randomizing can mitigate that nuance. If there are many demand partners being called, randomizing further levels the playing field as each demand partner faces the same disadvantage.

TIMEOUT

One slow demand partner can delay the whole auction. All bids must be returned to be able to select a winner of the auction. This means the whole process is awaiting a response to the bid request from all demand partners taking part, a slow partner will add to page latency and therefore negatively affect the user experience. By setting a timeout for a response to each bid as a deadline, slower partners will not affect the auction or the page latency.

Keep in mind that the lower the timeout is, the more bids you are going to lose and performance is likely to suffer. This means you need to find the shortest possible timeout that allows for the maximum amount of bids to be returned on average. There’s no fixed number here as it varies depending on demand sources, so it’s up to experimentation.

We genereally advise starting high (at about 1500ms) and then lowering it gradually to inspect how performance shifts. On average, we’ve found timeouts between 900ms and 1100ms to perform best in the long term, but that’s definitely not always the case.

PRICE FLOORS

Header bidding is designed to increase competition through increased demand providing higher CPMs and revenues. So why are price floors even needed?

The reason is Header bidding wrappers typically return rounded down demand partner bids to the ad server. These rounded down bids need to be managed into price buckets. The more granular, the less wastage. For example, buckets of $0.25, $0.50, and $0.80 mean that if a bid is rounded down from $0.76 to $0.50, then there is a $0.26 shortfall recorded. By creating a more granular bucket setup of $0.05 increments, the shortfall would have been $0.01. But how practical are $0.01 increments when you would need 1,000 buckets to cover bids up to $10? Prebid best practice suggests using price buckets to represent price ranges that matter:

If you’re still having difficulties with your Header Bidding setup or yield management, you can get in touch with one of our monetization experts who will be more than happy to help you out. Supercharge your header auctions today!