IX Perspectives

Replacing Inefficient Ad Libraries With More Prominent Solutions

blue skyscraper

As a programmatic platform, header bidding is moving toward creating “zero latency” for ads and minimising the work of the ad server. Consolidating ad libraries currently represents one of the major problems for wrapper integration in header bidding. While ad servers are relatively similar, the implementations of ad stacks are different for every publisher, often requiring ad utility libraries to wrap calls.

The history of ad libraries is one of active and incremental development, beginning with the introduction of the ad server in 1995. The ad server is a web server on which publishers can store advertising content used in online marketing and deliver it to various channels such as websites, social media platforms and mobile apps. These evolutions in ad serving have prevented it from experiencing a prolonged period of stability; it is a LUMAscape of developing code at different times.

For publishers, organising this information requires a significant amount of expertise. It means managing a large volume of code from not only header bidding but also data management and analytics partners. These elements need to be brought together piece-by-piece, taking into consideration the different requests on the page and how they will integrate with one another. The resultant nest of code brings additional logic into your content management system, otherwise referred to as an ad library.

With the introduction of a unified header bidding solution, a publisher can centralise all of this code in one place – the head section of the page –  where it can be managed more effectively. Wrappers are required to contain the ever-accumulating code in order to facilitate smooth integrations and keep ongoing site development streamlined. This technology is either available as a collection of open-source libraries or a service that customises the header integration to a partner’s unique specification. The benefit of the latter is that it moves the onus away from the publisher, instead of placing it on engineers and business people whose sole focus is to understand advertising-related code and the optimisation of its implementation.

Examples in Practice

When the need for a specialised solution recently arose for one news publisher, Index Exchange developed its own custom ad library called Bebop to facilitate the integration. The integration requirements were to remove the existing client header bidding solution in its entirety, but in doing so the publisher lost all calls into the Google Publisher Tag library. Bebop acts as an independent library around GPT and integrates seamlessly with Header Tag Wrapper. The products themselves are complementary and further assessment has shown that they reduce latency when deployed together. All three of these products offer their own distinct value for the publisher, as outlined below.

  • Header Tag Bidding – increases yield through parallel access to demand
  • Header Tag Wrapper – manages performance and reporting
  • Bebop Ad Library – minimises the effort required to render ads themselves
Bidder is enabled - measuring time to last DFP response
Bidder is enabled – measuring time to last DFP response
* On June 1, Index Exchange performed the following analysis on one publisher homepage.

Studying quantitative measures typically from HTTP Archives or “HAR” files are crucial in measuring page load performance. Previously, the header bidding implementation added a 5559ms delay to the last DFP HTTP response. Moving to Header Tag Wrapper with the Bebop ad library reduced DFP’s response time to less than half. Additionally, irrespective of whether header tag bidding was enabled or not, response time in DFP remained constant as highlighted above.

Header bidding represents a valuable alternative for publishers seeking to create zero or ‘negative’ latency implementations, while still enjoying faster and less latent ads.

Leave a Reply

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