(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.

(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.

Recently, Omniture released its latest version of SiteCatalyst (version 14.7) in which there were a bunch of new features added.  Below are a few links to other blog posts that describe some of these new features:

• New Dashboards
• Day of Week Trending, New User E-mails, Default Dashboards, Transfer of User Settings

However, one of my favorite new features was the addition of Alerts on Classifications.  In the past, you could set Alerts on Success Events and on eVar and sProp values, but not on Classifications of those eVars and sProps.  While this new feature doesn’t sound all that impressive, it can be quite powerful.  In this post I will demonstrate how it can be used.

Example – Traffic Driver Type Classification
For the purposes of this post, let’s imagine that we have an eVar or Campaign variable that captures individual Traffic Drivers (Sources).  These sources of traffic might be SEO keywords, Paid Search Keywords, E-mail links or clicks from Social Media sites.  However, in this case, we don’t want to be notified every time there is a increase/decrease for a specific Traffic Driver, but rather, we would like to know if there has been a significant change to one of the higher level types (SEO, SEM, Social Media).  Before this new version, doing that would be basically impossible, but this is easy now if you have used SAINT to classify your individual Traffic Drivers.

Let’s say that your boss wants to be alerted if there is a significant change in Social Media referrals to the website from one week to the next.  To be alerted about this, you would simply open up the Classification version of the Traffic Driver report (we’ll call it Traffic Driver Type) and click the Alert icon.  Doing this brings up the screen below which is basically the same as the Alert screen you may have used previously.  Once here, you can give your Alert a name, choose the time frame, pick your metric and then select the specific item you want to be alerted about (in this case I have selected Social Media).  Next, you set the type of Alert – in this case I have chosen a percent change of over 15% and then tell SiteCatalyst how you woudl like to be notified (e-mail or mobile device).  That’s it!

Other Uses
There are an infinite number of ways you can use this powerful feature.  Here are just a few that I can think of off the top of my head:

• Classify internal search terms into buckets and be alerted when a specific type of keywords hits a threshold or changes significantly
• Classify countries or cities into regions and be alerted when a metric related to a specific one changes
• Classify search engine keywords into Branded/Non-Branded and be alerted when each changes significantly
• Classify videos viewed on your website and be notified when a video type changes significantly
• If you are using the Omniture Twitter Integration, all of the Twitter data points are based upon Classifications so you can set an Alert when a particular person Tweets or if a specific Twitter keyword experiences a spike

These are just a few examples, and I am sure you will find many ones unique to your business that can prove beneficial.

Now, if only Omniture could combine this new feature with this future idea, then we will really be in business!  In the meantime, if you think of some really interesting ones, feel free to leave a comment 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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