Archive for 'Campaigns'

Recently, I had the pleasure of meeting a web analyst whose business relied on a subscription model.  In a subscription model, you often sell a product initially and then there is a subsequent Recurring Revenue stream (normally monthly).  During the conversation, I explained how I would address this in SiteCatalyst and since it is a somewhat advanced concept, thought I would share the same info here in case there are blog readers out there who also have Recurring Revenue models.

Why Is Recurring Revenue A Challenge?
So why is tracking Recurring Revenue in SiteCatalyst difficult?  As always, I like to explain through an example.  Let’s imagine that you sell a popular CRM product that has an initial sale price and then a monthly subscription.  A visitor comes to your website from a Bing keyword of “CRM” and they end up purchasing your product for $10,000.  You can track this $10,000 sale online and attribute it to the Bing keyword.  However, what do you do after one month?  Let’s say the customer pays $1,000 each month after the initial $10,000.  How do you attribute the recurring monthly $1,000 to the Bing keyword that originally brought the customer?  Many clients I have seen stop at the initial sale, but this is problematic.  What if there are some marketing campaigns that bring in a lot of initial sales, but those campaigns produce customers who quit the subscription after two months?  Perhaps there are other marketing campaigns that generate lower initial sale amounts, but result in customers who are retained for several years.  How do you compare “apples to apples” in this case if you cannot tie both initial and subscription revenue to the original marketing campaign?

The answer for most clients is to simply pass the original marketing campaign to their back-end system and do all of the reporting outside of a tool like SiteCatalyst.  However, this has the following negative consequences:

1. As a web analyst, you are now out of the loop which is not good for your program (or your career!)
2. There are hundreds of online web-only data points that you know about the original sale (i.e. visit number, internal search terms used, internal promos used, etc…).  Are you going to pass all of these data points to your company’s data warehouse and do analysis there?  If you are a big company that may be possible, but what if you are a small or mid-sized business?

If you are like me, at a minimum, I like to have all important data in SiteCatalyst so I can have a seat at the table.  With this in mind, the following section will describe what you need to do if you want to get Recurring Revenue into your SiteCatalyst implementation so it can be tied to the same data points as the initial sale.

Recurring Revenue in SiteCatalyst Reports
If you have read my past blog posts or even just my last post on Product Returns, you may know that one of my favorite SiteCatalyst features is Transaction ID (I suggest re-reading this post!).  At a high level, Transaction ID allows you to set an ID associated with a transaction and later upload offline metrics that are dynamically associated with any Conversion Variable (eVar) values which were active at the time the Transaction ID was set.  Just as Transaction ID was important to solving our Product Returns issue, it can be used similarly to solve the aforementioned Recurring Revenue challenge.

When visitors make their initial subscription purchase, you can set a Transaction ID value on the confirmation page.  Doing this allows you to establish “key” that can be used later to upload Recurring Revenue and tie it to all of the eVar values associated with the original sale.  Keep in mind that you will have to work with your Adobe account manager to get Transaction ID set-up.  Additionally, Transaction ID is normally only used for 90 days, but in this case you will need to work with your account manager to get it extended perpetually (or for as long as you want to include Recurring Revenue).  For example, if you want to associate two years of revenue with the eVar values that contributed to the original sale, then your Transaction ID data must persist for two years.

Once you have Transaction ID enabled and have started passing Transaction ID’s for online purchases, the next step is to create a new “Recurring Revenue” [Currency] Incrementor Event.  Transaction ID uploads are similar to Data Sources and, as such, can only import data as Incrementor Success Event.  Setting up a new Incrementor Event is easily done through the Admin Console.

Once you have Transaction ID set-up and your new Recurring Revenue currency Success Event, you need to generate a Data Sources template file that you can upload on a monthly/weekly/daily basis.  This file will consist of each subscription account that is still active and the amount of [monthly] Recurring Revenue that should be recorded for each date.  Normally, you will have subscriptions that expire at varying dates so you may decide to upload a file on a daily basis which represents all those who are starting a new subscription cycle on that date.  The Data Sources template that you will create should have the following columns:

