User initiated errors are most likely to occur where forms and/or input fields are involved. An element may not be working, or it could be that the design causes users to interact in such a way as to stall their smooth passage through the process.
An example of this might be an incorrect postcode in a look-up field (as seen below). These errors can be quite common, and something as simple as the inclusion or exclusion of a space in a postcode can cause issues e.g. W11 8QT versus W118QT.
Much is written about optimising form conversion such that it’s practically a science of its own, so there’s little point in my adding to that, instead in this blog post, I’ll explain how Google Analytics can be used to track errors that happen all across a site where a form field or any user initiated input function causes an error to happen.
The answer = good old Event Tracking
Sometimes it seems Event Tracking is the answer to life, the universe and everything; with a few exceptions it’s almost all you could want it to be in terms of tracking on-site interactions.
In this scenario it can be used to track instances where a form or a page carrying input fields has been submitted but an error occurred. Other kinds of tracking used to gather this insight include: usability studies (blunt tool), conversion funnel (even duller), heat mapping (hardly worth bothering with).
For precision tracking and insight, you need to know exactly what fields reported an error and, ideally, why.
Event Tracking uses five parameters:
- Category
- Action
- Label
- Value
- Non-interaction
It’s the first three that primarily interests us. But before saying any more about them, it might help to look at their output in its natural habitat.
The image above shows the three main variables in the Event Tracking overview report, you can get to this by navigating to ‘Behaviour > Events > Overview’.
By default you are presented with data from the ‘Category’ variable, when you drill down to the next level you will see data from the ‘Action’ variable and then from there the ‘Label’ variable.
The point here is that you start with the outer layer and work your way in until you get the insight that you’re looking for. This also forms the basis of how you need to configure Event Tracking to
record error data.
Because you will be using these three variables and because there may be many forms / form fields littered throughout a website, it helps to make sure that the output is collected in a way that
facilitates easy interrogation. For this you need an effective naming convention that brings these variables together in a way that makes sense.
One suggestion would be as follows:
- Category = “error states” (this never changes and represents the holding container so to speak)
- Action = page on which the error occurred – this should be automatically populated according to the page URI
- Label = the error field in question – this also should be populated according to the error field in question
By doing this, when you come to view the data in GA, you will easily be able to find the dataset you want by simply searching for “error states” in the Category report within Event Tracking, and then drilling down from there.
Of course in this instance you will not know what error actually occurred. The great thing about these variables is that you can populate them with almost anything, so in a pinch you could input another layer of information by adding two sets of data to a single variable.
For example, you could populate the ‘Label’ variable not only with the name of the field in which the error state occurred, but also the nature of the error state as reported in the subsequent error message displayed to the user on the page.
Alternatively you could group page and field together in the Action variable and use the Label variable to simply show the error message. That might be a nicer way to get a quick view of which error messages are occurring most frequently.
Whichever way the naming convention is set up, the output should allow the analyst to know the nature of the error that occurred, the field to which it is attributed and the page on which is happened.
Finally, you will also need to add some onclick tracking code to the element(s) you want to track so that GA can spot them.
In general terms, an event is tracked like this:
_gaq.push([‘_trackEvent’, ‘category’, ‘action’, ‘label’]);
This code is added to the element you want to track.
The event tracking here will be activated when the user interacts with the element. The interactions will need to be captured using JavaScript and information gathered from the current state of the page and which element was clicked will be communicated to GA.
For those who want to really wallow in the technicality of configuring Event Tracking, you will find the appropriate Google Analytics help file at the Google Developers website.
Applying this method to track user generated error states is not only more precise but it also carries the added advantage, over other methods, of being far more suitable for analysis given that the data is of course all collated in the standard Google Analytics UI and as such can be subject to the same filtering and segmentation as you would normally find and use in GA.