One question I hear from time to time from Omniture SiteCatalyst users is:  “What are the paths visitors take on my site when they are successful in reaching one of my desired Success Events?”  Basically, on most websites, there are a few ideal paths that you wish all visitors would take.  Unfortunately, most visitors don’t adhere to your ideal path so you need to see what paths they are choosing to take.  Of course, you can use Pathing reports to see all of the paths that visitors are taking, but that can be very cluttered and hide what is really happening related to Success Events.  Therefore, one interesting analysis you can do is to focus only on paths that do lead to success.  I equate this to the old “cow path” story where architects would wait to create sidewalks in front of new buildings to see where people naturally walked and then build the sidewalks where people are already going.  In this post I will show you how you can do this in SiteCatalyst.

But I Don’t Have Discover or Insight?
When I raise this topic, the first thing people say is that they can’t do this because they don’t have Omniture Discover or Omniture Insight.  While those products are great and I highly recommend them, the good news here is that you don’t need those tools to see the paths that lead to success.  In fact, due to a current Discover limitation (more info on this later on), you cannot do this analysis in Discover, but you can do it easily in Omniture Insight.  The one thing you will need to perform this analysis, however, is Advanced Segment Insight (ASI).

So How Do I Do It?
The key to this solution is the Full Paths report in SiteCatalyst.  Normally, this report is a tad boring since there are so many unique paths on a site that beyond ENTER>>HOME PAGE>>EXIT, the rest of the percentages are usually pretty slim (i.e. .1% of all paths).  However, if you could look at this report for a small subset of your website audience, the percentages should go up dramatically.  This can be done with ASI, where you create an entire new data set for a specific segment.  Once you have created your segment and run your ASI slot, you have access to all SiteCatalyst reports, including the Full Paths report.  Hence, all you need to do is to properly identify a segment containing a Success Event, run your ASI slot and then look at the Full Paths report.

The way I start this is by identifying the Success Event that I care about.  Let’s say that you want to see a segment of “Purchasers.”  In this case the only Visits you want to include in the segment are those that have completed an Order within the Visit (feel free to review Segmentation  in my old post):

Once you have created this segment, you now create an ASI slot for, say, 30 days of data (amount of days is up to you).  When the ASI slot has completed processing, you can open the Full Paths report and see which paths are the most popular and include an Order:

I have found it fascinating to extract these paths and look for common trends.  It is often like finding needles in a haystack!  The best part, is that after you have learned what you want to learn, you can delete the ASI slot and re-create it for a different segment.  Here are a few examples you can create:

• View all paths that led to an Order, but only when the visitor was a first time visitor
• View all paths that led to an Order, but only when the visitor was a return visitor
• View all paths that led to an Order that was greater than $100
• View all paths that used a Product Finder and led to an Order
• Etc…

Just remember the formula.  Create segment, run ASI, look at Full Paths (Repeat).  The possibilities are only limited by your imagination.  I usually look at the top five paths for a bunch of different segments and then compare them to see what is common between them.

As I mentioned earlier, it would be much easier to do this analysis in Discover (where segmentation is instantaneous), but currently, there is no Full Paths report in Discover (see my idea suggestion and feel free to vote for it!).  I hope that gets into the product since then you wouldn’t have to wait a few days each time for the ASI slots to process.

What About Failure?
But wait…there’s more!  As Avinash Kaushik likes to say, one of the cool things about the web is that you can fail faster (and learn)!  Therefore, you shouldn’t just look at success, but you should also look at failure.  Why not create an ASI slot for visits where people did NOT succeed (create an Order in this case)?  Find out where people are most often taking wrong turns and maybe you can correct them.  Remember, when you perform normal Pathing analysis, you are seeing the good paths mixed with the bad paths, but with this solution, you can easily segment them out and analyze each separately.  Here is a sample segment definition you can use (notice “Exclude” – opposite of the first segment):

Well…there you have it, a quick and dirty way to see which paths lead to success (or failure).  Enjoy!

Adam Greco is the Director of Web Analytics at Salesforce.com.  You can read his previous Inside Omniture SiteCatalyst blog at http://blogs.omniture.com/author/agreco/ and can follow him on Twitter at http://twitter.com/adamgreco.  Please send questions and comments to adam@the-omni-man.com.

