Recent changes to Firefox and Safari have caused us some major issues when trying to manually track links. Typically, this was done using the s.tl() method: you could call this on anything clickable, and it would send a payload of information to Omniture in the form of an image request. Newer versions of these two browsers however are silently failing to do this. So what’s going on? And more importantly, how does one fix it?
The problem
The short version of this story is that these browsers are basically ignoring any scripts that slow down a user’s experience when moving from one page to the next, including your s.tl() script calls.
The official solution
Adobe provides the following solution for tracking links that leave the page. Please note this example will only work for A tag links, I’ll get to other situations later.
[javascript]Click here[/javascript]
The standard s.tl() parameters are all still there:
- type – use this for A tags, and true for other types of HTML elements,
- type of link – ‘o’ for custom links, ‘d’ for downloadable files and ‘e’ for exit links,
- label – a human readable description of the link for reporting labels
There are also two new parameters, one for overriding certain variables and one that indicates the action to be taken after the s.tl() has completed its recording activities. Here, a pre-built function called ‘navigate’ reads and actions the HREF attribute.
But what of elements that aren’t A tags, that don’t have a HREF attribute? For example, forms that result in a new page? In these cases, the navigate method won’t work (remember it’s expecting a HREF attribute to follow) so we need to use some custom code:
Note the first parameter is now set to true, and the last parameter is an anonymous function that will submit the form once s.tl() has finished doing its thing.
Get off my critical path!
While the examples above will work, they commit what I consider to be a fairly serious no-no when it comes to implementing analytics – the tracking code becomes a critical dependency in the process. If the s.tl() method were to fail (and it could do so for any number of reasons), the user will be stopped in their tracks by the “return false;” command.
Following graceful degradation principles, a better solution is to place both the s.tl() call and the return false in a separate function. The following code also checks that the s object has been created properly, and that Tag Manager code has been fully executed (ie: does s.doPlugins exist?).
Form submissions
function trackFormSubmit(formObj,linkDesc){
if((typeof s !== "undefined") && (typeof s.doPlugins == "function")) {
s.tl(true,'o',linkDesc,null,function(){formObj.submit();});
return false;
} else {
return true; // allow form to continue.
}
}
Some commentary:
Line 2: Check that both the s object and the s.doPlugins() method exist.
Line 3: If they do exist, do the s.tl(), and submit the form when it’s done.
Line 4: Return false to the form, killing the default action.
Line 6: If the s object and s.doPlugins method are invalid, then just submit the form as per normal.
And the form tag would look like so:
Links to new pages
For links, we would do something similar, with the 5th parameter of s.tl() following the href value (line 3):
function trackLinks(aObj,linkDesc){
if((typeof s !== "undefined") && (typeof s.doPlugins == "function")) {
s.tl(this,'o',linkDesc,null,function(){document.location.href = aObj.href});
return false;
} else {
return true; // allow user click to continue.
}
}
And the link would look like:
...
Doing things this way means that failure of the trackForm() or trackLinks() method won’t stop the form submit or link navigation. My preference is that this function sits in the s_code file, since it means that should the s.tl() be invalid due to file unavailability, this function would be as well and the whole thing would be ignored by the form, allowing the user to go on their merry way.
