A Quick Explanation of Sitecatalyst Events for the Google Analytics Power User

This post is one half of a 2-post series of which, most likely, you are looking for only one of the two posts!

Here’s the guide:

If you are well-versed in Google Analytics and are trying to wrap your head around Adobe Omniture (Adobiture) Sitecatalyst “events,” read on! This is the post for you!

“If you are well-versed in Sitecatalyst and are trying to wrap your head around Google Analytics “events,” then this sister post is probably a better read.

If you’re looking for information about Coremetrics or Webtrends…well, you’re SOL. If you’re looking for a great flour tortilla recipe, then my limited SEO work on this blog has run so far amok that I’ll just thank my lucky stars that I’m an analytics guy rather than a search guy (but, hey, here’s a great recipe, anyway).

Why “Events” Seem Similar in Google Analytics and Sitecatalyst

At a basic/surface/misleading level, events in Google Analytics and Sitecatalyst are similar. In both cases, they’re something that are triggered by a user action on the site that then sends a special type of call to the web analytics tool:

Alas! The similarity ends there! But, since no one learns multiple tools simultaneously, this surface similarity causes confusion when crossing between tools. Hopefully, these posts will help a person or two overcome that messiness.

Google Analytics Events — Conceptually

Let’s just start by making sure we’re on the same page when it comes to Google Analytics events. In a nutshell, they’re just a handy way to record user actions that don’t get picked up by the base page tag and that don’t get recorded as page views, right? They’re useful for recording outbound link clicks, activities within Flash or DHTML content that don’t warrant the full “page view” treatment (and, hopefully, you have a standard and consistent approach for determining when to use an “event” and when to use a “virtual page view”). Those are Google Analytics events at their most basic level, right? Okay. Cool. Let’s continue.

Sitecatalyst Events — Different in Concept from Google Analytics Events

In Sitecatalyst, events are much more conceptually similar to Google Analytics goals than they are to Google Analytics events (except, of course, when it comes to their name!). In olden times (web analytics olden times, that is), so I hear, Sitecatalyst events were actually called “KPIs” — a nod to the fact that many of the best KPIs are about what visitors do on a site, rather than simply being related to the fact that they arrived on the site in the first place.

So, a key point:

Sitecatalyst “events” really are more like Google Analytics “goals” than they are like Google Analytics “events.”

Sitecatalyst Events — Different in Implementation from Google Analytics Events

If we can agree that Sitecatalyst events are really more like Google Analytics goals than they are like Google Analytics events, then it’s worth pointing out that Sitecatalyst events are primarily set/captured/identified client-side (on a page), while Google Analytics goals are primarily configured/set on the back end by a Google Analytics admin user.

Google Analytics goals are typically established by specifying a specific visitor activity or behavior (or set of behaviors) using already-being-captured data (page title, page URL, time on site, number of pages viewed, or, as of v5, triggering of a specific event category/action/label/value) as a “goal” within a profile. Once the goal is defined, you can track the number of visitors who complete that goal, the conversion rate, and a conversion funnel. And, you can do this (funnels excepted…unless you’re prepared to get fancy pants about it) by visitor segment. In short:

Google Analytics goals are primarily configured on the back end.

Now, you may occasionally do some tweaking on the client (page) side of things in order to enable you to set up the goals, but I’m not going to digress on that point (leave a comment if you’d like me to elaborate and I will).

With Sitecatalyst events, the main work occurs on the client side of things. You establish what activities/occurrences warrant “event” status, and then you make sure your site is configured so that the appropriate event(s) gets recorded any time that activity occurs. Typically,the event occurs at the same time — and in the same Sitecatalyst page tag call — that a view of a page (the pageName) and various other data gets passed to Sitecatalyst. For instance, when a visitor completes a site registration, the Sitecatalyst page tag will likely need to record the traffic to the confirmation page (via pageName and additional sProps) as well as the “event” of a registration being completed. This event (or “completion of a goal”) will be recorded as “event=eventx” in the page tag call. To make use of “eventx” (event1, event2, etc.) requires some backend configuration (including whether the event is serialized or not…but that’s another digression I will avoid). But, for the most part:

