Form Validation Errors - how to track them and what to do about them?
In this article, we'll try to cover all different types of errors and how to track them. Then, we will follow up with articles how to analyse these errors and also, how to react to them to optimise conversion rate or improve Customer Experience.
Types of Errors
In general, form validation errors fall into one of these groups:
- 1) a user entered an invalid data into a form field, for example, an email without "@" character
- 2) a user entered a valid data in an unsupported format, for example, a phone number with groups of digits separated by spaces or dashes, and form supports digits only,
- 3) a user entered a valid data in a valid format but of disqualifying value, for example, a year of birth that indicates that the user is underage and therefore not allowed to register
- 4) a user submitted a form without completing required fields, either because she/he didn't want to provide an answer, didn't realise that a field is required or didn't even notice the field, which is often the case with all kinds of agreement checkboxes
- after a user clicks a submit button,
- after a value is entered in the field, or
- while a user is still typing an answer (which can be very annoying)
- 5) the provided form data conflicts with other data in the system, for example, a user attempts to register using an email that is already associated with another account,
- 6) the form data is outdated, for example when a user attempts to buy a product that was just sold out,
- 7) the form data is matched against a user's data in CRM and, after it is enhanced, conflicts with validation rules, for example, when a user in the checkout signs in only to find out that a product in a basket is not available for overseas delivery and order cannot be placed,
- 8) a backend error occurred and form data was not processed, for example, when there was too much concurrent traffic and an error "try again later" was returned
The above list covers the most of cases in which form validation errors are displayed to users. At least those errors that are displayed correctly, as there are of course errors that are a result of bugs or improper validation rules:
There is nothing wrong with the email above, yet the validation throws an error.
Error Message Placement
Usually, form validation errors are displayed on the same page that contains the form and are placed:
- contextually, next to a field that an error is related to,
- above the form, when an error is related to the entire form and not to a specific question,
- next to a submit button, when an error requires a user to resubmit the form, or a form is short (i.e. login form),
- in a modal window, when an error is critical and a user is not expected or supposed to submit the form again
- on a separate page.
Tracking of Errors on separate pages
The last case, in which an error is displayed on a separate page, is rarely a validation error. Usually, it is a result of an unexpected or unhandled error after a form submission, when:
- a user's session expired
- a form submission request timed out,
- a server error happened
For users, such errors are extremely annoying especially that clicking the "back" button in a browser results in a scary browser alert: "Hit F5 to submit the form again".
You should know when these errors happen because most of analytics systems track URLs of visited pages. However, I'd say 9 out of 10 implementations of analytics is missing tracking code (or tag manager's code) on error pages.
Just take a look at the example below which shows the same page on which user lands after submitting a form, The page on the bottom, the one with the server error, the page is missing the analytics tracking code. But, even if the page had the tracking code, it would likely show up in the analytics as a successful form submission since it has the same URL as the page without an error.
To sleep well, send a quick email to your developers to check if error pages on your website are correctly tracked. And don't accept an answer that server errors are logged in server logs.
Tracking of Errors displayed on a page with a related form
If you are using UseItBetter Form Analytics, tracking of form validation errors will take you a moment - 2 minutes and 53 seconds to be exact. Just take a look at this short video and follow Error Tracking tutorial in Triggers documentation for more details.https://www.youtube.com/watch?v=aHd7G7YnQYI
If you are using Google Analytics, Adobe...
or other analytics tools, then here are some tips for you:
1) Every Error event should consist of at least two pieces of information:
- error message as it is displayed to a user
- a form element related to the error
That is important because in many cases the same error message can mean different things. For example, without the information about the related element, the error "This field is required" could indicate a problem with any of the fields in this form:
2) In most cases, error tracking should be executed both, when:
- a user submits a form and,
- a page is loaded/refreshed
to handle form validation performed by front-end scripts and by the back-end.
3) Make sure the tracking is delayed by half a second or so, to give time for the application to remove error messages that are already displayed and show new errors if there are any.
I found a guide by Adam Greco about tracking of form errors with Adobe and a guide by Peter O'Neill about doing the same with Google Analytics. Both are quite old but I couldn't find anything newer. If you know any other guides, please share them in comments.