(Estimated Time to Read this Post = 4 Minutes)

I recently received an e-mail from a blog reader who was having issues tying their Orders in SiteCatalyst to Orders in their back-end system.  Here is a snippet from the e-mail:

I have a little issue in my own SiteCatalyst setup that I recently discovered.  Sad for me I had trusted the number of Orders for each day’s Conversion Funnel and recently I decided to validate the numbers in SiteCatalyst against what our back-end system has.  SiteCatalyst is 5%-10% understated each day which makes for a heck of a difference at the end of the month!  I’d rather be understated than overstated, but can you give me some ideas where I should look first?

Unfortunately this is an all too common problem I hear out there.  In this post I am going to share some ideas on how you can tackle this Order/Revenue validation issue head-on and make sure you can trust your critical Orders/Revenue data in SiteCatalyst.

Order ID eVar
If you have an online shopping cart, you should already be setting the s.purchaseID variable with a unique Order ID when an Order takes place on the website.  This variable is used by SiteCatalyst to ensure Order uniqueness.  Unfortunately, the downside of this variable is that it is not readily available in the SiteCatalyst interface.  It is available in DataWarehouse but not in regular SiteCatalyst reports or Discover.  Carmen Sutter (@c_sutter) has submitted  an idea in the Idea Exchange to change this, but until then, I recommend that you set what I call an Order ID eVar variable.  To do this, all you need to do is set the same value you pass to the PurchaseID variable to a custom eVar.  This will allow you to see all Orders and Revenue by Order ID from within SiteCatalyst and Discover as you would any other eVar.  Once you have done this, you can open up this new Offer ID eVar and add your Orders or Revenue Success Event as needed:

In the example above, we can see that most Orders have only one Order ID, which is what we want.  However, in this case, we can see that one ID was counted twice.  That may require some research and I like to schedule a report like the one above to be sent to me weekly so I can make sure nothing strange is going on.

Data Sources Setup
However, while adding an Order ID eVar is helpful in seeing if you are over counting Orders in SiteCatalyst, it won’t tell you if you are under counting Orders or  how close your SiteCatalyst data is to your back-end systems.  To do this, I recommend you use Data Sources.  As a quick refresher, Data Sources allows you to import external data/metrics into SiteCatalyst (see post link for more details).  In this case, I recommend that you import in a file from your back-end system into SiteCatalyst which contains your unique Order ID, the number of Orders (which should always be “1″) and the Revenue Amount.  When you import data via Data Sources, you include the date that you want the data to be associated with so it doesn’t matter if you import the data on a daily, weekly or monthly basis, but the more frequently you upload it, the better so you can find issues quickly.

Here are step-by-step instructions on how to do this:

• Create the Order ID eVar described above
• Create two new Incrementer Success Events and name them “Back-End Orders” (Type=Numeric) and “Back-End Revenue” (Type=Currency)
• Create a new Data Sources upload template (ClientCare or Omniture Consulting can assist with this).  You want to be sure to map the two new “Back-End” Success Events to the Data Sources template.  Even more critical, is that you want to include the newly created Order ID eVar in the Data Sources template.  If you do not do this, then you will not be able to see these two new Back-End metrics in the same Order ID eVar report that you have in SiteCatalyst (more on this later).

• When you are done, you should have a Data Sources template that looks something like this:

• Now all you have to do is work with your developers to have this file sent via FTP to the Data Sources FTP on a regular basis.

The Payoff
So by now, you are probably saying to yourself: “That’s a lot of work!”  No argument here!  However, hang with me as I share what the ultimate payoff is for doing this.  As you recall, our primary objective was to see if our online Order and Revenue data was matching what our back-end systems indicated.  Now that we have the Order ID eVar and two new “Back-End” Order and Revenue metrics, we have everything we need.  This is where the fun begins and we put it all together!

All you have to do now is to open the new Order ID eVar report and add all of the relevant metrics.  First, we will add the SiteCatalyst Orders and Revenue so we can see online Orders and Revenue by Order ID:

Next, we will add the two new “Back-End” metrics to the report and, since we were smart enough to include the Order ID eVar value in the Data Sources upload, SiteCatalyst knows which “Back-End” Order ID and dates line up with our online data:

