Tracking pixels also referred to as 1x1 pixels is a common way to track user activity in the analytics and ad-serving world. There are multiple ways to achieve this; the most common being through a transparent 1x1 GIF image call and passing the data that is needed through URL params. This is also the reason why tracking pixels are referred to as 1x1 pixels. Overall, the tracking pixels are flaky and constrained by the limitations imposed by various browser environments and network connectivity. The Beacon API proposes to address these concerns and to provide a streamlined API and predictable support across browsers.

Beacon API

The work on the spec of the Beacon API started in 2013 and by the end of 2014, the then latest versions of Google Chrome and Mozilla Firefox started shipping support for the Beacon API.

You can either read the W3C spec of the Beacon API or a shorter version of the key aspects in the MDN docs to understand the motivation and inner workings.

Here is a quick blurb from MDN:

The Beacon interface schedules an asynchronous and non-blocking request to a web server. Beacon requests use HTTP POST and requests do not require a response. Requests are guaranteed to be initiated before a page is unloaded and they are run to completion without requiring a blocking request (for example XMLHttpRequest).

There are two key aspects which make this really interesting for tracking pixels:

• It’s non-blocking and are prioritized
• Requests are guaranteed to be initiated before page is unloaded and are allowed to run to completion

Together this would ensure that the end-user experience remains unaffected while still ensuring that there is no data loss if a request is initiated but the user decides to navigate to another page.

Migrating to the Beacon API

We did a small test across our ad-server tracking pixels with regards to support for the Beacon API by comparing it with our traffic across browsers, devices and the browser compatibility chart. It looked promising and so we moved ahead to add support for the Beacon API. We can’t be loosing any of the tracking data for non-supported browsers and so having a fallback was important.

Here is how that code block looks with support for Beacon API:

// URL to call
var eventUrl = 'http://www.tracking.com/1x1.gif';

if (navigator&&navigator.sendBeacon) {
  // Check if sendBeacon is supported
  navigator.sendBeacon(eventUrl);
} else {
  // Fallback to using JS Image call
  (new Image).src=eventUrl;
}

We deployed this change a few weeks back and looking at the data that we have gathered - here is the percentage of traffic that supports the Beacon API:

In hindsight, the transition went off smooth and this change will definitely make tracking more robust. It’s interesting how the W3C spec is continuously evolving and adapting based on use cases, and making the web more usable for users and developers alike.