Archive for 'ASI'

(Estimated Time to Read this Post = 4 Minutes)

(Estimated Time to Read this Post = 4 Minutes)

One of the funny things about SiteCatalyst (you will notice I can’t yet bring myself to call it Adobe SiteCatalyst!) is that there are some really cool features that are hidden.  In some cases, it almost seems like someone has gone out of their way to hide them, but I like to look at these “hidden gems” as a sort of rite of passage.  In this post I will share some of the ones I have found and hope that maybe you know of others so that all of us can learn!  Also, if you haven’t read my old blog post on SiteCatalyst Time Savers, I encourage you to do so!

The Magic Triangle and Checkboxes
If you are like me, it may seem like you spend most of your day adding/removing metrics from reports!  This can be a very time consuming process, so you might as well be as efficient as possible.  However, I often find that new SiteCatalyst users add extra steps to the process because they don’t know a few easy tricks in the Metrics window.  The first trick is that you can change the column that is used for sorting by clicking the [very] little triangle next to each metric.  It amazes me how many people add metrics, wait for the report to load and then click on a column to sort and wait for the report to load again!  Multiply that by twenty reports and it becomes a real time suck!  Instead, simply click the triangle until it turns green (soon to be Adobe red?) and you are done!

But wait!  There’s more…You will also notice that there are a bunch of check boxes next to each metric.  Those check boxes are used to choose which metrics you want to graph with your report.  You don’t have to graph every metric in the report, which may confuse your audience.  Also, I find that many clients don’t take advantage of the fact that you can display two graphs per report.  To do this, all you need to do is check off one of the boxes on the left and right side.  This is helpful if some of your metrics are numbers and them are percentages.  It is the closest SiteCatalyst comes to a secondary axis you may be used to in Excel.

Remove Subrelation BreakDowns
If you frequently use  eVar Subrelation reports, you may find that after breaking one eVar down by another eVar, you want to go back to the report before it was subrelated.  For example, let’s say you have opened aTraffic Driver report and broken it down by Offer Type as shown here:

Now let’s say you change the date range and some other report settings and then decide you want to just see Traffic Driver Type by itself again.  Unfortunately, if you use the trusty “Back” button in your browser, you will have to re-do all of those customized settings.  However, there are actually two ways to remove this subrelation without losing any work.

The first way to do this is to click on the “Broken Down by:” link shown in red above.  Once you click on this, you will see a list of all of your variables and you can choose the bottom-most one labeled “None.”  The other way is to click the green magnifying glass icon you used to create the Subrelation and do the same thing as shown here:

Double Your Searching Pleasure
Another thing I have noticed that a lot of SiteCatalyst users don’t know is that you can add search criteria to two different variables if you are using a Subrelation report.  To do this, click on the Advanced Search link and then you can use the drop down boxes to choose which variable/search term combination you want:

In this case, I have chosen to filter for all Traffic Driver Types containing “SEO” and can proceed to enter my search criteria for Offer Type…

Inherit Segments
If you use DataWarehouse or ASI, you probably spend a lot of time creating Segments.  If so, you may find times where you want to re-use some parts of a segment you have already created.  When I first started using SiteCatalyst, I did this by printing out my segments and re-creating them manually.  This is both time-consuming and prone to error, so I found the trick to do this more efficiently:

There it is!  See how easily you can copy an existing segment?  Do you see it?  If not, would you believe me if I told you that there are actually two different ways to re-use segments on the above screen?

The first way to do this is to click the icon to the right of the Segment title.  This will pop-up a new window which allows you to pick an existing segment you want your new segment to be based upon.

The second way to do this is to use the Segment Library.  You can access the library by clicking its name next to the “Components” item.  The Library is used to store commonly use segment building blocks.  In the example below, I have created a Page View container that looks for Pages where the IP Address Geography is in the United States.  By dragging this over to the Library, I can re-use this anytime I am creating a new segment.

Filter Report Suites
If you have Admin rights to your SiteCatalyst implementation and deal with a lot of report suites, the Admin Console quickly becomes one of your best friends.  One of the most time consuming Admin Console tasks is finding the report suites you are looking for among all of your report suites.  I frequently see people scanning up and down over and over hunting for the report suites they need.  Fortunately, there is a much better way that is somewhat hidden – using the “Saved Searches” feature of the Admin Console.  Using this feature you can create a filter to find report suites such that even if you add new ones, they will be added to your saved search if they meet the criteria.

