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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Recently out on Twitter, someone had asked how you can calculate Bounce Rate for various Traffic Sources.  In the past I have shed light on how you can create Bounce Rates for campaign elements, visitor types, etc…, but I failed to share how to see Bounce Rates for SEO, SEM, E-mail, etc…  In this post I will share the way to do this. If you are reading this post, odds are you know what Bounce Rates are, but quickly, it is the percent of visitors who saw one thing (normally page or section) and then went no further.  If you need a refresher on Bounce Rates, you can look at my old Bounce Rate post, or better yet, check out Avinash’s post on Bounce Rates.

Why Traffic Source Bounce Rate?
Often times, marketers want to see how each of their disparate online marketing channels are doing when compared to each other.  Most will rate them by how well they perform against the website KPI’s.  However, due to its popularity, may want to see the Bounce Rate for these online traffic sources.  While my Segment Pathing post showed you how to see the bounce rate for a specific traffic source element (i.e. SEO Google keyword going to your home page), what if you want to see the total Bounce Rate for SEO or SEM?  Unfortunately, that doesn’t come out of the box in Omniture SiteCatalyst (though you can derive it in Omniture Discover).  I am not going to tell you whether the Traffic Source Bounce Rate is a valid metric as that depends upon your business objectives, but the next section will outline how to implement it.

Implementing Traffic Source Bounce Rate
So how do you implement Traffic Source Bounce Rate?  Like any Bounce Rate metric, you need to be able to calculate Single Access and Entries.  In SiteCatalyst, that means you need Pathing to see these metrics, so you know right off the bat we are going to need a Traffic Variable (sProp).  Once you have identified which sProp you are going to use and had Pathing enabled for it by ClientCare, you need to find a way to get the various Traffic Sources that you use into that sProp.  The ones I commonly use are:

1. SEM
2. SEO
3. E-mail
4. Display Ads
5. Affiliates
6. Social Media
7. Other Websites
8. Typed/Bookmarked (a.k.a. the rest)

The key to this solution is that you need to find a way to identify the Traffic Source of the first click to your site.  This can be done manually in your JS file or semi-automated using the Unified Sources VISTA Rule or the similar Channel Manager Plug-in.  Regardless of the method, what I try to do is to find something that uniquely identifies each online marketing channel.  Usually the best way to do this is through a query string identifier.

Here is how I do this:

SEM – If a click to your website comes from a Search Engine, you should have an identifier (i.e. ?s_kwid=) in the URL.  If you do, you know the Traffic Source is SEM.

SEO -  If the click comes from a Search Engine, but doesn’t have that identifier, it is SEO!

E-mail – When you send e-mails, you should be tracking the inbound clicks with a query string parameter.  If so, set it to something unique for e-mails (i.e. ?eid=) so you know that if you see that identifier in the URL, the Traffic Source is E-mail.

Display Ads – In a similar manner, if you are buying Display Ads, you normally get to choose the destination URL.  Therefore, you can set the destination URL on your site to have another unique identifier (i.e. ?displayid=) so you know which clicks have come from Display Ads.

Affiliates – See Display Advertising (i.e. ?affID=)

Social Media – This one is a bit trickier, but what I do is make a list of the key Social Media sites I want to track and when I see the referring URL contains one of those URL’s, I set the Traffic Source to Social Media.

Other Websites – If all of the above criteria have not been met, but there is a referring URL, set the Traffic Source equal to “Other Website.”

Typed/Bookmarked – If none of the preceding conditions have been met and there is no referring URL, set the Traffic Source to “Typed/Bookmarked.”

Phew!  It sounds difficult, but you should be using different query string parameters anyway in your campaigns area and any good JavaScript developer can do this somewhat easily.  It does require coding (which I don’t do myself!), but maybe Omniture will provide this out of the box one day…