1. Date – Use the date that the new subscription cycle starts, not the date of the original sale.  This date will determine which month the Recurring Revenue will appear in when using SiteCatalyst.  NOTE: Please keep in mind that there is currently a SiteCatalyst restriction that you cannot upload a Transaction ID file that has dates spanning more than 90 days.  You can upload dates that are more than 90 days old, but the date ranges for the entire file upload cannot be more than 90 days (kind of lame in my opinion!).
2. Transaction ID – The ID set when the initial subscription sale took place
3. Product Name/ID – Same value that was passed to the Products Variable during the original online subscription purchase
4. Recurring Revenue – Amount that the client will be charged for the next subscription cycle

When you are done, your Data Sources upload file might look something like this:

Seeing Recurring Revenue in SiteCatalyst Reports
Once you have successfully uploaded some Recurring Revenue data, it is time to see how all of this looks in SiteCatalyst.  To do this, open the Products report and add Revenue and our new Recurring Revenue metrics.  The report should look like this:

Next, you can create a Calculated Metric which combines the two metrics to create a “Total Revenue” metric as shown here:

Finally, since Transaction ID allows you to apply the eVar values that were associated with the original transaction to the new Recurring Revenue data, you can use Subrelation break downs for the Products report by Campaign and see both Revenue and Recurring Revenue (and the Total Revenue Calculated Metric)!

In the above report, we can see an example of the quandary I described in the beginning of this post.  When we break down our first product (Sales Cloud) by marketing campaign, if we look at the Revenue column, it looks like we should be focusing our marketing spend on Bing Branded Keywords.  However, when we add our Recurring Revenue, we can see that the majority of our Recurring Revenue and the most of our Total Revenue is coming from E-mail.  Perhaps that is the best place to concentrate our marketing budget…

Final Thoughts
So there you have it.  A simple, yet [hopefully] effective approach for making sure that you show all Revenue you are helping generate whether it takes place during the initial sale or subsequently…  If you have comments/questions, please leave a comment here…

If you sell products or services on your website, you are probably working diligently to be sure that you are tracking the appropriate Orders, Units and Revenue associated with each product sold (you may even be doing some advanced stuff like I described here).  Doing this allows you to see all sorts of wonderful things, like what pages lead to sales and what online campaigns have better ROI than others.  However, one formidable challenge that web analysts don’t like to talk about is Product Returns.  How often have you bought something online only to ship it back or return it to a brick & mortar store associated with the website?  If customers return products in significant enough numbers, all of the great online data you have collected may be inaccurate.

I have seen some companies apply a “rule of thumb (dumb?)” in which they discount sales by 20% across the board to account for returns, but how does that help you determine if a specific marketing campaign is good or bad when your SiteCatalyst reports only show the good?  By not tying product returns directly to their corresponding online sales, your web analytic reports will be inherently flawed.  The truth is that I have seen very few clients who have adequately addressed this issue, so I thought I would suggest an idea that I think is an appropriate way to deal with Product Returns.  Even if you don’t sell things through a shopping cart, I encourage you to read this post as its principles are applicable to any situation in which you have an online success that later is retracted in some manner offline.

Tracking Product Returns
The best way to understand the tracking of Product Returns, is through an example.  Let’s pretend that are a web analyst for Apple and a first time visitor comes to the website from the Google paid search keyword “ipod” and purchases two iPods for $50 each.  In SiteCatalyst, when we open the Products report, we would see $100 for the Product labeled “ipod” and if we broke it down by visit number, the same $100 would be attributed to visit number one.  So far, so good…

However, let’s imagine that one of these iPods was returned to a local Apple Store.  Now our reality has changed.  The paid search keyword and first visit combination has now only led to $50, but SiteCatalyst still shows $100.  If we create calculated metrics to compare our Revenue per Marketing spend, suddenly our ROI just got cut in half, but this is not reflected in SiteCatalyst.  This might cause us to misallocate marketing dollars to campaigns that look to be good at first, but in reality are not as profitable as others when Product Returns are added to the mix (especially if we automate Paid Search using SearchCenter!).  I don’t know about you, but I certainly wouldn’t want to be the one telling my boss to invest in marketing campaigns that turn out to be “duds!”

So how do we fix this mess?  In order to track Product Returns, you’ll need to re-familiarize yourself with the Transaction ID feature of SiteCatalyst (I suggest re-reading this post!).  At a high level, Transaction ID allows you to set an ID associated with a transaction and later upload offline metrics that are dynamically associated with any Conversion Variable (eVar) values which were active at the time the Transaction ID was set (phew!).  In this case, you need to ensure that you are setting a Transaction ID value when the original online sale takes place.  By doing this, you create a “key” that will allow you to upload Product Return data later and back it out of its corresponding online sale.  Keep in mind that you will have to work with your Adobe account manager to get Transaction ID set-up and you’ll want to be sure that the Transaction ID table persists for as long of a time frame that you require to upload return data (default is 90 days, but this can be extended).

