2017 will be remembered as a year of transition in header bidding. Widely accepted client-side solutions that have been commonplace in the publishing community for the last 4-5yrs are now giving way to a new breed of script: server-side solutions.
The main difference between a client-side and a server-side wrapper lies in how it communicates with the participating exchanges. On the client-side, a publisher wrapper will make a call to multiple exchanges directly through the user’s browser.
When using a server-to-server solution, the publisher will make only one call to an external server using the browser, which in turn, will make all necessary calls to the demand partners or exchanges.
As of today, client-side header bidding is still broadly used by publishers. In that case, what happens is that the bidders or SSPs called in your client side wrapper are fetching and returning bids through the user’s browser in one of the following ways:
The issue with a client-side wrapper is that if the number of simultaneous calls exceeds the maximum number permitted by the user’s browser type, a bidder queuing will occur. Then, the execution of certain calls will be forced to wait for the connections to free up.
There are many reasons why you would want to avoid queuing - here are a couple:
Current number of simultaneous calls supported by browser
Chrome (32 & 34): 10 calls
Safari (7.0.1): 17 calls
Firefox (26 & 27): 17 calls
Internet Explorer (9): 35 calls
Internet Explorer (10&11): 17 calls
If you want to avoid bid queuing, decrease your timeout rate and ensure optimal revenue from all bidders, district m recommends moving to a hybrid solution that can accommodate both C2S and S2S calls.
Here is a scenario illustrating a call made with a client-side wrapper.
In the diagram below, you have three ad spaces available on the web page. Through the client-side wrapper, you have two single call exchanges and one call per placement will be made to each of the remaining six exchanges bidding, resulting in :
Now, we have seen that most browsers wouldn’t accept 20 simultaneous calls. This would then result in queuing, thus slowing the process and creating latency. Plus, some ads may never get an opportunity to be placed due to a timeout.
Now what happens when using a blend of S2S and C2S? Let’s take the same scenario where three ad spaces are available on the website.
Again, you have two single call exchanges , but this time, one call per placement will be made only to three exchanges. The remaining three exchanges will be called through only one S2S call.
Results?
With the same number of exchanges being called, the number of simultaneous calls will be reduced to 12. By using a blended solution, you may be able to avoid queuing and its associated drawbacks. This solution would result in reducing latency, improving user-experience, increasing global win rates and revenue and finally, adding more demand partners without concern.
For more information, please reach out to one of our representatives.