But Wait…There’s More!
Believe it or not, you are not done yet!  Once you have found a way to distinguish the Traffic Source and are passing that into an sProp on the first page of every visit, you are 90% of the way there.  The last step is a bit confusing (techie alert!).  In order for SiteCatalyst to know if a visitor made it beyond their first page of the visit (hence, did not “Bounce”), it needs to see a different value in the sProp at some point during the Visit.  If it doesn’t see another value passed to the sProp, it will assume they didn’t see any other pages and exited the site (your boss won’t want to see a 100% Bounce Rate for every channel – trust me!).  Therefore, when a visitor navigates to a second page in the visit (any page – doesn’t matter which one), you need to force a “dummy” value into the same sProp that you previously passed Traffic Source.  My clever developer, passes in the value “Did Not Bounce” as the dummy value.  I will let those more technical than me discuss the best way to pass this dummy value, but once you have done this, you will have a new sProp that has one value for each of your Traffic Source Types and one extra one for the dummy value.  Since this sProp has Pathing enabled, you will have a Single Access and Entries metric for each of your Traffic Sources and can now calculate Bounce Rate (I recommend using Advanced Search to hide the dummy value and save it as a Custom Report so you don’t confuse your users).

For the most part , this sProp won’t have much value beyond calculating the Bounce Rate since it is really only set on the first page of the visit, but here are some additional goodies:

1. Use Trended reports to monitor Traffic Source Bounce Rates over time
2. Enable Daily, Weekly, Monthly, etc… Unique Visitors on the sProp to see Uniques for each Traffic Source
3. Correlate it to any other sProps that are most important on the first page of the visit (i.e. Referrer, Visit Number, etc…)
4. There is one more cool thing you can do with this, but it is so cool, I need to do a full post about it so stay tuned for my next post…

Final Thoughts
Well there you have it.  I wish it was not so convoluted, but don’t shoot the messenger!  If anyone else knows an easier way to do this, I am all ears.  I apologize for this being a bit more technical/complicated than most of my posts, but I don’t know of a non-technical way to explain this.  Let me know what you think…

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.

While most of you reading my posts are focused on your public website, in this post I am going to share how you can leverage your web analytics skills internally at your organization.  Company Intranets are often times larger than the public website and using the tips I will share here, you can get some big visibility internally and become the hero of your HR team!

Why You Should Care About Your Intranet
Companies often spend a LOT of $$$ on building Intranets.  Unfortunately, not everyone at the company uses the Intranet.  If you can help your internal team show what is working and what is not working on the Intranet, you can help them to save a lot of money.  In addition to the altruistic reasons to track what happens on the Intranet, there are the following selfish reasons:

1. Tagging Intranets is a great way to try new things and get better at web analysis in a safe environment
2. Intranets often have low traffic volume so it is a great way to help cost-justify increased budgets for web analytics (“Mr. CEO, not only does this money go towards tracking the website, it also allows us to track our entire Intranet!” – Just don’t tell them that tracking the Intranet costs all of $1,000 in server calls!)
3. Showing people what is happening on the Intranet does wonders for people inside your organization understanding what the heck you do for the public website!

I have seen situations where a web analytics team has killed themselves trying to get senior executives to see what is taking place on the website and what improvements could be made based upon solid web analysis, only to see the same team get promoted or more budget after spending 2-3 weeks showing what takes place on the Intranet (something that they actually use)!  It sounds completely illogical, but I guess if you can’t beat them, join them!

Tracking Intranets
So what should you track on Intranets?  The following are my best practices learned working with a few large clients.  The one caveat to everything below is that you have to be sure to track all of this data in a different report suite than all of your other website data!

Employee ID
Depending upon the security policy of your company, ask if you are able to track down the the Employee ID level.  I tend to not do this since it can be a bit creepy, but it is technically possible and you can replace the Omniture Visitor ID with your own unique employee identifier.

Non-Personally Identifiable Employee Info
On each Intranet page, I recommend that you pass Department, Region, Business Unit, Office Location, Employee Band Level (i.e. VP, Manager), etc… to variables.  This will allow you to break down all Pages by these data points.  I generally pass these to an sProp and an eVar (save some time setting both through this post) and also recommend you put your top five of these into a 5-item Traffic Data Correlation.

