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.

Those of you who have read my blogs for a while know that I am a big proponent of using as many SiteCatalyst features as possible.  However, in this post I am going to venture into uncharted territory by suggesting reasons to NOT use a SiteCatalyst feature – File Downloads.  While you may be skeptical about this, I ask that you hear me out on my reasons and alternative approach before passing judgment!

How Does the File Downloads Feature Work?
Before dismissing the File Downloads functionality, let’s take a minute to understand what it does.  Like most web analytics programs, SiteCatalyst provides out-of-the-box functionality for File Downloads such that when a website visitor clicks to download a file, it captures the file name in a special File Downloads report.  In reality, file downloads are treated a lot like Exit Links as far as SiteCatalyst is concerned.  The File Downloads report is very handy since you can open it and see which files are downloaded most like this:

Why I Don’t Like Using The File Downloads Report
As I have become more sophisticated in how I approach SiteCatalyst, I have found several flaws in the File Downloads report.  Here is a quick summary of my issues with it:

• One of my pet peeves of the File Download report is that it stores the path of the file with both an http:// and a https:// so you often times have the same file represented twice in your reports.  This throws off your data and it can confuse users.  You can modify this by tweaking your JavaScript file, but I wish there were an out-of-the-box option to do this.
• There is no easy way to see how each file download impacts website Success Events.
• Often times, I want to see where the website visitor was when they downloaded a particular file, especially if the same file can be downloaded from different pages on my site.  In the past, I have worked around this by modifying my JavaScript file to pass the file name to a custom sProp and then enabling the Previous Value Plug-in to store the previous pagename and enabling a Traffic Data Correlation between file name and Previous Page.  This provides a way where I can choose any file name and then break it down by pagename to see the ranked order of pages it was downloaded from.  Net Result – Out of the box File Downloads report doesn’t get me what I want.
• However, the real reason I don’t like the File Download report is that it ruins my Pathing reports.  I love pathing.  I like seeing where people go backwards and forwards through my site.  But when I look at the Next Page Flow report or the Next Page report, I am not getting an accurate picture if there are File Downloads on a page.  There are many cases where the most clicked element on a web page is a PDF that visitors download.  However, when I look at my pathing reports, this file is nowhere to be seen.  I can see it in the ClickMap report, but not in my SiteCatalyst pathing reports.  Therefore, when my users look at the next page report, they are looking at incorrect data due to the fact that 10% of visitors downloaded that PDF.

So What Should You Do…
I don’t like to complain without offering alternative solutions so the following outlines what I would do instead of using the File Downloads report.  Per my list above, at the end of the day, I have the following requirements for understanding File Download activity on my site:

• Easily see which files have been downloaded the most (and only once per file regardless of http or https)
• Understand from which pages visitors are downloading files
• See how each file download impacts my KPI’s
• Ability to see file downloads in my pathing reports so I can see what is really happening on each page

Seems reasonable enough right?  So here is how you accomplish all of these without using the File Download report:

1. Work with your developer to treat every file download as if it were a web page on your site such that it is passed to the Pagename variable (s.pagename)
2. Ensure that when passing the file name to the s.pagename variable, you strip out the http or https so you just get the raw file path (you can also strip out your domain to make the pagename shorter)
3. When creating this pagename, be sure to insert the phrase “file|” or “file:” in the pagename (or something similar)
4. Remove the File Download code from your JavaScript file (so you don’t get double-charged server calls)

So that doesn’t seem so hard does it?  But what does this actually get you?  Let me extol the countless benefits:

• Passing the file download name to the s.pagename variable means SiteCatalyst sees file downloads the same way it sees any page on your website.  This means you can see file downloads in Pathing reports so your next page and previous page reports will be accurate.
• If you remove the http or https you will only have one pagename for each file so you avoid the duplicate file issue I mentioned earlier.
• If you insert a file identifier (“file:”) then you can recreate the current File Downloads report you have today by just opening the Pages report and doing an advanced filter on “file:” in the Search area area.
• If you want to see which page visitors were on previous to downloading a specific file, you no longer need to use an extra sProp nor enable a correlation.  All you have to do is find the file in the Pages report and open the Previous Page pathing report.
• If, by chance, people link directly to your file downloads, you can also calculate the Bounce Rate of each File Download since it is now part of the pagename variable which has pathing (and thereby Single Access & Entries) by default.
• Anyone want to see Daily, Weekly and Monthly Unique Visitors for each File Download?  You just did it if you have those enabled on your Pagename variable (which most people have by default)!
• As I mentioned above, it is not easy to see how often each file on your web site “participates” in your key success events?  This is because you cannot enable Participation on the File Downloads report.  However, now that File Downloads are part of the Pagename report, you can easily enable Participation on the s.pagename variable (which you should already be doing) to see how often each file download impacts your key KPI’s.
• Last, but not least, if you have any correlations to the Pagename report (which is very common), you now have those correlations to every file on your website.  For example, if you have Pagename correlated to Visit Number or GeoSegmentation Country, you now have all file downloads correlated to these as well without having to pay for any extra correlations or variables!

