Several years ago, we had an Analytics Rockstar deliver a unique and powerful tip that helped her win the competition. The tip was presented at 2019’s SUMMIT in Las Vegas by Audrey Salerno, of cars.com fame. You can actually watch the entire session via this link which is chock full of previously shared Rockstar tips.

The tip is ingenious (Audrey’s Analytics Rockstar slides) — prepend the current date to your Page Name value and throw it into an evar and/or prop.

For example:

a Page Name of:

rockstar: discography: live album

is saved in an evar/prop as:

17aug2021|rockstar: discography: live album

Audrey then shared how easy it’d be to classify the concatenated variable for a great use case: annotations! If there was a tagging issue, or a new campaign that went live on the 17th, she’d classify that date’s dimensional values with this additional information. It’s so, SO slick!

So why am I telling you this? Because I think there are plenty more use cases for applying Classifications to a variable with a date prefix.

Date-Enabled Classifications

For those of you that have been around the Adobe Analytics world for a while, you may remember a feature called Date-Enabled Text Classifications. The concept was great, apply a date range to your Classification values so they would only apply to a certain snapshot in time.

Classifications without Dates are incredibly valuable, but they are always set to overwrite and display the most recently uploaded value. So if you were to classify product-abc as a shirt today, then tomorrow you classify it as clothing, then Adobe Analytics will show the classification as clothing for your entire report suite’s history for product-abc.

As you can imagine, Classifications without Dates are useful for probably 90% of Classification use cases. However, Date Enabled Classifications, even though they no longer exist, still have several valid use cases — classifying values that change over time:

1. Your organization likes to reorganize the hierarchy of your product SKUs and would like the data to match with the assigned hierarchy during that time.

2. Tracking code values are re-used across different campaigns at different times, so the tracking codes need to map to different Classification values depending on the time.

3. As a publisher you are constantly moving articles from one section of the site to another and you need the Classification of these articles to always properly align with the section that it was placed in on that day.

A Date-Enabled Article ID is classified to show different article site sections for the same value depending on the date.

So What Can We Do?

Finally, we get to the point — you have the option to take Audrey’s trick above (classifying a dimensional value with the current date prepended) but apply it to Date Enabled Classification use cases!

Example 1 an organization that likes to reorganize their product SKU hierarchies: imagine if they had an evar that captured: date|SKU. The data could then be classified based on date! Voila — Date Enabled Classifications are back!

Example 2 an organization reuses tracking codes that need to be classified differently depending on the time: imagine if they had an evar that captured: date|trackingCode. The data could then be classified based on date! Bingo bango — Date Enabled Classifications are back!

Example 3 a publisher that likes to move their content to different site sections and classify them based on their location at that time: imagine if they had an evar that captured: date|articleID. The data could then be classified based on date! Easy peasy lemon squeezy — Date Enabled Classifications are back!

OK, but what are the limitations?

Yes, you guessed it, there are still some limitations. Let’s go through them one by one:

1. Plan ahead. You’ve got to create and set the evar in your Adobe Analytics tag before you Classify it. This means you’ll need to think ahead as you’re planning your implementation enhancements — think about the types of dimensions that Date Enabled Classifications could be applied to.
2. Consider cardinality limitations. You’ll basically be multiplying the number of unique values in your new dimension by up to 31 every month. Cardinality limitations kick in around 500,000 unique values in a month, and if you divide 500,000 by 31, then you’ll get 16,129 unique combinations of values with date prefixes. If in a month you sell more than 16,129 products, or utilize more than 16,129 unique tracking codes, or publish more than 16,129 unique articles, etc, then you may run into our old friend Low Traffic. Keep this in mind as you’re planning which variables to apply this trick to. Perhaps you can deal with just have weekly classifications, rather than daily? You could then set your base dimension as week1aug2021|abc123. Then you’d max at just 5 weeks per month, and your unique values goes from 16,129 to 100,000 per month.
3. Product SKU is tricky. Yeah, we all know this. The s.products variable is a beast, and you don’t want to pass date enabled SKUs into the Product variable in Workspace. So you would want to consider using a merchandising evar that you then populate using product syntax every time you set s.products in your tags. (If that didn’t make any sense, check out the documentation on merchandising evars to learn more).

Go forth and classify, you Rockstar you!