Please note: I am no longer an employee of Omniture and the content/views expressed here are my own and not those of Omniture.

Lifetime Metrics in Omniture SiteCatalyst are one of the most obscure and least utilized features in the entire product – and for good reason.  In their current implementation, they do not do all that much.  In this post I will explain what they are, how they are meant to be used and offer some suggestions on how Omniture can turn Lifetime Metrics into a more useful feature.

What Are Lifetime Metrics?
Before reading this post, I would hazard a guess that the majority of you reading this have never used Lifetime Metrics and that a good number of you haven’t even heard of them (at least based upon my experience when I was with Omniture Consulting!).  Most people who hear about them assume that they are metrics that are stored for website visitors for their entire lifetime (or until their cookie is deleted).  Unfortunately, that is not correct, as Lifetime Metrics have nothing to do with unique visitors or cookies…  When Omniture calls these “Lifetime Metrics” they mean the lifetime of the report suite (data set) in which the metrics reside.  For example, if you have a website Success Event for Form Completions, you use a regular Success Event to see how many Form Completions take place each day, week, month, etc…, but you would use the Lifetime Metric version of that Success Event to see the total number of Form Completions that have taken place since they were ever collected in the report suite.

So let’s say that in your main report suite, you started collecting Form Completions about a year ago and were segmenting those Form Completions by Traffic Source.  In the current month, you had 27 Form Completions driven by SEO, but going back until you started collecting Form Completions in the report suite, you had a total of 964.  In this situation, you would click the “Add Metrics” link and when you see the metrics selector window, you would use the drop down box (same place you go to use Participation or Calculated Metrics) and change “Standard” to “Lifetime” as shown here:

Once you have selected “Lifetime,” you should see a list of metrics that looks similar to what you would see under “Standard,” identical to what but with the word “Lifetime” in front of each (if you don’t see these metrics, talk to your Account Manager or ClientCare).  Simply select the appropriate Lifetime metric you desire (Lifetime Form Completes in this example) as you would any other metric and you would see a report like this:

As you can see here, the metrics for standard Form Completes is very different than the Lifetime Form Complete metric.  Again, this Lifetime metric has nothing to do with Cookies, but rather, it represents the sum total of all Form Completions that have taken place since the inception of the current report suite.

So What Can You Do with Lifetime Metrics?
Great question!  The truth is that these metrics are a bit limiting.  Here are the things I have seen done with these metrics:

1. You can use these metrics to see how you are doing in the current time period as compared with historical performance.  For example, in the report above, it might be interesting to note that SEO is greatly under-performing during the selected time frame (13.5%) as compared to its past performance (23.1% of Form Completes).
2. You can divide Form Completes by Lifetime Form Completes to see how the current time frame is contributing to the overall total.

I have really struggled to find other cool things you can do with these metrics, but I am hoping that maybe one of you can share how you have used them so I can learn new ways to use them (along with my readers)…

What I Would Do With Lifetime Metrics…
If you have read my posts in the past, you have heard me say that I don’t like to complain about something unless I can offer some potential solutions.  This will be no different.  I think that there is one simple change that Omniture can make to dramatically increase the usefulness of Lifetime Metrics… (drum-roll please…):

Give SiteCatalyst Administrators the ability to determine when Lifetime Metrics are re-started/expired

I know this subtle change doesn’t sound like it would accomplish much, but here is why I think it could:

Tying Lifetime Metrics to the date that data was collected in a report suite makes little sense.  Often times, you need to start a report suite or move to another one on arbitrary dates.  Therefore, these Lifetime Metrics make no sense in a business context.  If I use the same report suite for three years, why on earth would I want to see how my current month/quarter is doing compared to the last three years?  How would my users even know that Lifetime Metrics had been stored for three years?  It just doesn’t help make these metrics valuable.  However, if I could choose when Lifetime Metrics started over, I might re-start them on January 1st of each year and now I have a cool, easy way to see YTD information (i.e. how March is performing in relation to January-March).  As described above, I can also see how the ratio of SEO or SEM is performing against my YTD percentage.  Maybe I want to keep these metrics for two years, or re-start them when my company’s fiscal year starts – that should be my choice using the Admin Console.  While this will not propel Lifetime Metrics to MVP status of SiteCatalyst features, you could actually have something of use (of course, it would probably require a name change since Lifetime Metrics may not be appropriate) and bring this feature “back from the dead” so to speak…

