Background: With the limited number of evars and props - we are struggling to set aside enough variables to capture all the different attributes for each of the 30+ products we currently track.
My question is: what are the pros and cons of setting aside (let's say - 10-15 generic evars and props) that are set on product-specific rules with product-specific data elements?
Things to keep in mind:
Granted the SDR will need to be updated to this product matrix for proper documentation but if only a few people are working on it what would be the cons of doing something like this? I recon the SDR and variable mapping will need to be present and when creating dashboards and the Data dictionary will need to provide variable distinctions.
If this is not the best practice and there are pitfalls to what I am suggesting, kindly explain.
Solved! Go to Solution.
Views
Replies
Total Likes
Instead of using eVars and props, what if you use Classifications instead?
Classifications allow you to map the values of a variable (e.g. an eVar, a prop, product) to other values. Also, Classifications don't use up eVars nor props.
In your case, you could have the following Classification setup on your "Product" variable:
Product:
And your Classifications could look like this:
Key | Article Title | Event Title | Service Type |
Product 1 | the article title | ||
Product 2 | service type for product 2 | ||
Product 3 | the event title | ||
Product 4 | service type for product 4 |
Notice how you don't have to fill in every value for every column, except for the first column (which are the values from your "Product" dimension).
Depending on the value that you're tracking to your "Product" dimension, you could use Classifications Rule Builder to map your Classifications, otherwise you'd have to use Classifications Importer to map the values manually.
Instead of using eVars and props, what if you use Classifications instead?
Classifications allow you to map the values of a variable (e.g. an eVar, a prop, product) to other values. Also, Classifications don't use up eVars nor props.
In your case, you could have the following Classification setup on your "Product" variable:
Product:
And your Classifications could look like this:
Key | Article Title | Event Title | Service Type |
Product 1 | the article title | ||
Product 2 | service type for product 2 | ||
Product 3 | the event title | ||
Product 4 | service type for product 4 |
Notice how you don't have to fill in every value for every column, except for the first column (which are the values from your "Product" dimension).
Depending on the value that you're tracking to your "Product" dimension, you could use Classifications Rule Builder to map your Classifications, otherwise you'd have to use Classifications Importer to map the values manually.
Likewise, if you don't want to keep a full mapping of product to values, you could use something like one of your list variables, and use prefixes such as "at:" for article title, and "et:" for event title, etc...
Collect all the "at time of capture" data into the list with the delimiter of your choice (comma or pipe - I will use pipe in my example) E.g. "at:article title|et:event title|st:service type" then use classifications to automatically process the list items, base on the prefix, into classifications automatically (extract just "article title" and place into Article Title classification based on a regex that looks for "at:something" and stops at your delimiter).
This could be a little more "self managing" then setting up specific classifications based on the product id... and IF you add new data, you would just need to add a new unique prefix, and add an additional rule to process the data.
But it's very similar to the above solution, and both would work... it just depends on how you want to manage it
Views
Replies
Total Likes
You may also consider using list variable, list | Adobe Analytics, storing content like "att1=abc,att2=qwe" and "att2=asd,att3=123". Then create a classification on the list variable for all known attributes and follow by classification rule build to extract values into matching classification.
A list variable has no limit in total but only each "name=value" example above is limited by 255 bytes, but there are only 3 list variables per report suite so need to plan and use them wisely.
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies
Views
Likes
Replies