Once you have Transaction ID enabled and have started passing Transaction ID’s for online purchases, the next step is to create a new “Product Return Amount” [Currency] Incrementor Event.  Transaction ID uploads are similar to Data Sources and, as such, import data as Incrementor Success Events.  Setting up a new Incrementor Event is easily done through the Admin Console.

Once you have Transaction ID set-up and your new Product Return Amount currency Success Event, you need to use Data Sources to generate a Product Returns template which you can populate and upload on a daily/weekly/monthly basis.  This file will contain the following columns:

1. Date – I suggest you use the date that the original purchase took place, not the date of the return, so there is no lag time.  NOTE: Please keep in mind that there is currently a SiteCatalyst restriction that you cannot upload a Transaction ID file that has dates spanning more than 90 days.  You can upload dates that are more than 90 days old, but the date ranges for the entire file upload cannot be more than 90 days (kind of lame in my opinion!).
2. Transaction ID – The ID associated with the original online sale
3. Product Name/ID – Same value that is passed to the Products Variable during the original online purchase
4. Product Return Amount – This is the total $$ amount per product that is being returned

When you are done, your upload file might look something like this:

Using Product Returns in SiteCatalyst Reports
Once you have successfully uploaded some Product Return data, it is time to see how all of this looks in SiteCatalyst.  To do this, open the Products report and add Revenue and our new Product Return Amount metrics.  The report should look like this:

Next, we can create a Calculated Metric which subtracts the Product Return Amount from Revenue to create a “Net Revenue” metric as shown here:

Finally, since Transaction ID allows you to apply the eVar values that were associated with the original transaction to the new “return” transaction, you can even use Subrelation break downs for the Products report by Visit Number and see both Revenue and Returns (and the Calculated Metric) by Visit Number (pretty cool huh?)!

Orders & Units (Advanced)
For those that are a bit more advanced, I wanted to let you know that the above solution does not back out Orders or Units for Product Returns.  Backing out Orders is a bit tricky since you may only want to remove the Order if the entire Order is returned.  Units is a bit easier as you can simply create a second Incrementor Success Event for “Returned Units” as we did above.  However, I suggest that you start with Revenue since most of your questions around Product Returns will be related to Revenue.

Finally, SiteCatalyst does provide an out of the box Data Sources template for Product Returns which can be found in the Data Sources Manager:

However, I have not used this template myself and I would have the following potential concerns:

1. I don’t believe that this template uses Transaction ID which can be problematic as you will be unable to use the Product Return metric with all of your pre-existing eVar reports
2. It looks like this template uses the same Revenue, Orders and Units Success Events to back out Product Return data.  I feel like this can be a recipe for disaster if something goes wrong.  With my approach, the worst case scenario (if you upload some bad Product Return data) is that your new Product Return metrics are temporarily off.  If you use the standard Revenue, Orders and Units metrics, a mistake can be fatal and hidden amongst your normal online metrics (I never mess with Revenue, Orders or Units!).

For these reasons, I suggest you talk to your Adobe Account Manager if you want to pursue this route.

Final Thoughts
So if Product Returns are something that you have to deal with, the above is my suggested way to handle them.  Those of you who work in Retail day in and day out may have come up with some other ways to deal with Product Returns, so if there are other best practices out there, please leave a comment here.  Thanks!

(Estimated Time to Read this Post = 5 Minutes)

In my last post, I explained a bit about CRM and how you could improve CRM by passing Web Analytics data into your CRM system.  In this post, I am going to cover the reverse angle  – passing CRM data into Web Analytics.  Since most of you reading this are web analysts, I think you will find this post more relevant, but I think it is important to understand both sides.

Why Pass CRM Data into Web Analytics?
As I mentioned in my last post, we web analysts get lots of great information about website visitors, but for many companies (especially B2B), the richest data resides in the CRM (Customer Relationship Management) system.  If you want to be relevant in your organization, it is always best to be as close as possible to the $$$ and that often means playing nicely with CRM systems.  Don’t get me wrong,  showing your CMO that you can lift form completion rates by 200% through optimization is awesome, but if you can show him the revenue impact of it right there in your Web Analytics tool, you will be a rock star!  Additionally, I will show that if you don’t have actual revenue-generating events on your site (eCommerce and Media sites have this easy!), then not doing this could actually result in Web Analytics data causing incorrect business decisions…

