📘

Beacons definition

A web beacon is a small object, such as a 1-pixel GIF, embedded in markup, used to communicate information back to a web server or third-party servers. Beacons are generally included to provide information about the user for statistical purposes. They are often included within third-party scripts for collecting user data, performance metrics, and error reporting.

How Criteo uses beacons

When you make a call to Criteo's ad delivery API, it returns a JSON object containing all the necessary information to render and track the ads. This JSON object includes various elements such as ad creatives, metadata, and beacons.

These beacons are unique URLs provided by Criteo that need to be triggered when specific events occur.

For example:

• Load/impression beacon: are fired when the ad is rendered on the user's page.
• View beacon: is fired when the ad comes into the user's viewport.
• Click beacon: is fired when the user clicks on the ad.

📘

By accurately calling these beacons at the right times, you can ensure that all relevant interactions with your ads are tracked and reported properly. This data is then reflected on the Criteo platform as metrics used for reporting, optimization, and billing.

Beacons implementation best practices

Implementing beacons effectively is essential for accurate ad tracking and measurement. In this section, we present some of the best practices to follow to implement beacons properly. The best practices include:

• Sending beacons client-side,
• Using the sendBeacon() method,
• Not caching API calls,
• Not performing hard-code checks on beacon URLs.

Sending beacons client-side

This is a good practice for:

• Accuracy: Sending beacons from the client side ensures that the data reflects the actual user interaction and behavior.
• Real-time tracking: Client-side beacons provide real-time insights into user actions, which is vital for dynamic and responsive ad campaigns.
• Reduced server load: By transferring beacon sending to the client, the load on your servers is decreased, enhancing overall performance and scalability.

Using the sendBeacon() Method

Criteo supports both GET and POST HTTP requests when calling the beacon URL, but for web implementations, we recommend using the sendBeacon() method.

Why it is a good practice

As described in Mozilla's Developer Network (MDN):

The navigator.sendBeacon() method asynchronously sends an HTTP POST request containing a small amount of data to a web server.

It's intended to be used for sending analytics data to a web server, and avoids some of the problems with legacy techniques for sending analytics, such as the use of XMLHttpRequest.

Other methods have been shown to result in issues sending 100% of data.

This is a good practice for:

• Reliability: The sendBeacon() method is designed for sending data to the server asynchronously, ensuring the data is transmitted even if the page is unloading.
• Performance: It uses a low-overhead approach, minimizing impact on the user experience.
• Guaranteed delivery: The method ensures that beacons are sent before the page unloads, improving the reliability of data collection.

Implementation

Use the sendBeacon() method when available, with a fallback to other methods for older browsers:

function sendBeacon(beaconUrl) {
    if (navigator.sendBeacon) {
        navigator.sendBeacon(beaconUrl);
    } else {
        var img = new Image();
        img.src = beaconUrl;
    }
}

Not caching API calls

Why it is a good practice

• Unique tokens: Each beacon URL includes unique tokens containing important information such as session timestamps and user IDs. Caching these requests will result in inaccurate and/or duplicate data.
• Accurate data: Ensuring that each beacon call is unique and not cached guarantees that the data collected is accurate and up-to-date.

Implementation

Use HTTP headers to prevent caching of API calls:

fetch(beaconUrl, {
    method: 'POST',
    headers: {
        'Cache-Control': 'no-cache, no-store, must-revalidate',
        'Pragma': 'no-cache',
        'Expires': '0'
    }
});

Not performing hard-code checks on beacon URLs

Why it is a good practice

• Flexibility: The subdomain of the beacon URL might change based on the load balancer. Hard coding checks can lead to failures if the URL changes.
• Maintainability: Sending the URL as-is without hard-coded checks reduces the risk of errors and simplifies code maintenance.
• Adaptability: This approach ensures that your implementation remains functional regardless of infrastructure changes.

Implementation

Simply use the provided beacon URL without additional validation.

function sendBeacon(beaconUrl) {
    if (navigator.sendBeacon) {
        navigator.sendBeacon(beaconUrl);
    } else {
        var img = new Image();
        img.src = beaconUrl;
    }
}