Expand my Community achievements bar.

Webinar: Adobe Customer Journey Analytics Product Innovations: A Quarterly Overview. Come learn for the Adobe Analytics Product team who will be covering AJO reporting, Graph-based Stitching, guided analysis for CJA, and more!
SOLVED

Error tracking - List eVar?

Avatar

Level 1

Hello,

We are trying to find the right way to capture and report on form/site errors.  For each error that occurs we want to capture three elements: error code (number), form object identifier, and error message.  We also want to capture all errors that could occur for each visit, be it zero, 1, or 20 and know they were from the same visit.  And we would ideally like to be able to relate to conversion metrics. 

Format of data being captured is currently designed something like this dummy example for a single visit with three errors (pipe-delimited between elements and semicolon between occurrences):

'34|Checkout_address1|Address line 1 cannot be blank';

'37|Checkout_zip_code|Invalid zip code';

'44|Checkout_promotion_code|Promotion code has already been used'

The 255 char limit is certainly on our mind in this scenario.  List eVar and/or prop seemed like possibilities but we haven't had experience implementing and can't seem to find a good example to confirm that we're on the right track.  We do realize that we may have to reconsider how we are capturing, delimiting, and passing the data as well.

Any input would be greatly appreciated.

Thanks!

1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

I would actually advise against using a list var for this purpose. List Vars are intended to collect data where multiple values are needed in a single image request. An example of this would be element impressions - you can list all the elements on your site in a single list var, then view their aggregate total in reporting.

For this specific scenario, you have three unique values that do not need to be combined. You do not need to see '37' alongside 'checkout_address' - that would not make a lot of sense in a reporting context.

Instead, I would recommend separating these out into 3 eVars - 1 for error code, 1 for object identifier, and 1 for error message. Yes, you'll have a 255 char limit for each individual value, but it will allow you to organize your reports by each facet of the error message.

If you need to see how they relate to each other, you can use breakdowns and see what exactly were the identifiers per error code and vice versa.

View solution in original post

2 Replies

Avatar

Employee

Hi,

If you are planning to capture all these values within 1 variable itself, then ListVars are certainly recommended. Specifically considering that you want to use conversion data against it and it'd also ensure you don't have to use multiple variables.

Further, character limit shouldn't be a concern looking at the dummy values you have shared because the limit of 255 characters (or less when using multi-byte characters) is for each delimited value passed in the hit. There is no overall char limit for List Variables.

From an implementation perspective, you need to ensure the List Variable you want to use is first enabled at the report suite level and delimiter is defined correctly including the expiration to suit your needs. In the code itself, List vars are implemented similar to any other analytics conversion variable, however, values must be delimited (whenever required) using the same delimiter as specified in the interface when enabling it.

Hope this helps. Please let me know if you are looking for any other specific details.

Avatar

Correct answer by
Employee Advisor

I would actually advise against using a list var for this purpose. List Vars are intended to collect data where multiple values are needed in a single image request. An example of this would be element impressions - you can list all the elements on your site in a single list var, then view their aggregate total in reporting.

For this specific scenario, you have three unique values that do not need to be combined. You do not need to see '37' alongside 'checkout_address' - that would not make a lot of sense in a reporting context.

Instead, I would recommend separating these out into 3 eVars - 1 for error code, 1 for object identifier, and 1 for error message. Yes, you'll have a 255 char limit for each individual value, but it will allow you to organize your reports by each facet of the error message.

If you need to see how they relate to each other, you can use breakdowns and see what exactly were the identifiers per error code and vice versa.