Passing Post-Website Data from CRM to Web Analytics
OK.  So there are many different ways to merge CRM and Web Analytics data including passing data from both into a massive Marketing data warehouse (or Omniture Insight), but just for the purposes of this post, I am going to assume that you are a SiteCatalyst person and want to get something done relatively quickly.  In this scenario, we’ll assume the following:

• You want to see which of your website visitors completing lead forms on the site evolve into Leads, Opportunities and Revenue
• Your CMO has charged you with capturing all of the different marketing channels and asked for your opinion on where the company should invest to get the most Revenue
• You are tracking the various sources of traffic you receive and using SAINT Classifications to roll each up into a high-level marketing channel (SEO, SEM, E-mail, etc…)

Given all of this, you might have a SiteCatalyst report that looks like this:

As a web analyst, at this point, it looks like we might want to invest more in our E-mail program since that seems to be converting the best.  Without CRM integration, that would probably be as far as we could go.  But let’s now dig a little deeper.  As I mentioned in the last post, when website visitors complete a form, we have a brief moment in time when we can connect our website data with our CRM data.  Most CRM tools allow you to capture leads and set a unique ID for each form completion.  At the same time, Omniture SiteCatalyst has a really cool feature (that many don’t use enough!) called Transaction ID.  I highly recommend you read my full post on Transaction ID, but at a high level, it allows you to set an ID to a special SiteCatalyst variable and then days or weeks later, upload [normally offline] metrics into SiteCatalyst.  The magic of Transaction ID is that when you upload these metrics later, they are tied to the eVar values (sorry – no sProps or Participation) that were present at the time the Transaction ID was set.  That means that if a website visitor had a City eVar value of Chicago, a Traffic Source eVar value of Paid Search and a Visit Number eVar value of 3, then any offline metrics you import will also be tied to Chicago, Paid Search and Visit Number 3 in the respective eVar reports.  This means that if you set the CRM ID associated with a website form completion, you now have a primary key (think Rosetta Stone!) that can connect your Web Analytics data to your CRM data!

So what does this mean to you?  Following our preceding example, let’s assume that you have made this connection and later imported all of the new leads your CRM system has seen along with the status (i.e. Qualified)  of each into SiteCatalyst (these new metrics would be Incrementor Events).  This gives you a new metric named “Qualified Leads” that you can now see in SiteCatalyst reports and since you used Transaction ID, these imported CRM metrics are correctly attributed to all eVar reports in your implementation.  The result is that you can now open a report similar to the one we saw above, but now it has “Qualified Leads” instead of Form Completes and a new Calculated Metric that divides these Qualified Leads by Visits:

The icons above the report show where each data point comes from and as you can see, the last column is truly magical in that it is combining data from two disparate systems (Cool huh?)!  Once we have this, we can see that even though E-mail looked to be the best channel a few minutes ago, it now appears that SEM is where we want to spend our money.  It turns out that E-mail generates form completions at the highest rate, but perhaps those form completions are all junk!

However, I like to go as far downstream as possible and nothing is better than cold, hard cash!  Applying the same principles, we can import Qualified Opportunities, Potential Pipeline, but the CRM metric that trumps them all is Revenue.  By uploading Revenue via Transaction ID, we can see how much $$ we got from each Lead Form completed on the website and tie it to any eVar value we have – in this case marketing channel/traffic source.  The following report shows the result of this:

Again, we see that some data is coming from SiteCatalyst and some is coming from our CRM system.  Our new Revenue/Visit Calculated Metric can be used to see that, in the end, it is really SEO that provides the most Revenue/Visit and maybe we should consider additional investment there.  Please keep in mind that these examples are simply meant to illustrate the concept and show the value in adding CRM metrics to your Web Analytics tool.  Finally, don’t forget that Transaction ID data is available in Omniture Discover so you can slice and dice this data even further there!

Targeting Based Upon CRM Data
Another really cool integration between CRM and Web Analytics is in the area of Test&Target.  For those not familiar with Test&Target, it is an Omniture tool that lets you test and dynamically target content to website visitors based upon what you know about them.  It is commonly used to optimize your website success metrics.  However, this can be extended by importing in CRM data so that your targeting is based upon both online and offline data.

