Adam Greco's Blog at Web Analytics Demystified

(Estimated Time to Read this Post = 3 Minutes)

Robots are cool.  I like robots when they build cars, try to plug oil spills and clean carpets.  The only types of robots I don’t like are the ones that hit websites repeatedly and throw off my precious web analytics data!  Do you have a problem with these types of robots?  Would you know how to see if you do?  I find that many web analytics customers don’t even know how to see this, so in this post I will share what I do to monitor robots and hope that others out there will share other ways they deal with robots.

Why Should I Care About Robots?
This is often the first question I get.  Who cares?  Here are my reasons for caring about minimizing robots hitting your site:

1. If you use Visits or Unique Visitors as part of any of your website KPI’s (i.e. Revenue/Unique Visitor), you should care because robots are inflating your denominator and dragging your conversion rates down
2. If you are tasked with reducing Bounce Rates on your site, you should care as robots will often be seen as bounces
3. Omniture (and other web analytics vendors) often bill you by website traffic (server calls) so you may be paying $$$ for junk data
4. Often times web analytic KPI’s have razor-thin differences month over month and having a lot of garbage data can mean the difference between making a good and bad website business decision

Do I Have a Problem?
The first step is to identify if you have a problem with robots.  Unfortunately, SiteCatalyst does not currently have an “out-of-the-box” way to alert you if you have a problem (@VaBeachKevin has added this to the Idea Exchange so please vote!), but in the meantime, here is my step-by-step approach to determining this:

• Create a recurring DataWarehouse report that sends you Page Views and Visitors for each IP address hitting your site (If you store the Omniture Visitor ID in an sProp, I would use that in place of IP address).  This can be daily, weekly or monthly depending on how much traffiic your website receives.  I sometimes add the Country/City as well (you’ll see why later).

• When you receive this report, it should look something like this:

• Once you have the data, I create a calculation which divides Page Views by Visitors and then sort by that column (if you have a lot of data from different days/weeks, you can create a pivot table).  The result should look like the report below where you will start to see which IP addresses are viewing a lot of pages on your site per visitor.  Keep in mind that this doesn’t mean they are all bad.  It is common for small companies or individuals to share IP addresses.  The goal of this step is just to identify the IP addresses that might be issues.  In the example below, you can see that the the top two IP addresses appear to be a bit different than the rest.  While it may make you feel good that these unique visitors liked your website so much they viewed thousands of pages each, you might be fooling yourself!

• Once you have this list, I like to do some research on the the top IP Address offenders.  You can do this via a basic Whois IP Lookup or you can invest in a reverse IP lookup service.

What Do I Do If I Find Robots?
If after reviewing the top offending IP addresses you find that you do, in fact, have a robot hitting your site, you have a few options:

1. Work with your IT group to exclude these IP addresses from hitting your website.  This is your best option since it will be the most reliable and reduce your web analytics server call cost.
2. Work with Omniture’s Engineering Services team to create a DB Vista Rule that will move these website hits to a new report suite so it will not pollute your data.  The best part of this option is that you don’t have to engage with your IT team and you can add/remove IP addresses anytime you want via FTP.  Unfortunately, you will still be hit with server call charges for this (not to mention the cost of the DB Vista Rule!), but if you also pass data to Omniture Discover, you might save money there by not passing bad data to Discover.
3. Work with Omniture’s Engineering Services team to build a custom solution for dealing with robots…

Employee Traffic
While I don’t want to imply that your co-workers are robots, I wanted to mention employee traffic in this post as well since it is tangentially related.  I find that many Omniture customers don’t exclude their own employees from their web analytics reports.  This can be a huge mistake if you have a lot of employees or have employees who actively use the website.  For example, at my employer (Salesforce.com), we use our website to log into our internal systems which are all run on Salesforce.com!  This means that we have thousands of employees hitting our website every day to log in to our “cloud” applications and that traffic should not count towards our marketing/website goals.  Therefore, we manually exclude all employee traffic from our reports by IP address to minimize the impact of employee traffic impacting our KPI’s.  While we don’t consider this to be robot traffic, we address it in the same manner by passing employee traffic to its own report suite.  One cool by-product of placing employee traffic in its own report suite is that you can see how often your own employees are using your website so you can show management that the dollars they give you serve multiple audiences!

Final Thoughts
As I stated in the beginning of this post, this is just one way to investigate and deal with robots.  If you have other techniques, please share them here!  Thanks!

Posted Monday, September 20th, 2010 | 7 responses | Share, Save or Email

(Estimated Time to Read this Post = 4 Minutes)

