How to track form errors

Error tracking and handling is an important optimisation opportunity for any website. The randomness of user and device behaviour means that even thorough testing processes won’t catch all potential issues, and errors that stop the client from moving forwards will often result in lost revenue.

Error messages trigger cortisol, a well-known biomarker of psychological stress. This cortisol buildup can turn into anxiety, and eventually, when a user is sufficiently frustrated, they give up.

Alex Birkett, ConversionXL

Why fix form errors?

  • Reduce form abandonment (Stop losing revenue because of UX or code issues)
  • Reduce contact centre calls / emails (Let customers complete the process they want they want to: online)
  • Improve brand value and LTV (Stop customers from hating you, and then going to a competitor)
  • Elevate your UX standards

Types of form errors

In a form or checkout process there are two types of errors:

  • In-page errors related to what the user has entered (or not entered) into the form
  • Browser errors that relate to assets in the page, for example a JavaScript error.

An issue in a form may cover both of the above errors. An example is a problem with a third party address lookup service that results in both a browser error and an error visible to the user within the form. In this example the error would stop the user from completing the form.

ROI on fixing form errors

Fixing an error requires effort, which creates a cost for each fix. There is an assumption that fixing an error will return value by allowing more customers to complete the form. What I’ve found when optimising forms is that some errors have significant value, whilst others are negligible. I’d categorise errors as:

  • Critical Errors: Functionality fails to a point where even an experienced user cannot successfully submit the form. Potential ROI: High
  • Intrusive Errors: Users struggle with a form but could complete it with effort. Potential ROI: Medium to High.
  • Edge-case Errors: A sub-section of users will struggle with a form (that subsection could be defined by device, user demographic, marketing source etc.).
    Potential ROI: Low to Medium.
  • Hidden and Unintrusive Errors: An error occurs but it has no impact on the user experience. Fixing the issue does not lead to a revenue increase, but it does create a tidier house. Potential ROI: Minimal to zero.

Companies usually find it easy to silo the lowest and the highest ROI errors. Seeing data that shows you critical errors drives that company towards a fix (“This problem is costing us a lot of money!”). Where companies struggle is when the ROI isn’t low but doesn’t appear huge. Let’s take an example:

A company has a checkout process with a responsive design. It looks great on mobile, but on some laptop screen sizes there’s an issue with the address look-up going off-page. The company has a “mobile-first” mantra, and desktop represents 10% of their site-wide traffic. The screen sizes that struggle account for 4% of site-wide traffic.

The issue is de-prioritised but still added to the backlog. It’s seen as a problem that should be fixed, but there are more important things to do. Over time the fix gets pushed back as even more important tasks jump ahead of it.

What the company lacks is data on the value of the fix. If 4% of users are affected, does the issue cause them to abandon at a higher rate, and what is the cost of that? Answering this question is key to prioritising the fix, and that’s why we’ve built Zuko’s event tracking functionality. As you read on you’ll see how you can quickly and easily put a value on form errors.

How to track form errors

Zuko is a behavioural analytics platform that measures how users engage with online forms and checkouts.

We’re interested in how people engage with each input element, but our platform also allows you to push in custom data in. There are two ways to do this, and the one that relates to tracking errors is Custom Events.

Custom Events is a powerful way to track things that the user does in a form, beyond engagement with input elements. We created Custom Events to track error messages (it’s worth noting that our customers are using Custom Events to track things beyond errors, like when a user clicks an informational message or clicks on a link).

Custom Events can be fired multiple times for each website visitor so you can track all the errors that occur in a session, and link them back to a single anonymised visitor.

Each Custom Event accepts a string of text, allowing you to identify the event that has occurred. Within Zuko you can then visualise the events, and how the impact on form completion and abandonment.

Tracking in-page errors, like an in-line error message that tells the user they have entered their phone number in an incorrect format, is simple in Zuko. It’s as easy as firing a line of JavaScript before each error is shown to the user, and there’s more technical information at the base of this blog,