Here is a real-life example.  When I joined Salesforce.com, we had a lot of report suites and I began creating new report suites.  When I created the new report suites, I simply added the phrase “New” to my new report suites titles.  Once I did this, I clicked on the “Add” link within the Saved Searches area of the report suite manager and created a “Saved Search” rule like this:

Keep in mind that this is a very basic rule.  You can actually add multiple criteria items and can build rules that take into account any of the following report suite criteria:

Lastly, if you are an Admin, be sure to read my past blog post with even more Admin Console Tips.

Final Thoughts
So there you have it.  As you can see, none of these items are critical showstoppers, but I have found that knowing them can help speed up your day and give you SiteCatalyst bragging rights!  Do you know of others?  If so, please share them here as comments!

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!

Often times when I used to work with clients and now internally, I am surprised to see how many SiteCatalyst users don’t take advantage of Comparison Reports within the SiteCatalyst interface.  In this post I will review these reports so you can decide if they will help you in your daily analysis.

Comparing Dates
Hopefully most of you are familiar with this type of Comparison Report.  This report type allows you to look at the same report for two different date ranges.  To do this, simply open up an sProp or eVar report and click the calendar icon and choose Compare Dates when you see the calendar.  In the example shown here, I am going to compare February 2010 with March 2010:

For this example, I have chosen the Browser report, using Visitors as the metric.  After selecting the above dates, my report will look like this:

As you can see, SiteCatalyst adds a “Change” column where it displays the difference between the two date ranges.  This can be handy to spot major differences between the two date ranges.  In this case we can see that “Microsoft Internet Explorer 8″ had a big increase and that “Mozilla Firefox 3.5″ had a decrease (probably due to version 3.6!).  You can compare any date ranges you want from one day to one year vs. another year.

However, when you compare ranges that have different numbers of days, your results can be skewed.  For example, in the report above, March had three more days than February so that may account for why the differences between the two are so stark.  If this ever becomes an issue, you can take advantage of a little-known feature of Comparison Reports – Normalization.  In the report settings, there is a link that allows you to normalize the data.  When you normalize the data, SiteCatalyst makes the totals at the bottom of each report match and increases/decreases the values of one column to adjust for the different number of days.  I am not 100% sure what specific formula or algorithms are used to do this, but for the amount of times that you will use it, I would go ahead and trust it.  Below is an example of the same report with Normalization enabled:

If you look closely, you will see that the March 2010 column has been normalized when we clicked the “Yes” link shown in the red box above.  By doing this, SiteCatalyst has reduced the numbers in the March 2010 column to assume the same number of Visitors as there were in February.  If you want to normalize such that February is increased to match March, you simply have to reverse the date ranges so when you select your dates, March is the first column and February is the second column (the second column is always the one that gets adjusted).  As you can see, the “Change” column is now dramatically different!  In this version, “Microsoft Internet Explorer 8″ no longer looks like it has changed much.  I find that using this feature allows me to get a more realistic view of date range differences.

Finally, you may notice a tiny yellow box in the preceding report image (says “6,847″).  This is a secret that not many people know about.  When you normalize data, Omniture artificially reduces or increases the values in the normalized column.  But if you want to see what the real value is (if not normalized), you can hover your mouse over any value and you will see a pop-up with the real number!  If you look at the first version of the report (the one before we normalized), you will see the same “6,847″ number in the first row of the report… Pretty cool huh?

Comparing Suites
This second type of Comparison Report is the one that fewer people are aware of or have used.  In this type of comparison, instead of comparing date ranges you compare different report suites.  Obviously, this only makes sense if you have more than one report suite, but it also works with ASI slots so don’t assume this isn’t relevant to you if you have just one report suite.  Much of the mechanics of this are similar to the steps outlined above.  You simply open one report (in this case we will continue to use the Browser report) and then choose the “Compare to Site” link and choose a second report suite or ASI slot.  In this case, I am showing an example of the Browser report for two different geographic locations.  Since most report suites have different totals, I tend to use Normalization more in these types of comparison reports.

Final Thoughts
This covers the basics of Comparison Reports.  Hopefully you can use this to start creating these reports and adding them as scheduled reports or even to Dashboards.  In my next post, I will take this a step further and demonstrate an advanced technique of using Comparison Reports…

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!

In my last post, I described some of the benefits of using a Page View Success Event.  In this post I will continue along the same theme by describing the benefits/uses of a Page Name Conversion Variable (eVar).  I recommend you read my last post on the Page View Success Event prior to reading this post as the two go hand-in-hand.