Pages & Sections
Obviously, you want to pass in a unique page name for every Intranet page like you would any other website.  In addition, you should pass the Intranet section to the Site Sections (Channel) variable.  As always, I recommend that you enable Pathing on the Channel sProp so you can see how employees are navigating between Intranet sections.

Internal Search
Just like a public website, Internal Search is usually important on Intranets.  You should track Internal Search on the Intranet just as you would on a public website.  You can apply the same principles I mentioned in this Internal Search post.  This includes tracking what search terms people are looking for, but the beauty here is that you can see these by Department, Region, etc…

Timeparting
Many of my Intranet clients were keen to see when employees were accessing the Intranet, so I recommend you implement the Timeparting Plug-in.  This allows you to see what day of the week and time of the day employees access the Intranet.  Don’t forget to create a correlation between these sProps and your other ones so you can see when each page/section is accessed most often.

Internal Promotions
Much in the same way that I described Internal Campaigns in the past, Intranets may have promotional areas that try and entice employees to click.  You can track these the same way you would a public website.

Intranet KPI’s
The following are the types of KPI’s I have seen used for Intranets:

Page Views/Visit & Average Time Spent/Visit
Depending upon whether your goal is to get employees in and out or get them to spend more time reading Intranet content, you can use this calculated metric to see how you are doing.

Page Views (Event)
As I described in this post, I would recommend that you set a Success Event on each page.  Why?  Well let’s say you want to see how many pages on the Intranet a specific internal e-mail led to.  You can open the Campaigns report, find the e-mail and then see how many pages were viewed.  You can then use an eVar Subrelation to break this down by page name (as long as you pass Pagename to an eVar) to see the exact pages viewed.

Internal Searches
As you would on a website, you should track and trend the # of Internal Searches taking place on the Intranet.

Logins
If employees have to log into your Intranet, you can capture that as a KPI to see how you are doing at getting them to access the Intranet.  This can also be used for segmentation (i.e. show me all users who have not logged into the Intranet in the past 30 days…)

Custom KPI’s
Many times, Intranets are used to get employees to fill out forms, surveys, etc…  Each of these key actions should be captured with a Success Event and in the case of Forms, you should capture the Form Name in an eVar so you can break it down appropriately.

Employee Profile Views
As we march down the road of internal social media, it is fun to track how often each employee’s Intranet Profile is viewed.  Using new tools like my company’s upcoming “Chatter” product (see shameless plug video below!), we may be moving to a world where employees get “followers” so you can track how often people are looking at or following other employees.  This allows you to see who your employees think are important (which may not always align to the org chart!).

Final Thoughts
As you can see, if you know what you are doing for tracking a public website, tracking an Intranet uses many of the same principles.  If you are just getting started in web analytics, feel free to apply the above items on your Intranet as a testing ground before you tackle the public website.  If you have some other cool things you have done to track your Intranet, please 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.  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, Ben Gaines (@OmnitureCare) wrote a great blog post about tracking Internal Search.  In this post, I am going to add a few additional tips I have learned over the years…

Correlate Internal Search Term & Page Searched From
Knowing what people searched for on your site is certainly valuable, but knowing the exact page they searched for each term from is even more valuable.  Having this allows you to see what content visitors think they should be able to find on each page.  This is like gold to your content folks who can look for terms that are consistently searched for on a specific page and make a case that they need to add or improve content.

Setting up SiteCatalyst to do this is very simple.  All you have to do is pass the Internal Search term to a Traffic Variable (sProp) (as Ben showed) and then set a second sProp with the previous page name value (use the Previous Value plug-in) and create a Traffic Data Correlation for these two sProps.  When you are done, you will be able to see two cool things:

1) What terms are searched for on a specific page:

2) For any given term, what pages are visitors searching for that term:

Group Internal Search Terms
In Ben’s post, he discussed how to eliminate duplicate terms by taking upper/lower case out of the equation.  In addition to this, there are times when you might want to group specific keywords together into buckets since they represent the same type of search.  For example, if you manage a travel site, you might want to group all City internal search terms by State and Region so you can supplement your analyses.  This is easily done by taking advantage of SAINT Classifications which allow you to bucket your internal Search Keywords however you would like.  Here is an example of a SAINT File you could use in the preceding example:

