(Originally posted on philippesawicki.com)
Is your website compatible with every device? Is your checkout process working from start to finish for every single smartphone or tablet on customers use to shop online? Are you sure you are not missing revenue due to a broken Proceed to Checkout page, and sending traffic to your competitor’s website instead? Are those errors causing fatal crashes, or do they just cause minor inconveniences?
The truth is, you don’t know.
Of course, you test your website regularly and all its most important features have been validated on the largest set of real devices you can afford. But you can’t cover the entire set of devices readily available to the public, and deadlines are always too short.
How, then, can you be sure that website errors don’t prevent your customers from completing their transactions?
There are services available to log your JavaScript errors to a local or remote server, but these solutions cost money are require interfacing with external systems. This is usually not something stakeholders are willing to pay for — after all, there are no bugs in the application, right?
Few people know about this, but the free version of Google Analytics supports exception logging. It might be caused by the fact that Google Analytics does not provide any built-in Report surfacing that information. Fortunately, that does not prevent you from making your own.
First, you will need to either:
- Include the following JavaScript code snippet into your application.
- Use Google Tag Manager to inject it into every single page of your site.
You can customize a few things:
appName
(string): Name of the application you are trackingappVersion
(string): Version number and/or deployment date of the applicationexFatal
(boolean): “true” or “false”, depending on the Type of Error received
You can test that the everything is properly set up by opening your browser’s developer console and typing throw new Error('Crash!')
, then checking your Custom Report a few minutes later to make sure your Error is logged.
By advised, though, that debugging minified production code might not be trivial, and that the errors logged do not necessarily mean that something terrible has happened — it only collects data that would otherwise be impossible for you to get.
The ultimate goal, of course, is to have an indication that something has changed on the website, and being able to monitor its health after rolling out an update. That could easily be done using a Timeline Chart to plot the number of errors per day, or a Table listing the most frequent errors and the Device Model on which it occurs, with the Page URL and Timestamp of each error.
There are a lot of options available for Custom Dashboards and Reports, and your needs will dictate how exactly you need that data to be surfaced. For the most common uses, you can always import this free template I prepared into any of your Views.