Try {} to Catch(){} me if you can

I didn’t go crazy with the characters, quite the opposite as on this post I would like to introduce a best practice that web analytics developer should really develop.
I really hope that this post will be the start of this best practice as I find this very useful, ultra safe, and giving you additional information.

Go beyond the If

After years on doing implementation I saw a lot and still see a lot of if(){} conditions in the different implementation files.
The idea behind those conditions goes into 2 different categories (usually) :

1. You want your condition to run only on specific occasion
2. You want to bulletproof the implementation and therefore look for specific conditions to be united before firing a tracking.

Condition for firing (1):

With this first logic, you use the if syntax as its most purity.
You wait for the user to be on a specific url and send a tracking accordingly.

Something like this :

if(window.location.href=='https://www.example.com/'){
/*do something */
}

Bulletproofing your implementation (2):

With this logic, you also limit the firing upon specific conditions but this time, you are not looking for a condition to fire this, you are more looking for when to not fire this pixel or tracking.

Per example, you want to make sure that you have a pagename and a page type before you firing. (Otherwise you will have inconsistent data of Page Type without pageName and pageName without Page Type)

It would look something like this :

if(typeof s.pageName!='undefined' && typeof s.prop2!= 'undefined'){
/*do something*/
}

Why do I want to Try{} this ?

What I explained above is good practice and you should keep doing this. What I would like you to do, in addition, is to add a try-catch logic inside so you are really bullet proofing your implementation.

The problem (and the power) of the if condition is that it works only for those conditions.
There are always going to be conditions that do not fit into your logic and I can guarantee that. You may be sure right now that the condition(s) that you have just written are 100% exhaustive. It may be true, but what about in 6 months, 1 year, or later ?

Over time, issues appear and what seemed bulletproof is not anymore. If your if statement is very important, ie checking for error or important variables, you can actually create problems like JS errors that impact your website. (actually YOU didn’t create them, but it will be sold like this when it comes to find a responsible).

If you have an example as follow :

if(datalayer.traffic.type == 'Category'){//do something}
else{/*do other thing*/
}

if the datalayer is being modified and the variable type doesn’t exist anymore, it will return an error saying that this variable doesn’t exist.

Try {} to set it up :

By adding the try {} – catch(){} method, you solve that issue because the try – catch works in any situation.
Its main purpose is actually to catch when it doesn’t work.

As explained above, you just have to add a layer to the normal code that you are doing in order to make this implementation live.

try{
if(datalayer.traffic.type == 'Category'){//do something} else{//do other thing}
}
catch(){
//send data with minimal configuration.
}


Doing this wrapper doesn’t cost much and it is pretty robust now. You don’t have to worry about your data layer anymore.
But we can go even further…

Adding data…

As you probably know with me by now, there is not a single occasion where I see a possibility to get even more data from a situation.
The idea came actually from a colleague of mine as he wanted to know exactly what type of error were creating those catch situations.

He developed a function that would take your error and pass it to an eVar.
Obviously, it also works with Google Analytics in a Custom Dimension. Feel free to adapt it :

function error_handler(error){ var err_urlpath = window.location.href; var err_user_ag = window.navigator.userAgent; s.eVarXXX = "err:"+ error + "^path:"+ err_urlpath }


If we apply this to our previous example, it will look like this (and we do a ternary operator to be more compact):

try{ (datalayer.traffic.type == 'Category')?//do something://do other thing; }
catch(err){
//send data with minimal configuration.
error_handler(err) }


At the end, I don’t find that so hard to implement but it can be really helpful for debugging and for making your implementation more robust.