The subject might be peripheral to the experts, but I do believe it was important for discussion and clarification. From an architect’s view, we tend to restrict eVars because the maximum limit of eVars per Report Suite is around 200-250 based on Adobe packages. On those instances, we use a single eVar to capture multiple values with a delimiter and segregate them by classification. If we do, it poses concerns about the benefits of List Var and decide whether to use a List Var or an eVar with Classification for the business requirement. Let us take an example to understand the variables in-depth and conclude the whereabouts.
Business Requirements
Business wants to understand the below #s for their Personal Loan Calculator:
1. Understand calculator usage and re-target visitors online & offline after the successful submission, but personalized based on calculator inputs.
2. Understand the most frequent validation error message and the successful submissions after the validation error occurrences.
Shown below are the calculator input fields and validation errors that can trigger during unsuccessful submissions.
Business Requirement 1
For requirement 1, it is important to collect the input values for the calculator as the business is about to re-target or analyze visitors for personalization. Input values other than Pin Code are Non-PII (PII – Personally identifiable information) and thus data collection does not hinder the compliance.
There are 4 input fields and thus if we use the conventional approach, we must use 4 eVars. As an architect, we can opt to store 4 input values in the same eVar with a delimiter to limit the use of eVars. We can subsequently use the Classification Rule Builder to delimit the input values and relate them as separate eVars. If we do so, below is how the nomenclature and the values will look like for an eVar (Here, eVar1).
Though we have saved 3 eVars using the above nomenclature, the data manipulation will be harder with multiple possibilities. So, we must classify the delimiter values according to the input fields as mentioned previously. If we know how to classify an eVar, the following is how classification and classification values will look like (Here, eVar1 classification).
Now, the classified eVar will behave as a standard eVar and thus it is simple to evaluate or group the input values for personalizations. Using this approach we have also saved 3 eVars!
Even if the approach is to capture multiple values in an eVar, using a List Var is irrelevant. This is because, a List Var will automatically delimit the values into a single dimension than classifying them into multiple dimensions (Gender, Age, Type Of Employment and Salary Range). Below is how the input values take a gander when using a List Var.
Business Requirement 2
For requirement 2, we are set to capture validation error messages and error occurrences. Capturing the error messages is not straight-forward as a standard eVar because there can be more than one error message during the unsuccessful submission i.e. Multiple values. Multiple values, but this time it is a List Var than an eVar with Classification. Below is how the nomenclature and the values will look like for a List Var (Here, List1).
Individual or multiple error values, the values are properly listed in the dimension to understand the most frequent error message. As List Var is a persistent variable, we can also understand the submissions after the error occurrences.
eVar with Classification is not at all a choice because Classification Rule Builder will not list the delimited values in the same dimension. Even if we use classification, error messages will be distributed across various dimensions without listing under the same dimension i.e. We cannot understand the most frequent error message directly using classification.
Conclusion
Even if we have multiple values to collect, the decision to opt an eVar with Classification or List Var is based on the following:
– Use eVar with Classification if we need to collect multiple values and then segregate the values based on sub-dimensions i.e. Classifications.
– User List Var if we need to collect multiple values but listed under the same dimension.
Other Important Notes
Although the decision is based on the grounds of the conclusion below notes do have significance.
– eVar max length is 255 bytes for the entire variable; values longer than 255 bytes are automatically truncated when sent to Adobe.
– List Var do not have a maximum byte count; however, each individual value has a maximum of 255 bytes.
– There are only 3 list vars available per Report Suite.
– List Var store the most recent 250 values per visitor. If there are more than 250 unique values for a given visitor, the oldest values are not attributed to metrics.
– Do not use spaces when delimiting multiple items.
– To understand the concurrent values in List Var, we can use hit segmentation i.e. To understand the validation error occurrence on Gender and Age together for the above example, we can use hit segmentation.
– List prop max length is 100 bytes for the entire variable; if the decision is opted to take account of attributions, values longer than 100 bytes are automatically truncated when sent to Adobe.
Understand the disparity and make prudent use of the factors! Let’s connect again during the next post.