Use Compare Feature to find differences between Dates
Once you are tracking internal search terms, you can use the Date Comparison feature in SiteCatalyst to see how the same internal search terms perform in two different time periods.  You access this feature from within the SiteCatalyst Calendar window.  Below is an example of looking at how the top internal search terms for September perform in October:

As you can see, by using the date comparison feature, SiteCatalyst will show you the difference between the two time periods so you can be aware of significant changes.  Simply click the difference column and you can see the search terms that changed the most/least (depending upon whether you sort ascending or descending).

Use Compare Feature to find differences between Report Suites
In a similar manner, if your implementation has multiple report suites (or ASI Segments), you can use the Compare feature to see how internal search terms vary by suite/segment.  For example, if you have a Customer Segment and a Non-Customer Segment, you can see what internal search terms each group is looking for:

In the above report, we can see that Non-Customers are more apt to search for careers, while Customers are more interested in detailed product information.

One cool thing you can do with this is to combine this data with Test&Target by FTP’ing the most popular search terms to a Word Cloud program and having Test&Target show the appropriate Word Cloud based upon a cookie value indicating customer status.  That is a great way to proactively use your web analytics data to create a better experience for your users!

Trend Search Page Exits
One way to see how good or bad your internal search results are is to look at how often visitors exit your sie on the search results page.  While this isn’t a guarantee that your search results are bad, most of my clients agree that search results page exits are not normally an indicator of success!  Therefore, I like to trend this and set alerts to monitor this.  Here are the steps to do this:

1. Open your Pages report and find your Search Results page in the list
2. Click on its name and in the sub-menu choose Paths – Next Page report
3. Unfortunately, Exited Site might be one of your highest next pages, but in this case it is a good thing since you that makes trending it easier (I haven’t figured out how to trend it id it isn’t in the Top 5!).  Once you are looking at your list of Next Pages, click the “Trended” link to see the top five next pages trended.
4. From here, I usually refine the report to only show the Exited Site and Home Page (for some reason SiteCatalyst won’t let you see just “Exited Site” so you need to have one other value – not sure why – so I normally choose Home Page)
5. Finally, change your date range and View by (i.e. day, week, month) and you will see a report like the one below where I am trending Exits and clicks to the Home Page by percent over time.  You can now add this graph to a dashboard to monitor it over time…

Use Counter eVars!
There are two ways you can use Counter eVars with internal search.  First, per my last blog post, you can use the # of Pages Counter eVar concept to track how many pages visitors view prior to doing a search to see how your website design is functioning.  I showed this in my last post:

Second, you can track the # of internal searches in a counter eVar so you can see how many internal searches each visitor has done prior to completing your desired success event.

Track Recommended/Filtered Search Results
Many companies provide internal website searchers with recommended search results or filtered results based upon the search term as shown here:

You can use SiteCatalyst to track whether the visitor clicked on your organic links or the recommended/filtered links.  All you need to do is add a query string to links in each distinct area and capture that in an eVar when visitors click on these links.  For example, the eVar values may be “organic link click” or “filtered link click” which will show you the distribution.  You can take it further by passing this to an sProp and correlating it to the search term to see which internal search terms lead to visitors clicking each type of result.

These are just a few of the fun things you can do with internal search tracking…

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.

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.

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.

Thanks to all of you who took the time to complete my SiteCatalyst quiz.  I hope it was a fun way to put your knowledge to the test.

So for the rest of this post, I will show how people answered the survey and point out what answers I was looking for.  When looked at as an entire population, if I include anytime someone got the correct answer, the majority of people got 10 correct answers out of 15 (66.67%).  However if I just look at just those responses where the exact right answer was given (no incorrect answers included where you could check off multiple boxes), the average score went down to about 6 out of 15.  However, please bear in mind that I am not an educator so if you interpreted a question differently than I did and gave a different answer, it is probably my fault not yours so don’t lose any sleep over it!  On the bright side, one (anonymous) individual in Europe got 14/15 correct (I am resisting the urge to find you by IP address and hire you!).  Either way, I strongly encourage you to look at your answers and see which ones you missed and read the linked posts below so you can become a SiteCatalyst Ninja!!