Let’s walk through an example.  Imagine that a website visitor named Bill has been to your website a few times, looked at a few of your products and completed a lead form.  Next, Bill spoke to your sales representative and is at “Stage 3″ of the sales process (the discovery phase).  Over the next few weeks, meetings take place and Bill comes to the website occasionally (your sales team would know when and exactly what he is doing if you read my last post!).  But now let’s say that Bill is in sales “Stage 9″ which is the final stage before the deal is won or lost.  We know what products he wants, we know he is close to making a decision, we know how big is company is, etc…  If we knew all of this, what would we want to show him the next time he arrives at our website?  Here are a few things I would show to Bill on my home page when he (and only he) arrives on it:

1. Case studies related to his industry
2. ROI calculator for the product Bill is interested in
3. Links to community content to show Bill that he would be well taken care of if he were to be a customer
4. A time-sensitive offer (“Buy in the next 24 hours and get XX% off”) – You could even address him as “Bill” but that might freak him out!
5. etc…

The point is that if you can get the rich customer data related to Bill and multiply this to all of your prospects, each one could see more personalized content that helps move them further down the sales funnel.  You can even track how often they see these “recipes” and track the success of your intelligent targeting.  If you are interested in this type of CRM-based targeting I suggest that you contact @brianthawkins who is a Test&Target Jedi-master…

Final Thoughts
Hopefully this sparks some ideas about ways in which you can enrich your Web Analytics data by adding CRM data to the mix.  In the next post I will cover ways in which you can import CRM meta-data into your Web Analytics tool to augment your current web analyses.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Final Thoughts
As you can see, if you know what you are doing for tracking a public website, tracking an Intranet uses many of the same principles.  If you are just getting started in web analytics, feel free to apply the above items on your Intranet as a testing ground before you tackle the public website.  If you have some other cool things you have done to track your Intranet, please feel free to leave a comment here…

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.

Those who are familiar with Omniture SiteCatalyst come to learn that there is a big difference between Traffic Variables (sProps) and Conversion Variables (Events & eVars).  This separation can get in the way of many analyses unless you have access to Omniture Discover.  In this post I will describe one of the methods you can use to blur the lines between Traffic and Conversion variables by describing the use of the Page View Success Event.

Why a Page View Event?
In my experience as an Omniture Consultant, I found that most non-Media clients did not utilize a Page View Success Event.  However, there are great reasons why all Omniture clients can benefit from a Page View Success Event.  So what exactly is a Page View Success Event?  It is basically nothing more than setting a Success Event on every page of your site (kind of obvious huh?)!  Setting a Page View Success Event is very easy and can be done with minimal updates to your JavaScript file.  Once set, you will have a Page Views metric in your list of Success Events and this metric should, for the most part, be the same as the Page View metric you would see in the Traffic reports area.

OK.  So now you have the same metric you already had.  Doesn’t sound very exciting does it?  Despite its simplicity, it actually can be very beneficial.  Here are a few examples of what you can now do with this newly created Page View Event:

Basic Visitor Engagement
Let’s say that you are running a bunch of marketing campaigns and in addition to seeing how many purchases or leads each campaign generates, you also want to see how many pages on your site those arriving from each Campaign viewed.  Sounds easy right?  But how would you do this?  In the Traffic report area, there is no easy way to do this without using DataWarehouse, ASI or the Get&Persist Plug-in.  However, now that you have a Page View Success Event, you can open up your Campaigns report and in addition to your other site Success Metrics, you can add Page Views to see the number of Page Views visitors viewed on your site.  Having this metric is a [very] rudimentary way to view Visitor Engagement for Campaigns.

If you use the Unified Sources Vista Rule (or the JavaScript version known as the Channel Manager) to roll-up your traffic sources, you can use the Page View Event to see which Marketing Channel leads to the highest Number of Page Views on your site:

In addition, you can see how different Campaign Tracking Codes performed against each other with respect to Page Views by opening the same report at the Tracking Code level. For example, you can use this concept to see how many Page Views a particular Google Paid Search Keyword leads to on your site by finding that particular keyword in the Tracking Code report:

Internal Campaign Page Views
So earlier I mentioned that most Media clients set a Page View Event by default.  The reason they do this is that for most Media clients, Page Views represent how they make money!  They usually get paid for every Page View (through online advertising) so Page Views is one of their most important success metrics.  However, even if you aren’t a Media client you can use the same concept on your site.  Though you may not sell advertising on your site, you are most likely showing display ads for web promotions or to drive people to other areas of your site.  If you set an Internal Campaign code each time someone clicks on one of your on site promotions, you can use the Page View Event to see how many Page Views on your site each internal display ad leads to.

Basic Success Event Efficiency
Every once in a while, a client will ask me to do some analysis on how many Page Views it takes for visitors to complete website Success Events.  I have seen many clients try to answer this question by opening the Calculated Metric window and trying to create a metric that divides a particular Success Event by Page Views only to be puzzled why Page Views is not an option in the metric selector!  Why isn’t Page Views there?  Because Page Views is a Traffic metric and your Success Events are conversion metrics and you can’t mix those in SiteCatalyst.  However, if you have a Page View Success Event, you can easily create a Calculated Metric to see this.  Simply divide any existing Success Event metric by the Page View Success Event and you will be able to see a trended ratio that compares the two.  I call this Success Event Efficiency (at a high level, how many pages do visitors need to see for each Success Event) and it can provide an alternative view of how your site is performing.

Internal Search Term Influence
Ever wonder how many pages on your site people view after searching on a particular term using your site’s internal search?  How about seeing this for each internal search term?  While this sounds easy, it isn’t with an out-of-the-box implementation.  But if you have a Page View Success Event and are already storing internal search terms in an eVar, all you have to do is open the Internal Search Term eVar report and add the Page Views Success Event to the report.  This metric will show you how many pages were viewed on your site after each internal search term was passed to the eVar.

Sort by Page Views and you can see which internal search term led to the most site Page Views (keep in mind that the length of time you select to to expire the internal search term eVar will impact how many page views are shown, but most people expire this at the end of the Visit).  Another thing I have done is divide the number of Pages Viewed by the number of Internal Searches [Success Event] to see how many pages visitors tend to view after searching on each specific term (see 3rd column above).

Final Thoughts
As you can see, adding a Page View Success Event has many different uses and I have only touched upon a few here.  I encourage you to consider if you have a use for this for your SiteCatalyst implementation.  If you decide to do this, I would recommend the following:

1. Be sure to name the Success Event appropriately so you don’t confuse it with the Traffic Page View metric.  I tend to name the Page View Success Event as “Page Views (Event).”
2. Keep in mind that when you set other Success Events you need to have both in the s.events string separated by a comma (i.e. s.events=event1,event10).  You want to be sure you don’t lose your key website Success Events when you implement this!
3. Keep in mind that setting multiple Success Events can have an impact on latency so be sure to talk to your Account Manager if your site has a lot of traffic.
4. It is not recommended that you set a Page View event when using Custom Links.

By default, most Omniture SiteCatalyst clients are tracking their external Marketing Campaigns using Campaign Tracking.  These reports allow you to see how many Success Events take place on your site for each type of Campaign you run (i.e. E-mail, Paid Search, etc…).  However, I am surprised how rare it is that Omniture clients are tracking their Internal Campaigns (also referred to as Internal Promotions) to the same extent.  Most websites promote products or content on their site through the use of display ads, buttons or links.  These Internal Campaigns should be tracked in the same way as external campaigns.  While I have touched upon this concept a bit in the past in the Conversion Variable post and the Products Variable post, in this post, I will provide the basics on Internal Campaign tracking.

Why Track Internal Campaigns?
So why should you track Internal Campaigns?  At most organizations, there is constant debate about which website promotions perform better than others.  This is especially the case for high-profile pages like the Home Page.  For example, the screen shot below shows four distinct Internal Campaign Promos:

While you can try to see how often visitors are clicking on each promotion item by looking at Pathing reports (look how many people went from Page A to Page B where you had a promotion on Page A), this takes a lot of time and won’t help you if you have multiple links to this same destination page on the same page.  You can try to use the ClickMap feature of SiteCatalyst, but in my experience, ClickMap data is not wholly accurate.  If you have a tool like Test&Target then you can easily test and promote content that is proven to be the best in each content area, but if you don’t, you can use Internal Campaign tracking to provide some basic information.

