Blackbeaks Blog….All things Analytics

I have proposed a similar idea on my blog a few months ago here, and was called a dreamer.

I am very happy that you are bringing this up, because I do believe we should get free from proprietary data structure. I think further that we should make the data structure so that it could be handled by other types of applications (i.e. BI, etc.).Vendors would then have to compete only on how well they would they care of my data.

But as a first step, I agree with you that a common basic tag shared by everybody would simplify implementation.

“You, dreamer!”

It is of course a good idea and most will say it is. It is very ambitious and probably it will take time to get there. But most important, as you said is to get started with “feasible” & realistic goals like a basic light universal version. Then from there, continuously improve it (Kaizen way ;-)).

Start small, think big! And maybe you will move from “dreamer” status to the “visionary” one.

Cheers,
Michaël

The best part of dreaming is that they are usually based on some level of reality. This happens to be one of those dreams. Basically the idea sounds easy to do if you aren’t familiar with the tags, but as most of us are, everyone thinks it’s an impossible or at least a futuristic view of things.

I say this is easy and could be done with a some relatively easy solutions. It can be done in several ways, but I don’t see why it should be made the hard way. I have a working solution, which is not perfect, but can be perfected by sharing work and knowledge.

The idea briefly:
Using a 3rd (party service to host/CMS module to generate) a dynamic JS to be added to the site.

How it works:
Model A - WAA hosts a simple system that generates custom JS code for the target website. This code has a counter part in the CMS (module) that has a few account specific settings that are important and maybe if further developed, per page settings. When the CMS generates the JS tag, it includes a few parameters in the file location and the JS is generated based on these parameters. They will indicate necessary info and settings (or an account name which will be used if this info is stored in the service itself?).

Model B - The CMS module itself is a simple system that generates custom JS code for the target website. The module also has and admin functionality that has a few account specific settings that are important and maybe if further developed, per page settings. When the CMS generates the JS tag, it includes a few parameters in the file location and the JS is generated based on these parameters. They will indicate necessary info and settings (or settings ID if module is built to be able to have multiple).

After the JS has been included, the usage of vendor provided standard (or customized) JS code is used to actually gather the data and send it. No custom hacks needed to craft the data in to special format, no need fo gigantic JS files to include a switch-case structure. Of course when going to highly customized solutions this needs more work, but a quick solution isn’t designed for those needs anyway.

Using this sort of method allows only one tag that only has one line, no per page variables and is not different for all systems. And it’s easy to use multiple systems at the same time.

A piece of mudcake!

It’s an interesting idea. Question is if it’s realistic. Vendors haven’t exactly agreed over other standards yet.

Of course it’d be good if we’d focus on making things easy for users/our clients though.

The vendors will most likely never agree to a common tag, based on the different needs for cookies etc. their systems require.

This is why I believe in the solution I wrote about earlier, to completely avoid concerning the vendors and use the code they provide, but not tag with it.

Thanks for the comments both on and offline. Eric sent me a link I hadn’t seen before which perfectly describes the solution I was thinking of; http://www.tealium.com/products/trackevent/index.html.

We need something like that for free download by all CMS and e-commerce vendors. If it can be done in RIA then it can be done on ordinary web apps.

In my opinion value won’t flow in one direction, it will actually help the vendors as well if done right. To be able to easily switch from one app to another is as attractive for Omniture as it is for Google or IndexTools. Of course it works both ways, but there are far more customers on GA for instance that Omniture can fight for than GA have the ability to defend.

One of the objections companies have is changing the tagging on sites. This in effect could become a thing of the past if all new major content systems used a free tag ‘switcher’.

Especially with the new developments to GA on segmentation coming out of beta, Omniture and other paid solutions are going to find it tougher and tougher to compete with their standard tool offering.

Anything that helps them in the current economic climate can’t be a bad thing.

Further comments always welcome.

Hey Steve,

I like the idea. But the biggest problem I see is that the web analytics solutions are so different in the way that they rely on tags. For example, Discover On Premise, Clicktracks, and Unica don’t require much customization of the Javascript for tagging biz events. Instead that configuration is done in the UI (e.g. campaigns, content groupings, scenarios, etc.). In contrast, SiteCatalyst, Webtrends, and Coremetrics are known for a tagging approach that emphasizes flagging such things in the tag.

So before these solutions could use a common tag, we vendors would first have to make our solutions more similar to each other in terms of configuration.

Now, that isn’t a show stopper either. It is just that our customers all have other things that they tell us are bigger priorities that they’d like us to do. And that is why the show for tag standardization stops.

Greetings
Akin
Unica

@Akin,

Let me be the first to congratulate you. The first vendor to show enough backbone to comment publicly on the idea.

In response to the concern, yes I agree with you. SC, WebTrends and Core would not be tagged to any high level of sophistication but a middle layer tag could help with implementation issues.

Indeed an open source solution which CMS vendors and e-commerce vendors got a hold of would be very useful as it could be simply selecting variables from a list and presto.

The point is that the vendors wouldn’t have to make any alterations at all.

Paranoia. I’m working with a customer now that refuses to implement Google Analytics because they’re paranoid that Google will learn too much about them and may, in the future, abuse that information. Of course the customer doesn’t have the resources to implement anything that’s not free, which makes my job exceedingly difficult (if not impossible).

A universal tag for web analytics may worry other companies like this customer that still cherish the illusion of data obscurity.

Hi Barry,

Nice to hear from you. Hope you enjoyed DesignForConversion.

Your point about Paranoia is a good one. That would be one factor we’d have to build into any release of universal tags. Education of the market.

It’s an interesting idea.

Good stuff here. Interesting concept and all, but the title you chose for this post is even better.

CW