Question #1 (Correct Answer=Traffic Variables (sProps))
This first question was intended to be an easy one.  Think of it as a way to build engagement and not scare you off.  Most of you got this answer correct, but I was surprised to see that 33% of you thought that you could enable Pathing on more than just Traffic Variables (sProps).  Keep in mind that one of the main reasons to use sProps is to enable Pathing.   If you need a refresher, please check out my past posts on Traffic Variables (sProps) or on Pathing.

Question #2 (Correct Answer=True)
For many of these True/False questions, it is hard for me to tell if you got the right answer based upon knowledge or luck, but I am going to give you the benefit of the doubt!  In this case 75% of you were correct in saying that it is possible to share a segment with other users in your company.  I show how to do this in my past post about the Admin Console.  Keep in mind that you can only share a segment within one report suite so if you have multiple report suites you are out of luck.  If you really need to share segments across multiple report suites, the only way I know to do this is to create them under a shared Omniture User ID and give that ID to multiple users so they can see the segments owned by that ID.

Question #3 (Correct Answer = ZERO)
This question is admittedly a difficult one.  To get this one right, you would have had to really been in the trenches with SAINT Classifications.  Those who have ever tried to classify a variable that has a value of “0″ in the Key column have probably learned this the hard way.  While you can classify a value of “1″ or “43,” there is no way to classify a Key value of “0″ in SiteCatalyst.  Therefore, you need to pass in a text value for “0″ so you can classify it later on.  Therefore, the best answer to this question is the 3rd answer below “ZERO.”

Question #4 (Correct Answer=When a Success Event takes place or after a specified Time Period)
You guys knocked it out of the park on this one.  The correct answer here is that an eVar can be expired when a Success Event takes place or based upon a time period.  This happens to be one of my pet peeves since I really wish you could expire an eVar based upon a Success Event or a time period (whichever comes first).  There are many cases where having this ability would have saved me a lot of time.  Maybe in a future release (or all of you can help me by requesting this as a feature request!).

Question #5 (Correct Answer=True)
Most of you got this one right as well.  One of the cool things about classifying Conversion Variables (eVars) is that if you have paid for full subrelations on the eVar it is based off of, you get full subrelations on all of the Classifications.   This can save you time and money!

Question #6 (Correct Answer= All but Conversion Variables (eVars))
This question was a hard one and another one of my pet peeves.  The correct answer is the second one “Conversion Variables (eVars).”  The security features in the Groups area of the Admin Console are very good and a much better way to hide reports from select groups of users than the Menu Customizer.  However, for some unknown reason, you can hide pretty much everything in SiteCatalyst except Conversion Variables (eVars), which are some of the most critical reports!  I am not sure why this one thing was omitted and I have been asking for this for some time.  Hopefully it is on the product roadmap.

Question #7 (Correct Answer=None of the Above)
This question probably caused some confusion due to the wording, but the correct answer here is “None of the Above” since I was looking for the best way to assign credit across multiple visits.  Most of you fell for the trap I set here and chose “Linear Allocation.”  Many people I talk to think that Linear Allocation of an eVar works across multiple visits, but it does not.  Linear Allocation only works within a visit (for the most part, but the details are a bit confusing!).  Therefore, the real best answer for this question was Cross-Visit Participation which I covered a while ago.  Cross-Visit Participation is the only real way to assign credit to an eVar across multiple visits.  If you are not familiar with Cross-Visit Participation, please review my previous post.

Question #8 (Correct Answer=None of the Above)
Importing offline or external data via Data Sources is a more advanced topic, but many of you look like you are familiar with it.  The majority of you got this one correct since none of the options provided here will allow you to back out data sources metrics.  For this reason you have to be extremely careful when importing Data Sources data since there is really no going back if you make a mistake!

