So what's the big deal?
I continually get to look inside the Site Catalyst implementations of various companies as they struggle to extract value from the product. Those implementations are usually done in such a way that future upgrades are extremely painful and time consuming, if not virtually impossible. Javascript page tagging is messy, but you can make it much cleaner by following the tips below.

Standard Practice and why you can do much better
Most web sites have a block of Omniture variables declared in the page code. For example, somewhere in the body, you may see something like:

s.pageName="site:some page";
s.prop12="calculator";
s.eVar14="widgets";
s.events="event2";

Lets say that prop12 is looking at tool usage and eVar14 is looking at product category affinity. The above will work fine, the variables will be populated in the scode and sent with the request as expected. But what happens when a developer comes back in 2 years time and wants to switch the usage of eVar14 or prop12? The variables are hard-coded everywhere, they appear in lots of templates, a few microsites, and are straight hard-coded on some custom pages, it's a complete nightmare.

The Solution
Call the variables something meaningful to you instead, don't use the Omniture naming convention in your HTML, this makes future changes very messy. Once you have your own variable names you can then transfer the information to the relevant site catalyst variables in the scode file.

Useful naming convention has several benefits:
1. It makes sense to the developer and hence they are less likely to screw it up
2. If you later want to make a change, that's fine, you simply make one change in the scode file and all the old usage will cease immediately as the new usage takes it's place. Switching a variable for your whole site/s can be done in minutes.

Example:
On page:
s.pageName="site:some page";
scToolUsage="calculator";
scCatAffinity="widgets";

In the scode, inside the s_doPlugins(s) function:
s.prop12=scToolUsage;
s.eVar14=scCatAffinity;

In the scode, outside the s_doPlugins(s) function (this makes sure the variables are declared in case they are not declared on the page):
scToolUsage="";
scCatAffinity="";

What about events?
Many events are page related (i.e. a registration event is triggered on the registration confirmation page). So why declare it on page in the variable section? You may want to change it later. Again this is something that can be easily dealt with in your scode file. If you use good s.pageName notation, you can trigger events specifically when certain pages are loaded. Below is an example using the s.apl plugin to append event2 to the s.events variable whenever the pageName contains "registration-thank-you". If you later decide to change the usage of event2 you can once again make a single change in the scode file and you're done, you don't have to worry about searching for code across your site/s.

Example code inside the s_doPlugins(s) function:
var scRegistration=new RegExp("registration-thank-you");
    if (scRegistration.test(s.pageName)) {
        s.events=s.apl(s.events,'event2',',',1);
    };

In short, centralise all the code maintenance you can in your scode file, this makes your developers jobs easier and also provides the freedom and flexibility to make changes quickly moving forward. Secondly, the pageName variable should be your one constant on-page declaration, use it wisely and it can be very powerful. For more tips on s.pageName convention best practice, see our earlier blog post on top 5 tips for deploying Omniture SiteCatalyst. For more information on Site Catalyst deployments, drop me a line at hogilvy@datalicious.com

Loading mentions Retweet

Update: Datalicious now Atomic Lab Pion reseller and integration partner for Australia.

Is implementing and updating Omniture page tags an issue for you? Atomic Labs's Pion Reactors provides a solution to process your website and campaign data server side and then insert it via the Omniture API. They also currently support sending data to Google Analytics and Unica.

In contrast to using a central JavaScript file to dynamically populate the Omniture variables based on page URLs, the Atomic Labs software taps into the network traffic stream and can then use any text within the transmitted data to create/modify additional variables and events via processing rules. At the same time you can also enrich your visitors click stream data from the website with profiling information from your CRM database using simple SQL queries and all in real-time, a great first step towards single customer view.

Why would you want to implement this?

1. Bypass your developers, staging, testing, etc. Increase your speed to new insights
2. Deploy new analytics without risking errors on your web site
3. Hide your tracking data from prying eyes
4. Modify your CRM in real time. Create targeting algorithms to better serve your customer as well as lead queues for call center staff, all on the fly.
5. Enrich your analytics with data you would not allow in javascript, such as "profit on a sale transaction".
6. You won't lose data because of analytics request delays