Setting a Page Name eVar
Setting the Page Name in an eVar, while somewhat nontraditional,  can be used for many different purposes.  In this post I will cover just a few, but I am sure those reading this can come up with many more.  The implementation of this couldn’t be easier.  Simply pass the s.pagename value to an eVar and you are done!  The following sections will outline how I use this variable once it is set.

Campaign Pages
Let’s say that you are running a bunch of online marketing campaigns and you want to see how many pages on the website people coming from each Campaign Tracking Code view.  In SiteCatalyst, the main way to figure this out would be to use DataWarehouse, ASI or Discover unless you read my last post and had set a Page View Success Event.  But now let’s take it a step further.  What if you want to see the pages that visitors from each Campaign Tracking Code viewed on your website.  Easy right?  Not so fast.  There is really no easy way to see this in SiteCatalyst using out-of-the-box reports.  One way to do this would be to use the Get&Persist Plug-in to pass the Campaign Tracking Code to a Traffic Variable (sProp) on each page of the visit and then use a Traffic Data Correlation to correlate this new sProp with the Page Name variable, but that is a lot of work!  The other way is to use a Page Name eVar.  By default, your Campaign Tracking Code report will store and persist the Campaign Tracking Code for multiple page views (you choose your time frame in the Admin Console) so if you begin to store Page Names in another eVar, you will have an intersection between Page Name and Campaign Tracking Code on each page.  That allows you to use a Conversion Variable Subrelations report to see all Pages viewed by visitors coming from each Campaign Tracking Code  You can see this by opening up the Campaign Tracking Code report, selecting the Page View (Event) metric and clicking the icon next to a specific Tracking Code to break it down by the Page Name eVar.  Once you have done this, you should see a report like this:

Channel Pages Tracking
If you role up your Campaigns to higher-level Marketing Channels using SAINT Classifications you can use the concept from the Page View Event post to see how many pages are viewed on your site after visitor arrive from each Marketing Channel.

You can then break this report down by the Page Name eVar to see the most popular pages for each Marketing Channel:

While this is not as granular as viewing Pathing by Campaign (as I demonstrated in this post) , it can give you a high-level view of what pages are popular for each different marketing channel.  If you are using the Unified Sources DB VISTA Rule or Channel Manager plug-in, it gets even better as you can see what pages people coming from another website or SEO are viewing on your website by breaking down a particular SEO keyword or external website link by Page Name:

Internal Search Follow-On Pages
If you are properly tracking Internal Search on your website, you should have Internal Search Terms stored in an eVar so you can use this concept to break down Internal Search Terms by this new Page Name eVar (while using the Page View Event) to see what pages visitors view after they search on each specific Internal Search Term:

What Page Does Success Take Place?
Another side-benefit of setting a Page Name eVar is that you can see on which page a Success Event takes place.  For example, if you set a “File Download” Success Event and a file is available on several pages, you can subrelate each file name with the Page Name eVar to see which page is the most popular for downloading each file.

Conversion Variable QA
Finally, there is a completely different use for the Page Name eVar – Quality Assurance.  Often times, you will run into situations where you have eVars that have bad data or no data at all (the dreaded “None” row!).  Often times, these issues are hard to troubleshoot.  However, if you have a Page name eVar, your life is much easier.

Let’s say that you have forms on your website and when visitors complete a form, they are required to enter a “Company Size” field which is stored in an eVar.  However, there are many cases where you are seeing the Form Company Size eVar with no data.  This might mean that IT forgot to make the field required on some of the Forms (would never happen right?).  How do you figure out which forms are causing the issue?  All you have to do is the following:

1. Open the eVar report that has data issues with a relevant Success Event metric (Form Company Size and Form Completes in this example)
2. Find the row that has bad data or no data (“None” row)
3. Click the breakdown icon to break the report down by the Page Name eVar
4. The resulting report (see below) will show you a list of Page Names where SiteCatalyst set the Form Complete Success Event, but did not have a corresponding Form Company Size eVar value

You can then send this report to your IT team to help them find pages where there may be tagging issues.  You could even schedule this as a recurring report to you and IT so you are alerted when similar issues arise in the future, which helps with overall data quality.  Keep in mind that this will only work if the eVar you are looking at has Full Subrelations or you add Full Subrelations to the Page Name eVar (see below).

Final Thoughts
As you can see, there are many different uses of this functionality.  The following are some final pointers related to this topic:

1. As previously noted, if you plan to use the Page Name eVar extensively for testing, I would recommend that it have Full Subrelations so you can QA all eVar reports, not just those that already have Full Subrelations.
2. In one of the rare times I ever tell clients to do this, I would recommend that you set the Page Name eVar to expire at the Page View in the Admin Console.  Expiration beyond that will probably add little value and only slow down reporting.  There are some special things you need to do here if you use Custom Links so I would advice you speak to Omniture  Consulting about this.
3. Consider Classifying the Page Name eVar by Page Type, Page Product Category, etc… to increase the value you get from this eVar.

In my last post, I discussed a topic which I called Segment Pathing, which allows you to see how Pathing on your site differs by Visitor Type or Campaign Tracking Code.  In this post I will build upon this concept with one of the most popular topics in the Web Analytics field: Bounce Rates.  While I am not as enthusiastic about Bounce Rates as many others in the field, I do understand their importance and why people like them them.  However, one of my gripes with the Bounce Rate metric (which I have always defined as Single Access/Entries) is that there is not an easy way in SiteCatalyst to see Bounce Rates for different types of visitors or Campaigns.  Unless they have Omniture Discover or are experts at ASI Segments, most of the Omniture clients I worked with were primarily looking at Bounce Rates for the entire population.  While this is OK, I think we can do better than that.  In this post I will show you how I create Segment Bounce Rates.  However, to get the most out of this post, I strongly encourage you to read my prior post on Bounce Rates and my previous post on Segment Pathing before reading this post.

Segment Bounce Rates
As I just described, my goal when looking at Bounce Rates is to be able to tell my peers how visitors are bouncing off key pages based upon both the page and the segment.  In my previous post, I highlighted two segments that I commonly use: 1) Visitor Type (i.e. Customer vs. Non-Customer) and 2) Campaign Tracking Code (i.e. visitors from Google keyword A vs. Yahoo keyword B).  If I can dissect how each segment bounces off pages, I can determine if I need to create different versions of pages for each Visitor Type or Campaign Code or I can use this information to build future A/B Tests using a tool like Test&Target.  As I mentioned in my last post, this is a moot point if your organization already has Omniture Discover, but as is always the case in my blogs, my goal is to show you how to do things if you only have access to SiteCatalyst.

Implementing Segment Bounce Rates
The good news is that if you have already followed my instructions from my previous post on Segment Pathing, you are 95% of the way to being done with implementing Segment Bounce Rates!  As a quick recap, in my last post I described a process in which you concatenate the Page Name with another Traffic Variable (sProp) that contains a segmentation that you care about (i.e. Visitor Type).  Once you have these values concatenated on every page, you enable Pathing so you can see paths or pages by segment.  However, when you enable Pathing on this new sProp, you immediately gain access to the two metrics that you need to calculate Bounce Rate: Single Access & Entries.  Therefore, without even knowing it, by implementing Segment Pathing, you have also implemented Segment Bounce Rates!  All you need to do is to create the Bounce Rate Calculated Metric (which hopefully you already have as a Global Calculated Metric) and you are done.

So how do you see the results of your work?  All you need to do is to open the new concatenated sProp and add the Bounce Rate metric to the report.  In the example shown below, I will use the Campaign Pathing sProp which shows Campaign Tracking Codes concatenated with Page Names.  I will add Visits, Single Access, Entries and Bounce Rate to the report:

As you can see, the Bounce Rate for each Tracking Code/Page Name combination is displayed and you can sort by any metric you wish.

As a best practice, I like to conduct a text search filter to isolate one Page Name so I can see how the Bounce Rates differ for the same page with different Campaign Tracking Codes.  In the following example, I filtered on the phrase “:Home Page” and limited my results to see only Home Page Entries and the associated Bounce rates of each Campaign Tracking Code:

Keep in mind that I am only showing a few simple examples here and that this functionality can be extended to any segment of your choosing.  If you want to get really advanced, you could even concatenate multiple items together, such as Visitor Type + Campaign Tracking Code + Page Name.  This would allow you to see how different Visitor Types, coming from specific Campaign Tracking Codes, landing on specific Pages, navigate your site or Bounce off pages (i.e. Customer:ggl_1:Home Page).  Just don’t go too crazy since there are character limits on sProps and you don’t want to exceed the 500,000 monthly unique limits on sProps.

Final Thoughts
As you can see, you get a “two for the price of one” deal if you do all of the steps in this post and the previous post.  If you don’t have access to Omniture Discover and want to see how people navigate through your site or bounce off your site pages by specific segment, I suggest you give this a try and see if it helps you.

