(Estimated Time to Read this Post = 5 Minutes)

Unless your website is very basic, odds are that you use some sort of navigation to help visitors find website content.  Usually navigation is in the header or left side of web pages.  Inevitably, there will be times when you are asked how often and in what ways visitors are using navigation.  In this post I will cover some common navigation questions and how to answer them.

Common Questions
So what are the common questions you may get around navigation.  Here are some that I have been asked over the years:

1. Which individual navigation links are clicked the most?
2. Which navigation areas are clicked the most?  This is usually related to the main section area, not individual links.
3. From which pages are visitors using each navigation link?
4. For what percent of website visits is navigation used?
5. In what order do website visitors use navigation links?
6. Which navigation links lead to key website success milestones being accomplished?

The following will show how to answer each of these questions:

Which individual navigation links are clicked the most?
In this scenario, people are looking to see which detailed navigation links are clicked the most.  In the image below, this would represent such links as “Sales Cloud 2,” “Service Cloud 2,” “Custom Cloud 2,” etc…

To answer this question, you should have your developer write code that will pass the name of the link to a Traffic Variable (sProp) when a visitor clicks on each link in your navigation.  In addition, I highly recommend that you have them include the high-level navigation area in the value passed to the sProp.  For example, when a visitor clicks on “Sales Cloud 2″ in the example above, I would pass the value of “products:sales cloud 2″ (I always use lower case since sProps are case-sensitive) to the sProp.  Passing the high-level area will ensure that your data is clean as there are times when the same link can occur more than once in a navigation structure.  When this is complete, you can view a report that looks like this:

Which navigation areas are clicked the most?
In this question, people are generally asking to see (in the example above) if the “Products” section is clicked more than the “About” section and if so, by how much.  The good news is that if you have done the previous step correctly, you can answer this question by creating a SAINT Classification which rolls up the values in the preceding report into higher-level buckets.  You can create this classification easily by exporting the above report to Microsoft Excel and splitting the column by the separator and using the first part as the high-level navigation name.  Here is what your SAINT file might look like:

After you create and process this SAINT file you will be able to see a new high-level navigation report that looks like this:

From which pages are visitors using each navigation link ?
In this scenario, people at your company may want to know what is the most common top navigation link clicked from the home page or from another page on your site.  To see this, you need to have setup a Previous Page sProp.  This sProp passes the name of the previous page to the current page which allows you to create Traffic Data Correlations between it and any other Traffic variable.  In this case, once we have a Previous Page sProp, we can correlate it to the Top Navigation Link sProp shown above to see what navigation links are clicked from each page.  For example, I can open up the Previous Page sProp within a report suite and then break it down by the new Top Navigation sProp…

…to see a report like this:

In this case, we can see that the “customers:india customers” Top Navigation link was only clicked 482 times from the home page.

In addition, since this uses a correlation and correlations are bi-directional, you can also use this to find out all of the pages from which visitors clicked on a specific navigation link:

In this case, we can see that the “customers:india customers” link was clicked a total of 957 times and then see the breakdown of pages visitors were on when they clicked it.  This can help your content people understand when visitors are reaching for the navigation…  Finally, if you look closely, you can see that the “SFDC:in:homepage” shows the same 482 clicks referenced above, but in this case we can see that it accounts for 50% of all clicks this link gets across the entire website…

For what percent of website visits is navigation used?
In some cases, you may be asked how often website navigation is used (in general).  One easy way to figure this out is to look at the the total Page Views from the first SiteCatalyst report shown in this post and divide it by the number of website Visits.  This can be done easily using the ExcelClient where you can pull a Visits data block and the report above and divide the two.  However, if you think you might need this on a recurring basis and if trending is important, I will show you another way to do this.  When visitors click on navigation links, in addition to passing the link name to a Traffic Variable as shown above, set a “Navigation Clicks” Success Event.  Once you have a Success Event, you can create a Calculated Metric that divides Navigation Clicks by Visits as shown here…

…which will allow you to see a report like this:

In what order do website visitors use navigation links?
If you are redesigning your navigation, a useful piece of data is the order in which visitors click on navigation links.  Do they always click on the first items in the list?  The ones that are farthest to the left?  Fortunately, if you have implemented the items above, you can see this by simply enabling Pathing on the new Navigation Links sProp created above.  This will allow you to view the Pathing reports including a Next Page Flow and Previous Page Flow just for navigation items:

Which navigation links lead to key website success milestones being accomplished?
Finally, I will occasionally be asked which navigation links are contributing to success.  To answer this question, all you have to do is enable Participation for your key metrics on the Navigation links sProp described above.  This will allow you to add a Participation metric to the first report shown above to see which links were in the flow of your key website Success Events.

Final Thoughts
Well, there you have it.  Everything you wanted to know about tracking your website navigation, but were afraid to ask!  If you have any comments/questions, use the form below.

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.  You can also hear Adam on the BeyondWebAnalytics podcast.  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.

(Estimated Time to Read this Post =3 Minutes)

I believe that every SiteCatalyst implementation should have a Previous Page sProp.  There!  I said it (I feel like I am channeling Avinash!).  In past blog posts I have touched upon the use of a Previous Page sProp, but I feel like I have not done it justice and wanted to take time to explain it in greater detail.  In this post, I will describe why I think this variable should always be set and provide some examples of its use.

Why You Need a Previous Page sProp
I find that in the web analytics world, I often receive the following question:

“What page was the visitor on when he/she _______?”

You can fill in the blank with many things.  Here is a list of the ones I have been asked:

• …searched for this phrase in our internal search box…
• …clicked on a button to go to a web lead form…
• …downloaded a white paper…
• …added products to the shopping cart…
• …clicked on a banner advertisement…
• …started using the ROI calculator…
• …clicked to fill out a website survey…

