OMS Analytics

With the release of Sitecore 6.1 and OMS last week, I can finally write about it! I was lucky enough a few months ago to be invited to a sneak peak session for Sitecore's new product the Online Marketing Suite (OMS), previously called "Everest" (Everest was actually the title given to Sitecore 6.1 and OMS 1.0). OMS is built on top of Sitecore 6.1 and provides more advanced marketing capabilities, but these capabilities rely on specific new features in Sitecore 6.1.

There were a few new features that really stuck in my mind from the presentation and I'll discuss one of those now; analytics.

Analytics? But we've been doing analytics for ages using a variety of commercial and free products. What could Sitecore really do so great in the area of analytics?

It all comes down to how the analytics data is interpreted to determine what is going on on the website. Generally analytics products come in two major varieties and can be categorised by the technique they use to collect the page hits. These categories are the javascript ones and the log parser ones. Both of these techniques have certain advantages and disadvantages. Sitecore analytics in OMS covers the pitfalls of both of these previous analytics techniques.

Let's look at javascript type analytics products. The most commonly used of these would probably be Google Analytics (based on what I've seen). The issue with javascript products is they can't collect data if the user disables javascript in their browser. And there's no fallback either. Also, usually to improve page load times and promote SEO, developers will place the javascript code required to make the analytics work at the bottom of the page. If the user is quick enough they are likely to navigate to a different page before the current page is finished loading (javascript and CSS are usually loaded sequentially by a single thread in the browser) and the code doesn't have a chance to run and hence the analytics data is not collected.

And IE 8 provides more issues with javascript type products. IE 8 comes with a new "private browsing" feature to enhance the security and anonymity of internet users. This feature called "InPrivate blocking filter" (or so I'm told) is turned on by default and will block third party content on a website, meaning it won't even load the google analytics javascript code. This will effectively make default IE 8 users invisible to these types of analytics products. IE 8 isn't the only web browser that contributes to this issue. There are various Firefox plugins to enhance security and will do the same thing.

The other major type of analytics product are those based on log parsing such as Web Trends. These kinds of products parse your web servers request log and present the data to you. These kinds of products will always record data for every request made to the server. And another benefit is that they don't require any code changes to the website, and can be implemented and changed completely independently of the website.

So that would make log parser products better than javascript right? Well, it depends on what data you're interested in. Google analytics for example offers a very rich collection of data about the user, their browser, screen resolution, operating system, etc. With log parsers you're limited to the data the web server logs. Much of the extended data I mention above is not even available to the web server.

Both major categories of analytics product suffer from a lack of understanding how ASP.NET works. In ASP.NET a user will make a request for a page with their browser issuing an HTTP GET request to the server. If that web page contains form controls such as buttons and these buttons use postbacks (the default behavior of Button controls in ASP.NET) then the browser will issue an HTTP POST request to send the data to the server. And for each postback control (button, droplist, linkbutton, etc) that is used on that form the same will happen; an additional request. So even though I'm just interacting with the same page, analytics products that don't understand ASP.NET will see this essentially single request as multiple requests and the data is now skewed. Keep in mind that most analytics products are not built for ASP.NET. They are built to be generic and usable on any technology.

Potentially another issue may be to do with content reuse. Sitecore provides a few mechanisms for having the same piece of content appear in multiple locations of the website. The analytics product types above are generally just URL based. Being that they are generic and don't know what if any CMS is being used they will see each URL as being a unique asset on the server. If we were to bring the analytics into the CMS then these statistics can be collated properly against the CMS assets where a single asset may be known by many URLs.

Given the above issues it's plain to see that the analytics provided in OMS are going to be much more accurate and tell you much more about the web site visitor. I'd never really given a great deal of thought to how Google Analytics works and how it's data is going to be skewed in comparison to something built directly into the CMS.