SiteCatalyst is not a Database

I had a lengthy discussion the other day with people who looked at a common scenario: their implementation was about 2.5 years old and they were struggling to get at the data that they needed.

The interesting part about this specific discussion was that we had a guy at the table who clearly was approaching the whole thing from a developer’s perspective.

As you might have guessed, I like that.

It also helped me understand something that hadn’t even occured to me before: some people see Adobe Analytics as a database!

Of course, in a sense, it is storing data and providing access to it. And in a very real sense, there is a lot of database involved in the backend. But to an analyst or a marketer, it does not look like a database at all, and — my hunch would be — purposefully so.

It is fair to say: Adobe Analytics Reports & Analytics (fka SiteCatalyst) is not a database.

Not a Database

Let me explain what I mean.

The main feature of a database, be it SQL, Hadoop or any other technology, is to store data and make it accessible. A database does usually not deal with the semantics of the data and it also does not restrict how a user can retrieve the data.

In fact, the whole idea behind SQL was to have a language for accessing stored information!

The focus clearly lies on simple storing and an ability to run complex retrieval operations. That principle is the same for Hadoop and most other database technologies.

Adobe Analytics, on the other hand, is focused very much on the needs of the users from the very start. Instead of collecting data in a “oh, just chuck it in!” fashion and then putting the burden of organising and analysing it on the user, it asks the implementer to sort out the semantics.

The data that you collect and — crucially — the way you collect that data determine what your marketer will see and how they will see it. What you do makes all the difference! Oh, the power!

Now you understand why consultants are involved in the implementation process, and you also understand why implementation is a big deal. And last but not least, you can see why an Analytics implementation is never finished!

As your analyst or friendly marketer uses the data you gave them, they will unearth insight and in the process ask themselves new questions. Chances are that the implementation will have to be tweaked to answer those questions.

A Domain-specific Tool

Like other domain-specific tools, Adobe Analytics has been built to make the jobs of the users easier. Using it should be as easy as possible, fast access to the information, the least possible amount of training involved, that kind of thing. A bit like Notepad is easier to use than emacs.

The focus very much is on the accessibility of the data (or as my colleagues in the US would call it, the democratization of data). The underlying idea, obviously, is that the easier it is to access the data, the more people will use it. Using data, in turn, helps making better decisions, so the easily available data should help make a lot of decisions better in a company, leading to success.

The downside of this is that the complexity happens at the data collection or data processing stage. Most data-driven domain-specific tools have to go through a non-trivial deployment stage.

Vendors know this, of course. My colleagues in product management are aware that deployment could ideally be easier. They are working on that all the time.

One recent step in that direction was the creation of the Tag Management tool and then the inclusion of Satellite, now known as “Dynamic Tag Management”.

Tag Management systems help with the technical side of deployment. They allow users to change tagging without too much intervention from IT. Obviously, that puts the complexity squarely into the hands of the user. And it is also obvious that the user has to be able to understand how it all works.

Bloggers like Adam Greco will still have a lot of work to do, educating marketers all over the world. And even this blog will still be valuable, I hope, for marketers will often need the help of a developer, even with tag management in place.

Notes

If your marketing department or your analyst decide that they would actually want a tool that places the complexity at the reporting level, somewhat like a database, then you might be a good candidate for Analytics Premium which includes the “Data Workbench”, formerly known as “Insight”.

Data Workbench is mainly sold as the tool for multi-channel analysis. It allows you to pull in data from pretty much anywhere and tie it together using whatever data points you have available. That way, you can use loyalty card data, logins or even card data to see what people have done on your site, in your stores, or with your call centres.

Since these associations are made in the the tool itself, rather than using cookies on the visitors’ devices, data collection is actually relatively straight-forward. Configuring the tool is where the fun part lies.

Even more fun is that you can change the configuration at any stage, should you need or want to. The system then crunches through the data again, even the data you had recorded before you changed the configuration.

For a lot of marketers, this is close to nirvana. It really aligns well with the way they work: look at data, come up with theories, then collect data differently to confirm (or refute) it. Using Data Workbench, you can usually do that without any changes in the tags.