Save yourself some time, reduce your frustration, remove code deployment risk and improve your insight by using our technique to quickly test and deploy new web analytics code on your site without the need for staged testing.

Fear driven motivation ...

Quite frequently we needed to test site updates on a staging server for fear of breaking the production site, upsetting customers and losing revenue. This seems like a really good idea, except that when the files are pushed live things don't always happen quite as expected. Staging sites are never the same as production, we've seen perfect copies have issues with cookies due to the different domain, poor version control, different asset location and other network issues like load balancing amongst a range of other problems, the bottom line is they are never the same, period. 

In addition to the testing issues, we also need to deal with the fact that assets like Javascript are cached by some browsers. Code roll outs are not immediate, but dribble out over a period of up to a month as browsers invalidate their cache. This is a scary proposition for people relying on the analytics data, especially when frequent updates are required. 

Efficiency driven motivation ...

In addition to this, for many of our clients (e.g. banks) we have rare deployment windows as far as 6 months in the future (yes this is not an exaggeration) and aren't allowed to test code outside their building. We have other clients where we need to send them code and wait for a testing response when they can allocate the resources. The feedback loop becomes very slow and sometimes very minor code issues can cause significant deployment delays. The loss in revenue and general inability to find answers to key business questions in a timely manner cannot be underestimated.

Our background is in analytics and strategy, so we're usually dealing with Javascript files for tracking purposes, but the same issues occur with all asset based code updates. We want a simple means to test and deploy new code without making any on page changes or requiring testing in a staging environment. Maybe i'm lazy, but i don't want to test the same code twice! This initially sounds a bit ambitious, but it's actually pretty simple.

The solution ...

We use a single controlling file to include all other Javascript assets. The single file has the ability to switch between different Javascript file versions based on the existence of a cookie (created from a URL parameter when testing is required). This single file is also utilised to control the file version of the asset files without making any on page changes.

Advantages

1. No on-page changes are required for Javascript updates EVER
2. All updated files roll out instantly to everyone, there is no caching lag. Roll backs are just as easy.
3. Testing on the live site can be performed without ever affecting a single other user. Staging sites are not required.
4. Testing can be performed remotely (wherever the production site is accessible).
5. Risk of web site down time or customer irritation is greatly reduced.
6. Time to go live is significantly reduced.
7. Development costs are significantly reduced.
8. Javascript file names can include a version number, this greatly reduces confusion around version control.

Implementation

If you know Javascript and you're looking for an example, check out below. If you need more explanation, then drop us a line.

Email Hamish at hogilvy@datalicious.com if you need help with your implementation.

When running Windows IIS as your web server, you might find that the issue of upper and lower case URLs can very annoying and troublesome.

Windows is a case insensitive OS, meaning test.html and Test.html are actually physically the same file in Windows. However, in Google Analytics they will by default be recorded as two different pages if you don't do something about it. The following screenshot shows an example of the folder '/candidates/' and how it is tracked as two different folders simply because of the case sensitive issue.

It's very easy to fix the problem. All you need to do is to setup a filter in your Google Analytics profile to convert all the URLs into lower case or upper case. To do that, login to Google Analytics and click on Filter Manager, then add a filter as shown in the following screenshot. This filter will turn all URLs in Google Analytics to lowercase eliminating the duplication on the content and goal reports. Please note, this only works form the moment you create the filter and not in retrospect.

We recommend that all websites running on Windows IIS should have such a filter to avoid the problem caused by case sensitivity.

Another awesome article form Jakob Nielsen's Alertbox, especially the stats on how many decisions we make online vs. when watching TV which has serious implications for online advertising and website usability.

Today, of course, we're in the opposite scenario: everything we write competes with trillions of Web pages, all a few clicks away. As a result, most people actually read very few words on the Web.

The velocity of media consumption has increased dramatically. Readers no longer linger over lovingly described passages detailing a lord's style of dress. They click here, they click there, they click everywhere. But they don't stay.

People's consumption of print media is different than their use of websites, leading to the many differences in designing for print versus the Web.

Compared to TV, the Web also has a much finer granularity of user control:

When watching TV, you make one decision every 30–120 minutes: pick a show or movie to watch, and then it's lean-back time. Ah, easy.

When surfing the Web, you make a decision every 10–120 seconds: leave or stay on this page; leave or stay on this site. Where to click now? Where to click next? A bit stressful.

Adding up all these differences explains the fast pace of Web use: the velocity is much higher than we see for TV use.

Read the original Alertbox article here
http://www.useit.com/alertbox/media-velocity.html

Check out MultichannelMetrics's interactive flowchart if you're experiencing issues with a drop in traffic or conversion rates, it's a great starting point to figure out what to do.

Click on the below link to get to the interactive version of the chart

