contact us

Feel free to reach out to us using the form to the right, or contact us us directly. | 5o8-650-0271


PO Box 433
Natick, MA 01760


EWB Analytics Blog

Browser-Specific Custom Link Tracking Challenges

Elizabeth Brady

If you find custom links aren’t tracking for certain browsers, read on.  Certain browsers (Safari, in particular, sometimes Chrome, and the newest versions of Firefox) prioritize a new page load over the analytics tracking code for links leading to another page or site.   When this happens, the custom link tracking code is ignored.  To compensate, analytics tools recommend adding a fraction of a second to the link to give the tracking code more time to executive.   This post summarizes standard solutions for SiteCatalyst and Google Analytics.   While we did not see expected improvement with the Google Analytics solution when we tested it recently (results included here), I wanted to write up my own experience with the issue as it has not been easy to find documentation or discussion.  I would appreciate feedback from anyone who does get results with the proposed solutions.

A client with a very large number of custom links consistently recorded click rates for Safari much lower than other browsers since tracking was implemented in 2011.  With the adoption of larger numbers of IOS products in 2012, the Safari challenge alone impacted key metrics.  Beginning April 2013 (with the release of Firefox 20.0) the tracking challenge spread to Firefox.  Notice the percenta of Firefox visits registering a click event drops from almost 50 percent to under 20 percent within a few days.

 A summary of click rates by browser now demonstrates a clear tracking issue for both Firefox and Safari compared to Chrome and Internet Explorer.

Google Analytics’ standard custom link tracking code guide  fails to mention the challenge or provide a workaround.  A Google Analytics help article on outbound links does mention the possible browser challenge for outbound links with advice to introduce a function call with a 1/10 second delay on the link.

setTimeout(function() {
document.location.href = link.href;
}, 100);

In our tests the 100 millisecond delay provided no observable improvement in link tracking.  Increasing the delay to 500 milliseconds resulted only in very sporadic tracking for Firefox, and tracking for other browsers actually decreased with the function in place.

SiteCatalyst has been more upfront about the browser tracking issue in its implementation documentation.  The release of code version H.25 in 2012 included a standard 250 millisecond delay (if needed, to give the tracking code extra time to execute) for standard exit links for Safari and Chrome.  The SiteCatalyst blog covers the issue in the code announcement. The newer H.26 includes the delay for Firefox 20.0+ as well.  

In order to implement the delay for custom links, a ‘done action’ parameter must be added to the custom link tracking code.

<a href="" onclick=",'e','AnotherSite',null,'navigate');return false">

This should be added to any custom links to another page, not just exit links to other sites. (Document downloads and AJAX in-page events don’t need the extra delay and therefore don’t need the done action code).

To disable the forced link tracking (which is actually just a forced delay of up to 250 milliseconds if needed) for non-custom exit links use:

To disable:  s.useForcedLinkTracking=false:

To increase the delay time (to, for example the highest recommendation I have seen ½ second) use this:


I’m curious whether the recommended maximum delay (half a second) is actually sufficient to consistently compensate for the browsers’ design, yet have yet to find a client willing to consider a longer delay enough to even test it.