Tracking in-browser errors, like javascript errors, is also easy. Adding a snippet of code via your tag manager will allow you to trap console errors and push these into Zuko. Here’s a great example of a simple error tracking snippet that can be used to fire a Custom Event into Zuko

Realising value from form error data

The first step in using form errors to optimising a form is capturing when errors occur and (using Zuko) linking error messages to abandonment. The next step is using Zuko to visualise how the errors impact on conversions and revenue.

Most websites have console errors, and most users will experience an inline validation error as they try to complete a form. What’s important is to understand which errors lead to form abandonment. These errors can be prioritised, whilst other errors that are annoying, but do not cause revenue loss, can be tackled at a later date.

When you track form errors in Zuko you can view headline data in the Form Aggregate report. The chart below tells us how many times an error was fired and shows you the breakdown of events related to . Note that the label contains both the field the error relates to and a short version of the error message. In this example, we’re focussed on errors shown to the user in the form, but if you’re tracking browser errors then they’d appear here too.

You can view error data for any time-range, and also segment the data (e.g. by device type or browser). Let’s make the chart simpler by removing the users who saw an error, but who went on to complete the form.

The chart above makes it easy to see which error messages appear in abandoned user sessions, and if I hover over a bar I can see the total count of abandoned users.

The data tells me that three errors appear the most for users, and by isolating abandoning users I can see how the errors could be causing drop-offs.

I can then dig deeper into the data and see the event tracking in a table format. The screenshot below shows a list of all the errors, along with the number of times the error has happened (split out by events that happen in abandoning sessions), the percentage of sessions that an event occurred in and the mean times that an event occurred in an average session.

Let me break down the value of these three types of data:

  • The Total Count tells me how many times an error message appeared for users. This helps me understand which errors are seen the most, and lets me focus on the higher volume errors.
  • The % of Sessions Occured In helps me understand the relationship between this error and abandonment. For the “Already in use” error message for the Email field this is seen by over half of all sessions, but almost two-thirds of abandoning users see this error.
  • The Mean Times Occurred helps me understand if errors are shown to users multiple times (on average) and if there is any relationship between frequency and abandonment. The “Already in use” error message is seen by abandoning users almost twice as many times as by all users.

The two reporting blocks that I’ve mentioned above will give you data on form errors that you won’t have seen before – they’re simple and easy to use, and they help you quantify how an error is causing abandonment and costing you money.

Deploying form error tracking in Zuko

Our help documentation contains more information on installing Zuko and using Custom Events.

Tracking form errors in Zuko involves a single line of JavaScript that is fired each time an error occurs. The trackEvent function accepts a single attribute (type) which is a string that identifies the error.

In this example, I fire the code snippet below to point Zuko at that form, so that it can track general user behaviour within it. The code can be fired via a tag manager, or added to the page.

//Line below loads the Zuko tracking javascript
<script src=""></script>
//Block below points Zuko towards the right form and creates a slug
      target: document.getElementById('mailing-list-signup'),
      slug: 'mailing-list-signup'

The trackForm function tells Zuko about the form you want to monitor behaviour on. The target attribute tells us the object that the form elements are in, and the slug is a name that we want to give the form. This slug is used in the code below to tie Custom Events to the form.

  // Line below checks to see if an email address field in a form is valid
  if (!emailField.valid()) {
    //The next three lines tell Zuko which form this event relates to
    //and then the trackEvent stores an event called 
      .trackForm({slug: 'mailing-list-signup'})
      .trackEvent({type: 'inline-error_email '})

The code above contains a simplified error handler. If you have a form with any kind of validation (almost all do) then you’ll already have an error handler function in place.

The most important lines in the block above are the Zuko.trackForm and Zuko.trackEvent functions. trackForm tells Zuko that we’re going to be doing something with the form referenced by the slug, and the trackEvent pushes an event into Zuko

Al Al is the CEO of Zuko, and one of the founders. He works with some of our key clients to help them get the best results, and he manages our agency partner program.