http://multichannelmetrics.com/WebAnalyticsQuestionSupportSystem/WebAnalyticsQSS.html

Below are some pretty basic tips to Site Catalyst setup, they may seem straight forward, but i am continually surprised at how poorly Omniture is set up, so maybe they're not so obvious!

1. Have one scode file
Duplicating the scode file is painful and you will eventually make mistakes. Keep all your code in one file.

2. Use a cachebuster
This will ensure your javascript code updates propagate quickly. Otherwise your existing users may not reflect the changes, which can complicate and confuse reporting. A cachebuster automatically adds a parameter to the end of the javascript file reference, which forces it to be reloaded. i.e. scode.js?cb=1234

3. Make it protocol independent
Don't put "http:" in your file reference, this will allow the javascript to work for either http or https. i.e src="//www.example.com/js/scode.js"

4. Use the s.pageName variable properly
This is by far the most important thing to set, i can't even stress that enough. Any extra effort to get it right is worth it. Your pageName should preferably follow a set structure so your javascript can utilise it fully. If you get this right, your reports will immediately become more powerful. We typically follow a structure like the following:
site:sub-section:sub-sub-section:sub-sub-sub-section

This should follow the site directory structure where possible. i.e. www.site.com/sub-section/sub-sub-section/sub-sub-sub-section

By breaking this up and putting it into several props and eVars, you will be able to look at success events at a site, sub section, sub sub section and sub sub sub section level, which is very useful. You will also be able to trigger certain events based on these values. Code example below, which should also be copied from props to eVars:

The output of the above will be:
s.prop1 = site
s.prop2 = site:sub-section
s.prop3 = site:sub-section:sub-sub-section
s.prop4 = site:sub-section:sub-sub-section:sub-sub-sub-section

5. Minimise the on page javascript
Any logic you can use to trigger events based on the pageName, the URL or section variables, will make things so much easier. If you can get code off the individual pages and keep all the logic in the scode file, you will greatly simplify any deployments and rollbacks. For some things you can't avoid putting code on individual pages, but it's suprising how often it can be avoided.

An example might be a segmentation rule that will label someone once they have stayed for at least 2 pages in a particular site section. For things like this, very small changes to the scode can be very powerful, if you paid attention to tip 1 above, they're also immediately site wide!

Many online businesses don't really need the complex capabilities of Omniture Site Catalyst, Google Analytics is good enough to meet their requirements, or almost good enough. Omniture's custom variables are very powerful, but i would think the average utilisation that i observe (when we're not setting it up!) is less than 10%, which is interesting considering the cost. I've experienced the frustration of Google Analytics limitations, but I can also appreciate that for free it is a pretty nice piece of software. Both have their rightful place, so I thought it would be appropriate to illustrate the differences you need to consider before deciding which to deploy.

One of the interesting features of Google Analytics is the custom variable, which can be set to any value and then later used for custom segmentation. The functionality of this variable is different to Omniture though and unlike with Omniture's variables, it is not configurable. The key difference is is the way the value sticks. With Google, although it can be changed during a session, the value associated with reports does not change for the rest of that session, so it can effectively only be one value per session. If it's changed again during that session, subsequent sessions will reflect this new value, but the current session will not. For some things this is ok, but for other applications it is quite frustrating.

Summary of key characteristics

Omniture Variables
- Can be related to pageviews (i.e. they don't have to stick). These are called props
- Can be related to success events, like purchases, registrations. These are called eVars
- Can change during the session (or not if you prefer, first or last setting can be configured)
- Can be made to expire
- Can be configured to be stacked (this stores a sequence of values)
- Many variables available, so you can customise lots of different things at the same time

Google Analytics Variable
- Cannot change during a session (can change between sessions)
- Can be stacked using javascript
- Has nice custom segmentation tools which are easy and instant, unlike Omniture ASI segments

Which to choose?

If you have the cash and the resources to use Site Catalyst properly, their custom variables are far beyond Google Analytics, the two aren't even close. If you also consider many variables are important to your business, then Google will probably not get you where you need to go. But if you just want standard usage information and possibly only require one variable to perform some basic segmentation, then Google Analytics is for you. You can also stack the custom variable, which will buy you a little extra capability, but it's pretty clunky. If you need some advice, drop Hamish a line at hogilvy@datalicious.com.

Adobe has announced the planned acquisition of Omniture, a leading web analytics software / solution provider. This is an interesting purchase for Adobe and a lot of analytics people out there will be wondering how this is going to change their landscape. Traditionally tracking flash has been a bit of a pain, you can bet that will change if this deal goes through. If it doesn't go through, Omniture will be paying $64 million for the privilege of withdrawing from the deal, but seeing as it's already progressed to a public announcement, you can probably bet it's going to go through.