Looking at Ease of Implementation Across Web Analytics Platforms

Picking and choosing an analytics solution is only half of the battle.  Getting it implemented can be a challenge as well as it probably requires a code release (push) to production to get the code in place.

Also, you probably have to loop in many different areas (marketing, IT, QA, usability, etc) for testing prior to going live which can, in some cases, slow down gaining valuable insight from the new/updated code.  Below is an explanation of each tool, how it can be implemented as well as some of the challenges faced.

Omniture SiteCatalyst

SiteCatalyst is the most used web analytics package on the market.  It seems like 8 out of every 10 clients I come across has SiteCatalyst on their site in one way shape or form.  SiteCatalyst leverages basic page code plus a reference javascript library file to track user interaction/pathing on the site.  To get SiteCatalyst code in place, you need to place the base page code on either each and every page you wish to track or within a global file that is referenced by each and every page (i.e. footer file).  Once you find which option works best for your setup, you will need to do some customization work to track granular interactions/events.  With Omniture SiteCatalyst, users have 50 traffic and commerce variables as well as 80 events at their disposal.  This is a nice to have when you are tagging/tracking a robust site and need to allocate specific variables to specific items/events.  SiteCatalyst also provides plugins or custom javascript code that can be placed within the reference javascript library file for additional tracking capabilities.  Please refer to the Plugins page for a small (not complete) list of plugins provided by Omniture.

Now onto the downside of SiteCatalyst.  The first is its robustness.  For many companies who have already used web analytics platforms before, having this won’t be an issue and is welcomed versus a free tool.  However, if this is your first foray into web analytics, SiteCatalyst might prove to be too much for you in the onset.  With Advanced Segmentation Insight (ASI slots), data warehouse, SAINT classifications, customizable variables and various variable allocations and designations (lifetime, participation, linear, etc.), this might overwhelm many.  Another downside to SiteCatalyst is code changes always require a code build (that is unless you have a CMS and have the code residing there). Changes to the reference javascript file can have an impact on overall tracking and must be QA-ed which slows down the time to release. Lastly, if you need to track multiple things on a page, you will need to add secondary calls and tracking code to the page which not only needs to go through QA but also raises the total cost for having and using the product.  In hard economic times, like we face currently, companies don’t want their cost to rise and are looking at all ways to cut cost.

Coremetrics

Coremetrics is similar to Omniture that it has page code and reference files that it leverages to track user behavior.  However, Coremetrics doesn’t provide the level of granularity tracking that Omniture SiteCatalyst has.  While this might not be good to many, this does make implementing and QA-ing Coremetrics easier than SiteCatalyst.  To begin, you will need to figure out which of the tracking functionalities you wish to use.  Please refer back to the previous blog posting entitled, Coremetrics Non Marketing Tags Explored, for a list of all the tags that can be used in Coremetrics.  Coremetrics doesn’t have any custom variables that you can populate which shortens the time to production process nor provides any plugins for additional tracking insight.

Coremetrics, comes with its downside as well which will be discussed.  The first of which is the required development steps.  During the development phase of implementation, four main tasks need to be accomplished:

  1. Data being passed to Coremetrics must be available on the specified pages.
  2. The three javascript reference library files provided by Coremetrics need to be included on each and every page.
  3. A Category Definition File will need to be created to map the category IDs sent in tags to a hierarchy.
  4. A Data Integrity Process File will need to be created for use in the Validation phase of the implementation.

** The complexity of each task will diagram how long each will take to complete.  With the other analytics packages, a category definition file (CDF) or data integrity process (DIP) file are not needed.

Another downfall is you need to include three javascript reference files for your implementation.  They are the eluminate.js, techprops.js and cmdatautils.js file.  If one or more is forgotten, tracking functions that create tags and populate values within those tags will not be available causing tracking not to work. Lastly, there isn’t much customization that can be done within Coremetrics.  You are kind of limited to their out of the box functionality and can’t layer on plugins like Omniture SiteCatalyst (that is unless you write and test it yourself).

Google Analytics

Google Analytics, the relative newcomer on the block, is one of the easiest web analytics packages to implement.  You generate the code, place within your page (if you are using asynchronous tracking, referenced in the blog posting entitled: Asynchronous Tracking in Google Analytics, then you can place the code anywhere on the page.  If you are using the older version, it must be placed within the footer file) and start tracking.  Google Analytics also provides custom variable tracking via the _setCustomVar function (please see Tracking Custom Functionality via Custom Variable in Google Analytics for more information). With little to do, it makes this one of the easiest to pick up and run with.

The downside to Google Analytics is that you really need to understand their tracking API to leverage all the functionality afforded by the tool.  Without this knowledge, you are stuck dealing with the out of the box tracking that Google provides which is good but not great.

Convertro

Convertro, a tool that I just began testing and blogging about, is another easy to implement tool that provides great out of the box tracking functionality.  With two simple blocks of code needed to be placed within a global file, implementing is pretty straight forward.  Adding additional tracking functionality (i.e. tracking conversion or success events) is also a snap with Convertro.  The company provides you with a deployment guide that list the necessary steps and the necessary code to cut and paste onto your page.  No need to tweak or fix as they do all the heavy lifting for you.  Plus, they provide implementation hours when you sign up so that if you do run into any unforeseen issues, they will be ready to assist.

The downside, and I have only be able to find one so far, is that they have two blocks of code that need to be implemented on each and every page versus one.  The first block, which goes into the head, is easy to house within the header file.  However, the body block of code that needs to be at the top of the <body> tag, might be a little more challenging to implement across all pages.  I think if they figure out a way to combine these into one or just have a reference file that resides on their server that handles both head and body tags, that this tool will put itself head and shoulders above the competition in ease of implementation.



Written by: Dorian D. Regester

Analytics, Convertro, Coremetrics, Google, Omniture, SiteCatalyst, Web Analytics

If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.

Comments

3 Responses to “Looking at Ease of Implementation Across Web Analytics Platforms”

Leave Comment

(required)

(required)