All in all, you can get a lot of bang for your buck with this handy trick.  I think it can easily save you a few sProps, correlations and unique visitor CPM increases (I make no money on this blog so feel free to send contract savings my way )!

Final Thoughts…
Well there you have it.  These are the reasons why I have chosen to take an alternative approach to the File Download report and I think it makes a pretty compelling argument!  I will be curious to get your thoughts and see if you agree or disagree with me on this…

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.

Last week I shared a way to capture the various traffic sources (i.e. SEM, SEO, E-mail, etc…) so you could calculate the Bounce Rate for each of these Traffic Source types.  In this post I am going to build upon this and show you another cool way you can leverage this to have what I call Cross-Visit Traffic Source Attribution.

What is Cross-Visit Traffic Source Attribution?
As an online marketer, one of the things I want to see is how each traffic source leads to online success.  Within a visit, it is relatively easy to see which Traffic Source types lead to success.  Normally this is done by capturing the various campaign elements and using SAINT Classifications to roll these up into Traffic Source types.  However, what many marketers want to see is the overall mix of Traffic Source types that lead to success over several visits.  For example, maybe Paid Search is always the last thing your visitors are doing before placing an order, but maybe the first thing they did was to click on an SEO keyword.  I touched upon this a bit in an old blog post on Cross-Visit Participation which you can review here.  If your organization has a desire to see a high-level view of which combinations of Traffic Source types lead to success, then Cross-Visit Traffic Source Attribution may be your answer.

Implementing Cross-Visit Traffic Source Attribution
If you have followed the instructions I laid out in my last blog post, then you have already done much of the work required to enable this feature in your SiteCatalyst implementation.  Now that you have an sProp that contains the Traffic Source type set on the first click of each website visit, all you have to do is the following:

1. Pass this value to an eVar (Most Recent Allocation)
2. Implement the Cross-Visit Participation plug-in
3. Have the eVar expire when your primary success event takes place (i.e. Orders)

As a refresher, the Cross-Visit Participation plug-in stores a list of elements, in this case Traffic Sources, with each visit so when a Success Event takes place, you can attribute the success to the current string of cross-visit values.  For example, if someone comes to your site three times, first from SEO, second from E-mail and third from SEM and then places an order, the current value in the eVar would be “SEO|E-mail|SEM.”  As time goes by, and you have more website visitors, the combinations that occur most frequently will rise to the top (web analytics darwinism?).  Usually the single Traffic Sources will be at the top (i.e. SEO by itself or SEM by itself), but what I look for are the combinations that are at the top of the list.  I sometimes even hide the individual items using the advanced search feature (Tip=Show if it Contains “|”) so I can see only multiple session Traffic Sources:

The only warning I will give about using this functionality is that it might burst the bubble of some of your co-workers who think that their Traffic Source type is the “end all, be all” of success.  In my experience, many people bounce around quite a bit and the results can surprise you!

First Touch, Last Touch
When it comes to attribution, many talk about First Touch, Last Touch and All Touch, meaning which Traffic Source was the first that visitors saw in a sequence leading to success, the that visitors saw last or a list of all of the Traffic Sources that influenced the success.  In SiteCatalyst, the easiest way to implement First Touch and Last Touch is to use two separate eVars.  Both capture Traffic Sources, but one has Original Allocation and a long expiration (never or say 6 months), while the other eVar is set to Most Recent Allocation and expires at the Visit.  However, you can also use the new Cross-Visit Traffic Sources eVar shown above to do this.  Simply download the above report to Excel and then isolate the first Traffic Source or the last Traffic Source and add up the Orders (or use a Pivot Table) to see the total for each Traffic Source.

Traffic Source Influence (All Touch)
For me however, I am most interested in seeing the total influence of a specific Traffic Source (All Touch).  While this is not readily available in SiteCatalyst (since Linear eVar Allocation only works within one visit), you can use the new eVar mentioned above to quantify the potential impact/influence of a specific Traffic Source Type.  Here is how you do it:

1. Download the report above to Excel (you decide if you want to include the single Traffic Sources or only when multiple exist – as shown above)
2. Use an Excel Formula to set the Traffic Source Type for a specific Traffic Source Type (i.e. SEO) in all rows where it is found (see green column below)
3. Create a Pivot table off this new column (i.e. SEO) and look at the total Success Events (Orders in this example) that are associated with a row that contains the Traffic Source Type you chose in step two (in this case 754,328)
4. Take that total (i.e. SEO Influenced Orders in this case) and divide it by the Total Orders (in this case 76.07%).  This will show you how much SEO influenced Orders such that SEO was involved in a visit that ultimately led to an Order.

Finally, if you want to see Cross-Visit Attribution of individual Campaign elements (Tracking Codes) instead of Traffic Sources, you can apply the same principles shown in this post and my last post.

Hopefully, between this post and my last post, you will be able to answer the nagging Traffic Source questions that come up from time to time and help your organization better understand where it should use its precious marketing dollars…

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.