Cool huh!  As far as SiteCatalyst is concerned, these offline metrics are connected to your Order ID eVar values just as if they had happened online.  Using this report, we can see if there are any differences between our online and offline data.  In the example above, it looks like the “Back-End” system had an order with $2,350 in revenue that wasn’t captured online.  Having this information makes it much easier to troubleshoot order submission issues.  You can even use DataWarehouse or Discover (only if you use Transaction ID Data Sources) to break down Order ID by browser, domain, IP address, etc… to see if you can figure out what is happening.  In addition, you can export this data to Excel and look at the totals to see how far off you are in general.

Finally, for the true SiteCatalyst geeks, you can create a Calculated Metric that divides Orders by Back-End Orders and/or Revenue by Back-End Revenue to see a trended % that each is off and set up Alerts to notify you if they deviate too much!  When you take into account this level of assurance all of a sudden the Data Sources work above might not seem like all that much in the long run!

Final Thoughts
If you sell products online, nothing is more critical than believing in your key metrics.  Even if you don’t sell online, the same principles here can be applied to lead generation forms, subscriptions or any other metrics you store in SiteCatalyst and also in your back-end systems.

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.

Thanks to Laura MacTaggart in the Omniture Consulting group, I just learned an awesome Discover time-saver I felt obligated to share.

Have you ever needed to pull a bunch of different successive reports in Omniture Discover?  Maybe you want to look at Pages, then Visit Number, then Campaigns, but for each you want to see the same metric columns.  If you are like me, you open a new report and then have to re-add all of the metrics that you want to see.  If you are looking at a lot of reports this is very tedious and can drive you crazy.  However, I just learned of a “hidden” Discover feature that can avoid all of this (maybe you all knew about this, but I certainly didn’t!).  Here is what you do:

1. Open the first report you want to analyze
2. Add the metrics you want to see
3. When you are ready to see the same metrics for a different report, simply right-mouse click on the name of the report (above the rows of values as shown below – in this report you would right-mouse click on “Pages (Traffic)”)
4. Select the “Change Report” option and select the new report that you want to see!

Presto!  You are now looking at a different variable report using the same metrics without having to re-add all of your metrics…Coolness!

In other good news, Laura MacTaggart and Derek Tangren from Omniture Consulting will soon be starting a blog on blogs.omniture.com to discuss all things Discover so be on the lookout for that!!

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.

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.

In my last post, I described some of the benefits of using a Page View Success Event.  In this post I will continue along the same theme by describing the benefits/uses of a Page Name Conversion Variable (eVar).  I recommend you read my last post on the Page View Success Event prior to reading this post as the two go hand-in-hand.

Setting a Page Name eVar
Setting the Page Name in an eVar, while somewhat nontraditional,  can be used for many different purposes.  In this post I will cover just a few, but I am sure those reading this can come up with many more.  The implementation of this couldn’t be easier.  Simply pass the s.pagename value to an eVar and you are done!  The following sections will outline how I use this variable once it is set.

Campaign Pages
Let’s say that you are running a bunch of online marketing campaigns and you want to see how many pages on the website people coming from each Campaign Tracking Code view.  In SiteCatalyst, the main way to figure this out would be to use DataWarehouse, ASI or Discover unless you read my last post and had set a Page View Success Event.  But now let’s take it a step further.  What if you want to see the pages that visitors from each Campaign Tracking Code viewed on your website.  Easy right?  Not so fast.  There is really no easy way to see this in SiteCatalyst using out-of-the-box reports.  One way to do this would be to use the Get&Persist Plug-in to pass the Campaign Tracking Code to a Traffic Variable (sProp) on each page of the visit and then use a Traffic Data Correlation to correlate this new sProp with the Page Name variable, but that is a lot of work!  The other way is to use a Page Name eVar.  By default, your Campaign Tracking Code report will store and persist the Campaign Tracking Code for multiple page views (you choose your time frame in the Admin Console) so if you begin to store Page Names in another eVar, you will have an intersection between Page Name and Campaign Tracking Code on each page.  That allows you to use a Conversion Variable Subrelations report to see all Pages viewed by visitors coming from each Campaign Tracking Code  You can see this by opening up the Campaign Tracking Code report, selecting the Page View (Event) metric and clicking the icon next to a specific Tracking Code to break it down by the Page Name eVar.  Once you have done this, you should see a report like this:

Channel Pages Tracking
If you role up your Campaigns to higher-level Marketing Channels using SAINT Classifications you can use the concept from the Page View Event post to see how many pages are viewed on your site after visitor arrive from each Marketing Channel.

You can then break this report down by the Page Name eVar to see the most popular pages for each Marketing Channel:

While this is not as granular as viewing Pathing by Campaign (as I demonstrated in this post) , it can give you a high-level view of what pages are popular for each different marketing channel.  If you are using the Unified Sources DB VISTA Rule or Channel Manager plug-in, it gets even better as you can see what pages people coming from another website or SEO are viewing on your website by breaking down a particular SEO keyword or external website link by Page Name:

Internal Search Follow-On Pages
If you are properly tracking Internal Search on your website, you should have Internal Search Terms stored in an eVar so you can use this concept to break down Internal Search Terms by this new Page Name eVar (while using the Page View Event) to see what pages visitors view after they search on each specific Internal Search Term:

What Page Does Success Take Place?
Another side-benefit of setting a Page Name eVar is that you can see on which page a Success Event takes place.  For example, if you set a “File Download” Success Event and a file is available on several pages, you can subrelate each file name with the Page Name eVar to see which page is the most popular for downloading each file.

Conversion Variable QA
Finally, there is a completely different use for the Page Name eVar – Quality Assurance.  Often times, you will run into situations where you have eVars that have bad data or no data at all (the dreaded “None” row!).  Often times, these issues are hard to troubleshoot.  However, if you have a Page name eVar, your life is much easier.

Let’s say that you have forms on your website and when visitors complete a form, they are required to enter a “Company Size” field which is stored in an eVar.  However, there are many cases where you are seeing the Form Company Size eVar with no data.  This might mean that IT forgot to make the field required on some of the Forms (would never happen right?).  How do you figure out which forms are causing the issue?  All you have to do is the following:

1. Open the eVar report that has data issues with a relevant Success Event metric (Form Company Size and Form Completes in this example)
2. Find the row that has bad data or no data (“None” row)
3. Click the breakdown icon to break the report down by the Page Name eVar
4. The resulting report (see below) will show you a list of Page Names where SiteCatalyst set the Form Complete Success Event, but did not have a corresponding Form Company Size eVar value

You can then send this report to your IT team to help them find pages where there may be tagging issues.  You could even schedule this as a recurring report to you and IT so you are alerted when similar issues arise in the future, which helps with overall data quality.  Keep in mind that this will only work if the eVar you are looking at has Full Subrelations or you add Full Subrelations to the Page Name eVar (see below).

Final Thoughts
As you can see, there are many different uses of this functionality.  The following are some final pointers related to this topic:

1. As previously noted, if you plan to use the Page Name eVar extensively for testing, I would recommend that it have Full Subrelations so you can QA all eVar reports, not just those that already have Full Subrelations.
2. In one of the rare times I ever tell clients to do this, I would recommend that you set the Page Name eVar to expire at the Page View in the Admin Console.  Expiration beyond that will probably add little value and only slow down reporting.  There are some special things you need to do here if you use Custom Links so I would advice you speak to Omniture  Consulting about this.
3. Consider Classifying the Page Name eVar by Page Type, Page Product Category, etc… to increase the value you get from this eVar.

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.

In my last post, I discussed a topic which I called Segment Pathing, which allows you to see how Pathing on your site differs by Visitor Type or Campaign Tracking Code.  In this post I will build upon this concept with one of the most popular topics in the Web Analytics field: Bounce Rates.  While I am not as enthusiastic about Bounce Rates as many others in the field, I do understand their importance and why people like them them.  However, one of my gripes with the Bounce Rate metric (which I have always defined as Single Access/Entries) is that there is not an easy way in SiteCatalyst to see Bounce Rates for different types of visitors or Campaigns.  Unless they have Omniture Discover or are experts at ASI Segments, most of the Omniture clients I worked with were primarily looking at Bounce Rates for the entire population.  While this is OK, I think we can do better than that.  In this post I will show you how I create Segment Bounce Rates.  However, to get the most out of this post, I strongly encourage you to read my prior post on Bounce Rates and my previous post on Segment Pathing before reading this post.

