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

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

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

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

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

Here is how I do this:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I know many Omniture clients that spend much of their time using SiteCatalyst for SEO and SEM tracking.  If you are one of these clients, the following will show you a fun little trick that you can use to improve your Search reporting by setting custom Search Success Events.

That Darn Instances Metric!
As a Search marketer, you tend to spend a lot of your time in the various Paid and Natural Search Engine reports within SiteCatalyst.  While in those reports, you would normally use the out-of-the-box “Searches” metric for most of your reporting.  If you stay in the Search reports, life is good, as you can use the Searches metric and any other Success Event to see what success takes place after visitors arrive from a particular Search Engine or Search Keyword.  For example, here is a report that shows Searches and Form Completions coming from various Search Engines:

However, as I blogged about a while back in my Instances post, the Searches metric is really a really a renaming of the dreaded SiteCatalyst “Instances” metric.  Why is that bad?  It means that if you need to see Searches in any other Conversion Variable (eVars) report, you are out of luck.  For example, let’s say that your boss wants to see a report that shows Searches and Form Completes (and possibly a Calculated Metric that divides the two) by Site Locale (each country in which you do business).  To do this, you would open the Site Locale eVar report and add Form Completes, but guess what…there is no “Searches” metric to add to the report since it only exists in the Search Engine reports!  Rats!

Let’s say you are an eternal optimist and you say, darn it, I can solve this!  I’ve read all of Omni Man’s blogs and there has to be a way to do this.  After pouring over past blogs, you finally arrive at the perfect answer!  I can use Conversion Subrelations to break the Search Engine report down by Site Locale while the Searches metric is in the report!  So you go back to the Searches report shown above and realize that all you have to do is use the green magnifying glass icon to and break the report down by the Site Locale eVar (which BTW will only work if Site Locale has Full Subrelations enabled).  I’m a genius, you think to yourself!  Then you wait for the report to load…brimming with anticipation only to see this…

Yuck!  What’s up with all of the “n/a” values?  Foiled again by the darn Instances metric!

Don’t Panic!
Don’t be so hard on yourself since if you got that far, you are ok in my book!  Just consider this a well earned lesson on why you have to be careful around any Instances metric (don’t fall for the same thing with Product Views!).  As always, I don’t like to just present problems since the Omni Man is all about solutions!  To solve this enigma, we have to find a way to get around the Instances metric.  At a high level, the solution is to set custom Success Events when visitors arrive at your site from a Search Engine.  I usually set a Natural Search, Paid Search and Paid + Natural Search metrics.  This can be done in several ways, but the easiest way is through the Unified Sources Vista Rule or the JavaScript equivalent known as the Channel Manager Plug-in (I recommend talking to Omniture Consulting about implementation details).  Regardless of how you implement it, once you have true custom success events set when visitors arrive from a search engine, you can use these success event anywhere within Omniture SiteCatalyst which means that you can now create the report you were looking for above like shown here:

The following are some other advantages of using a custom success events for Searches:

1. You can use these metrics in Calculated Metrics (i.e. Shopping Cart Additions/External Natural Search) without having to rely upon the ExcelClient
2. You can create Alerts on Paid or Natural Search metrics
3. You can add some cool SiteCatalyst Plug-ins or advanced features to the new Custom Search success events that make them even better than the out-of-the-box Searches metric (i.e. Avoid back button duplicate counting by using the getValOnce plug-in or Event Serialization).
4. You have an easy way to create a metric report for Searches (see below) and add it to a SiteCatalyst Dashboard

The only caveat I will give you is that the new custom Search metrics will probably never tie exactly with the out-of-the-box metrics, but in many cases you can make them more accurate and useful.  If SEO/SEM is something that is important to your organization, I suggest you talk to Omniture Consulting and give it a whirl…  Let me know if you come up with any other cool uses for this functionality…

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

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

While there are many great out-of-the-box reports in Omniture SiteCatalyst, there is one key limitation to them that can cause problems from time to time.  This limitation is that you cannot apply  SAINT Classifications to out-of-the-box reports.  In this post, I will demonstrate why this can cause issues and how I get around this limitation.

What’s The Big Deal?
So you cannot classify some out-of-the-box reports.  What’s the dig deal?  Let me show you a real-life example of where this limitation comes into play.  Let’s imagine that your boss tells you that he needs to see a weekly report of the top 25 Natural Search Keywords leading to Site Registrations.  No problem!  Simply open the Natural Search keywords report, add the Site Registrations Success Event and schedule the report for delivery (easy enough!).  However, the life of a web analyst is never that easy.  Next your boss says that he needs to see the same weekly report, but broken out by Branded vs. Non-Branded Natural Search Keywords.  Uh oh!  Now you have a problem.  Your first thought is to use the ExcelClient to download the Natural Search Keywords report and then use a pivot table to group each Keyword into Branded vs. Non-Branded buckets.  However, you soon realize that this will soon become a maintenance nightmare as you will have to manually do this each week and there isn’t an easy way to distribute the report to all Omniture users like you can through a SiteCatalyst Dashboard.  So next, you recall reading a [brilliant] blog post about Classifications and realize that the easiest thing to do would be to classify the top 200-300 Natural Search Keywords and then add the Branded vs. Non-Branded Classification version of the report to a SiteCatalyst Dashboard.  This would only require a one-time work effort and barely any maintenance.  Problem solved!  However, when you go to the Admin Console to add a Classification to the Natural Search Keywords report, you soon discover, that there is no way to do this (why, Omniture why?).  The inability to classify this report can have a real negative impact on end-user adoption, which is why at times, this can be a big deal.

But this is not the only place where this limitation can haunt you.  Another common example, is the Visit Number report.  It is pretty cool that you can look at the Visit Number report and add a Success Event metric and see what percentage of success takes place within the first visit, second visit, etc…  But if your site has a “long tail” it may take many visits for success to take place.  How would you like to present your boss with a report about Internal Searches that looks like this:

While not the worst thing in the world, this report does not provide an easy way to perform analysis, nor does it “tell a story” at an executive level due to its level of granularity.  However, if you could classify the Visit Number report, you could create a more functional report like this:

Here we can more easily see that the bulk of Onsite Searches are being conducted by first timers and those who have been on the site many times which can lead to follow-on questions.

The following are some of the places where I have run into this limitation:

1. Search Keywords
2. Search Engines
3. Visit Number
4. Referrers/Referring Domains
5. GeoSegmentation Country, Region, City, etc…

The Workaround
So if this limitation has affected you or you could see how it might in the future, how do you get around it?  Thankfully, the solution is very easy if you know what you are doing.  To get around this problem, all you need to do is to use JavaScript (or in some cases a VISTA Rule)to copy the values stored in these out-of-the-box reports into regular Traffic Variables (sProps) and Conversion Variables (eVars).  By duplicating this data into custom variables, which can be classified, you can use the Menu Customizer to steer your users to the custom versions of each report (which contain the Classification) instead of the out-of-the-box versions.  I have seen this quick/easy solution help clients turn otherwise unused reports into versions that are popular amongst SiteCatalyst end-users.

Enjoy!

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

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

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

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

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

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

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

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

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

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

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

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

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