In past blog posts I have discussed SiteCatalyst Pathing Analysis in general and some specific examples (i.e. Success Event Pathing).  In this post, I will share a more advanced technique I call Segment Pathing which is often used to extend the capabilities of Pathing Analysis.  While this technique can be used in many different ways, I will use Visitor Type Pathing as the primary example and way to explain the concept.

What Is Segment Pathing?
Most of you are probably familiar with the idea of Pathing and that SiteCatalyst Pathing Analysis tracks the order in which a visitor looks at pages, sections or anything else on your site.  As such, it is normal to pass a page name or section name value to a Traffic Variable (sProp) so you can then enable Pathing.  However, there are often cases where you want to see how different segments of your visitors navigate through your site.  For example, what pages do New Yorkers look at first vs. those from Chicago?  Are there Pathing differences between younger vs. older visitors?

In order to see how these different segments navigate your site, you have the following options:

• Create an ASI Segment for the population you care about and look at Pathing reports there
• Utilize Omniture Discover (assuming you have paid for that), create a Segment and view Pathing reports

But what if you don’t have Discover and you don’t want to burn up an ASI segment perpetually for this Pathing Analysis?  The answer is to use Segment Pathing which I will demonstrate here.

An Example: Visitor Type Pathing
In this example, let’s assume that your organization has a cookie that stores (to the best of its ability) the current visitors customer status.  Often times companies assume that a visitor with no cookie value is a “Non-Customer” and those who have logged in or purchased something are “Customers” (obviously this is subject to cookie deletion).  Now let’s assume this this Visitor Type is passed to a SiteCatalyst Traffic Variable on every page.  Obviously, the name of each page is passed on each page and should be set to the s.pagename Traffic Variable.  Therefore, you have Page Name and Visitor Type, but no way to see pages by Visitor Type.  All you have to do is to set a new Traffic Variable (sProp) that concatenates these two values together in a format like this:

[VISITOR TYPE]:[PAGE NAME] or “Customer:Home Page”

If you do this on every page of the site and then have your Account Manager enable Pathing on this new sProp, you now have an intersection between Visitor Type and Page Name on each page and can use any of the many Pathing reports (including Fallout and Pathfinder) for this new variable.  SiteCatalyst experts long ago realized how simply concatenating values together into one SiteCatalyst variable could yield powerful results.  By using this technique, you can now select the appropriate “Visitor Type” concatenated value in the Next Page Flow report to see what “Customers” do on your Home Page:

as compared to “Non-Customers” viewing the same page:

As you can see here, Non-Customers have a much higher exit rate from the Home Page than Customers do, but without the use of this Visitor Type Pathing, it might be difficult to spot this since you are looking at Pathing for all segments lumped together.

Keep in mind, however, that this is just one example of how you can do Segment Pathing.  One of my favorite uses of this technique is to concatenate Campaign Names or Campaign Tracking Codes and Page Name so you can see how visitors from different Campaigns navigated through your site.  In the more advanced version of this shown below, you can see a Pathing Flow for visitors who arrived at a website from a Tracking Code “ggl_1″ and landed on the Video Games page.  By concatenating these two values, we can see how visitors arriving from the “ggl_1″ Campaign Tracking Code navigated the site as compared to those arriving from a different Campaign Tracking Code.  In fact, we can also see how people coming from the same Campaign Tracking Code (i.e. “ggl_1″ navigated the site differently when they arrived on a different page (i.e. a page different than the “Video Games” page).

Note that in the example below, the Campaign Tracking Code is not concatenated with the Page Name on every page, but rather just on the first page.  In this case, this was done because of the massive number of potential Campaign Tracking Code & Page Name combinations, which could lead to a “uniques” issue in SiteCatalyst.  However, the good news is that since Pathing reports only show values that took place after the element before it, by simply selecting the value of “ggl_1:Video Games,” we are guaranteed that all path views after it had to be preceded by the selected value.

Final Thoughts
As you can see the implementation of this through the use of variable concatenation is not terribly difficult.  However, before you run out and concatenate all of your Traffic Variables together, keep in mind the following:

• You do not want to enable Pathing on too many sProps since it will cost you $$$ and could result in report suite latency
• While powerful, this technique is more of a “hack” so if you are going to be doing a lot of segmentation, I encourage you to invest in Omniture Discover which is a much easier way to do Segment Pathing