Preventing Canceled Adobe Analytics Beacons Using s.useBeacon

The canceled analytics beacon is a rare, but real occurrence. I have experienced it myself when tracking elements or interactions that cause the browser to navigate away from the current page to a new page; think navigation clicks and form submits.

These types of events cause the current page to unload. Due to the speed of this unload event, although the browser recognizes that a request is being sent, it does not have time to process and send the request. Specifically, the element which caused the request to be originated in the first place no longer exists; therefore, the request is canceled.

The most nefarious aspect of this problem is its elusiveness. This can be frustrating for two reasons:

• It's unpredictable. Two people can test a website, one will see canceled beacons, one won’t.
• It's difficult to consistently reproduce.

^{The dreaded red canceled beacon}

Anecdotally, I believe the following factors contribute to the canceling of Adobe Analytics beacons:

• Speed of internet connection
• Simplicity of the page (simple pages load faster leading to more canceled beacons)
• The number of Launch rules that must be evaluated when an event occurs and the order in which those rules may fire
• Mercury being in retrograde

In this example, clicking the shopping cart icon (top left) navigates to the shopping cart page. This causes the shopping cart icon HTML element to unload and cease to exist. Since the originating element for triggering the beacon does not exist anymore, the Adobe Analytics beacon is canceled and data is not sent to Adobe Analytics.

Understanding navigator.sendBeacon

The browser is synchronously building and sending our network request, and waiting for a response from the server indicating the status of that request. Therein lies the solution.

As an alternative to the standard XHR request, there's a special type of request that utilizes the user agent to queue asynchronous network requests to send data before a page unloads. This method is called navigator.sendbeacon. You can use this method to fire network requests asynchronously and not worry about the response of the server.

This type of request is ideal for analytics code because it fires quickly and, due to its non-blocking nature, does not delay the next page from loading.

The below code is an example of a regular request that might be canceled if its originator page or element is unloaded before the request can be sent:

var analyticsData = {"pageName": "homepage"}
var xhr = new XMLHttpRequest();
xhr.open("GET", "//httpbin.org/status/200", false);
xhr.send(analyticsData);

This code uses the navigator (user agent) object to queue an asynchronous request. According to MDN documentation, sendBeacon requests are "guaranteed to be initiated before the page unloads."

let analyticsData = {"pageName": "homepage"}
navigator.sendBeacon("//httpbin.org/status/200", analyticsData);

s.useBeacon and Adobe Analytics

If canceled beacons may result from common analytics requests, why does Adobe not utilize the sendBeacon method on their requests? The good news is they do and you can too. Adobe already uses navigator beacons to track exit links by default. You have the option to use the navigator beacon in your analytics calls as well.

Unfortunately, there's no way to do this in the Launch UI, but it's easy to implement in custom code. When sending an s.t or s.tl call, you just have to indicate to your AppMeasurement library that you want to use the navigator beacon to send these calls to avoid canceled requests. You can do this by setting s.useBeacon = true.

Setting s.useBeacon to true will send the analytics hit via a navigator.sendBeacon request.

Once the Adobe Analytics hit is sent, s.useBeacon will reset itself to false behind the scenes and subsequent calls will not use the navigator beacon. You must reset s.useBeacon to true prior to your call if you want to use it again.

s.useBeacon = true;
s.tl(this,'o',"My Click Event");

Remember that since you are sending your tracking request in custom code, you do not need a send beacon action in your Launch rule.

Caveats

The use of this feature in general and in Adobe Analytics is not without caveats.

Not Supported by Internet Explorer 

First, the navigator sendBeacon method isn't supported by Internet Explorer (there are polyfills, however). In the image below you can see two Adobe Analytics beacons. The top one is a regular beacon and the bottom uses s.useBeacon. Notice that the second request type is x-javascript. The "x" prefix here indicates an experimental Javascript function and browser support may vary.

POST Requests Only

Second, the sendBeacon method sends POST requests exclusively. Post-type requests may not be compatible with all types of data requests. For example, some marketing pixels redirect their GET requests to route data to a database and return a pixel.

Sending a POST request to these pixels will not trigger the redirect, and thus the data will never get to its intended destination. Be sure to test your implementation.

Pending Analytics Hits

Finally, due to the design of sendBeacon not requiring a response from the server, you may see your Adobe Analytics beacon request stay at pending (instead of returning 200 or another type of response). Although initially concerning, this is ok. You can even verify that pending requests are making it to Adobe Analytics by watching real-time reports.

In Summary

Although canceled beacons are troublesome, they can be accounted for by thinking ahead.

Does this action I am tracking cause the page to unload quickly? And do a lot of rules fire when this event occurs? If the answer to either of these questions is yes, setting up s.useBeacon can save you a lot of trouble in the future. However, you must take the caveats into account and make a judgment call based on your specific situation.