Tales from the Click: Bounce Rate in Omniture SiteCatalyst

This is the horror story of a guy who tried to get the bounce rate metric in Omniture.

PS: No Omniture rep where injured during the making of this story.

Chapter 1: What’s the formula?

Bounce rate is kind of a standard web analytics metric, no? Well not for our friends at Omniture. First of all, you need to build the metric because it doesn’t come by default. I quickly found the formula in the help section:

[Single Access] / [Entry Pages]

Once my calculated metric “Bounce Rate” was built, I thought it was just a matter of selecting the metric in your reports, right? That would be too easy… :)

See, in SiteCatalyst, you cannot use traffic metrics with conversion variables. Since bounce rate is built from traffic metrics and your campaign codes are stored in a conversion variable, the bounce rate is not available in the campaign reports! Snap!

Chapter 2: New traffic variable!

Ok, I am not discouraged. If I need a traffic variable, traffic variable it will be.

The solution was to set an s.prop to the campaign tracking code in our JavaScript file. (In this particular implementation, the campaign code is pushed on every page and uses the GetValOnce plugin to send it only once to Omniture.)

Setting this s.prop would allow campaigns to show in traffic reports with their bounce rate. Everything was smooth running until I realized all campaign bounce rates were at 99%…  Damn it! What was going on?

After investigating the issue, I discovered that ‘Single Access’ in Omniture is not calculated on page view per se, but rather calculated on the value of the s.prop. Hence, let’s say

  1. you land on a page where s.pageName=”Search Results”
  2. you visit a second page where s.pageName=”Search Results”
  3. then you exit the site

Then looking at a page name report, this visit would be considered a bounce because it has never visited a page with a page name other than ‘Search Results’!

Now, since all page views of a visit had obviously the same campaign code (unless a visitor used 2 campaign codes during the same visit), all visits were considered ‘Single Access’! Crap!

Chapter 3: Google & Twitter to the rescue!

Back to the drawing board… Let’s hit Google and see what it has to say about it:

On the Omni Man Blog, I found an article explaining how to concatenate the page name with the campaign tracking code in an s.prop. This allows to enable pathing and see the bounce rate for specific campaigns.

This solution works and I especially like the ability to see bounce rate for a specific page/campaign combination. But it has one big caveat: there is no way to apply classification on your campaigns! So you’re stuck with bounce rates at the campaign code level; no way to see bounce rate for a channel or sub-channel for example which is a problem when you have hundreds of campaign codes. On top of that, campaign codes are not always self-descriptive… hence why classification is so handy!

Seeing myself in a dead-end, I post the following Tweet:

To my surprise (I’m not what you would call a Twitter power user) I quickly get two replies:

From @adamgreco:

And @OmnitureCare:

The first one referred to the article I had already found and the second one was another very recent article from the Omni Man Blog.

I soon discover that this second article explains how to fix the individual tracking code problem and see bounce rates at the traffic source & channel level. The solution involves setting an s.prop to the traffic source/channel on the first page visited, then setting the same s.prop to a dummy value such as ‘Did not bounce’. The goal is simply to have a different value on the second page so it’s not considered a ‘Single Access’. Quite clever actually. Great!

But I quickly spot another issue: the classification needs to be done on the fly by the JavaScript file. This can be done by looking at unique identifiers for each traffic sources (ex: ?afflD= for affiliates) . Problem is, I don’t have unique identifiers for all my channels. Bummer!

A second solution is proposed: use a DB Vista rule. But I don’t like DB Vista rules much. They cost money, are not super easy and quick to implement, and you lose a bit of transparency and control since only Omniture client care can bring changes to them. :(

Chapter 4: The path to illumination!

And this is when we found another solution! Drums rolling!

Inspired by the solution just above, we set an s.prop to “Did Not Bounce” on the second page of a visit. But instead of identifying the channel thought the Javascript file or though a DB Vista Rule, we set that s.prop to the campaign tracking code and use SAINT classification to identify the channels!

So it goes like this:

  1. Set the campaign tracking code to an s.prop
  2. Check the s.prop to see if it matches the s_campaign cookie value that gets set by the getValOnce plugin. If the two values match, set the s.prop to ’Did Not bounce’

Et voilà! Simple non?

Chapter 5: The path is illuminated, but I still need a flashlight

Now that I have bounce rate by channel, what about bounce rate for the entire site? For some kind of reason, the metric was not available under ‘My Calc Metrics’ top menu.  I’ll spare you the details and jump right to the conclusion: I found an article on Google that explains that the site bounce rate is actually another calculated metric formula!

[Total Single Access] / [Total Entries]

By selecting any traffic report, just add this metric and you will see the site bounce rate (which is weird, but c’est la vie)!

Final Thoughts

Bounce rate is just one of the many frustrations that come with SiteCatalyst (“sorry, you can only do this with Discover” anyone?). Simply put, Omniture SiteCatalyst feels like a cross between an 800 hundred pound gorilla and an 800 pounds sloth. It’s uber powerful but moves so slowly, it’s maddening.

Useless? Maybe not. But with Google Analytics constantly releasing new features, Omniture is doomed to stay isolated as a niche player only appropriate to companies with full dedicated web analytics teams composed of both analysts and programmers.

Avinash 10/90 rule has never seemed so relevant…

This entry was posted in web analytics and tagged . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

Post a Comment

Your email is never published nor shared. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>