Recently, I was re-reading one of Avinash Kaushik’s older blog posts on tracking Internal Search Term Exit Rates and realized that I had never discussed how to report on this using Omniture SiteCatalyst.  In a past Internal Search post, I covered many different things you can do to track internal search on your site, but did not cover ways to see which terms are doing well and which are not.  In this post I will share how you can see this so you can determine which search terms need help…

Why Track Internal Search Term Click-Through & Exit Rates?
So why should you do this?  In the era of Google, we are all slowly being trained to find things through search.  Many of my past clients saw the percent of website visitors using search rise over the past few years.  In addition, Internal Search and Voice of Customer tools are some of the few out there where you can see the intent of your visitors.  Unfortunately, most websites have horrible Internal Search results which can lead to site exits.  In my previous Internal Search post I demonstrated how to track your Search Results Page Exit Rate, but that only shows you if you have a problem or not.  If you do have a high Search Results Page Exit Rate, the next logical step is to determine which search terms your users think have relevant search results and which do not.  Note that this is not meant to show you which terms lead directly to website exits, but rather, which terms cause visitors to use or not use the search results you offer them after they search on a particular term.

How Do You Track Internal Search Term Click-Through & Exit Rates?
Ok, so how do you do this?  Follow the following implementation steps:

• Make sure that you are setting a Success Event when visitors conduct Internal Searches on your website.  Hopefully you are already doing this so in many cases this step will be done!
• Make sure that you are capturing the Internal Search Term the visitor searched upon in an eVar variable.  Again, you should be doing this (if not, shame on you!).
• Here is where we get into uncharted territory.  The next step is to set a new Success Event when visitors click on one of the items on the search results page.  Depending upon the technology you use for Internal Search, this could be hard or easy.  Regardless of how you actually code it, the key here is to set the second Success Event (I call it Internal Search Results Clicks) only if visitors click on a search result item (not if they click on a second page of search results or go to another page through other navigation).  It is also critically important that you only set this Search Results Clicks Success Event once per search term!  Do not set it every time a visitor clicks on one of the search results after using the “Back” button.  If you don’t do this correctly, your Click-Through and Exit Rates will be off.  This could take a few iterations to get right, but stick with it!
• Once you have both the Internal Searches and Internal Search Results Clicks Success Events set, you can create a Calculated Metric that divides Internal Search Results Clicks by Internal Searches to see the Internal Search Click-Through Rate as shown here:

• From there you can create the converse metric which subtracts the Internal Search Click Through Rate by “1″ to come up with the Internal Search Exit Rate as shown here:

• After this is done, you can open the Internal Search Term eVar report and add all three metrics so you see a report like this:

In this case, it looks like the “Zune” Internal Search term might need some different search result content as it has a much higher exit rate as the others.  Another cool thing you can do is to create a report which trends the Internal Search CTR % or Exit % for specific Internal Search terms so you can see if they have been good/bad over time.  Also, if you use SAINT Classifications to group your Internal Search Terms into buckets, you can see the report above for groups of Internal Search terms.  If you vote for my idea in the Idea Exchange, you would be able to set SiteCatalyst Alerts to be notified if your top Internal Search Terms have spikes in their Click-Through or Exit Rates.  You can also segment your data to see how the Internal Search rates differ when people come from Paid Search vs. SEO, etc… and even use Test&Target to try out different promotional banners on your search results page…

Finally, don’t forget that when you create a new calculated metric like the Internal Search CTR % metric described above, you also get the bonus of seeing this metric across your entire website under the My Calc Metrics area of the SiteCatalyst toolbar.  Simply find this new metric and click on it and you can see your overall Internal Search Click-Through Rate regardless of internal search term.  Your report will look something like this:

For The True Web Analyst Geeks
If you were bothered when I mentioned above that you should only set the Search Results Clicks Success Event once per search term, then you are my kind of person (please apply for a job with me!)!  You were probably saying to yourself: “If I only count once per search term, how will I know which search terms get visitors to click on multiple search result links?”  Right you are!  That could be valuable information.  If you want to see that as well, all you have to do is set a second Success Event each time a visitor clicks on a search result [I call this Internal Search Result Clicks (All)].  Then you can compare how many times people click on any search result to how often click in total.  Here is a sample report:

In this example, you can see that the search term “api” had one click only in either scenario, but the search term “chatter” had people click on it 100% of the time and 5 times they clicked on two search result items.  If you want, you can create another Calculated Metric that divides the Internal Search Result Clicks (All) by the # of Internal Searches to see how many search result clicks each term averages.  In the case of “chatter” above, it would be 2.25 search result clicks per search!

