Archive for 'Segmentation'

(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!

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

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

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

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

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

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

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

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

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

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

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

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…

A few weeks ago, Ben Gaines (@OmnitureCare) wrote a great blog post about tracking Internal Search.  In this post, I am going to add a few additional tips I have learned over the years…

Correlate Internal Search Term & Page Searched From
Knowing what people searched for on your site is certainly valuable, but knowing the exact page they searched for each term from is even more valuable.  Having this allows you to see what content visitors think they should be able to find on each page.  This is like gold to your content folks who can look for terms that are consistently searched for on a specific page and make a case that they need to add or improve content.

Setting up SiteCatalyst to do this is very simple.  All you have to do is pass the Internal Search term to a Traffic Variable (sProp) (as Ben showed) and then set a second sProp with the previous page name value (use the Previous Value plug-in) and create a Traffic Data Correlation for these two sProps.  When you are done, you will be able to see two cool things:

1) What terms are searched for on a specific page:

2) For any given term, what pages are visitors searching for that term:

Group Internal Search Terms
In Ben’s post, he discussed how to eliminate duplicate terms by taking upper/lower case out of the equation.  In addition to this, there are times when you might want to group specific keywords together into buckets since they represent the same type of search.  For example, if you manage a travel site, you might want to group all City internal search terms by State and Region so you can supplement your analyses.  This is easily done by taking advantage of SAINT Classifications which allow you to bucket your internal Search Keywords however you would like.  Here is an example of a SAINT File you could use in the preceding example:

Use Compare Feature to find differences between Dates
Once you are tracking internal search terms, you can use the Date Comparison feature in SiteCatalyst to see how the same internal search terms perform in two different time periods.  You access this feature from within the SiteCatalyst Calendar window.  Below is an example of looking at how the top internal search terms for September perform in October:

As you can see, by using the date comparison feature, SiteCatalyst will show you the difference between the two time periods so you can be aware of significant changes.  Simply click the difference column and you can see the search terms that changed the most/least (depending upon whether you sort ascending or descending).

Use Compare Feature to find differences between Report Suites
In a similar manner, if your implementation has multiple report suites (or ASI Segments), you can use the Compare feature to see how internal search terms vary by suite/segment.  For example, if you have a Customer Segment and a Non-Customer Segment, you can see what internal search terms each group is looking for:

In the above report, we can see that Non-Customers are more apt to search for careers, while Customers are more interested in detailed product information.

One cool thing you can do with this is to combine this data with Test&Target by FTP’ing the most popular search terms to a Word Cloud program and having Test&Target show the appropriate Word Cloud based upon a cookie value indicating customer status.  That is a great way to proactively use your web analytics data to create a better experience for your users!

Trend Search Page Exits
One way to see how good or bad your internal search results are is to look at how often visitors exit your site on the search results page.  While this isn’t a guarantee that your search results are bad, most of my clients agree that search results page exits are not normally an indicator of success!  Therefore, I like to trend this and set alerts to monitor this.  Here are the steps to do this:

1. Open your Pages report and find your Search Results page in the list
2. Click on its name and in the sub-menu choose Paths – Next Page report
3. Unfortunately, Exited Site might be one of your highest next pages, but in this case it is a good thing since you that makes trending it easier (I haven’t figured out how to trend it id it isn’t in the Top 5!).  Once you are looking at your list of Next Pages, click the “Trended” link to see the top five next pages trended.
4. From here, I usually refine the report to only show the Exited Site and Home Page (for some reason SiteCatalyst won’t let you see just “Exited Site” so you need to have one other value – not sure why – so I normally choose Home Page)
5. Finally, change your date range and View by (i.e. day, week, month) and you will see a report like the one below where I am trending Exits and clicks to the Home Page by percent over time.  You can now add this graph to a dashboard to monitor it over time…

Use Counter eVars!
There are two ways you can use Counter eVars with internal search.  First, per my last blog post, you can use the # of Pages Counter eVar concept to track how many pages visitors view prior to doing a search to see how your website design is functioning.  I showed this in my last post:

Second, you can track the # of internal searches in a counter eVar so you can see how many internal searches each visitor has done prior to completing your desired success event.

Track Recommended/Filtered Search Results
Many companies provide internal website searchers with recommended search results or filtered results based upon the search term as shown here:

