Archive for 'Pathing'

(Estimated Time to Read this Post = 4 Minutes)

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

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

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

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

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

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

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

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

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

…to see a report like this:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Final Thoughts
So there you have it.  A quick hack in case you ever need to calculate Site Wide Bounce Rate for your HIPPO’s!  Enjoy!

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

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

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

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

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

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

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

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

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

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

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

Final Thoughts
These two posts should cover pretty much all you need to know about SiteCatalyst comparison reports.  If you are using them in any other creative ways, please leave a comment here.  Thanks!

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 page names 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…

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!

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…

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…

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 Salesforce.com Chatter, 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…