Capture web page validation errors

[Hith]

Can we capture validation errors using Adobe Analytics?

[Jennifer_Dungan]

What type of errors are you trying to capture? I capture 4xx and 5xx errors, I had our developers add status code data layer into our error page that I can read and track.

If you are actually trying to capture if the HTML on the page is valid (i.e. W3C validator) I'm not sure this would be the best use of the tracking, as the page will always come back with the same validation errors... plus having to run a check on the page when it loads to include tracking would be a lot of extra processing on every page....

Or if you are trying to capture form errors (to see where potential fall off is on your forms) you would just need to create a hook to detect the those issues... I can't really give you specifics without seeing the form and how it's coded....

[VaniBhemarasetty]

@Hith You can implement s.pageType to capture error pages in adobe analytics.

The pageType variable is a flag used to designate error pages on your site, such as 404 errors. If this variable contains the string errorPage, it populates the ‘Pages Not Found’ dimension.

Below is the documentation on the same

https://experienceleague.adobe.com/docs/analytics/implementation/vars/page-vars/pagetype.html

[Jennifer_Dungan]

Right, but as you mention pageType is only for 404 errors.... other types of errors don't fall into this category (hence why I was trying to figure out what type of errors they were trying to capture).

I wouldn't, for instance, want to log 503 server errors into my "Pages Not Found" report... since that is used to try and determine permanently missing pages so that we can figure out where people are finding them and if we need to add 301 redirects to equivalent pages, a temporary server error wouldn't make sense to track here, but I record these a different way so that I can check for ongoing issues.

[Hith]

can we capture form validation errors using custom code?

[Jennifer_Dungan · Accepted solution]

Yes, though methods will vary depending on how the form is coded.

So first off, you need to identify how the form validation works... do users fill out the whole form and submit, if there are issues are they all provided at once? Or does each field do a live update as the user is actively filling out the form? Is it a combination of the two (as in there are live updates for formatting like dates, valid zip code, etc that trigger "live", vs an on-submit that will catch missing required fields, or other invalid selections)? Do you need to capture in detail all errors, or in general that the form had errors? 

Basically you need to first identify how things work, and what you want to track.

Next, there are many ways to try and connect into these form validations.... sometimes it will be easier if you can get your developers to trigger an event that you can listen for; or to update a data layer with information you can leverage... Maybe you just want to have a "form submit" and watch for errors in a specific DOM element that indicates the form failure....  it really depends on your implementation and what works best for you.

Taking the above into consideration:

• what you want to track and how detailed it should be
• how the form works and when errors are triggered
• how you are going to hook into this to know when to track

Will allow you to determine the best way to start your tracking..

But now comes the "how" to record the data. Depending on the granularity you need... I would be tempted to create an event for "form failure", I would pair this with either a custom link (if this is going to track as a separate action) / or an prop/evar (if this will be combined into the standard form submit where you want to separate success/failure; etc) to indicate a "general form validation error"...  and IF you want to itemize all the potential failures... if you haven't already used up your 3 list variables, I would be suggest using one of them to track an itemized list of issues (since you can send all the issues here without worrying about truncation) OR if these are already in use, you might want to come up with a short form notation / numeric representation of the issues that you can send through a prop/eVar that you then map using classifications  (the short form to prevent data truncation and the classification to expand these short forms back to a readable version for your reporting)