In Search of the Simplest, Useful Analytics Setup

Thought experiment? Challenge? Naïve day-dreaming? Solid advice?

This post might be all of the above, which, in my book, makes it a beautiful thing.

The question is this: what is the simplest possible Analytics setup that is still useful?

There are so many details in that question!

Setup

Most importantly: why am I even asking?

I have in the past done two things: a) stated that simply tracking pageName on every page is not enough (example: “Basic Tracking – Remix (contains Launch)”), and b) urged you to keep things simple (example: “Analytics Project vs Space Shuttle“).

There is a clear lower boundary set (“just tracking pageName is not enough”), and the upper boundary is when we look at the dimensions and metrics in the left rail in Workspace, and we feel “there sure is a lot there…”

I value usefulness over being prepared for all eventualities, as you may know, and so I would like to push the upper boundary down a bit.

That’s the why.

There is also some more on the why over on QA2L, where Nikolay Gradinarov summarises a discussion with Jason Thompson of 33 Sticks. The last section lists everything that looms when you do not keep it simple.

Next: can we define “useful” in a way that makes sense for everyone?

Almost 100% sure that we can’t.

There are ways around that, though. At Omniture, we used a “verticals” model. We looked at your business and put it in one of our boxes: retail, travel, high tech, B2B, automotive, news sites, and so on.

Underneath that, we had these building blocks of site functionality, and for each vertical, we decided which blocks were useful. For retail, as an example, we would think that “shopping cart analysis” should be useful.

Today, I would argue that some of those blocks have faded in usefulness, but others have come about, especially others that include non-Analytics aspects, like targeting.

What I am thinking: the “building blocks of site functionality” should be a good starting point, and we should be able to come up with a good Analytics setup for each one.

Then: what does “simplest” mean?

I see three aspects: simplest to use, simplest to deploy, and simplest to maintain.

The former may include some sorcery behind the scenes, while the latter should definitely not. The latter two, on the other hand, may be harder to use, and the former is very likely to be harder to deploy and maintain.

I think that it makes most sense to balance ease of use and ease of maintenance at the expense of ease of deployment, maybe with a small bias towards ease of use.

With those three aspects covered, we could move on. And the next step is to find those building blocks of site functionality I mentioned above.

Would it make sense to try and catalogue what modern sites do? I’d call that the “inclusive” approach. It would be big, I think, a big library. Or should we “follow the money”? Concentrate on things that help businesses make money? And on things that businesses spend on, of course.

I am a fan of keeping it simple, so I shy away from exhaustive, inclusive approaches, and I chose “follow the money”, at least in this case.

And before that, there are basics that we need to cover.

Skeleton

Some things should be done on all types of sites, or course.

The pageName must be tracked on every page load, for example.

If your site is multilingual, you should track language, and if you are using a template system, track the page type (such as “home page”, “product page”, “article page”, etc..).

Most sites have sections, and if yours does, track the site section.

These are all page-load-related data points, and they are needed so you can see what content is consumed on your site, and how people move around.

If your business is content, then you should likely add a couple of dimensions, such as author, publish date, maybe tags. They would help you understand what you can do to make more money with your content, and with what content, exactly.

Note that if the actual content is your product (you’re running a media site or a blog), you could track a content ID and add a lot of meta data using Classifications. That has to be automated, though, otherwise it’ll violate our ease of maintenance goal.

It is also really important to see how all sorts of campaigns perform, usually by tracking a tracking code.

Most people use Classifications for these, too, and again, that should be automated. There are a ton of cool tools out there to help you with that.

Visitor Activity

Most sites allow visitors to interact in some way. The simplest want you to drop your email, and the most complex are full-blown applications (this blog is on the simple end, whereas Launch, for example, is on the complex).

Since there is probably an unlimited number of possibilities for user interaction, I want to look at two things: value and grammar.

Let’s start with value, because it is more clear-cut.

For all the possible interactions that your visitors can do on your site, tell me how much money your company makes when someone does them.

Often, you do not know.

When a visitor to a car manufacturer site submits a request for a test drive at a dealership, we know there is a certain chance they’ll actually turn up, and there is also a (smaller) chance that they’ll buy the car. When someone orders a credit card on your site, they may or may not use it, and they may or may not move all of their business to your bank.