Check out the Atomic Labs website below or email Hamish at hogilvy@datalicious.com for more information and implementation help.

http://www.atomiclabs.com/

Loading mentions Retweet

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.

Loading mentions Retweet

All right, we've been posting for a while now and hope you like our view of the data world out there but now it's time for a little self-promotion (nevertheless interesting we think). 

Have a look at the below case study outlining the Omniture implementation we did for Vodafone Australia over the past few months (we're rather proud of it) and how it enabled the company to extract some serious ROI from its web analytics platform.

“I’ve been working with SiteCatalyst for over six years, 3 years as a customer and 3 years as an employee, consulting to some of our largest customers around the world. The current Vodafone implementation of SiteCatalyst is one of the most impressive I have seen and ranks in the top 10 from my perspective. It is an amazing foundation for taking action on the data and improving online return on investment.” Adam Greco, Team Lead Business Consulting at Omniture.

(download)

Click here to download:

200909 Vodafone Omniture Case Study.pdf (1470 KB)

Loading mentions Retweet

Google is slowly but surely leveling the playing field with its latest release and has made significant headway in the three key areas in which Omniture provides much more flexibility than Google Analytics (i.e. custom variables, custom goals, data export).

New Google Analytics features include

• Engagement goals (time on site, pages per visit, see video below); can also be enabled in Omniture but not as easily (i.e. needs custom code) but you have up to 60 custom events
• 5 custom variables (was only one before); there's up to 50 custom variables in Omniture so the key question is how many do you need (probably more than 5)?
• Mobile reporting including iPhone and Android apps; Omniture has offered this for a while in different forms with and without JavaScript but the Google options sounds a little easier
• Advanced analytics and report filtering options (see videos below); Omniture certainly offers something similar with its Discover product but it's 'slightly' more expensive
• Easy report sharing between users via unique URL; Omniture just rolled out the same functionality a few months ago
• Automatic alerts if your data changes significantly (very cool, see video below)); that I haven't seen from Omniture, alerts still need to be set-up manually by the user

All in all a pretty impressive release, thanks Google! Especially cool are the automatic email alerts that need no manual user set-up.

However, even though the Google Analytics platform has improved significantly and now even features a data extraction API it's still impossible to extract data on an individual user level which is crucial if you want to import website behavioral data into your CRM platform for example (to improve your cross and up-sell using website data). Drop us a line if you want to know more.

Read the official Google Analytics blog article here
http://analytics.blogspot.com/2009/10/google-analytics-now-more-powerful.html

Loading mentions Retweet

In reports where there are many unique & distinct values, it can sometimes be quite hard to analyse and extract usable insights out of it due to clutter. In such instances, grouping & classifying the data into major and easily understood categories is all it needs to take the analysis to the next level. For instance, the raw data on natural search/pay-per-click keyword report in telecommunications vertical makes more sense when viewed through the lens of holistic categories such as plans, prepaid, broadband and many more.

In Omniture SiteCatalyst, SAINT Classifications is one means to accomplish this. SAINT Classifications enable you to classify any custom variables (ie. Traffic or Conversion variables) into any numbers of categories and sub-categories that you have pre-defined.

In this example, we will SAINT classify natural search keywords.

Step #1:

Extract the data from the custom variable report. In this case, the natural search keywords in one of the custom conversion variables (ie. eVar).

Step #2:

Here we want to break it down by 2 levels: Keyword Type (ie. Brand or Generic) and Keyword Category (ie. Prepaid, Plans, Broadband, Mobile, Handsets, Content, Service, etc).

Step #3:

Set up the classifications in SiteCatalyst by following these steps:

Select the report suites of interest.

Then add the classifications and sub-classifications that you have pre-determined.

Step #4:

Download the template for the SAINT Classifications.

Step #5:

Populate the template with the categorisation that we have come up with in Step #3. After completion, save the file as Tab Delimited file.

Step #6:

Upload the Tab delimited file back into SiteCatalyst .

Step #7:

Now the data can be broken down into the categories that we have created earlier.

The implication for this is significant. Simply by doing this you can see that handset-related queries generate the most conversions for the site. You can also see that Prepaid products generate more orders compared to Plans products. Knowing this, you can ask questions such as “Is the website optimized for Plans-related queries to boost up its performance?” to further the success of the website.

You could also further breakdown the Keyword Category report by Keyword Type. Doing this, you can see for each of the major product categories, what is the order contribution of the generic terms? (Obviously the brand terms converted much higher). Is the generic term contributions for each category increasing or decreasing over the long term? If decreasing, perhaps more optimisation effort should be undertaken for the site. 

For more detailed reference, view .

If you are interested in web data analytics and its implication on actionable insights for immediate wins, shoot us a quick email at insights@datalicious.com. Alternatively, drop us a comment below!

Loading mentions Retweet

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!

Loading mentions Retweet

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.

Loading mentions Retweet

If you haven't read part 1, you should probably start there! http://blog.datalicious.com/call-center-tracking-using-omniture-site-cata

Where to begin setting this up? As with all analytics and tracking, there are many ways to approach the problem, but below is our preferred solution as it fits so easily with the existing online architecture. If call centre staff are indeed able to use a modified version of the online store, the steps below will slash wasted time, improve call to sale conversion as well as bring your phone and online tracking together into a single reporting view.

Step 1 - The basic link
Configure your call center software such that an answered phone call will trigger the opening of a URL. To avoid opening lots of new windows, you should give the window a name, if the name is the same, each call will trigger in the same window.

Step 2 - Where the magic happens
Call center software has access to lots of information, the number dialed, the callers number, who answered the call, the time the user has waited in the queue, any menu selections, the calls unique ID, etc. There is no limit to what is available. You need to look at all the information and decide what is relevant (both for tracking and sales optimisation). Once you've decided what is relevant, you need to pass this information in the URL triggered when a call is answered. Example below:

http://callcentre.example.com/redirect.php?cc=yes&caller=5551231234&dialed=1800123123&id=1234567890&queue=350&agent=samsmith

Step 3 - Now what?
So you've completed the most important step, you've passed all the key information seamlessly between two previously independent systems. Now it's time to use it. The redirect.php is a script written to deal with the information passed. This is not only for capture in Site Catalyst, but also for directing the Agent straight to the right product or content to save time. This happens effectively instantaneously.

Examples:
- Take the sales agent straight to the product page associated with the number dialed.
- Apply appropriate discounts based on known customer information
- Populate fields with customer information to save time

Step 4 - What about the tracking?
The redirect script will send the agent to the appropriate page with all the appropriate site catalyst data as URL parameters. You can then use the getQueryParam plugin to extract these parameters and direct them into the correct Site Catalyst variables.

Typically an Agent will sit on their computer all day, that's no good as the one session will stay alive. To start a new one in Omniture for each call, set the visitor ID to be equal to the unique ID of the call. This will ensure each call appears as a visit in your reports. Usually you would put this ID into an eVar as well, so you can use classifications to import additional data later.

To differentiate call centre traffic to the online traffic, set an eVar and persist it (you must have the get and persist plugin installed), this will allow you to break out call centre traffic with a vista rule later if required. All your Agents traffic will be marked.

Some information you'll want in eVars: Typically i would put the Agents name, the number dialed and any customer ID as a first start. Products, Events on the modified call center interface should follow the logic of online where possible, so they can be easily compared, ie checkout, order, registration, etc.

Before you know it, you'll have some very rich information on your call center. This is only the beginning though, some more advanced segmentation and targeting techniques will be discussed in part 3, along with data imports to close the information loop.

Loading mentions Retweet