Well…that’s it…just wanted to provide a bit of education about this little known feature and some suggestions on how it might be improved… If you would like to see the change I propose made by Omniture, click here to vote for this idea in the new Idea Exchange (requires an Omniture Account).

Adam Greco is the Director of Web Analytics at Salesforce.com.  You can read his previous Inside Omniture SiteCatalyst blog at http://blogs.omniture.com/author/agreco/ and can follow him on Twitter at http://twitter.com/adamgreco.  Please send questions and comments to adam@the-omni-man.com.

Please note: I am no longer an employee of Omniture and the content/views expressed here are my own and not those of Omniture.

A few weeks ago, fellow Omniture SiteCatalyst blogger Jason Egan described some ways to take advantage of the Menu Customization feature in SiteCatalyst.  I wrote about how to use the Menu Customizer in this post, but recently I have been wanting to do something new with the feature that doesn’t appear to be possible.  In this post I will describe what I am trying to do in hopes that someone else out there knows of a way to do it or if nothing else to get it on the radar of the SiteCatalyst product management team…

Why Classifications Mess up the Menu Customizer
For those of you who are savvy enough to understand SAINT Classifications, you will quickly realize how powerful they can be in a SiteCatalyst implementation.  In addition to the normal function of rolling up data into groups, SAINT Classifications are great in cases where the root source of the data is not as “clean” as you would like.  For example, imagine a scenario where you are trying to capture two character text strings for US States into a Traffic Variable.  Unfortunately, your developer has passed data in using both upper and lower case (i.e. CA and ca).  While this can be fixed going forward, there may be reports you need to show that group these together.  Therefore, you would create a SAINT Classification and lump both of these values into a value of “California” in the classified report.

So far so good.  But what if you wanted to show only the Classification report, but not the source report (the one with the “CA” and “ca”)?  Believe it or not, this is actually possible by 1) creating a custom report for the Classification version of the variable and then 2) using the Menu Customizer to put this custom report in the right spot and 3) hiding the original report that was classified.  However, there is one major drawback of this approach.  If you ever need to have a user perform a break down by that classification, for say a Traffic Correlation, you are completely out of luck since hiding the source report disables the ability to break it down.  So in this case, if you had an Internal Search Term report and wanted to break Internal Search Term instances down by state (either the “CA” version or the “California” version), you cannot do it once you have hidden the source report.  The same limitation applies to classified Conversion Variables (eVars) and Conversion Variable Subrelations.

Proposed Solution
While the example above is somewhat basic, there are many cases where you might want to show a classified version of a report, but not show the source report of the same variable. Unfortunately, since you cannot even see Classifications in the Menu Customizer yet, I am not optimistic that this will be addressed anytime soon, but in an ideal world, it would be possible to do the following:

1. See SAINT Classifications in the Menu Customizer as they appear in the regular SiteCatalyst menus and have the ability to hide/move any of them or the source of the Classification.  Currently, most of my Classification data appears in a 3rd level fly-out from the menus and it would be great if I could move these reports anywhere I’d like as I can with non-classification reports.
2. In cases where the source of the Classification is hidden, still allow users to breakdown Traffic and Conversion reports by the classified versions of the source variable
3. If a Custom Report is created using a variable that has Classifications, allow users to have breakdowns of that report in the same way they would if they were looking at the regular version of that report (i.e. don’t punish users for using the Custom Report functionality!)

If anyone out there has come up with a work-around for this, please leave a comment here…Thanks!

Adam Greco is the Director of Web Analytics at Salesforce.com.  You can read his previous Inside Omniture SiteCatalyst blog at http://blogs.omniture.com/author/agreco/ and can follow him on Twitter at http://twitter.com/adamgreco.  To be alerted to new blog posts, I recommend subscribing to this blog via e-mail using the tool provided on the top-right of this page.  Please send questions and comments to adam@the-omni-man.com.

Please note: I am no longer an employee of Omniture and the content/views expressed here are my own and not those of Omniture.