Segment Bounce Rates
As I just described, my goal when looking at Bounce Rates is to be able to tell my peers how visitors are bouncing off key pages based upon both the page and the segment.  In my previous post, I highlighted two segments that I commonly use: 1) Visitor Type (i.e. Customer vs. Non-Customer) and 2) Campaign Tracking Code (i.e. visitors from Google keyword A vs. Yahoo keyword B).  If I can dissect how each segment bounces off pages, I can determine if I need to create different versions of pages for each Visitor Type or Campaign Code or I can use this information to build future A/B Tests using a tool like Test&Target.  As I mentioned in my last post, this is a moot point if your organization already has Omniture Discover, but as is always the case in my blogs, my goal is to show you how to do things if you only have access to SiteCatalyst.

Implementing Segment Bounce Rates
The good news is that if you have already followed my instructions from my previous post on Segment Pathing, you are 95% of the way to being done with implementing Segment Bounce Rates!  As a quick recap, in my last post I described a process in which you concatenate the Page Name with another Traffic Variable (sProp) that contains a segmentation that you care about (i.e. Visitor Type).  Once you have these values concatenated on every page, you enable Pathing so you can see paths or pages by segment.  However, when you enable Pathing on this new sProp, you immediately gain access to the two metrics that you need to calculate Bounce Rate: Single Access & Entries.  Therefore, without even knowing it, by implementing Segment Pathing, you have also implemented Segment Bounce Rates!  All you need to do is to create the Bounce Rate Calculated Metric (which hopefully you already have as a Global Calculated Metric) and you are done.

So how do you see the results of your work?  All you need to do is to open the new concatenated sProp and add the Bounce Rate metric to the report.  In the example shown below, I will use the Campaign Pathing sProp which shows Campaign Tracking Codes concatenated with Page Names.  I will add Visits, Single Access, Entries and Bounce Rate to the report:

As you can see, the Bounce Rate for each Tracking Code/Page Name combination is displayed and you can sort by any metric you wish.

As a best practice, I like to conduct a text search filter to isolate one Page Name so I can see how the Bounce Rates differ for the same page with different Campaign Tracking Codes.  In the following example, I filtered on the phrase “:Home Page” and limited my results to see only Home Page Entries and the associated Bounce rates of each Campaign Tracking Code:

Keep in mind that I am only showing a few simple examples here and that this functionality can be extended to any segment of your choosing.  If you want to get really advanced, you could even concatenate multiple items together, such as Visitor Type + Campaign Tracking Code + Page Name.  This would allow you to see how different Visitor Types, coming from specific Campaign Tracking Codes, landing on specific Pages, navigate your site or Bounce off pages (i.e. Customer:ggl_1:Home Page).  Just don’t go too crazy since there are character limits on sProps and you don’t want to exceed the 500,000 monthly unique limits on sProps.

Final Thoughts
As you can see, you get a “two for the price of one” deal if you do all of the steps in this post and the previous post.  If you don’t have access to Omniture Discover and want to see how people navigate through your site or bounce off your site pages by specific segment, I suggest you give this a try and see if it helps you.

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.

In past blog posts I have discussed SiteCatalyst Pathing Analysis in general and some specific examples (i.e. Success Event Pathing).  In this post, I will share a more advanced technique I call Segment Pathing which is often used to extend the capabilities of Pathing Analysis.  While this technique can be used in many different ways, I will use Visitor Type Pathing as the primary example and way to explain the concept.

What Is Segment Pathing?
Most of you are probably familiar with the idea of Pathing and that SiteCatalyst Pathing Analysis tracks the order in which a visitor looks at pages, sections or anything else on your site.  As such, it is normal to pass a page name or section name value to a Traffic Variable (sProp) so you can then enable Pathing.  However, there are often cases where you want to see how different segments of your visitors navigate through your site.  For example, what pages do New Yorkers look at first vs. those from Chicago?  Are there Pathing differences between younger vs. older visitors?

In order to see how these different segments navigate your site, you have the following options:

