How Classifications are Different

[Due to a mistake I made yesterday evening, this post went out partly, so I decided to post it now rather then wait for Apr 1. No April’s fool joke in here.]

I hear singing on TV, the girls are watching CBeebies, the BBC channel for children. They’re watching a show called “3rd & Bird” about the adventures of a little lovebird. This has of course nothing to do with Digital Marketing, Analytics or this blog, but I have that in my head now, so I must share it.

Back to our subject today: Classifications and SAINT.

If you need a reminder of what that is, go read my earlier post.

Right, now you remember that Classifications are a way of changing the look of data. You can make existing data readable or you can aggregate it if the data is too granular.

I mentioned back in 2013 that one way of classifying data was in beta at the time. Since then, “Classification Rules” have gone live and whilst I haven’t written about it, you can refer to the Classification Rule Builder doc for information. Chances are your friendly marketer will need your help! (Regular expressions, anyone?)

But today, I want to point out a very important thing that makes Classifications unique.

And for that, we need to start where all good stories start: at the beginning.

Data Collection

You might remember a little graphic that I posted in the article about modifying data server-side. It looked like this:

The graphic shows what happens to data that you pass into Adobe Analytics.

To quote the older article:

First, data is assigned to “variables” in Javascript. Those “variables” are then sent off to the collection servers. The collection servers process each hit. They initiate geo-lookup based on the IP address and apply some mobile-specific meta data. Then they pass the hit through Processing Rules and VISTA, two mechanisms that can modify it to a certain extent. The data is now enriched with other data from the visitor’s profile and then processed and stored for reporting.

Every step in this chain can enrich and change the data until it is finally written into a storage (not a database). Once the data is stored, and this is a fundamental design principle, it cannot be modified!

Letting that sink in for a moment here…

… cannot be modified …

Adobe Analytics, like most analytics tools, is built to accept, crunch, store and report on data. That sort of sums up the core capabilities of a reporting and analytics tool.

(There are tools that can change data, reprocess it. Adobe Analytics Premium includes the “Data Workbench”, fka “Insight”, which allows pretty radical changes to the data via reprocessing. But that is not our focus today.)

Data Presentation

Classifications add one really cool feature to the core capabilities, or as my colleagues in product management and marketing would call it, a really big differentiator — with Classifications, you have an additional layer that allows you to manipulate data at reporting time.

People often compare Classifications to the View concept in SQL databases. They cover part of that functionality, specifically the aggregation of data. But since SiteCatalyst is not a Database (sorry for repeating myself), I don’t want to go down that route.

Instead, let me compare Classifications with functions in programming. Chances are that the audience of this blog is more familiar with functions than Views anyway.

One idea behind creating a function is that it is easier to read sort(myArray); than it is to read the actual code that would sort the array if it was in the flow of the program.

Imagine reading through source code where every function had been inlined…

Impossible except for the simplest of programs.

Guess what: the exact same is true for reports!

I mentioned some specific examples of reports that do not make much sense in the past, but the truth is: most reports have too much data! Condense them down, aggregate the data, and it will almost always be more useful or easier to understand.

And that is what makes Classifications such a great tool. Using SAINT, you can aggregate data so users can actually understand what it is they’re seeing.

Aggregate!

Example Campaigns — you likely set it up so your implementation tracks at a fairly granular level, usually the “Tracking Code”. What that means is that when your friendly marketer looks at the reports, they can see exactly how many orders or how much revenue they had thanks to a specific email they sent out.

That may be useful information, but I would argue that it rarely comes to that. Most of the time, the CMO wants to know how to spread her budget, and for that, the report is useless.

But aggregate those tracking codes into marketing channels (like “Email”, “PPC”, “Banners”, “Social”), and all of a sudden you have a report that helps! The marketer can now see what percentage of revenue was driven by email, and she can think about whether the budget fits or not.

Yes, it is more complicated. There’s attribution, cross-device, multi-channel to be taken into account. But the example shows: aggregate the data to the right level of abstraction for the stakeholder, and that person will be able to use it.

Why am I going on about all this?

SAINT Classifications are unique in the Analytics world. They bring huge value. And what matters for you: they are fundamentally different from all other mechanisms in Adobe Analytics because they are applied at report time.

Back to CBeebies: I’ll let “3rd & Bird” provide the summary for this post with a catchy tune.