You can use SiteCatalyst to track whether the visitor clicked on your organic links or the recommended/filtered links.  All you need to do is add a query string to links in each distinct area and capture that in an eVar when visitors click on these links.  For example, the eVar values may be “organic link click” or “filtered link click” which will show you the distribution.  You can take it further by passing this to an sProp and correlating it to the search term to see which internal search terms lead to visitors clicking each type of result.

These are just a few of the fun things you can do with internal search tracking…

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

Thanks to all of you who took the time to complete my SiteCatalyst quiz.  I hope it was a fun way to put your knowledge to the test.

So for the rest of this post, I will show how people answered the survey and point out what answers I was looking for.  When looked at as an entire population, if I include anytime someone got the correct answer, the majority of people got 10 correct answers out of 15 (66.67%).  However if I just look at just those responses where the exact right answer was given (no incorrect answers included where you could check off multiple boxes), the average score went down to about 6 out of 15.  However, please bear in mind that I am not an educator so if you interpreted a question differently than I did and gave a different answer, it is probably my fault not yours so don’t lose any sleep over it!  On the bright side, one (anonymous) individual in Europe got 14/15 correct (I am resisting the urge to find you by IP address and hire you!).  Either way, I strongly encourage you to look at your answers and see which ones you missed and read the linked posts below so you can become a SiteCatalyst Ninja!!

Question #1 (Correct Answer=Traffic Variables (sProps))
This first question was intended to be an easy one.  Think of it as a way to build engagement and not scare you off.  Most of you got this answer correct, but I was surprised to see that 33% of you thought that you could enable Pathing on more than just Traffic Variables (sProps).  Keep in mind that one of the main reasons to use sProps is to enable Pathing.   If you need a refresher, please check out my past posts on Traffic Variables (sProps) or on Pathing.

Question #2 (Correct Answer=True)
For many of these True/False questions, it is hard for me to tell if you got the right answer based upon knowledge or luck, but I am going to give you the benefit of the doubt!  In this case 75% of you were correct in saying that it is possible to share a segment with other users in your company.  I show how to do this in my past post about the Admin Console.  Keep in mind that you can only share a segment within one report suite so if you have multiple report suites you are out of luck.  If you really need to share segments across multiple report suites, the only way I know to do this is to create them under a shared Omniture User ID and give that ID to multiple users so they can see the segments owned by that ID.

Question #3 (Correct Answer = ZERO)
This question is admittedly a difficult one.  To get this one right, you would have had to really been in the trenches with SAINT Classifications.  Those who have ever tried to classify a variable that has a value of “0″ in the Key column have probably learned this the hard way.  While you can classify a value of “1″ or “43,” there is no way to classify a Key value of “0″ in SiteCatalyst.  Therefore, you need to pass in a text value for “0″ so you can classify it later on.  Therefore, the best answer to this question is the 3rd answer below “ZERO.”

Question #4 (Correct Answer=When a Success Event takes place or after a specified Time Period)
You guys knocked it out of the park on this one.  The correct answer here is that an eVar can be expired when a Success Event takes place or based upon a time period.  This happens to be one of my pet peeves since I really wish you could expire an eVar based upon a Success Event or a time period (whichever comes first).  There are many cases where having this ability would have saved me a lot of time.  Maybe in a future release (or all of you can help me by requesting this as a feature request!).

Question #5 (Correct Answer=True)
Most of you got this one right as well.  One of the cool things about classifying Conversion Variables (eVars) is that if you have paid for full subrelations on the eVar it is based off of, you get full subrelations on all of the Classifications.   This can save you time and money!

Question #6 (Correct Answer= All but Conversion Variables (eVars))
This question was a hard one and another one of my pet peeves.  The correct answer is the second one “Conversion Variables (eVars).”  The security features in the Groups area of the Admin Console are very good and a much better way to hide reports from select groups of users than the Menu Customizer.  However, for some unknown reason, you can hide pretty much everything in SiteCatalyst except Conversion Variables (eVars), which are some of the most critical reports!  I am not sure why this one thing was omitted and I have been asking for this for some time.  Hopefully it is on the product roadmap.

Question #7 (Correct Answer=None of the Above)
This question probably caused some confusion due to the wording, but the correct answer here is “None of the Above” since I was looking for the best way to assign credit across multiple visits.  Most of you fell for the trap I set here and chose “Linear Allocation.”  Many people I talk to think that Linear Allocation of an eVar works across multiple visits, but it does not.  Linear Allocation only works within a visit (for the most part, but the details are a bit confusing!).  Therefore, the real best answer for this question was Cross-Visit Participation which I covered a while ago.  Cross-Visit Participation is the only real way to assign credit to an eVar across multiple visits.  If you are not familiar with Cross-Visit Participation, please review my previous post.

