Slipping Google Analytics into your SiteCatalyst implementation: Part 3


Slipping Google Analytics into your SiteCatalyst implementation: Part 3

Editor’s note: This is the third part in a three-part series exploring SiteCatalyst and Google Analytics. Brian Katz, Senior Web Analyst and resident SiteCatalyst and Google Analytics expert at Cardinal Path, is guest writer for this series.

So far, we’ve compared the ultimate “free” web analytics tool, Google Analytics, with its ultimate paid counterpart, Adobe Omniture’s SiteCatalyst, in conceptual and specific ways.

Now we’re going to talk about how to slip Google Analytics code snippets into a well-implemented SiteCatalyst.

Part 3 of this series describes a scenario and a challenge and provides a code snippet that some might consider controversial. We look forward to your feedback regarding the snippet.

The Challenge

This challenge is often encountered by companies that have a wide range of users in terms of needs and web analytics experience. They have SiteCatalyst, but many users or a few highly placed users who want Google Analytics. This may arise out of an increased investment in AdWords or new hires with GA experience.

The request for the addition of GA often comes with little budget and expectations of perfect data. That perfection also includes the expectation that the numbers be the same in Google Analytics as in SiteCatalyst.

No problem!

Except the last expectation is unrealistic—a person with two watches is likely to have two readings to choose from, particularly if the watches use different methods of time keeping. Each web analytics tool tracks and reports in its own way, so no two tools will, nor should, give you the same results. It’s a little like the credibility of two witnesses giving precisely the evidence about complex events.

But there are some technical solutions to budgetary, time and head-space constraints.

The Retrofit

Retrofitting relies on piggy-backing Google Analytics code on an existing SiteCatalyst implementation.

If your site and its SC implementation are well structured, meaning all pages are generated using a few, well managed templates, then adding any other tool is straightforward—the GA code is added to the same templates. (If you’re trying to track the same aspects in GA as you’re tracking in SC, that is more of a translation project, which is discussed in the next part in this series.)

One of the requirements of a satisfactory SC implementation is a single s_code.js file (or, if there have to be multiple files, a well coordinated set of s_code files).

The GA retrofit we’re proposing will be required to report the following:

  1. Page Views with the same pages names as in SC
  2. All Custom Events
  3. File Downloads
  4. External Links (clicks on links to other sites)
  5. Form Analysis Events

Conspicuous by its absence is the reporting of variables. That requires some headspace and will be dealt with in Part 4 of this series.

SiteCatalyst plug-ins

SiteCatalyst provides JavaScript methods or functions called plug-ins to perform various tasks. For example, s.setupFormAnalysis and its s.fa* siblings track the use of forms and form fields, s.getQueryParam() gets query string parameter values and s.getValOnce() helps ensure that only new or changed values are assigned to variables.

I want to make special mention of a really neat piece of JavaScript coding that allows s.c_rr and s.c_wr to use “retrofit” cookie-combining functionality into existing SC implementation. The technique of overriding SiteCatalyst methods will be used in our solutions.

Code snippit

If one is to retrofit, one has to rely on SC as the “host” application to do all the grunt work and execute all the logic. That means we need to grab data as and when it is being reported by SC, and then report it to GA.

The more intrusive we can be, the easier and more reliable will be our solution. But how much intrusion can SC, or our developers, handle? At the end of the day, we are not going to present an unreliable solution, but any solution must involve some measure of inclusion of GA coding in s_code.js.

Here is a snippet of code to get people thinking and talking about the issues. In Part 3.2 (coming soon!) we will provide the full solution.

/* *****
* Extension of s.t
* In order to ensure that the s.sendGA plugin is invoked whenever SC sends page data, 
* we need to extend s.t() to call s.sendGA.
* This technique is used by Omniture in their cookie combining plugin.
***** */
s.t_orig = s.t;
s.t = function (vo, id) {
    var s_code = s.t_orig(vo, id);
    return s_code;

* Plugin: sendGA
* Google Analytics Plugin for SC
* Be careful about calling s.sendGA() from s_doPlugins(s)
s.sendGA = function (s_pageName) { 

    _gaq.push(    ['_setAccount', 'UA-######-#'],
                ['_setDomainName', s.c_gd()] );

    s_pageName = s_pageName || s.pageName;
    if (!s_pageName) {
        var dl = document.location;
        s_pageName = dl.pathname + + dl.hash;
    _gaq.push(['_trackPageview', s_pageName]);

The series

Comments are closed on this post