It may be difficult to find out, but you should be able to group interactions, at least. Some are high-value, some are definitely not. If in doubt, check your KPI framework, and then do only those that make a difference.

To show the polar opposite: a click on a menu item is clearly not what I have in mind here.

One person who does this very successfully is Urs Boller.

In his guest post “Minimalistic approach for more insights” he describes how he mostly gets away with 3 events. His approach puts the question about value of an interaction into the hands of the stake holder, and he ends up with very few events as a result. Very easy to understand, and easy to maintain, too!

Grammar

Now that we have slimmed down the list of interactions that should be tracked, let’s think about what exactly we would track about them.

My suggestion: use the key grammar concepts.

In its most simplified form, every website interaction is a sentence, and what I’m suggesting is to take those sentences, take them apart, and track accordingly.

Let me show an example.

“Visitor X submitted the credit card application form”

That’s a standard sentence, and so it contains a subject (visitor X), a predicate (submitted), and an object (the credit card application form).

How would I think about tracking that?

The subject, most often on the web, is an anonymous visitor, so I would not track that at all.

The predicate would map onto a Success Event in Analytics. That could be a generic event (Urs would track a “Convert” event), a specific one (“Form submit”), or a very specific one (“Credit card form submit”). The event would answer the question “What happened?” and “How often did it happen?”

The object would map onto one or more dimensions, likely eVars. The dimension would answer the question “So to/with what did it happen?” and the answer might be “well, the ‘Form submit’ happened to the ‘Credit card form'”.

This is really simplistic.

But it quickly comes alive when you speak with stake holders!

They will let you know whether your questions and answers are good or not.

“But Jan, which credit card are you talking about? The Ultimate Gold-pressed Latinum one?”

So my example should really be “Visitor X submitted the credit card application form for the Ultimate Gold-pressed Latinum Card”, and I would need two dimensions to capture that.

Makes sense?

I think this method reduces misunderstandings because you spell out what your analytics can answer, in detail.

You obviously apply the same principle as above: follow the money. If you do not care about parts of the sentence, then do not track them.

Back to the Classifications I mentioned earlier.

If the sentence becomes very long (“Visitor X added the green, XL-sized, round-neck, pure cotton, … T-Shirt to the basket”) it might be time to use Classifications.

But, again, I think they work best when they are automated, and they make the life of a maintainer difficult when they’re not.

Equipped with your KPI framework (so you can ignore things on your site that do not matter that much) and the “grammar approach” (so you can ignore things that are not part of your sentences), you can get to a pretty simple setup, I hope.

Notes – how badly did I fail?

My goal was to “push the upper boundary down a bit” and the question is: how badly have I failed at this point?

When I started writing this post a couple of months ago (yup), I thought I’d be able to come up with some sort of catalogue, not too different from the old “Fusion” documentation of the Omniture days.

But the moment I realised that that was what I tried to do, I also saw that it wouldn’t work. It would have been overly simplistic (“You’re a retailer? Ok: Product Views events with a product ID, Cart Add events with the product ID, Checkout events, plus a purchase event with a list of all product IDs. That’s it. Oh, and internal searches!”) and not realistically useful.

Part of me still thinks this would be a good idea.

In my mind, consultants would always implement those items on the list, and gently push back on everything else the client wanted, with the goal to keep the additional dimensions as few as possible.

But after pushing stuff around and playing with different ways to list, I started to classify all of my examples (I had many), and then eventually threw them away and only kept what I had written about the principles.

So this isn’t a list of useful things, after all. Instead, it explains a little bit of how I would come up with such a list.

Is that useful?

It feels like it is. Of course, it feels like that to me because my goal is to reduce tracking, all in the spirit of keeping things simple.

But, overall, I utterly failed! I wanted to lower the upper boundary, and instead, I upped the lower one!

There is probably an article about blogging somewhere that says if you failed to make the point, throw away what you wrote. Somehow, I am unable to do that. I think the quest is valid and necessary, and while this article doesn’t bring it forward a lot, it documents what I have tried.

Sod it, why am I justifying myself? This is my blog!

Have you read all the way to here? Thank you! Much appreciated, especially this time!