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.

What is the difference between server-side and client-side wrappers?

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.

Client-side calls: two different methods

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:

1. One call is made per page load, regardless of the amount of ad units or sizes
2. Individual calls are made for each ad unit/placement on the page.

So what is the problem?

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.

Why is queuing an issue?

There are many reasons why you would want to avoid queuing - here are a couple:

• It will negatively affect the response rates from queued partners due to reduced percentage of total timeout within which to fetch and submit bids.
• Queued bidders may have higher value bids to submit, but never get the opportunity due to these connection constraints, causing publishers to miss opportunities.
• You may also be elongating timeout settings unnecessarily based on slow bidder response time caused by queuing. Abbreviating your timeout will improve page load times and positively affect user-experience.

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.

Let’s demonstrate

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.