• Create an ASI Segment for the population you care about and look at Pathing reports there
• Utilize Omniture Discover (assuming you have paid for that), create a Segment and view Pathing reports

But what if you don’t have Discover and you don’t want to burn up an ASI segment perpetually for this Pathing Analysis?  The answer is to use Segment Pathing which I will demonstrate here.

An Example: Visitor Type Pathing
In this example, let’s assume that your organization has a cookie that stores (to the best of its ability) the current visitors customer status.  Often times companies assume that a visitor with no cookie value is a “Non-Customer” and those who have logged in or purchased something are “Customers” (obviously this is subject to cookie deletion).  Now let’s assume this this Visitor Type is passed to a SiteCatalyst Traffic Variable on every page.  Obviously, the name of each page is passed on each page and should be set to the s.pagename Traffic Variable.  Therefore, you have Page Name and Visitor Type, but no way to see pages by Visitor Type.  All you have to do is to set a new Traffic Variable (sProp) that concatenates these two values together in a format like this:

[VISITOR TYPE]:[PAGE NAME] or “Customer:Home Page”

If you do this on every page of the site and then have your Account Manager enable Pathing on this new sProp, you now have an intersection between Visitor Type and Page Name on each page and can use any of the many Pathing reports (including Fallout and Pathfinder) for this new variable.  SiteCatalyst experts long ago realized how simply concatenating values together into one SiteCatalyst variable could yield powerful results.  By using this technique, you can now select the appropriate “Visitor Type” concatenated value in the Next Page Flow report to see what “Customers” do on your Home Page:

as compared to “Non-Customers” viewing the same page:

As you can see here, Non-Customers have a much higher exit rate from the Home Page than Customers do, but without the use of this Visitor Type Pathing, it might be difficult to spot this since you are looking at Pathing for all segments lumped together.