How to Track Internal Campaigns?
Tracking Internal Campaigns is done through an eVar.  As I have pointed out in the past, the s.campaigns variable in SiteCatalyst is really nothing more than a predefined eVar with Full Subrelations.  Therefore, you can track Internal Campaigns in the same way.  I tend to do this using the getQueryParameter plug-in which captures a code placed in the URL and passes it to the Internal Campaigns eVar.  These codes can be whatever you like, but the parameter identifier should be different from what is used for external campaigns.  In the fictitious example shown here, a user has clicked on a website banner and the destination URL has a “pid” parameter which passes the code “home_hero_112″ to the Internal Campaigns eVar:

As you can imagine, the hardest part of Internal Campaign Tracking is adding tracking codes to each promotion link on your site.  However, this can be built into the process of banner/promo creation and done on a going forward basis if needed.  All you need to do is to come up with a logical naming convention or if you want, you can even just use numeric codes and use SAINT Classifications to add meta-data later.  When using SAINT for Internal Campaigns I tend to use the following Classifications:

1. Page on which the promo banner was shown
2. Location on page of promo banner
3. Format (i.e. GIF vs. Flash)
4. Creative Copy (i.e. $50 off vs. 10% Discount)
5. Owner of the Promo

How to Use Internal Campaigns?
Once you are passing Internal Campaign codes to an eVar, it is time to use the data for analysis.  The most basic way to do this is to open the Internal Campaigns eVar report and look to see how many of your website Success Events take place after a visitor clicks on one of your Internal Campaign elements.  You can see an example of this in the following report:

In this example, I have set an additional “Internal Campaign Clicks” Success Event to track each time a visitor clicks on an Internal Campaign promo item.  You could rely on the “Instances” metric, but as I have stated in this post, I am not a big fan of this.  This new “Internal Campaign Clicks” metric is an internal equivalent to the Clicks metric set by default for External Campaigns.

However, there is one difference between Internal and External Campaigns to keep in mind.  Unlike External Campaigns that usually have one value per visit, visitors can click on multiple Internal Campaigns within one session.  Therefore it is important that you understand the principles of eVar Allocation so you understand which Internal Campaign element will get credit for website Success Events.  If you want to go really deep with Internal Campaigns, you can even set multiple eVars such that you have the following:

1. One eVar to store the first Internal Campaign clicked in a visit (First Value)
2. One eVar to store the last Internal Campaign clicked in a visit (Most Recent)
3. One eVar to store all Internal Campaigns clicked in a visit (Linear) [remember that Linear Allocation is only Visit-based!]
4. One eVar to store all Internal Campaigns clicked across multiple visits using Cross-Visit Participation

One of my favorite reports to run is one in which I look for synergistic effects between External and Internal Campaigns.  Since the External Campaigns eVar comes with Full Subrelations, you can automatically break it down by the Internal Campaigns variable.  Doing this allows you to see which combinations of External campaigns and Internal Campaigns lead to success.  For example, it may be the case that a particular Paid Search Keyword, when combined with a specific Internal Campaign promo converts above the average for the site.  These hidden gems can help you boost overall conversion and are found by simply opening a Subrelation report between the two variables as shown here:

Finally, another benefit of tracking Internal Campaigns is that it enables you to improve your building of DataWarehouse Segments to include visitors who have/haven’t seen a particular Internal Promo.  This information can be valuable to re-marketing efforts in general.

In this post, I am going to delve into an advanced topic that very few of my past Omniture customers had dealt with – Extracting Unique Visitor ID’s for re-marketing purposes.  Unless you have done a few Genesis integrations, this is most likely functionality that is new so I will do my best to keep it simple and explain why it is useful.

Why Extract Unique Visitor ID’s?
The easiest way to explain this topic is through an example.  Let’s imagine that your business sends lots of marketing e-mails to customers and prospects.  Each of these e-mail recipients, has a unique ID in your e-mail system (we’ll use Responsys for this example).  If you are a good web analyst, you should have set-up your e-mails so that when an e-mail recipient receives an e-mail and clicks on one of its links, they arrive at your website with both a campaign ID and a unique e-mail ID.  For example, your e-mail link may resolve to:

www.test.com?cid=springmailblast&mid=bd69c458909

Setting these in Conversion Variables (eVars) will allow you to see how each e-mail performed (through the campaign ID) and how often each e-mail recipient visited the site (through the e-mail ID).  If you aren’t doing this already, I suggest you start there.

