The topic today is slightly removed from your typical developer day-to-day activity, but it’s nevertheless important in the context of Adobe Analytics.
Think of a report that shows tracking codes, like so:Apart from the person responsible for those codes, no one will ever be able to read this report. Even that person might have to look up the values.
[In the voice of Ian McKellen] Pointless, really.
For that report to be useful we need to turn those campaign IDs into something readable. Campaign names might be a good first step.
Let’s do that:The report now looks like this: Now most people in the company might understand the report, at least most people in marketing, i.e. those who a) know what a campaign is and b) care about how they perform. So far so good.
At a slightly higher level, the report is still useless. If someone asks your friendly colleague in marketing about the general performance of email campaigns versus paid keywords, this report won’t help.
We need to aggregate!
Your friendly marketer was planning ahead and kept to a strict schema when assigning new campaign IDs, which makes it easy to just add up the numbers. As an example, all those tracking codes starting with “EML” are definitely email campaigns.
If we add them up and also aggregate the others, like so:We get this report: That is a useful report! And if you look closely at the tracking codes above, there seems to be more information encoded.
It is up to the marketing department to figure out a good schema for their tracking codes. Here’s a couple of ideas:
- Use three letters to designate the campaign channel or type, like email or PPC.
- Assign 6 digits for year and month. That can be aggregated into years, months, or seasons!
- Reserve a couple of letters for the initials of the person responsible for the campaign. Aggregating that would give us a direct comparison between people working with campaigns.
- Finish the code with some digits that increment, per channel or person.
Each of these aggregations can be modeled in Adobe Analytics using SAINT Classifications.
In essence, SAINT creates new reports based on existing ones. It does that by aggregating the data when the report is requested. In a sense, the Classifications created using SAINT are similar to the View in the database world. A very powerful tool, and one that is not nearly used enough by most marketers!
Use cases for SAINT Classifications: making data readable (examples would be tracking codes or numerical dimensions like ‘number of visits’), aggregating and therefore abstracting data (like the Campaign Channels we mentioned above, email, PPC, etc.), correcting typos (“Homepgae”). I’m sure there’s more.
So how do you add the meta data into Analytics?
Well, the tool is called SAINT and it has four entry points for meta data, so to speak.
The Manual Way
You basically upload a CSV file that looks almost like the list above, with just some headers added:
While this is so easy that even a non-technical person can learn how to do it, the manual way obviously doesn’t scale very well.
Most marketers are easily able to work with that tool, but since it is done by Engineering Services, it comes at a cost.
Yup, there’s an API that let’s you automate the whole process! You can use the SAINT API to upload data straight into SiteCatalyst and no one has to do anything manually.
This is great for companies that use some sort of a campaign management tool. The data in that tool can simply be pushed into Adobe Analytics and no further work is required.
The obvious downside is that someone needs to develop the code that collects the data and pushes it into SiteCatalyst.
From you point of view as a developer, that might not be a downside, of course.
Currently in beta, but hopefully we will soon have auto classifications within Analytics. When the time comes we shall write about them. Let’s just leave it for now with one little teaser: they’ll support regular expressions.