Keep in mind, however, that this is just one example of how you can do Segment Pathing.  One of my favorite uses of this technique is to concatenate Campaign Names or Campaign Tracking Codes and Page Name so you can see how visitors from different Campaigns navigated through your site.  In the more advanced version of this shown below, you can see a Pathing Flow for visitors who arrived at a website from a Tracking Code “ggl_1″ and landed on the Video Games page.  By concatenating these two values, we can see how visitors arriving from the “ggl_1″ Campaign Tracking Code navigated the site as compared to those arriving from a different Campaign Tracking Code.  In fact, we can also see how people coming from the same Campaign Tracking Code (i.e. “ggl_1″ navigated the site differently when they arrived on a different page (i.e. a page different than the “Video Games” page).

Note that in the example below, the Campaign Tracking Code is not concatenated with the Page Name on every page, but rather just on the first page.  In this case, this was done because of the massive number of potential Campaign Tracking Code & Page Name combinations, which could lead to a “uniques” issue in SiteCatalyst.  However, the good news is that since Pathing reports only show values that took place after the element before it, by simply selecting the value of “ggl_1:Video Games,” we are guaranteed that all path views after it had to be preceded by the selected value.

Final Thoughts
As you can see the implementation of this through the use of variable concatenation is not terribly difficult.  However, before you run out and concatenate all of your Traffic Variables together, keep in mind the following:

• You do not want to enable Pathing on too many sProps since it will cost you $$$ and could result in report suite latency
• While powerful, this technique is more of a “hack” so if you are going to be doing a lot of segmentation, I encourage you to invest in Omniture Discover which is a much easier way to do Segment Pathing

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.

When using Omniture SiteCatalyst, Pathing analysis is one of the truly unique things that is not easily replicated by other analysis tools.  While your company can find a way to track how often each of your key Success Events are taking place, you would be hard-pressed to get data warehouse tools to duplicate the Pathing analysis available in SiteCatalyst.  However, too many Omniture clients are limited in their thinking when it comes to Pathing, relegating it to Pages or Site Sections.  In past blog posts I have covered a few unconventional ways to use Pathing (i.e. Success Event Pathing), but there are many more ways to leverage Pathing.  In this post, I will show you one of my favorite uses of Pathing – Page Type Pathing.

What is Page Type Pathing?
So what is Page Type Pathing?  To fully understand it, I need to put it into context.  Imagine you are a web analyst at a company and your boss comes to you and asks “What is the fallout of visitors starting from the Home Page and then navigating to Product Pages, then Product Sign-up Forms and finally the Product Form Thank You Page?”  Well that sounds easy enough, but is it?  You can create fallout reports from each product, but what if you have hundreds of products?  You can look at Site Sections, but you may have many of those as well.  After a while, you may resign yourself to creating a massive dashboard with fallout reports for each product.  Just then, your boss reiterates that what she wanted was a fallout of all of the steps for all of the products in one overall fall-out report (and she wants it every week from now on!).  Besides learning the valuable lesson that you should always ask more questions before doing analysis, you are bummed because you don’t know how to do this other than manually add together all of these individual fall-out reports.

What your boss is asking for is what I call Page Type Pathing.  This is the ability to deconstruct your website so that you group all of your pages (or at least your key ones) into buckets that represent page types.  I think of it in the same way that species are grouped into classes like mammals or amphibians.  Many executives don’t have time or care about page or section-level Pathing since it contains too much “noise” (and they have limited attention spans!).  By lumping pages into a small number of meaningful page types, you can take a step back and see a 50,000 foot view of where people are going on your website.  Sometimes, page-level Pathing can make it hard to see that 30% of your visitors go from the Home Page to Product Pages since all you can see is individual page paths to product #1 or product #2.  By implementing Page Type Pathing you can end up with a new pathing report that looks like this:

Plus, since having Pathing enabled allows you to see all Pathing reports, you can create high-level Fallout reports using the same Page Type Traffic Variable (shown here in Discover):

Implementing Page Type Pathing
So how do you do this?  There are actually a few different ways to do this so how you implement it will depend upon which Omniture products you have and your ability to get tagging done at your organization.  I will outline the ways I recommend doing it, but there may be other ways.

The Old Fashioned Way
The most straightforward way to implement this is to create a new Traffic Variable (sProp) on every page and pass in the value that you have chosen as the Page Type for that page.  Obviously, you need to identify what you think your Page Types are ahead of time.  The values I recommend as Page Type Values are: Home Page, Product Page, Registration Page, Search Results Page, Checkout Page, Thank You Page, Content Page, etc…  However, setting a new sProp on every page can be a tagging nightmare as many of you can attest to if you have worked with IT to clean up your Page Names.  If you have a good Content Management System (CMS), you can add Page Type as a required meta-data field (be sure to make it a picklist!) for website pages and have your content owners enter it for each page.  But if getting tagging done is too difficult or you have too many pages to make the CMS approach feasible, go on to the other options…

Discover
If your company is lucky enough to have Omniture Discover, it is your lucky day!  Implementing Page Type Pathing in Discover can be done in less than 24 hours if you know what you are doing (or reading this blog!).  One of the benefits of Omniture Discover is that you get Pathing on SAINT Classifications which is not possible in SiteCatalyst. Therefore, if you create a “Page Type” Classification of the Page Name sProp, you can simply use Microsoft Excel to fill in a Page Type value for each page on your site and upload it using SAINT.  The next day, after Discover processes its data, it will pick up that new Classification and presto, you have Page Type Pathing in Discover!  Just be sure to thank the person at your organization who got you Discover or maybe you can use this as a reason to get it!

DB Vista
If tagging or CMS aren’t options and you don’t have Discover, what then?  Don’t despair, I won’t leave you in a lurch.  You can use Omniture’s DB Vista tool to get Page Type Pathing working.  Simply create a spreadsheet like described in the Discover approach above, but when you are done, tell your Omniture Account Manager that you would like to purchase a DB Vista Rule in which you upload a table of Page Type values for your Pages and have the DB Vista rule do a lookup on this table and pass the Page Type value to a Page Type sProp on every page.  As you add new pages to your site, you simply upload new rows to the DB Vista table.  There is a nominal charge for DB Vista rules, but it is worth it.

So there you have it, Page Type Pathing in a nutshell.  Once you have this functionality working you will be amazed by what you can learn about how people are navigating your site and I have seen it used by companies to drastically simplify their website with great results.  Finally, don’t forget to combine this functionality with segments using Advanced Segment Insight (ASI) or Discover so you can see the same cool Page Type Pathing reports for 1^st time visitors, people from Google, etc…

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.