Question #9 (Correct Answer=False)
This is one of those questions you used to get from your teacher and absolutely hate them afterwards when they told you the answer, so I will apologize in advance.  The key phrase here is “the only difference” so the correct answer here is “False.”  While the difference cited here is correct, there is one really big difference between Correlations and Subrelations that you need to know.  That difference is that you can correlate two sProps, five sProps or twenty sProps with each other, but with Subrelations it is an all or nothing proposition.  It would be great if you could Subrelate just two eVars together, but that is not currently possible like it is for sProp Correlations.  This is a key thing that every SiteCatalyst Ninja must know!

Question #10 (Correct Answer=Unique Visitor Counts an Pathing)
Most of you got this one correct.  The key disadvantages of Roll-ups are that they don’t de-dup uniques and you cannot do Pathing analysis.  But hey, they don’t cost a lot!  Personally, I tend to not use Roll-ups since I can duplicate a lot of the info they provide using the ExcelClient and I like Pathing and de-duped Unique Visitors so I tend to favor Multi-Suite tagged sites.

Question #11 (Correct Answer=Calculated Metrics)
Great job on this one as most of you got this one correct!  In my post about Conversion Funnels I explained all of the ways they can be used and highlighted what, in my opinion, is an oversight of the functionality that you cannot add Calculated Metrics to them.  I hope this ability will be available at some point in the future, but in the meantime, you should keep this in mind when determining whether you should pass in a metric organically or rely on a calculated metric.

Question #12 (Correct Answer=Page Views)
In this question, I allowed you to choose from the following metrics.  While most of you got this correct that the Page Views metric is available in Traffic Variable Correlations those of you who also said that you could add Visits, DUV’s and MUV’s were not correct.  Please keep in mind that only Page Views are available when using Correlations.

Question #13 (Correct Answer=Classifications cannot be used in DataWarehouse Segments)
I had a hard time figuring out how to word this question, but if you really understand SAINT Classifications, you should have been able to get this one right by the process of elimination.  As you can see, most people had a hard time with this one, but the correct answer did emerge in the end as the only true statement below is that Classifications cannot be used in DataWarehouse Segments.  We can deduce this by understanding that 1) Classifications can be used in correlations/subrelations, 2) Classifications can be used in Omniture Discover and 3) Classifications cannot have pathing enabled in SiteCatalyst (You can, however, apply Pathing to classifications in Omniture Discover, which you can read about in this post on Page Type Pathing).

Question #14 (Correct Answer=False)
While I have been using Advanced Segment Insight (ASI) segments for many years, I only recently figured out that you can change the ASI type from recurring to time slice and vice versa if you know what you are doing so the correct answer below is actually False (the whole double-negative thing!).  If you have a static ASI that has run for say last month, you can use the “Add Data” link to bring up the ASI segment set-up screen, change the type to Daily Recurring and make the start date the day after your ASI last ran.  Just be sure to uncheck the box that asks if you want to remove existing data or you will lose your past ASI data.  If the ASI you already have is a Daily Recurring, simply wait until it has finished its daily processing and click the “Cancel” link.  Once you have cancelled it, you can click the “Add Data” link, make the type “Time Slice,” select your dates and set it to run.  Again you have to be sure to uncheck the remove existing data checkbox.  I am not sure if this is “officially” supported, but I have done lots of testing on it and so far it has worked fine…

Question #15 (Correct Answer=>!)
This last question is one of those “inside secrets” that only true SiteCatalyst Ninjas know.  Unfortunately, only 32% of you got this one right as the correct answer is “>!” which is a way to tell if a value exists or not in a specific variable when using the segment builder.  I covered this in my Tips & Tricks are of the Segment Builder post so if you didn’t get this one correct, check out that post which has lots of goodies in it.

Well, there you have it.  Hopefully this was a fun way for you to see some of the things that SiteCatalyst Ninjas know.  If you keep reading my blog posts, I can (almost) guarantee you will learn everything that there is to 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.  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.