Error Tracking - What are YOUR Best Practices?

[jeff_bloomer]

I would assume a lot of implementation specialists are setting up tracking for error in some way in Adobe Analytics, so I figured that I would ask if anyone out there in the Adobe Analytics community who have been doing this a long time developed a best practice for that.  Recently, we'e been going back and forth about the "best" way to accurately track different types of errors while also using Adobe Analytics to its best potential.  We've approached it from different ways:

• Originally, we fired one event any time there was an error and then two eVars:
  • Error Type
  • Error Message
• More recently, we have tried firing the same event but instead used a list variable to capture all errors happening in a particular scenario, so we would have an errors array with the error event.
• The most recent discussion has centered on using three different kinds of error events, like service errors vs. user generated, etc.

I've also started to rethink how we also manage the expiration of the eVars associated to the error events, as they are currently defaulted to expire after the visit.  I've been thinking about expiring them after the hit.

I understand that everyone has different goals in how they might track errors in their own implementations, but I'm highly curious to see if anyone has landed on a configuration that worked particularly well in their environment.  Thanks in advance for any insights you can provide!

[yuhuisg]

As with most implementation and reporting in AA, I normally start off with business requirements. In this particular case, I would consider what are the obstacles that prevent users from converting.

With that thinking, I normally narrow down my error reporting to be based on the errors that prevented a user from continuing his journey. It doesn't have to be the JavaScript error (though most times, it is) nor a system error number-and-message. It just needs to be a "reason" that can fit within the 255-character limit of an eVar. Knowing the error "reason" together with its timestamp is normally sufficient to start investigating with the developers.

I would normally configure that error eVar to have a "Hit" expiry. Again, from the user's perspective, I would assume that encountering an error is a momentary irritation, such that the user is likely to try doing what he was attempting earlier. In that case, there's little reason to expire the error much later after it has occurred. If I need to know what the user did after the error occurred, I can use a sequential segment to find that out.

Hope that helps with your research.

[Jennifer_Kunz]

I think my eventual findings are similar to where you seem to have arrived: a list var (if available) with hit expiration (if a list var is unavailable, a list prop might do). And, like @yuhuisg , I try to focus on errors that impact the user experience, and what the user sees rather than what the server might know. I've seen folks put error codes in separate variables but I've never once seen someone get use out of them when the error message is so much more telling. If anything, I'd do a preface, like "404: page not found", "500: Something went wrong", "password: Password must contain at lease one capital letter and the name of one member of the Beatles".
To be honest, I've found that Adobe is just not a great tool for non-user-generated errors. It's very good at user experience issues, like surfacing that too many people aren't meeting your ridiculous password requirements, or merely that they are getting stuck due to a server problem and unable to proceed. But for javascript and server errors, there are tools that exist for that purpose that work better, and in many cases, organizations already have those tools but just don't talk to the analytics team about it. Adobe can tell you a problem exists; but I'd count on other tools to spot site-breaking issues faster and isolate the cause.