Final Thoughts
If Internal Search is important to your site, make sure you are tracking it adequately so you can improve it and increase your overall website conversion.  Do you have any other cool Internal Search tracking tips I haven’t covered?  If so, leave a comment here…

Posted Tuesday, September 7th, 2010 | 3 responses | Share, Save or Email

(Estimated Time to Read this Post = 5 Minutes)

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

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

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

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

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

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

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

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

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

…to see a report like this:

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

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

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

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

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

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

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

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

Posted Monday, August 23rd, 2010 | 7 responses | Share, Save or Email

(Estimated Time to Read this Post =3 Minutes)

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

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

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

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

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

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

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

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

…so you can see a report like this:

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

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

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

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

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

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

Posted Monday, August 9th, 2010 | 2 responses | Share, Save or Email

(Estimated Time to Read this Post = 4 Minutes)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Posted Monday, July 26th, 2010 | 6 responses | Share, Save or Email

(Estimated Time to Read this Post = 3 Minutes)

[I apologize in advance for such a horrible blog post title, but I couldn't think of a succinct way to describe what I intend to cover.  Maybe one of you out there will have a better suggestion after reading the post!]

If your website is like many I have seen, you get a fair amount of daily visits and unique visitors, but it may be the case that a large number of your visitors don’t go beyond the first few pages of your site.  When I see this, I get very frustrated when I think about all I have done to get people to my site and optimized the site for my designated conversion goals.  But as web analysts, we need to put our emotions to the side and get down to the numbers.  Therefore, one of the things I like to do is to quantify how big of a problem my website has with visitors who only view a small number of pages.  In this post I will show you how to quantify this so you can begin to take action on addressing this issue.

The Setup
Before I get too deep into this topic, I’d like to setup the scenario since I think this will help it make more sense.  Let’s say that the main purpose of your website is to get visitors to view and complete lead generation forms.  Let’s also say that on your website you see that your most significant drop-off takes place after the third page of each visit.  In this situation, you might have lots of Visits and relatively few Form Completes so that your Conversion Funnel looks like this:

As you can see in this funnel, there is a pretty significant gap between Visits and Form Views.  While that presents a huge optimization opportunity, I like to break massive efforts like this into smaller chunks that I can work towards (or as Avinash points out – Micro-Conversions).  Since we noted earlier that a large portion of visits exit after three pages, wouldn’t it be nice if we could bridge the gap between our Visits metric and our Form Complete metric in the funnel above?  Having a middle ground between these Visits and Form Views might get our team to think about ways to turn more Visits into Visits of four pages or more which, depending upon your site, might be a step in the right direction.  In many sites I have worked with, there is a direct correlation between visitors viewing more pages and higher form conversion rates.

X+ Visits Explained
Now that we have set-up the situation,it becomes a bit easier to understand what I mean by “X+ Visits” since I am really saying that you can set a new Success Event metric which represents how many Visits your website gets where the visitor viewed more than “X” Pages.  What “X” represents is up to you and should be based upon your own data.  In this example, we will say that we are going to call it “4+ Page Visits” meaning the number of Visits in which Visitors viewed four or more pages.

The implementation of this is very easy for any good JavaScript developer since all that is involved is setting a Success Event as soon as each Visitor hits the fourth page of the session.  Once you have done this, you can update the conversion funnel shown above to look like this:

While this may not seem like much of a difference, here are some cool things you can do once you have this implemented:

• Create a Calculated Metric to divide 4+ Page Visits by Total Visits to see what % make it to four pages and trend this over time to see if you are getting better or worse

• Use the filter feature of the conversion funnel to see your funnel by Visit Number or Traffic Source (i.e. SEO) to see how each impacts the mix of Visits and Visits of four or more pages

• Create a calculated metric for the inverse (in this case three pages & fewer) by subtracting 4+ Page Visits from Visits.  I also like to pass both to Excel using the ExcelClient to create a stacked graph like this to show progress

Final Thoughts
There you have it.  If you find that you consistently have significant website drop-off after a few pages, hopefully, this new metric will help you better dissect what is happening so you can “Micro Conversion” your way to more Macro Conversion!

Posted Monday, July 12th, 2010 | One responses | Share, Save or Email

(Estimated Time to Read this Post = 2.5 Minutes)

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

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

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

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

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

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

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

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

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

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

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

Posted Tuesday, July 6th, 2010 | One responses | Share, Save or Email

(Estimated Time to Read this Post = 3.5 Minutes)

Imagine that you are in a retail store and you grab a bunch of items, bring them up to the counter and just as you are about to pay, you decide to push a few of the items off to the side and not include them as part of your purchase.  While this may not happen too often in real life, it happens quite often in eCommerce.  If you are a retail website, these discarded items can add up quickly!  In this post, I am going to show you how to quantify how much money you are leaving on the table.  For those not involved in a Retail site, I will also do my best to show how this concept can be applied to non-Retail sites.

The Standard Cart Process
So before we get to the more advanced stuff, let’s make sure we are all on the same page when it comes to the eCommerce shopping cart process.  Normally, here’s how it works:

1. Visitors view products on your website and you capture this with a Product View Success Event and store the products viewed in the Products Variable.
2. At some point, visitors add items to the shopping cart and you set the Cart Add Success Event and the Products Variable with the product ID or name(s).
3. Hopefully, visitors get to the Checkout Page and you set the Checkout Success Event and the Products Variable with the Product ID or name(s).
4. Finally, the order is completed and you set the Purchase Success Event which sets the Orders, Units and Revenue Success Events for each Product purchased.

Hopefully this is straightforward and if you sell online you have successfully implemented these steps on your site.  If so, you are ready to take things to the next level and do some stuff that is not traditionally done as part of standard eCommerce implementations.

How Much $$$ Left on the Table?
As the post name implies, in this scenario we would like to see how much $$$ we are losing online by website visitors leaving items in their Cart.  If you think back to the initial scenario above, this is equivalent to the Retail store adding up how much they could have made that day if no one had left stuff on the counter when they were checking out.  In addition to seeing how much $$$ is being missed out on, the store owner would probably want to know what products are being left to see if there are any patterns he/she could identify.  For example, it may be the case that items over $100 are left more often than products under $100, etc…

Well the good news, is that if you are doing business online, this much easier and you can see a lot more data on the items being abandoned and those who abandon them.  So here’s how you do it:

• When a website visitor adds one or more products to the shopping cart, in addition to setting the Cart Add Success Event (scAdd), you should set a currency Incrementer Event with the dollar amount associated with the items added.  As a refresher, an Incrementer Event allows you to pass in a numeric/currency value to a Success Event instead of using it as a counter.  By passing in the amount associated with the items added the Cart, you will have a new metric which represents the total potential that you could have made had no one left anything in the cart.  I call this new metric $$$ Added to Cart.



• Once this is done, you can compare this “$$$ Added to Cart” metric with your Revenue metric, either in a conversion funnel report or in a normal Conversion Variable (eVar) report by creating a Calculated Metric dividing the two metrics to see what % of $$$ Added to Cart turns into Revenue.

• If you want to be even more particular, you can set another incrementer event with the $$$ that the visitor has in the Cart at the time of Checkout.  However, if you find that you don’t have much loss between Cart Add and Checkout or between Checkout and Purchase, this may prove to be unnecessary.
• Finally, since you are setting the Products variable with the Cart Add event already, when you compare these two metrics, you can easily break it down by Product (or any other eVar variables you have set previously).

Beyond Retail
As promised, I wanted to touch upon a few ways you could use this same concept if you manage a non-Retail website.  Here are a few that come to mind:

1. On a Financial Services site, pass in the total loan amount a person is requesting and compare that to how much they are eventually loaned.
2. On a Media site, pass in the total amount of advertising your site could have earned if all ads were clicked.
3. On an Auto site, pass in the total value of cars visitors configure to see your max potential.
4. On a Lead Generation site, pass in a value for ever visitor who starts completing a lead form.
5. On a Travel site, pass in the total value of trips planned online and compare it to the amount actually booked.
6. On a Manufacturing site, pass in the total Bill of Materials value the visitor has added.

As you can see, the concept of seeing what your high-end potential is and comparing it to actual performance can be applied to almost any website and gives you another data point for comparison.  I like using this metric better than Visits or Unique Visitors since it is not realistic that you are going to convert every person who comes to your site.  However, once a visitor takes some more deliberate actions, they are self-qualifying themselves, and therefore, capturing their potential revenue streams gives you a high, but realistic goal to strive for and a KPI that you can use to see how you are doing over time.

Final Thoughts
So there you have it.  Just a quick, easy way to add some more data to your all-important shopping cart process.  In general, I feel like Incrementer success events are under-utilized by SiteCatalyst users so hopefully this example helps to get your mind working in new and inventive ways to use them…

Posted Monday, June 28th, 2010 | 2 responses | Share, Save or Email

(Estimated Time to Read this Post = 3.5 Minutes)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Posted Monday, June 21st, 2010 | 2 responses | Share, Save or Email

(Estimated Time to Read this Post = 2.5 Minutes)

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

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

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

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

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

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

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

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

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

Posted Monday, June 14th, 2010 | 13 responses | Share, Save or Email