I could go on for days and never come to the end of these types of questions!  People want to know this information because it helps them get inside the head of their visitors.  Often times it leads to navigation or content changes.  Regardless of the reason, I assure you that you will be asked this question at some point and the truth is that it is not easy to answer with out-of-the-box functionality (i.e. Pathing).  The good news is that setting the Previous Page sProp is easy and will pay great dividends down the road…

How To Set the Previous Page sProp
Setting the Previous Value sProp could not be easier.  All you have to do is use the Previous Value JavaScript Plug-in to pass the previous page name to a new Traffic Variable (sProp).  You can even see a detailed description of the code for this in Ben Gaines’ great Summit blog post.  If you need help, call your Omniture Account Manager, Omniture Consulting or ClientCare.

Once you have your JavaScript setup to pass the Previous Page Name to the sProp, you need to enable a Traffic Data Correlation to any sProp for which you want to create a breakdown.  For example, if you want to see what pages visitors were on when they searched for a particular internal search term, you would correlate the Previous Page Name sProp with the Internal Search Term sProp…

…so you can see a report like this:

In addition, if you are familiar with correlations, you may recall that they are bi-directional, so in addition to seeing the pages people searched for specific terms from, you can also see the converse.  In this case, that would mean seeing all of the internal search terms visitors searched for on a specific page:

As you can see here, we see the same “4″ searches for the phrase “chatter” from the selected page as we saw in the first internal search term report (in this case I am just using Internal Search as an example, but if you want to learn more check out my Internal Search post).

One Is Usually Enough
However, one word of caution, I have seen many clients implement several Previous Page sProps and I am not a fan of doing this as I will now explain.  Let’s say you want to see what page people were on when the searched on a specific search term (as described above) and you also want to see what page they were on when the downloaded files on your site.  A lot of people will set two Previous Page sProps in this situation – one for the search term and one for the file downloads.  In my opinion, this just wastes a variable, wastes correlations and causes confusion for your users.  The truth is that all you need is one Previous Page sProp to answer both questions.  Since on each page there will be one and only one Previous Page value, there is really no reason to do this multiple times.

I have seen some clients who have chosen to pass the Previous Page Name to an eVar.  There are some interesting uses of this.  For example, if you want to see what pages visitors were on when they added a specific product to the shopping cart, you can pass the Product Name to the Products Variable, set the Cart Add Success Event and the Previous Page Name to an eVar.  The main issue you will run into is that Conversion Subrelations are an “all or nothing” proposition so you can only do breakdowns by eVars that have Full Subrelations.

One final tip that I will throw out there is to consider having your developer pass a value of “[NO PREVIOUS PAGE AVAILABLE]” (or something similar) to the Previous Page sProp on entry pages (or any other time no Previous Page is available).  I find that this is easier than dealing with questions around “Unspecified” in correlation reports and it is easier to remove this value using the search box than it is to hide the “Unspecified” values.

Final Thoughts
As I mentioned in the beginning, I highly recommend that you have a Previous Page sProp for all of your key report suites and add correlations as needed.  If you have any questions/comments, feel free to leave them here…

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.  You can also hear Adam on the BeyondWebAnalytics podcast.  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.

(Estimated Time to Read this Post = 2.5 Minutes)

In my last post, I discussed how you can see how much money you are leaving on the table when it comes to the online shopping cart.  While I still have the shopping cart on my mind, I thought I would follow this up with a concept I call Product Pathing.  Product Pathing answers one of the questions I get from time to time:  How can I see the order in which website visitors are looking at my products or product categories?  The following will provide details on why you might want to do this and its implementation.

Why Product Pathing?
So why would you want to implement Product Pathing?  Here are a few reasons:

1. Understanding how visitors jump between products or product categories which helps you understand how visitors navigate your products
2. Seeing what products are viewed concurrently which helps you understand what cross-sell/up-sell opportunities might exist
3. If one of your website goals is to get visitors to view multiple products, you can measure how you are doing against that goal

There may be more reasons, but the preceding items should help you build a case for implementing this, especially since it is not difficult to do.

Implementing Product Pathing
So the standard way to see the answers to the questions above is to use page name-based Pathing reports.  You might find the page name of a particular product and then look at Pathing reports to see what visitors did after viewing the product.  However, I find that this approach does not work because there are so many pages on the website that it is impossible to sift through them all and isolate just product pages.  Therefore, I am going to propose the following alternative solution:

1. On all Product View Pages, in addition to setting a Product View Success Event and the Products Variable, pass the Product Name (or ID if that is all you have) to a new “Product” Traffic Variable (sProp). Be sure that you pass nothing but the Product Name (or ID) to this sProp.
   
2. After that is done, enable Pathing on this sProp

Believe it or not, that is all you have to do! By passing only the Product Name (or ID) to this new sProp, you will have a clean, new sProp that allows you to see Pathing reports on only Products like this:

Moreover, keep in mind that you have access to all Pathing reports so you get the bonus benefits of seeing the following as well:

• How often visitors looked at Product X and then didn’t look at any other Products (Exit % – 42.32% in this case)
• All paths containing Product X (Full Paths Report)
• What Products visitors see (if any) between Product X and Product Z (Pathfinder Report)
• How often did visitors see Product X and then Product Y (Fallout Report)
• Which Products were viewed first the most often (Entries) or last the most often (Exits)

A Few Other Cool Uses of Product Pathing
In addition to this, there are a few other cool things you can do:

• Instead of passing Product Names (of IDs), you can pass in Product Categories to see the same data at a higher level
• Instead of passing Product Name values at the Product View Success Event, you can set an additional sProp in which you pass Product Names when the Cart Add Event is set to see the order in which visitors add products to the shopping cart

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.  You can also hear Adam on the BeyondWebAnalytics podcast.  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.

(Estimated Time to Read this Post = 3.5 Minutes)

From time to time, I will see people talking about some of the limitations of SiteCatalyst Traffic Data Correlations on Twitter and blogs.  Below is the most common request I see:

For those of you not familiar with Correlations, they are a way to break one Traffic Variable (sProp) down by another sProp, assuming that both are set on the same page (image request).  Unfortunately, in SiteCatalyst, the only metric you can see for Correlations are Page Views.  In the example below, I can use a Correlation to see what page a visitor was on when searching for a specific phrase in the internal search box:

While this is handy, what if I wanted to see how many Visits people searched for this phrase from each page or better yet, how many Daily, Weekly, Monthly Unique Visitors did this?  Currently, the only way to get at this information is to use DataWarehouse or Omniture Discover.  However, the following section will show you a handy little hack to get this information directly from SiteCatalyst…

The Hack
So in this scenario, we will say that we want to see how many Weekly Unique Visitors searched for the phrase above from each page on our website (as in the example above).  Here is the trick to doing this:

1. Just as in a Correlation, you must have both data points you want to correlate available on the same page.  In this example, it is Previous Page Name (from the GetPreviousValue JavaScript Plug-in) and the Internal Search phrase
2. Once you have the two data points available, create a new Traffic Variable (sProp) and concatenate the two values using a separator.  In this example, if the user searched for the above phrase from the Japan Customers page, the value would be “キーワード検索:SFDC:jp:customers”
3. After you have passed the concatenated value to the sProp, contact your Omniture Account Manager and tell him/her that you would like to enable Visits, Daily Unique Visitors, Weekly Unique Visitors, etc… on that sProp

When all that is done, using the example above, you will have a report that looks like this:

The confusing part of this hack is that you won’t actually use a Correlation report anymore.  You will no longer open one report and break it down by another report, but instead you will simply open the new sProp report and add the metrics you want to see.  In the report above, I have added Page Views, Visits and Weekly Unique Visitors and searched on the specific Internal Search phrase for which I am interested.

However, as you can imagine, you could have a lot of unique values in this report.  One caveat is that you need to make sure you don’t exceed the SiteCatalyst variable limit which is 500,000 unique values per month.  In this example, you would want to make sure that the combination of Page Name and Search Term does not exceed 500,000 per month, but for most sites this shouldn’t be a problem.

Another thing to keep in mind is that the above scenario is just one example.  This “hack” is by no means limited to Internal Search Terms and Pages.  Here are some other examples of what you can do with this “hack:”

• Unique Visitors/Visits who saw a specific page by visit number (i.e. Home Page:Visit 1, Home Page: Visit 2, Demo Page: Visit 1, etc…)
• Unique Visitors/Visits who searched for a term by visit number (i.e. Pricing: Visit 1, Pricing: Visit 2, Demo: Visit1, etc…)
• Unique Visitors/Visits who saw a specific page by country (i.e. Home Page:US, Home Page:UK, Demo Page:US, etc…)
• Unique Visitors/Visits viewing a specific product page by search engine (i.e. Product X:Google, Product Y: Google, Product X:Yahoo, etc…)
• Unique Visitors/Visits viewing a specific product page by search keyword (i.e. Product X:walmart, Product Y:walmart, Product X: walmart.com, etc…)

These are just a few examples and my advice is to look at whatever you are currently correlating (in Admin Console) and determine the items for which you would like to see Visits and Unique Visitors.

Advanced Users
For advanced users out there, I wanted to call out a few more things you can do with this concept:

• If you don’t have a lot of unique combinations, you can add multiple correlations to the same sProp and use the search box to find the item combinations you need.  For example, you may use the Internal Search & Page example shown above, but also store Page Name & Visit Number combinations in the same sProp.  As long as all of your data is underneath the 500,000 unique value monthly limit you are ok.  Alternatively, you can multiple sProps assuming you have enough variables that can have Visits and Unique Visitors enabled remaining in your contract.
• With this alternative approach, you can also view Trending Reports for each of your combinations if you enable Pathing.  This means that you can trend Visits or Unique Visitors for any combination (i.e. Weekly Unique Visitors who view Product Page X on Visit Number 1 over the last 90 days).  This temporarily solves the following Idea Exchange item (Allow Trended Versions of Correlation Reports)

Final Thoughts
So there you have it.  Just a quick “hack” that allows you to get a bit more information out of SiteCatalyst.  In the future, perhaps Omniture will allow you to see Visits and Unique Visitors right form the normal Correlation interface (please vote for this here: Provide Visits and Unique Visitors in Correlation Reports), but in the meantime, hopefully this will help bridge the gap…

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.  You can also hear Adam on the BeyondWebAnalytics podcast.  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.

(Estimated Time to Read this Post = 2.5 Minutes)

In the past, I have written about Bounce Rates, Traffic Source Bounce Rates and Segment Bounce Rates.  Hopefully this will be my last post related to Bounce Rates, but I recently found a “hack” to calculate and trend a Site Wide Bounce Rate in SiteCatalyst so I thought I would share it.  I define Site Wide Bounce Rate as the total number of Single Access Visits divided by the total number of website Visits.  Unfortunately, for some reason, this metric is very difficult to wrestle down in Omniture SiteCatalyst because you cannot view Pathing metrics (i.e. Entries, Single Access) in Calculated Metrics unless you are within an Traffic (sProp) report that has Pathing enabled.

To date, the way I have reported on Site Wide Bounce Rate was by pulling Visits and Single Access data into Excel using the SiteCatalyst ExcelClient.  Once there, I could divide the two and if I wanted to see it by day (or week or month), all I needed to do was to pull both metrics by day.  It was straightforward, but I could not add this to my SiteCatalyst Dashboards.

The Hack
So let’s say that you want to report a daily/weekly/monthly trend of your Site Wide Bounce Rate and add it to one of your executive dashboards.  Here are the steps:

• First you need to create the required calculated metric.  In this case you want to divide Total Single Access by Total Visits (or Total Entries which is the same thing).  I would recommend making this a Global Metric so all of your users have access to it going forward:

• Once this metric is created, open your Pages report, click the Add Metrics link and add the new Site Wide Bounce Rate metric to your list of metrics.  It will be under the Calculated Metrics area.  Place this new Site Wide Bounce Rate metric so it is the first metric and then add your regular Bounce Rate metric and finally add the Page Views metric and click the small triangle to sort by Page Views.  When you are done, it should look like this:

• When you click OK, you will be able to see a report that shows your most popular pages, the Bounce Rate for each page and the overall Site Wide Bounce Rate.  This report is handy for seeing how each page is doing in relation to the Site Wide Bounce Rate.

• However, our original objective was to see the trend of the Site Wide Bounce Rate and add it to a dashboard, so let;s get back on track.  To do this, all you have to do is click the “Trended” link shown in the report above.  As is always the case, trending will show you the left-most metric trended over your chosen date range (which is why it was important to put Site Wide Bounce Rate in the first metric slot!).  After clicking it, you will see a report that looks like this:

So the resulting graph is your Site Wide Bounce Rate and you can now add this to any SiteCatalyst Dashboard.  However, as you recall, I mentioned this is a “hack” so if you look closely you will see a bunch of pages in the data table for this report.  What is strange is that the values for each row are the exact same.  This is the place where you can see how much of a hack this is.  This data is pretty much useless so I recommend just adding the graph to your dashboards and ignoring the data table.  Perhaps in the future Omniture will let us add this type of Calculated Metric to the “My Calc Metrics” area so we don’t have to take such a convoluted path to add this trend graph to a dashboard!

Final Thoughts
So there you have it.  A quick hack in case you ever need to calculate Site Wide Bounce Rate for your HIPPO’s!  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.  You can also hear Adam on the BeyondWebAnalytics podcast.  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.

In my last post, I covered Comparison Reports and showed the basics on how to use them.  In this post, I will cover a few advanced ways that I use these reports related to Pathing reports.

Date-Based Pathing Comparisons
For many of the analyses I perform, I like to see how website visitors are navigating my site via Pathing reports.  However, these reports are usually static – for a specified time period.  Therefore, what I like to do is to view a few of the standard SiteCatalyst Pathing reports in a way that I can see how Pathing is changing day to day, week to week or month to month.  While SiteCatalyst doesn’t let you use comparison reports in all Pathing reports, there are a few key ones that do allow you to compare date ranges – Next/Previous Page Report and Full Paths Report.  The following are some examples of how you can take advantage of this.

Next/Previous Page Report
Let’s say that you have a key page like your home page and you want to see what pages visitors are going to from it in March vs. February.  To do this, simply open the Next Page report (under Pathing) and select the Home Page as the page of focus.  Once there, you can use the calendar as shown in my last post to select two different time periods (February & March in this case) and see the report:

When looking at this type of report, I tend to change the graph so I am looking at percentages instead of the raw numbers since that is what I care about the most.  Also, you can apply Normalization to this report by selecting it in the report settings (to learn about Normalization see my previous post).  Finally, the same principles apply if you want to see the above report as a Previous Page report to see how people are getting to a specific page differently between two different time periods.

Full Paths Report
In this next example, let’s say that we don’t have a specific page in mind, but rather, want to see how all of our paths are changing between two different time periods.  To do this, you can use the Full Paths report (found under Pathing).  This report shows all of your paths and can be quite massive, but I tend to use it to see just my top few site paths.  Using the date comparison feature, you can see how the paths of  the same site differ between two distinct time periods.  To do this, simply open the Full Paths report and use the calendar tool to select your two date ranges and you will see a report that looks like this:

As you can see, this report allows you to look at your top paths and see if there are any significant changes you should know about.  This is handy if you have a special promotion on a page and want to see how it is changing your Pathing behavior.  Finally, there are some cool advanced things you can do in the Full Paths report like limiting paths to a specific number of pages and specifying an entry page, but you can explore that as needed.