Now let’s say you are capturing these ID’s.  What most intelligent marketers want to do is to segment their website behavior and then see if they can re-market to those who meet certain criteria.  For example, let’s say that you want to send a re-marketing e-mail to all e-mail recipients who came to your site from the e-mail and then filled out a specific offer form.  To do this, you would need to find a way to identify the e-mail ID’s of those completing the specific offer form you care about.  For an advanced SiteCatalyst user, this would be pretty easy since they would know that they could simply use a Conversion Variable Subrelation report to breakdown the Offer ID eVar value by the E-mail User ID eVar, but you would need to pay for Subrelations on one of these eVars.  However, there is a pre-built feature of SiteCatalyst that is available to do this using Data Warehouse.  In fact, SiteCatalyst has had the ability to extract Unique Visitor ID’s for many versions, but it is rarely used.  This feature allows you to tell SiteCatalyst which eVar stores your Unique User IDs (e-mail ID in this case) and will allow you to easily extract those ID’s using Data Warehouse.  By using this feature, you can automatically create a Data Warehouse Segment that pulls the Unique Visitor ID’s you are looking for and then simply tell SiteCatalyst what data points you want as you would in a normal Data Warehouse request.  As I mentioned, this is a bit more advanced, but pretty cool (even though it is sufficiently well hidden!).

How It Works
So how does it work?  The first step is to tell SiteCatalyst which eVar you are going to use to store your Unique Visitor IDs.  Please note that this is not the same as replacing Omniture’s Visitor ID in your js file.  To learn more about that, see this post.  Adding this value in the Admin Console will not affect your unique visitor counts in any way.  In this example, we will use e-mail ID’s which I have labeled “Responsys ID” and to do this we go to the Admin Console.  In the Admin Console, you select the report suite(s) and under the conversion area, select “Unique Visitor Variable” as shown here:

On the next screen, you simply choose the eVar that stores your Unique Visitor ID (Responsys ID in this example) as shown here:

Believe it or not, you are done!  But what does doing this actually do?  Now if you go to reports in this report suite, you will see a very subtle difference.  Per the example above, we want to identify all of the E-mail ID’s of people who looked at a particular website offer.  To do this, we will go to the eVar report that stores all of our website Offer ID’s which might look like this:

Normally, if you click on an eVar value in a report it will take you to a what is known as an “Item-Specific Summary” report which details how often and what percentage that eVar value was involved in each website success event.  I find that very few people actually use that report and often go to it once, panic and then hit the back button (I do encourage you to explore that report, but in the interest of staying on topic, I will continue)!  However, once you have enabled your Unique Visitor ID variable in the Admin Console, clicking this row will not take you to the Item Specific Summary report, but rather, will present you with a magical new option shown here:

If you then click on the new row that you see “Extract visitor IDs for event…” you can select the success event that you want (in this example we are looking for Form Completes).  Doing this will pop open a new screen that outlines what you are looking for like this:

From this screen, you choose the “Request” button at the bottom and you will be e-mailed a list of the ID’s that match your criteria.

In addition, you will also be taken to the Data Warehouse request manager screen (assuming you have security access to Data Warehouse) and you will see a new segment (see screen shot below) created that matches the criteria you are looking for (in this case, all Responsys ID’s that had a Form Complete and the form matched the specific Offer ID we selected from the eVar report).  While this screen is optional, I believe it is presented in case you want to further refine the segment or add additional data fields to your Data Warehouse report:

At first, I was skeptical and didn’t believe that my click in an eVar report had actually led to a full blown Data Warehouse segment having been created, so if you have any doubts, you can click the Edit Segment button and see the actual segment definition:

Now all you have to do is to add any data points you want to see related to the report area and use this newly created segment.  Obviously, you would want to include the Responsys ID’s in this example (I wish this would be pre-selected in the new Data Warehouse screen, but what can you do?), but you can add any others that you wish.

Additional Information
As you can see, while powerful, this functionality can get pretty involved!  If you have implemented Genesis integrations, you will find that much of this functionality comes bundled with Genesis so the Unique ID’s you need are automatically extracted and sent to partners for you through API’s.  However, I think it is useful to understand how this User ID extraction works, especially if you plan to do advanced customer segmentation.

Finally, keep in mind that there are many other ways to use this functionality beyond the simple e-mail example here.  One of the most powerful uses of this feature applies to sites where users login to the website.  In these cases, you can store the user’s ID (or a hashed version of it using DB Vista) and perform some amazing analysis and re-marketing to registered users.

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