Client-side vs Server-side header bidding

Client-side vs. Server-side Header Bidding

Authored by

WordPress architect with passion for electronics and personal mobility.

The goal of header bidding is to ensure that multiple ad networks and ad exchanges can compete on price for a particular ad slot on a website which in turn increases the publishers’ revenue.

There are several header bidding implementations and understanding the differences is necessary when evaluating and finding the best fit for each publisher.

It boils down to the following differences:

Bidding Performance

In client-side header bidding there are multiple bid requests sent by the user’s browser in real-time to the participating ad networks during the initial page load. This requires a lot of network requests and, without an optimized implementation, can impact the page performance and reduce the number of participating bidders because of network latency. For example, a typical timeout for a header bidding auction is 1 to 2 seconds in which the bidders need to respond with their bids.

In server-side header bidding there is only one bid request to the ad server which then sends the bid requests through a good network connection to all participating bidders. This reduces the network latency and increases the number of bidders that can participate in the auction in a timely manner.

Ad Revenue

In client-side header bidding each bidder gets access to the users cookies for their domain and the associated browser meta information. This increases their chance of mapping the request to a known user which allows them to increase their bid prices. This increases the revenue per mille (RPM) or revenue per thousand impressions and obviously the publishers overall revenue.

In server-side header bidding the information shared with each participating bidder depends only on the ad server that receives the request and has access to user’s browser. This limits the bidder capabilities to match the user and can lead to lower bids.

Integration

Most of the popular header bidding implementations such as Prebid.js, Sortable, Index Exchange, OpenXRTK and Freestar use client-side header bidding.

Hosted solutions such as Sortable and Index Exchange are easier to integrate because the bidders and auctions are configured in their administration panel while the actual bidding process happens through a simple Javascript wrapper library and is almost identical to the self-hosted Prebid.js.

All header bidding solutions offer simple integration with DoubleClick for Publishers (DFP) which is the most popular ad server used by publishers.

Recently it has become possible to compete with Google’s own Ad Exchange and get even better exposure for the publisher’s ad slot inventory through Exchange Bidding which is a server-side header bidding solution that runs seamlessly through DFP.

Prebid Server is an open-source solutions which essentially moves the Prebid.js client-side functionality to a web server which reduces the auction latency and increases the amount of participating bidders.

Header Bidding with WordPress

WordPress websites with existing ad managers that control the ad unit placements on the website and integrate with the DFP don’t require any changes to work with some of the hosted header bidding wrapper implementations such as Index Exchange and Sortable.

Here at XWP we’ve helped our clients with all types of header bidding integrations including running A/B tests for determining the best performing implementation between some of the hosted wrappers and Prebid.js.

2 thoughts on “Client-side vs. Server-side Header Bidding”

  1. you are truly a excellent webmaster. The site loading speed is incredible.
    It seems that you are doing any unique trick. In addition, The contents are masterwork.
    you have done a magnificent activity in this subject!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.