Below are some of the biggest benefits publishers and users will receive by switching the header bid requests from the client to the ad server.
Any time additional requests must be made from the client, latency is increased. Header bidding has evolved to use wrappers to limit the latency from client header bid requests but they still have an impact.
Moving the ad requests from the client to the server removes most of these requests which results in quicker page load times, and leads to a better user experience.
Send More Simultaneous Requests at Once
Browsers are limited in the number of concurrent connection requests they can send out at one time. The limit varies from browser to browser, but is usually in the range of 5 to 10 connections. This means that a client header bid request cannot include more than 5 to 10 header bid partners in the auction.
Servers have a much higher limit and are better suited to handle a larger number of simultaneous connection requests. Servers do have their limit but it is much higher and will most likely never be reached. This means that server side header bid auctions can include many more partners then a client side header bid auction. Publishers do not have to be as selective about which partners to include in the auction, and can include a much higher number which can result in higher CPMs.
Some header bid auctions use second price logic to identify the highest bidder and then pass in the winning second price auction CPM to compete against the rest of the demand. The second price auction CPM is typically lower than what the partner initially bid in the header bid auction, so by passing in the second price CPM the header bid partner has a lower chance of winning when compared to the rest of the demand and the eventual outcome is that the publisher can end up being paid less.
If a single unified auction is held on the server, with all demand competing at once in a single auction, then only first price bids are considered when comparing buyers. This can result in the publisher receiving more revenue since only the higher first price bids are used.
For example if the header bid auction is second price and received 2 bids of $5 and $3 then the winning price would be $3.01. If the ad server then holds a first price auction including the header bid winner and the ad server has bids of $4 and $3.01 (from the header bid auction) then the winning price is $4 even though the header bid winner would have been willing to pay $5. If it was a unified auction on the ad server, including all the header bids from the previous auction, then the bids would have been $5, $4 and $3. The winning price would be $5 if it was a first price auction or $4.01 if it was a second price auction. Either way the revenue is higher for the publisher.
Reporting All in a Single Place
The client header bid auction usually selects a winner and then passes that to the ad server to compete against the rest of the demand. In this scenario, ad request metrics are generated in 2 separate places, the header bid request and the subsequent ad server request that competes against the header bid auction winner. In order to get a full view of how all the demand partners are performing, the publisher would need to combine the header bid auction metrics with the ad server metrics.
Besides the additional step of combining these metrics, there is also the challenge of making sure that both auctions report the same metrics and use the same methodology. If they do differ, than the process of combining the reporting can become much more challenging or may not be possible at all.
When there is a single unified auction on the server all the reporting is in a single place and the publisher does not need to combine reporting from two separate auctions. This allows the publisher to quickly get an accurate and holistic view of how all of their demand partners are performing.
Less Strain on the User’s Device
When the header bid request moves from the client to the server the stress on the user’s device decreases. Less bandwidth is required since the requests are now being sent from the server rather than the client so the user’s data usage is lower. In addition, since the process of requesting and processing the requests occurs on the server rather than the client the user’s device battery usage is also less.
The typical response is that these benefits are great and it seems like a no brainer to move the header bid request from the client to the server, but there is one potential downfall.
Moving the header bid requests from the client to the server removes the ability for header bid partners to drop their own first party cookie on the user’s device in order to track and identify the same user on future requests. From a user’s perspective this seems like a positive outcome since it helps protect their privacy, but from a buyer’s perspective it is a negative.
Many buyers bid on inventory based on their ability to identify a user and track their previous performance (i.e. have they installed an app before or what frequency do they click on ads), so by removing this ability it could reduce the amount of inventory the buyer wants to buy. The only solution is for the ad server provider to work with each buyer to perform a user or cookie sync which involves the ad server storing the buyer’s user ID and then passing it in the bid request to them. This can become cumbersome though as the number of buyers increases and it is not as effective as allowing buyers to create and manage their own first party cookies.
There are many positive benefits to moving the header bid request from the client to the server, but based on the impact of buyers losing first party cookies it could also have a negative impact. Publishers will need to weigh the many benefits of the server side header bid request against the potential lower fill rate. Although, the loss of cookies is a limitation to server side header bidding, the industry appears geared to continue moving towards server side and it is unlikely that this one limitation will derail the momentum.