In part one of “Nailing the Setup”, we covered the market’s header bidding technology offerings of client-side, server-side, and hybrid solutions. We also outlined the advantages and disadvantages of all three solutions.
Now it’s time to deal with the three questions that each publisher should ask before implementing a solution for selling their inventory. At the end of the article, we will address best practices and tips on how to implement each solution.
Here the three key questions:
- How many partners do we need?
- How important is inventory control for us?
- How much importance do we place on the user experience for our users?
How many partners do we need?:
How many partners do you really need? Client-side header bidding wrapper solutions are obviously restricted. The more you add partners, the more work you ask the browser to do. Browsers also have a maximum number of parallel connections (between 10 and 20). When you exceed that number, you won’t be able to call all buyers at the same time and you will not leverage the potential increase of liquidity from a header setup. Only some buyers will be able to participate in the auction before the timeout is reached.
If you determine your optimal yield is realized keeping only 5-6 partners, you can efficiently manage them in a client-side setup. As a general Adomik recommendation, we don’t see much value in having more than 6 SSPs in the client-side wrapper.
If you determine your optimal yield is realized using more than 6 partners, you should look at managing them in a server-side or hybrid setup.
But how do you determine optimal yield? Always ask yourself if that partner is bringing real value to your stack. It’s difficult to say beforehand, but keep monitoring any new partner you add. Does the partner give me access to more unique demand? Does the buyer have decent response times? What happened in terms of yield when I added this buyer? Did my overall revenue increase or is this buyer only taking some share from my existing partners? (More on that in a future article). A lot of these answers will depend on the type of inventory. The more diverse your inventory is, the more partners you may require.
If you determine you need more than 6 partners, then it’s worth looking into server-side header bidding solutions or a hybrid header bidding solution where your non-preferred partners can go server to server (More on that in a future article).
How important is inventory control for us?
When it comes to choosing between solutions, you have to determine the sweet spot balancing between publisher control and time spent on the implementation/maintenance.
If this is you: “I want 100% control and transparency on what’s going on in my stack and I don’t mind spending time making tweaks.”
Then you should favor a client-side header bidding solution. Everything is visible in Javascript consoles and you have access to analytics solutions where you can precisely monitor evolutions in your stack such as:
- How are my partners performing?
- How do time outs affect my monetization
- How does a yield set-up change on one partner affect the monetization and balance between all the bidders in the header?
If you have time to make these kinds of analyses and if you manage a reasonable number of partners, client side solutions might be more appealing.
If this is you: “I want to have some points of control but have many other projects to manage.”
Client-side might be the right solution but you should consider that it takes some time to implement on your site and structure the set-up in the ad server. However, these processes have been experienced by many publishers, tend to improve and get less complex and time-consuming. Server-side header bidding solutions are also an option. Bear in mind though that a single partner monitoring this process has full control over the auction dynamics (and could easily fix rules to its advantage). This is why the solution chosen either needs to earn your trust via transparent data or trust in the relationship with the vendor managing the entire process. In the case of server-to-server header bidding integrations, the partner owning the wrapper will take care of everything in terms of implementation and you will be able to focus on other matters.
How much importance do we place on the user experience for our users?
All publishers want to have the best user experience possible. Today, with well designed set-ups there is little proof showing that client side header bidding set-ups are adding latency or deteriorating the user experience compared to other models. Still, as mentioned, always “be gentle with browsers” — meaning don’t overwhelm them with too many partners.
That said, the prevailing wisdom these days is that the server side header bidding solution will not contribute any latency and is generally preferred if the only decision criteria is latency and time outs.
CONCLUSION
If you haven’t been thinking about adopting either client-side or server-side yet, you need to start now.
At this point you should have a clear idea of which solution to go for. If you dont here is some suggested reading.
Once you have made your decision, you’ll need to monitor what’s happening to both keep your partners honest and to understand your stack better.
If you implement a client side header bidding solution:
- Find an analytics solution to monitor the average bid value, response time, etc..(Hint Adomik has one)
- Find the optimal time-out rate to revenue trade off between collecting the bids from all your partners and keeping the auction with as little latency as possible.
- Monitor your partner’s response times as well as the added value (unique demand, high bid gaps with other partners bringing value, etc.) This will help you understand which partners you want to keep and which partners you can remove from your HB set-up.
- Keep in mind that the last two analyses are related. For example, you may want to remove a slow partner bringing undifferentiated demand, rather than increase the time-out to keep that partner.
If you implement a server-side header bidding solution:
- Reporting: make sure you are aware of log-level reporting of bid-stream data and make sure all of your partners are using a fair auction model, among other things.
- Build a good relationship with the wrapper vendor holding the auction. Then require that you receive data about their buying, timeout, and performance to validate that you can trust them, and at the same time illustrate you are very aware about what happens in your stack.
- Be sure not to lose too much cookie match data, so that all your demand partners know which audience they are bidding on. Ask for cookie-match rates between the wrapper provider and your other partners. Also keep in mind that the wrapper vendor will have the advantage that DSPs will more easily recognize a cookie using its route rather than another partner – this may introduce some bias.
If you implement a hybrid header bidding solution:
- Regularly check your partners response time, and, in case of inefficiencies, move one partner from client side to server side (if they are not performing well). And move one partner from server to client when that partner brings unique value to your demand ecosystem. Having your unique demand partners in the client side wrapper is advantageous because it increases cookies match rate.
- Also, bear in mind, within hybrid header bidding solutions you’ll need to consider all recommendations above concerning both client and server side header bidding solutions
Now that you know the pros and cons and what questions to ask, its time to move on to to how to user your data and analytics to optimize your setup. Stay tuned
< Previous post: Rule 1 – Part 1 Next Post: The Magic Number of Header Partners >