Tracking Errors with Web Analytics

By Peter O'Neill, posted 21st November 2012 in Tips and Tricks.

I have developed an approach to tracking form validation and 404 page not found errors that I now use with all clients. The insights derived have been used to fix issues with their websites, positively impacting on their bottom line. The instructions below are for Google Analytics but the same approach can be used with any web Analytics tool.

Within GA, this approach requires the use of five page level custom variables. Yes, there are only five custom variable slots available total (soon to be more). But I said five variables, not five slots. Form pages and 404 error pages are two different page types and therefore we can reuse the custom variable slots. In fact, I generally use three slots for all of my page level custom variables.

Validation Errors

The first set of custom variables need to be set on pages where a form validation error has occurred. There are three pieces of information to be captured (so three slots):

  • the name of the form
  • the name of the first field that triggered a validation error
  • the error message for this field

Only the name of the first field that triggers a validation error needs to be captured as it is not realistic to capture everything, the first field will be sufficient.

The naming convention for these validation error custom variables is thus:

GA custom variables for Form Validation errors

The GA code on the page if you fail validation on a payment details page due to the customer entering a card number with spaces (form should be fixed to accept this) is:

_gaq.push([‘_setCustomVar’, 1, ‘form error – form’, ‘payment details’, 3]); _gaq.push([‘_setCustomVar’, 2, ‘form error – field’, ‘card number’, 3]); _gaq.push([‘_setCustomVar’, 3, ‘form error – message’, ‘Invalid card number, spaces not allowed’, 3]); _gaq.push([‘_trackPageview’]);

Your developers will need to add code to capture the form name, field name and error message. Note as well that the maximum length of each custom variable name and value combination is 128 characters so the error message may need to be truncated.

404 Page Not Found Errors

The code for 404 error pages is similar with only two pieces of information to be captured:

  • URL of the page
  • referrer to the page

Note that I recommend using the same page name for all 404 error pages as it makes identifying and understanding the scale and impact of these pages much easier.  A page name can be as simple as /error-page.

The naming convention for these custom variables is:

GA custom variables for 404 Page Not Found errors

The code on a misspelled page for the L3 Analytics Set-up service that is accessed via a YouTube page would be:

_gaq.push([‘_setCustomVar’, 1, ‘404 error – url’, ‘/services/web-analytics-setup/’, 3]); _gaq.push([‘_setCustomVar’, 2, ‘404 error – referrer’, ‘www.youtube.com/watch?v=3Sk7cOqB9Dk’, 3]); _gaq.push([‘_trackPageview’, /error-page]);

Accessing the Insights

So the data is being collected but how does it become actionable? DO NOT use the standard custom variable reports, they are not accurate/useful for page level custom variables. Instead create custom reports, one for each business question you wish to answer.

Each custom report should use the metrics of unique events (this equates to visits) and pageviews. The dimensions should be custom variable value 1, custom variable value 2 and, for the Form Validation Errors report, custom variable value 3. On the 404 Page Not Found Error report, create a second report tab with the two dimensions reversed.

Configuration for a Google Analytics Form Validation Custom Report

The key point is to create a filter for each report. This filter is based on the dimension custom variable key 1 matching “form error – form” or “404 error – URL”.  To make even easier, I have already created these custom report for you, simply copy these URLs to the address bar while in the appropriate Google Analytics account.

Identifying Actions to Take

On the Validation errors report, you will see a list of forms with the number of validation errors triggered for that form. Click on a form and you will see that fields that triggered the errors, again ranked based on number of errors. Finally click on a field name to see what the actual validation errors are. That’s actionable information!!

It is a similar story for the 404 error page report. You can see the top urls or top referrers creating these errors. In either case, you can click through for more information to help you narrow down the cause of the errors. Now go fix the links or set up some redirects.

So what do you think? Can you suggest any other ways this approach can be used? Please share the story in the comments if these reports help you to fix any problems.

Comments

    1. Hi Richard – you could use either. I have gone for page level custom variables as we are capturing additional information about a pageview, not about a new/separate website interaction. Basically it seemed more logical to me.

    1. Ahh – hadn’t discovered that tool. That solution appears to work as well. The benefit with my approach is that you will get one page name only rather than many and the URLs/referrers are grouped together so easier to access. So basically that solution requires less code, my solution should be easier for analysis (I think).

Comments closed.