Question #8 (Correct Answer=None of the Above)
Importing offline or external data via Data Sources is a more advanced topic, but many of you look like you are familiar with it.  The majority of you got this one correct since none of the options provided here will allow you to back out data sources metrics.  For this reason you have to be extremely careful when importing Data Sources data since there is really no going back if you make a mistake!

Question #9 (Correct Answer=False)
This is one of those questions you used to get from your teacher and absolutely hate them afterwards when they told you the answer, so I will apologize in advance.  The key phrase here is “the only difference” so the correct answer here is “False.”  While the difference cited here is correct, there is one really big difference between Correlations and Subrelations that you need to know.  That difference is that you can correlate two sProps, five sProps or twenty sProps with each other, but with Subrelations it is an all or nothing proposition.  It would be great if you could Subrelate just two eVars together, but that is not currently possible like it is for sProp Correlations.  This is a key thing that every SiteCatalyst Ninja must know!

Question #10 (Correct Answer=Unique Visitor Counts an Pathing)
Most of you got this one correct.  The key disadvantages of Roll-ups are that they don’t de-dup uniques and you cannot do Pathing analysis.  But hey, they don’t cost a lot!  Personally, I tend to not use Roll-ups since I can duplicate a lot of the info they provide using the ExcelClient and I like Pathing and de-duped Unique Visitors so I tend to favor Multi-Suite tagged sites.

Question #11 (Correct Answer=Calculated Metrics)
Great job on this one as most of you got this one correct!  In my post about Conversion Funnels I explained all of the ways they can be used and highlighted what, in my opinion, is an oversight of the functionality that you cannot add Calculated Metrics to them.  I hope this ability will be available at some point in the future, but in the meantime, you should keep this in mind when determining whether you should pass in a metric organically or rely on a calculated metric.

Question #12 (Correct Answer=Page Views)
In this question, I allowed you to choose from the following metrics.  While most of you got this correct that the Page Views metric is available in Traffic Variable Correlations those of you who also said that you could add Visits, DUV’s and MUV’s were not correct.  Please keep in mind that only Page Views are available when using Correlations.

Question #13 (Correct Answer=Classifications cannot be used in DataWarehouse Segments)
I had a hard time figuring out how to word this question, but if you really understand SAINT Classifications , you should have been able to get this one right by the process of elimination.  As you can see, most people had a hard time with this one, but the correct answer did emerge in the end as the only true statement below is that Classifications cannot be used in DataWarehouse Segments.  We can deduce this by understanding that 1) Classifications can be used in correlations/subrelations, 2) Classifications can be used in Omniture Discover and 3) Classifications cannot have pathing enabled in SiteCatalyst (You can, however, apply Pathing to classifications in Omniture Discover).

Question #14 (Correct Answer=False)
While I have been using Advanced Segment Insight (ASI) segments for many years, I only recently figured out that you can change the ASI type from recurring to time slice and vice versa if you know what you are doing so the correct answer below is actually False (the whole double-negative thing!).  If you have a static ASI that has run for say last month, you can use the “Add Data” link to bring up the ASI segment set-up screen, change the type to Daily Recurring and make the start date the day after your ASI last ran.  Just be sure to uncheck the box that asks if you want to remove existing data or you will lose your past ASI data.  If the ASI you already have is a Daily Recurring, simply wait until it has finished its daily processing and click the “Cancel” link.  Once you have cancelled it, you can click the “Add Data” link, make the type “Time Slice,” select your dates and set it to run.  Again you have to be sure to uncheck the remove existing data checkbox.  I am not sure if this is “officially” supported, but I have done lots of testing on it and so far it has worked fine…

Question #15 (Correct Answer=>!)
This last question is one of those “inside secrets” that only true SiteCatalyst Ninjas know.  Unfortunately, only 32% of you got this one right as the correct answer is “>!” which is a way to tell if a value exists or not in a specific variable when using the segment builder.  I covered this in my Tips & Tricks are of the Segment Builder post so if you didn’t get this one correct, check out that post which has lots of goodies in it.

Well, there you have it.  Hopefully this was a fun way for you to see some of the things that SiteCatalyst Ninjas know.  If you keep reading my blog posts, I can (almost) guarantee you will learn everything that there is to know…