Unlike Google Analytics goals, Sitecatalyst events are primarily set up client-side — via values in the “event” variable recorded by the Sitecatalyst page tag.

With Google Analytics goals, it is handy to use segments — standard or advanced — to explore how different subsets of visitors behave. For instance, how do visitors who viewed product details tend to convert to an order as opposed to visitors that do not? Do visitors that entered the site via organic search reach product details pages at a higher rate than visitors who arrived as direct traffic? You get the idea.

Excepting the segmentation capabilities of the lugubriously rolling out v15, as well as the capabilities of Discover, Sitecatalyst relies largely on eVars to do this sort of exploration. With scads of available eVars to work with, and with the appropriate use of subrelations (allowing the cross-tabulation of eVars), it’s largely a matter of solid up-front thinking and planning, combined with a willingness (and ability) to make site-side adjustments over time, to get at “segmented conversions” using Sitecatalyst.

eVars are both a blessing and a curse when viewed through a Google Analytics lens. They’re a blessing because they allow much more detailed and sophisticated capture and analysis of conversion data. They’re a curse because they require much more site-side planning and implementation work!

Does This Help?

Describing this distinction in a clarifying manner is tricky — it’s quite confusing and frustrating…until it makes sense, at which point it’s hard to identify exactly what made it so confusing in the first place!

If you’ve gone through (or are going through) the process of adding Sitecatalyst to your toolset after being deeply immersed in Google Analytics, please leave a comment as to how you overcame the “events” hurdle. With luck, others will benefit!

I’m not sure I understand the distinction you are making. In GA, you get to set the Category, Action, and a Label with each event you set. Wouldn’t these labels (or setting a GA custom variable at the same time) be analogous to setting an eVar in Omniture every time you fire an event?

I’ve never used Goals in GA (another thing for me to learn!), but it seems like goals are analogous to calculated metrics in Omniture, except less flexible.

@Randy Well, keep in mind that the standard example that GA documentation always uses with events is tracking video viewing — basically, “tracking user *actions* or *experiences* that wouldn’t otherwise be tracked.” That doesn’t mean that they can’t be used for much more (even more so since they became available to be used as goals).

I’m trying to think through the “GA event categories/actions/labels” analogous to an Omniture “simultaneous eVar and event”…and…yeah, I think that’s valid. With a GA event, the category/action/label are all available as dimensions in a report, while your metrics will be limited to clicks and unique clicks. In the eVar + event scenario, the eVar setting would define your dimension, and the event would be establishing the metric(s) available.

Goals in GA definitely fall under the eVar/event paradigm (and calculated metrics being available as part of that). “Flexibility” is a matter of perspective. Without re-opening the can of worms I covered in a separate post, Omniture has more flexibility IF you have access to update the page code or tag management(which eVars are set and which events fire when) AND you have admin access to Sitecatalyst to set up eVars and events (including configuring serialized or not) and enable metrics on specific reports. GA has more flexibility if you’re limited to backend configuration (admin access is needed to configure goals and funnels, but advanced segments allow quite a bit of slicing of goals).

I think what tripped me up from the original post is that I do think in the Omniture way, so I’ve used GA events just like Omniture events.

For example, I’m currently in the process of creating an engagement metric on my blog. What I’ve been doing is setting a GA event on every action I want to track (clicking on Twitter button, clicking on Read More link, Related Post link, etc.). But to make your head hurt even more, I set a GA event every time someone VIEWS my About page. So there, it’s not even a JavaScript action like onClick, just a page load.

So I’m using a GA event like setting a prop in Omniture! Or, like an event and eVar with a single page expiration…

Interesting. Obviously, I don’t know the full details, but rather than firing an event when someone hits the About page, you can simply set viewing the About page as a goal — no updates to the site required at all. Presumably, the page has a unique URL (or URL pattern), and that could be set as a goal. Even using the event-firing method, you may still want to set that event (or a group of events) as a goal for the site, which will give you easy access to total conversions and conversion rate (…although I’m starting to see where your “calculated metric” comment comes into play — in GA, you’ll get a conversion rate for each goal that you establish that is calculated as: unique goal completions / total visits to the site; in Omniture, you might do a calculated metric to get to the same thing, right?).