5 Awesome Adobe Analytics Classification Use Cases

Adobe Analytics has a rich set of features that help businesses collect and report on data in most efficient ways. I’ve written a lot of posts already on how it can be configured to collect data in better ways or how the interfaces can be used to its full extent. Today I want to show you some use cases for one of my favorite features, as it can help you in every stage of an analytics project: Dimension Classifications.

Using Classifications, at least in my opinion, is a big step towards making the best use of Adobe Analytics. It can help simplify implementations, manage resources (like the number of used dimensions), surprise users with great new features, or even help you correct errors in data collection retroactively.

But before I start with the use cases, let’s make sure we are on the same page by asking…

What are Classifications in Adobe Analytics?

A commonly used explanation of what Classifications actually do is simple: They act as a lookup table that you can use to translate dimension values that you have tracked (like a campaign parameter or a page name) into a different value that you would like to use in reporting. This is super handy for a bunch of applications, because we can even define more than one lookup value for a single key (more on that later).

When we create Classifications for a dimension in Adobe Analytics, we select the dimension that we want to translate into other values and then add as many lookups as we want. For example, we may already capture a rather cryptic campaign code in the Tracking Code dimension like in the leftmost column below. Without any further effort, as a user we would then need to analyze all those codes individually, which would not be the nicest experience. Instead of forcing our poor users to do that, we can use Classifications to translate those cryptic values into something that makes sense for our analysis, like a Campaign Name, Marketing Channel, or Traffic Type in our example:

With this little trick, we enabled our users to report on their Christmas Campaign and analyze the performance of different Traffic Types for that campaign without issues! This makes life much easier for all parties involved and just requires the setup of those dimensions and that we provide a table like above to Adobe Analytics. We can then use those values instead of the originally tracked values for reporting.

There are a bunch of ways how we can provide a table like above to Adobe Analytics. We can use a manual upload via FTP (which is great for getting started and explained with a different example application in my previous post) or even utilize the classifications API (as done in this post). On top of manually classifying data, we can also use the amazing Classification Rule Builder to create those lookups automatically from the data we tracked (see use case 3 below for an example).

While the manual ways of classifying data work fine if you are just starting to use them or just have to update them every now and then, but the process can become quite tedious very quickly. Luckily, there is a solution for this!

Make your life easy with a Classification Management Tool

A great thing about classifications is that we can update them whenever we want to. Since they are lookup values, this will even change the reporting of historical values that were tracked before the classification even existed! But how can we then ensure we don’t mess up our valuable lookup data? And how can we avoid the manual work?

I’ve written a post about a possible approach already. In this previous post, I’ve used Google Sheets to automatically upload and manage classifications through the Classifications API. Google Sheets is awesome for this because, beside it being free and very easy to use, it allows to share a Sheet with our co-workers and agencies and collaborate with them in one big, constantly updated file. Thanks to the neat permission system and version history, it’s also easy to give guidance to users and correct mistakes if they should ever happen. I can really recommend this approach and used it at multiple companies already.

However, using a solution based on Google Sheets may not be the right thing for you. Especially in large corporates, there may just be too many potential users to manage. Depending on your guidelines, you may even be forbidden from using it completely for compliance reasons. In those cases, you may want to talk to companies like Accutics, which offers a product for this exact use case. I’ve personally used their tool and can recommend it wholeheartedly to anyone who wants to manage classifications for campaign codes or even other applications.

Now, onto the first use case!

Use case 1: Translate and enrich values in Adobe Analytics

This is the most obvious of our use cases on this list. I’ve already given you one example with the basic demonstration above, where we can classify a campaign tracking code from our marketing links to provide information about the campaign or marketing channel that a code belongs to. That is super neat already, but there are other applications beyond the marketing example!

Another great application may sound strange at first but can potentially hold a lot of value for your business: Why not, instead of tracking metadata about a page (like a page name, its business unit, site section, page type, etc.) directly in the frontend, only use a page id that you can later classify? If you talk to the developers of your site’s CMS, you may discover that it is quite easy for them to provide a table like below to you or Adobe Analytics directly:

This brings all the advantages of Classifications (updatable, retroactive, extensible) to your page data too. So if you in the future decide to include even more information about your pages in Adobe Analytics, you can just create a new classification column and upload the data, which will make it look like it has been there from the very beginning. Super nice!

So while Classifications can be used to make a value understandable to humans in the first place, they can also be used to provide additional information that you can not provide through the frontend or likely want to extend in the future. Another good example for this is purchase information about an order or a product that should not be brought to the frontend, like profit margins, fraud order checks, etc. If you have a key, like an order number, that is shared between your frontend and backend, you can always create Classifications after the fact.

Use case 2: Correct data retroactively in Adobe Analytics

Our second use case is something that a lot of analyst wished to do for a long time: The option to retroactively correct values that have been erroneously tracked. For example, consider this case where someone mistyped “homepage” and later corrected their mistake:

This is super ugly, because now there will always be two separate values showing up in reports for what is actually the same page. I’ve seen some unfortunate examples for this where editors even decide to leave the page name in its wrong state so reporting is not disturbed. There is a very real risk that something like this will happen sometime on every website or app.

The good message is: We can just create a Classification dimension for the page name, then use a manual classification to correct the value retroactively. There is even a super simple way to bring all existing page names over to a classification dimension using a regular expression like below in the Classification Rule Builder. Make sure you don’t overwrite any existing values here, as you will only want to do that manually:

You may want to create those Classification dimensions as one of the first things when you create a new report suite, but even for existing ones it has always been worth the effort to migrate to classified values. The potential advantage of correcting values after the fact is just too good to miss out on!

Use case 3: Increase number of Props and eVars in Adobe Analytics

This is one of my favorite use cases, and that’s not even because I encourage a wasteful use of Props and eVars. Sure, there is a technical limit on how many we can use, but I’ve never been even close to reaching it in reality. If we still want to save on dimensions, Classifications offer us a super easy way to do so.

Consider this example: We may have a number of interactive elements on our page, like buttons, image galleries, links, etc. Most certainly, someone would like to know what our users actually do with those elements. This gives us an interesting challenge: How do we track those different types of content? Sure, a button and link are only clickable and therefore easy, but what about the image gallery on the same page?

What I’ve seen in other implementations is quite wild: Things like a button name, link name, or image gallery name would all be their own eVars! On top of that, they all have dedicated events like “Button clicks”, “Link clicks”, or “Gallery clicks” alongside those dimensions. Besides this being incredibly wasteful and not very scaleable, there is no way to get a list of all clicked items on a page without having to consider three different dimensions. Can’t this be much easier? It can!

What I want to propose to you is a framework approach to this challenge. Instead of using dedicated dimensions for each type of element, we could just use one dimension to capture the type, name, and interaction of every type of content. For the examples above, we could think of a list of possible pieces of information like this:

With those three dimensions, we can capture all interactions that are relevant for my example use case. On top of this being super efficient, we also only need a single Event to capture content interactions, which we could then use with our dimensions to create Calculated Metrics like “Downloads”, “Clicks”, etc.

But how does this tie into Classifications? I’m glad you asked! Instead of using three dedicated dimensions for those values above, we could just put them into one eVar and use a Classification Rule Builder rule to separate them afterwards. If we define a syntax like “t=<type>;n=<name>;i=<interaction>”, we would have a very efficient way to track three values with only one eVar. Extending the table above, this is how our Classifications table would look like:

Once we track our values like in the first column, we can create a Classification Rule Builder regex rule like “t=(.*);n=(.*);i=(.*)”, where t stands for “type”, n stands for “name”, and i stands for “interaction”, to respect the syntax we chose for our tracked values. A full list of rules could look like this, where I assign specific dimensions to the groups defined in the regex:

Awesome! This will now help us to reduce the number of dimensions used drastically, because we can track all metadata for an interaction with just one eVar! For our users, they will hardly know the difference between using a classified vs. a tracked value, because Adobe Analytics just treats them the same way. How cool is that! As long as you don’t exceed the character limit of an eVar, you are good to go.

There is an even cooler application for this type of framework approach that I will show in Use Case 5. But before we get there, let me first show you how to get…

Use case 4: Unlimited List Variables in Adobe Analytics

List Variables (or list vars) are possibly the most powerful and valuable type of dimension in Adobe Analytics. With List Variables, we can track an unlimited number of values in a single dimension, where we would separate them with a custom delimiter. We can configure a List Variable in the Report Suites section of the Admin area like this:

You can already see on this screenshot why they are so valuable: We can only have three of them for the whole Report Suite. That is not a lot, but all we get in Adobe Analytics. Fortunately, Adobe Analytics’ successor Customer Journey Analytics has unlimited List Variables, but we have to use a trick to get something similar in Adobe Analytics: Classifications!

We can use the same approach from Use Case 4 again to namespace our tracked values. In my example above, I want to track the freely definable attributes of a page or content interaction in just one dimension, so I create my Classification dimensions as show below:

In this example I only need a Name and Value for those attributes. With those dimensions created, we can now use a Classification Rule again to pull the values apart with a regex like “k=(.*);v=(.*)”, k for “key” and v for “value”, and put them into the right Classification dimensions. This is how my setup looks like now:

What this setup now allows me to do is quite cool: In List Variables, we can send values like “k=Teaser Impression;v=Teaser 1,k=Teaser Impression;v=Teaser 2,k=Teaser Click;v=Teaser 3”, which tracks impressions for two teasers and a click on a third teaser. We could extend this list quite far and track both teaser impressions and teaser clicks in the same dimension or even add other pieces of information! In Analysis Workspace, we could then build reports like this, going from the raw values to filtered tables and specific analysis:

How cool is that? Again, we could create Calculated Metrics or filters to narrow down which elements we would like to analyze. With a setup like this, we can practically use this one List Variable like an unlimited resource by providing different types of namespaces, until we run out of unique values for a given month. Now, onto my last tip for today.

Use case 5: Combine dimension values in Adobe Analytics

I’ve been promising you a real banger of a Use Case back in Use Case number three. Let’s revisit the example really quick: Instead of using three separate dimensions to track three data points, we were using a syntax like “t=<type>;n=<name>;i=<interaction>” to track an event and created a Classification Rule Builder rule with a syntax like “t=(.*);n=(.*);i=(.*)” to populate the Classification dimensions.

But we can do something even cooler with a setup like this. For example, we could create some additional Classification dimensions that would combine the ones we have been using before. So instead of just using a setup like this:

We could just go ahead and extend our list of Classification dimensions, even after data has already been collected, to something more like this:

To create those two new dimensions from existing data, all we have to do is extend our Classification Rule Builder rules to something like below. Notice how in the last two rows I’m using more than one variable from the regex:

How awesome! Without us ever having tracked a value like “Subscribe Button Click” we are just able to create this new value long after data has been collected. This way we can finally combine dimension values if we tracked them using Classifications. For me personally, this gives me lots of opportunity to positively surprise stakeholders with helpful new dimensions for historical data.

Wrap up

I hope you see why I love Classifications in Adobe Analytics as much as I do. Maybe some of those use cases helped you to think about them in a completely new way or extend your existing usage. While they are pretty cool already, I think Adobe could make them even more usable with some small enhancements, like if we could see when the Classification Rule Builder has had its last run or if we could even trigger those manually. A bigger, but even more exciting, feature would be a nice frontend that would allow us to edit classification tables on the fly. I know this is a big ask but I can always dream, right?

As always, let me know which cool use cases you can think of yourself. Have a great rest of your day!

Frederik Werner

German Analyst and Data Scientist working in and writing about (Web) Analytics and Online Marketing Tech.

2021&2022 Adobe Analytics Champion

EMEA Adobe Analytics User Group Lead

www.frederikwerner.de/