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.

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

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

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.

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

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

A few weeks ago, fellow Omniture SiteCatalyst blogger Jason Egan described some ways to take advantage of the Menu Customization feature in SiteCatalyst.  I wrote about how to use the Menu Customizer in this post, but recently I have been wanting to do something new with the feature that doesn’t appear to be possible.  In this post I will describe what I am trying to do in hopes that someone else out there knows of a way to do it or if nothing else to get it on the radar of the SiteCatalyst product management team…

Why Classifications Mess up the Menu Customizer
For those of you who are savvy enough to understand SAINT Classifications, you will quickly realize how powerful they can be in a SiteCatalyst implementation.  In addition to the normal function of rolling up data into groups, SAINT Classifications are great in cases where the root source of the data is not as “clean” as you would like.  For example, imagine a scenario where you are trying to capture two character text strings for US States into a Traffic Variable.  Unfortunately, your developer has passed data in using both upper and lower case (i.e. CA and ca).  While this can be fixed going forward, there may be reports you need to show that group these together.  Therefore, you would create a SAINT Classification and lump both of these values into a value of “California” in the classified report.

So far so good.  But what if you wanted to show only the Classification report, but not the source report (the one with the “CA” and “ca”)?  Believe it or not, this is actually possible by 1) creating a custom report for the Classification version of the variable and then 2) using the Menu Customizer to put this custom report in the right spot and 3) hiding the original report that was classified.  However, there is one major drawback of this approach.  If you ever need to have a user perform a break down by that classification, for say a Traffic Correlation, you are completely out of luck since hiding the source report disables the ability to break it down.  So in this case, if you had an Internal Search Term report and wanted to break Internal Search Term instances down by state (either the “CA” version or the “California” version), you cannot do it once you have hidden the source report.  The same limitation applies to classified Conversion Variables (eVars) and Conversion Variable Subrelations.

Proposed Solution
While the example above is somewhat basic, there are many cases where you might want to show a classified version of a report, but not show the source report of the same variable. Unfortunately, since you cannot even see Classifications in the Menu Customizer yet, I am not optimistic that this will be addressed anytime soon, but in an ideal world, it would be possible to do the following:

1. See SAINT Classifications in the Menu Customizer as they appear in the regular SiteCatalyst menus and have the ability to hide/move any of them or the source of the Classification.  Currently, most of my Classification data appears in a 3rd level fly-out from the menus and it would be great if I could move these reports anywhere I’d like as I can with non-classification reports.
2. In cases where the source of the Classification is hidden, still allow users to breakdown Traffic and Conversion reports by the classified versions of the source variable
3. If a Custom Report is created using a variable that has Classifications, allow users to have breakdowns of that report in the same way they would if they were looking at the regular version of that report (i.e. don’t punish users for using the Custom Report functionality!)

If anyone out there has come up with a work-around for this, please leave a comment here…Thanks!

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

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