Site-Based Pathing Comparisons [If you don't have multiple report suites or ASI slots you can skip this section!]
As I mentioned in my previous post, the other type of comparison report you can create is one based upon report suites/ASI slots.  These comparisons allow you to see how one data set is doing compared to another.  A perfect example of this is if you are part of a multinational and have basically the same website for different geographies.  Other examples might be a company that has multiple divisions/products that are similar enough that they use the same type of website template.  In both of these cases, you have the same page names, just different locales or products and might want to see how one is doing vs. another.  In this example, we will assume that a website is basically the same except for the site geography and that we want to see how people are navigating from the home page of two different geographies.  If you are clever, you will quickly realize that this might be problematic since each website might have different page names including the site locale.  This why in my Page Naming Best Practices post I recommended that you set a custom sProp without the site locale (and have Pathing enabled).  Here is a quick excerpt from that post:

One wrinkle that can emerge are cases where you have multiple geographic websites.  For many companies, this results in a similar version of the website, but translated into different languages.  If you have this situation, I recommend tweaking the above page names to include a site locale indicator.  For example, each page in the UK site should have “uk:” in the page name and so on.  When this is done, your page names might look like this:

[Advanced User Alert - If you have multiple site locales, I also recommend passing the page name without the site locale to a different sProp (with Pathing enabled) so you can see how a page does across all site locales (i.e. Participation).  I also like to pass the site locale by itself to a separate sProp so in a global report suite I can create correlations between sProps and other variables (i.e. Internal Search Terms).]

If you have done this, then you can simply open the next page report for this custom sProp (that has no site locale) and choose the “Compare to Site” option and select the sites that you want to compare.  In this example, I am looking to see what visitors from Spain and Italy do when they are on the home page.  In this case, I am normalizing the data so I can get a better view of the next page differences between the two sites even if they have different amounts of traffic.  As mentioned previously, you can do the same thing for Previous Page and Full Path reports…

Using Comparisons With Other Custom sProps
Lastly, if you have Pathing enabled for other custom sProps, you can take advantage of this functionality there as well.  Let’s say you have Pathing enabled on what internal search terms people look for on your website.  You can compare this between websites or for two different time periods.  Below is an example of looking at the same internal search terms for two different time periods.

Final Thoughts
These two posts should cover pretty much all you need to know about SiteCatalyst comparison reports.  If you are using them in any other creative ways, 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.  You can also hear Adam on the BeyondWebAnalytics podcast.  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.

Often times when I used to work with clients and now internally, I am surprised to see how many SiteCatalyst users don’t take advantage of Comparison Reports within the SiteCatalyst interface.  In this post I will review these reports so you can decide if they will help you in your daily analysis.

Comparing Dates
Hopefully most of you are familiar with this type of Comparison Report.  This report type allows you to look at the same report for two different date ranges.  To do this, simply open up an sProp or eVar report and click the calendar icon and choose Compare Dates when you see the calendar.  In the example shown here, I am going to compare February 2010 with March 2010:

For this example, I have chosen the Browser report, using Visitors as the metric.  After selecting the above dates, my report will look like this:

As you can see, SiteCatalyst adds a “Change” column where it displays the difference between the two date ranges.  This can be handy to spot major differences between the two date ranges.  In this case we can see that “Microsoft Internet Explorer 8″ had a big increase and that “Mozilla Firefox 3.5″ had a decrease (probably due to version 3.6!).  You can compare any date ranges you want from one day to one year vs. another year.

However, when you compare ranges that have different numbers of days, your results can be skewed.  For example, in the report above, March had three more days than February so that may account for why the differences between the two are so stark.  If this ever becomes an issue, you can take advantage of a little-known feature of Comparison Reports – Normalization.  In the report settings, there is a link that allows you to normalize the data.  When you normalize the data, SiteCatalyst makes the totals at the bottom of each report match and increases/decreases the values of one column to adjust for the different number of days.  I am not 100% sure what specific formula or algorithms are used to do this, but for the amount of times that you will use it, I would go ahead and trust it.  Below is an example of the same report with Normalization enabled:

If you look closely, you will see that the March 2010 column has been normalized when we clicked the “Yes” link shown in the red box above.  By doing this, SiteCatalyst has reduced the numbers in the March 2010 column to assume the same number of Visitors as there were in February.  If you want to normalize such that February is increased to match March, you simply have to reverse the date ranges so when you select your dates, March is the first column and February is the second column (the second column is always the one that gets adjusted).  As you can see, the “Change” column is now dramatically different!  In this version, “Microsoft Internet Explorer 8″ no longer looks like it has changed much.  I find that using this feature allows me to get a more realistic view of date range differences.

Finally, you may notice a tiny yellow box in the preceding report image (says “6,847″).  This is a secret that not many people know about.  When you normalize data, Omniture artificially reduces or increases the values in the normalized column.  But if you want to see what the real value is (if not normalized), you can hover your mouse over any value and you will see a pop-up with the real number!  If you look at the first version of the report (the one before we normalized), you will see the same “6,847″ number in the first row of the report… Pretty cool huh?

Comparing Suites
This second type of Comparison Report is the one that fewer people are aware of or have used.  In this type of comparison, instead of comparing date ranges you compare different report suites.  Obviously, this only makes sense if you have more than one report suite, but it also works with ASI slots so don’t assume this isn’t relevant to you if you have just one report suite.  Much of the mechanics of this are similar to the steps outlined above.  You simply open one report (in this case we will continue to use the Browser report) and then choose the “Compare to Site” link and choose a second report suite or ASI slot.  In this case, I am showing an example of the Browser report for two different geographic locations.  Since most report suites have different totals, I tend to use Normalization more in these types of comparison reports.

Final Thoughts
This covers the basics of Comparison Reports.  Hopefully you can use this to start creating these reports and adding them as scheduled reports or even to Dashboards.  In my next post, I will take this a step further and demonstrate an advanced technique of using Comparison Reports…

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.  You can also hear Adam on the BeyondWebAnalytics podcast.  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.

In the Web Analytics space, we spend a lot of time recording and analyzing what people do on our website in order to improve revenues and/or user experience.  While this implicit data capture is wonderful, you should be supplementing it with data that you collect directly from your website visitors.  Voice of Customer (VOC) is the term often used for this and it is simply asking your customers to tell you why your website is good or bad.  There are two main ways that I have seen people capture Voice of Customer:

1. Page-Based Comments – Provide a way for website visitors to comment on pages of your site.  This is traditionally used as a mechanism to get direct feedback about a page design, broken links or problems people are having with a specific page.  Unfortunately, most of this feedback will be negative so you need to have “thick skin” when analyzing this data!
2. Website Satisfaction – Provide a way for visitors to rate their overall satisfaction with your website experience (vs. specific pages).  This is normally done by presenting visitors with an exit survey where you ask standard questions that can tell you how your website is doing and compares your site against your peers.

There are numerous vendors in each of these spaces and the goal of this post is not to compare them, but rather discuss how you can integrate Voice of Customer data into your Omniture SiteCatalyst implementation.  In this post, I am going to focus on the first of the aforementioned items (Page-Based Comments) and specifically talk about one vendor (OpinionLab) that I happen to have the most direct experience with (their headquarters was a mile from my home!).  The same principles that I will discuss here can be applied to all Voice of Customer vendors so don’t get hung up on the specific vendor for the purposes of this post.

Why Integrate Voice of Customer into SiteCatalyst
So given that you can see Voice of Customer data from within your chosen VOC tool, why should you endeavor to integrate Voice of Customer and your web analytics solution?  I find that integrating the two has the following benefits:

1. You can more easily share Voice of Customer data with people without forcing them to learn [yet] another tool.  People are busy and you are lucky if they end up mastering SiteCatalyst, lest you make them learn how to use OpinionLab, Foresee Results, etc…
2. Many Voice of Customer tools charge by the user so if you can port their data into SiteCatalyst, you can expose it to an almost unlimited number of users.
3. You can use Omniture SiteCatalyst’s date and search filters to tailor what Voice of Customer each employee receives.
4. You can divide Voice of Customer metrics by other Website Traffic/Success Metrics to create new, interesting KPI’s.
5. You can use Omniture SiteCatalyst Alerts to monitor issues on your site.
6. You can use Omniture Discover to drill deep into Voice of Customer issues

I hope to demonstrate many of these benefits in the following sections.

How to Integrate Voice of Customer into SiteCatalyst
So how exactly do you integrate Voice of Customer data into SiteCatalyst.  For most VOC vendors, the easiest way to do this is by using Omniture Genesis.  These Genesis integrations are already pre-wired and make implementation a snap (though there are cases where you may want to do a custom integration or tweak the Genesis integration).  You can talk to your Omniture account manager or account exec to learn more about Genesis.

Regardless of how you decide to do the implementation, here is what I recommend that you implement:

1. Set three custom Success Events for Positive Page Ratings, Negative Page Ratings and Neutral Page Ratings.  These Success Events should be set on the “Thank You” page after the visitor has provided a rating.
2. Pass the free form text/comment that website visitors enter into an sProp or eVar.  If they do not leave a comment pass in something like “NO COMMENT” so you can make sure you are capturing all comments.  If you are going to capture the comments in an sProp, I recommend you use a Hierarchy variable since those have longer character lengths vs. normal sProps which can only capture 100 characters.
3. Pass the actual page rating (usually a number from 1 to 5) into an sProp.  I also recommend a SAINT Classification of this variable such that you classify 1 &2 as Negative, 3 as Neutral and 4 & 5 as Positive.  This classification should take less than 5 minutes to create…
4. Use the PreviousValue plug-in to pass the previous page name to an sProp.
5. Create a 2-item Traffic Data Correlation between the Previous Page (step #4) and Page Rating (step #3).  This allows you to see what page the user was on when they submitted each rating.

All in all, this is not too bad.  A few Success Events and a few custom variables and you are good to go.  The rest of this post will demonstrate some of the cool reports you can create after the above implementation steps are completed.

Share Ratings
As I mentioned previously, you [hopefully] have users that have become familiar with the SiteCatalyst interface.  This means that they have Dashboards already created to which you can add a few extra reportlets.  In this first example, let’s imagine that you want to graphically represent how your site is doing by day with respect to Positive, Negative and Neutral ratings.  To do this, all you have to do is open the Classification version of the Page Rating report (can be an sProp or eVar – your call) and switch to the trended view.  You should have only three valid values and I like to use a stack ranked graph type using the percentage to see how I am doing each day as shown here:

This graph allows me to get a quick sense of how my site is doing over time and can easily be added to any Dashboard.

You can also mix your newly created Voice of Customer Success Events with other SiteCatalyst metrics.  For example, while you could look at a graph/trend of Positive or Negative Comments by opening the respective Success Events, a better way to gauge success is to divide these new metrics by Visits to see if you are doing better or worse on a relative basis.  The following graph shows a Calculated Metric for Negative Comments per Visit so we can adjust for traffic spikes:

Find Problem Pages
Another benefit of the integration is that you can isolate ratings for specific pages.  The first way to do this is to see which pages your visitors tend to rate positively or negatively.  In the following report, you can open the Rating variable report (or Classification of it as shown below) and break it down by the Previous Page variable to see the pages that most often had negative ratings:

This will then result in a report that looks like this:

Alternatively, if you want to see the spread of ratings for a specific page, all you need to do is find that page in the Previous Page report and break it down by the Rating variable (or its Classification) as shown here:

Share Comments
As noted above, if you capture the actual comments that people leave in a variable, you will have a SiteCatalyst report that captures the first 256 characters of the comments visitors enter.  This report duplicates scheduled reports from your Voice of Customer vendor in that it allows you to share all of the comments people are leaving with your co-workers.  However, by doing this through SiteCatalyst, you gain some additional functionality that some VOC vendors don’t provide:

1. You can create a Traffic Data Correlation between the Comments variable and the Previous Page variable so you can breakdown comments for a specific page.  Therefore, if you have users that “own” specific pages on the website, you can schedule daily/weekly reports that contain comments only for those pages so they don’t have to waste time reading all of the comments left by visitors.
2. You can use the Search filter functionality of SiteCatalyst to scan through all of the visitor comments looking for specific keywords or phrases that your co-workers may be interested in.  In the example below, the user is looking for comments that mention the words “slow” or “latent” to be notified of cases where the visitor perceived a page load speed issue:

Set Alerts
Another cool thing you can do with this integration is set automated Alerts in SiteCatalyst so you can be notified when you see a spike in Negative Comments on your site.  This allows you to react quickly to broken links or other issues before they affect too many visitors (and help avoid #FAIL posts in Twitter!).  Here is an example of setting this up:

Review Problem Visits using Omniture Discover
Finally, if you have access to Omniture Discover, after you have implemented the items above, you can use Discover to do some amazing things.  First, you can use the unlimited breakdown functionality to zero in on any data attribute of a user that is complaining about your site.  For example, if you had visitors complaining about not being able to see videos on your site, you might want to see their version of Flash, Browser, OS, etc… or even isolate when the problem took place as shown here:

Additionally, you can use Discover to isolate specific comments and watch the exact visit that led to that comment.  This is done through a little-known feature of Discover called the “Virtual Focus Group.”  This feature allows you to review sessions on your site and see the exact pages people viewed and some general data about their visit (i.e. Browser, GeoLocation, etc…).  While not as comprehensive as tools like Clicktale, it is good enough for some basic analysis.  Here is how to do this:

1. Open Discover and find the comment you care about in the custom sProp or eVar report
2. Right-click on the row and create a Visit segment where that comment exists
3. Save the segment in a segment folder
4. Open the Virtual Focus Group (under Pathing in Discover)
5. Add your new segment to the report by dragging it to the segment area
6. Click “New Visit” in the Virtual Focus Group
7. Click on the “Play” button to watch the visit

Now you can watch how the user entered your site, what pages they went to and see exactly what they had done prior to hitting the Voice of Customer “Thank You” page.

Final Thoughts
So there you have it, a quick review of some cool things you can do if you want to integrate your chosen Voice of Customer tool and Omniture SiteCatalyst.  This is by no means the only way to do this, but merely a few suggestions that I have found helpful over the years.  If you have done other cool things, please let me know…

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.  You can also hear Adam on the BeyondWebAnalytics podcast.  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.

[Warning: Some elements of this post are meant for advanced SiteCatalyst users so read at your own risk!]

Last week, Ben Gaines (@OmnitureCare) wrote a great blog post about the getPercentPageViewed JavaScript plug-in, which he had demonstrated in his Summit presentation.  This plug-in is very fun and I have enjoyed using it.  While this topic is fresh in people’s mind, I wanted to throw out some additional/advanced uses of this plug-in in case they are relevant to those out there using it or thinking about implementing it.

Beyond % of Page Viewed
When I first started using the aforementioned plug-in, my goal was like most, to see the total % of each website page that my visitors viewed.  I found the Browser Height report to be too limiting (shows pixels, not % of page viewed) and this plug-in helped provide some additional insight.  However, after using the plug-in, and correlating % of Page Viewed to pages, I realized that there were a few more things that could be done with this concept.  The next question that popped in my head was “I wonder what % of the page, for each website page, can be attributed to scrolling?”  After all, the % Page Viewed plug-in really only shows you how much of the page they saw in total, but not how much of the page they initially saw vs. saw because they scrolled.  This line of thinking drove me to ask what else could be learned from this plug-in such as:

1. Total % of Page Viewed by Page Name
2. % of the page that users tend to scroll by Page Name
3. Initial % of Page visitors tend to see before they start scrolling (to get around the pixel limitation of the Browser Height report)

As I mentioned earlier, Ben’s post covered item #1 above, so in this post, I will show you how to solve items #2 and #3.

How Much Are Users Scrolling on each Page?
To see how much visitors are scrolling on each page, I asked my developer if he could calculate the actual % of the page that users scroll through the plug-in.  Through his supreme awesomeness, he told me that he could.  That meant that we would have the total % of the page that was viewed and the % representing scrolling (both available on the next page as described by Ben).  From there, we decided that we would concatenate the two values into an sProp.  This means that the sProp Ben described would be slightly different such that instead of having raw number values (i.e. 100, 95, 56, etc…), it would have two values concatenated together as shown below [TOTAL % OF PAGE VIEWED]|[TOTAL % VISITOR SCROLLED]:

(Before you get scared, bear with me as I will show you how to deal with these strange looking values in the next few paragraphs!)

Once you have these concatenated values in the sProp, it is time to classify them using SAINT Classifications.  To do this, you create the following classifications of this sProp:

• Total % Page Viewed.  This is the first of the two values and this classification replicates what Ben blogged about.
• Scrolling %.  This is the second value and represents the % of the page the visitor scrolled to see.

When you are done with this, you can see the report Ben showed in his post, but can now see the following additional report:

Through this clever classification, you can see how often people on your website tend to scroll.  In this case, it looks like 73.2% of visitors don’t reach for that scroll bar!  However, as Ben stated, all of this data is more valuable when viewed by Page Name.  Since this Scrolling % report is really a classification of an sProp that is correlated to the Previous Page Name sProp, any classifications of it will also be correlated to Previous Page Name (if you understand that in one reading you are a true SiteCatalyst ninja – if not, re-read it a few times).  This means that you can break the above report down by Page Name, or in other words, you can look at any page on your website and determine how often visitors are scrolling.  To do this, simply open your Previous Page Name report, find the page you care about, and break it down by the Scrolling % (classification of the Percent of Page Viewed sProp).  In the following example, we can see how much visitors scroll when looking at the Home Page:

In this case it looks like about half of the time visitors are scrolling on the Home Page.  Finally, if you want, you can bucket these Scrolling percentages into more meaningful groupings by adding additional SAINT classification columns as Ben described.

What % of the Page Do Visitors See Upon Page Load?
So the other thing I wanted to see was the percentage of the page that visitors see before scrolling.  I don’t like looking at Browser Height pixels, but would rather simplify things and see the exact % of the page my visitors are seeing – period!  Unfortunately, there is not an easy way to do this in SiteCatalyst.  However, when I was looking at the above items in this plug-in, I realized that the answer to this question was a side-benefit of doing the SAINT Classification shown above.  Think about it…we have the Total % of the Page Viewed and the Total % that visitors scrolled, both concatenated in an sProp as shown above.  If you subtract these two values, you are left with the percent of the page that visitors saw before scrolling (in other words, upon page load)! For example, if the value in the sProp is “58|10″ (see first row of example above), then we know that the visitor saw a total of 58% of the page and they scrolled 10% of it, so they must have seen 48% of it initially (good thing web analysts like math!).

Therefore, when you are classifying the sProp shown above, you can add a new Classification of the Percent of Page Viewed sProp named “Initial % of Page Viewed” and simply subtract these two values and add that as a new classification (no new data to collect!).  When you do this, you end up with a new report that shows you the total % of pages visitors tend to initially see like this:

Here we can see that, in general, about 60% of visitors are essentially seeing the entire page without having to scroll.  Again, we can group these values into more meaningful buckets using SAINT, but the real power is seeing this Initial Page Viewed % classification by a specific Page Name.  Again, using the Home Page as an example, the following report shows how much of the Home Page most visitors see before scrolling:

What’choo Talkn ‘Bout, Willis?
OK…I know this sounds complicated, but really all you need to do is slightly modify the code (see below) that Matt Thomas  (of Omniture Consulting) created and that Ben alluded to in his post to add one concatenated value (% Scrolled).  The majority of the hard work is in building the SAINT classification file to get all of these cool, new reports.  Well the good news there is, that I have already created the file which you can use as a starting point for these extra reports.  All you have to do is to download it by clicking here (save .TAB file to your hard drive).  Simply save this file and add the values to your own SAINT template after you have created the Classifications mentioned in this post.

So there you have it…a few additional ideas for you to ponder while you have % of Page Viewed on the brain…  If you have other ideas or questions, please leave a comment here…Thanks!

FOR OMNITURE GEEKS ONLY!
Here is the “enhanced” JavaScript code that modifies the great code that Matt Thomas (from Omniture Consulting) created and is in the Omniture KnowledgeBase.  This is not currently supported by Omniture so use at your own risk!

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.  You can also hear Adam on the BeyondWebAnalytics podcast.  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.

Recently on Twitter, there was some discussion about the best way to name your pages in SiteCatalyst.  Therefore, I thought I would share some thoughts on the best way to set names for Pages, Sections, etc… when using SiteCatalyst.  Hopefully, you are already doing most of what I will mention here, but just in case, here are my suggestions.  Also, keep in mind that many people have different styles of naming pages (and feel very strongly about it!) so what is shown here are my personal preferences…

Naming Pages
If you don’t manually apply a “friendly” page name to the s.pagename Traffic variable (sProp) in SiteCatalyst, Omniture will capture the URL by default.  This is not ideal for the following reasons:

1. URL’s can be very long and exceed the sProp character limit (normally 100 characters)
2. URL’s can be hard to understand by end-users
3. URL’s can have querystring parameters that get cutoff which means that many pages get treated as one page name in SiteCatalyst (which ruins Pathing reports)
4. URL’s can have a http:// and https:// versions which means two versions of each URL which subdivides Pathing, Unique Visitors, etc…

Therefore, it is highly recommended that you name your pages the way you would like to see them in the Pages report.  I generally recommend naming pages based upon directory structures or manually by adding fields to your content management system.  Once you figure out how you will name your pages, the key question is what should you name your pages.  Here are my recommendations:

• Make sure all pages within each unique website have a common identifier.  For example, if you have three distinct websites that serve different purposes, I like to assign a value in the page name for each website so I can easily filter those pages in a global report suite (one that has data from all websites).  For example, for the Omniture website, I would have an identifer for the public (marketing) website (i.e. “omtr:”) and a different identifier for say the Idea Exchange (i.e. “ideas:”).
• I like to include the section in the page name when possible.  For example, if the Omniture public website has a section for “Products” and another for “Services,” I would include those in the page name (i.e. “omtr:products:” or “omtr:services”).  This allows you to easily filter Page reports to get all of the pages within a section.  Some companies also include the sub-section in the page name which is fine as long as you don’t hit the sProp character limit.
• Make sure all pages have a unique name.  If you have two pages with the same exact page name, SiteCatalyst will treat them as a single page and all stats for that page will be merged (including paths).
• Be mindful of case-sensitivity.  sProps are case-sensitive, so if you have the same pagename value, but in different cases, you will get two distinct page names.  A common best practice is to force upper or lower case in the JS file to avoid any issues.

So if you put all of these ideas together, a list of your pages might look like this:

One wrinkle that can emerge are cases where you have multiple geographic websites.  For many companies, this results in a similar version of the website, but translated into different languages.  If you have this situation, I recommend tweaking the above page names to include a site locale indicator.  For example, each page in the UK site should have “uk:” in the page name and so on.  When this is done, your page names might look like this:

[Advanced User Alert - If you have multiple site locales, I also recommend passing the page name without the site locale to a different sProp (with Pathing enabled) so you can see how a page does across all site locales (i.e. Participation).  I also like to pass the site locale by itself to a separate sProp so in a global report suite I can create correlations between sProps and other variables (i.e. Internal Search Terms).]

One other item related to site locales is the use of different languages or translated pages.  While I do recommend different page names for each site locale, I do not recommend that you have different pagen ames for the same page translated into different languages.  You can read more about this in my old Foreign Language post.

As you can see, this doesn’t look all that hard to implement, but by using the above items you can easily:

• Filter pages for a website (i.e. omtr: vs. ideas:)
• Filter all pages for a specific section (Search contains :services:)
• Filter all pages for a particular site locale (Search contains “:uk:”)
• Filter on a combination of the above items.  For example, let’s say you wanted to see all UK Product pages (Search contains “:uk:products:”)

When you look at this it makes common sense, but I can’t tell you how many clients I ran into that had incomprehensible page naming which made everything more difficult.  Even if it means losing some historical page data, I always recommend that clients have good page names as it pays great dividends down the road…

Site Sections (s.channel)
After dealing with Page Names, the next thing I like to tackle is Site Sections.  These are useful if you want to see how visitors are navigating your website at a higher level than pages.  If you have good page names, you really should be able to build your Site Sections by setting it equal to the page name minus everything past the last “:” symbol.   For example, in the example above, if the page name is “omtr:us:services:consulting” then the section would be “omtr:us:services” (you choose whether you want to include the “:” at the end or not).  I have seen many clients that can set Site Section values automatically based upon good page names which saves a lot of development work and ensures consistency.

Site
One variable that many clients forget to include is the Site variable.  Essentially, what you are doing here is to pass in a value for the website by itself into an sProp.  In the example above, this would mean values of “omtr” or “ideas” by themselves in an sProp.  Doing this allows you to see total Visits and Unique Visitors by site in one report and when Pathing is enabled, allows you to see how people are navigating from one website to another.  Again, if you have good page names, you can set the Site variable by simply grabbing everything before the first “:” symbol in the page name.

Page Type
Those of you who have read my previous blog posts know that I am a fan of setting a Page Type on each page that represents the function of the page.  I won’t rehash this topic, but recommend you check out my prior post on this.

Advanced Stuff
For those who are a bit more advanced in their SiteCatalyst usage, you can check out the following page related advanced topics:

• Setting a Page View Event
• Passing Page Name to an eVar
• I recommend passing the URL to a custom sProp.  This is a good thing to do since URL is not available in DataWarehouse by default.  There are also cases where being able to segment on the URL can get you out of a jam…

So there are a few items related to naming Pages, Sections, etc…Let me know if you find these tips helpful and/or if you have come up with best practice suggestions of your own you’d like to share…

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.