Inside SiteCatalyst

http://blogs.omniture.com/author/agreco/

Why Am I Starting This Blog? [Inside Omniture SiteCatalyst] Tuesday, 5 August 2008 @ 9:20, by Adam Greco

Three years ago, when I joined Omniture Consulting after being one of the early Omniture SiteCatalyst customers, I thought I knew

everything there was to know about SiteCatalyst. I had used the product for years, had created hundreds of reports/dashboards

and presented data to the highest levels of my organization. Then I started working side by side with the (then) small band of

Omniture Consultants and with each passing day, I quickly realized that I had much more to learn. My fellow consultants had done

things I never dreamed of and had a ninja-like mastery of SiteCatalyst that put me to shame! As I learned from them and began

working with great, cutting-edge clients, thankfully I got to the point where I could honestly call myself knowledgeable in

SiteCatalyst. After going through this evolutionary process, I was often quoted as saying:

“If every Omniture client could learn some of the things I learned in the process of going from an Omniture client to an Omniture

Consultant, we’d have a lot more clients doing amazing things with our products!”

Therefore, I have always made it a priority to recall the things I didn’t know then, but have since learned and to impart as much of

that knowledge as possible to my clients. Time and time again, I meet Omniture clients that are using twenty to thirty percent of our

product capabilities due to a lack education or simply not knowing about the existence of key features. As evidence of this, we did

an experiment at last year’s Omniture Summit. I gave a presentation on SiteCatalyst Power Strategies which was very atypical in

that it focused on SiteCatalyst features vs. web analytic concepts. The response was overwhelming (as rated by the # of positive e-

mails I received!) and appeared to have struck a nerve. Those in attendance were self-described ”power users” and many

contacted me afterwards to say they weren’t familiar with many of the concepts I had discussed. If these power users learned

something new, imagine what the rest of the SiteCatalyst user base has the potential to learn! The feedback we received from this

session was that customers need a venue (for which the word “blog” was mentioned repeatedly) for helping them transition

from novices to experts so that they could know enough to maximize their investment in SiteCatalyst.

What This Blog Is…

While nothing can replace the classroom training provided by Omniture University, my goals for this blog are to accomplish the

following:

1. Ensure that all Omniture clients have a venue to learn about the fundamentals of SiteCatalyst so that they can be successful in their Web Analysis or Marketing roles. Much of the content will be educational in nature, but I will strive to provide only the

essentials and do so in a non-user manual way!

2. Provide power user tips and tricks on how to answer real-world web analytics questions by leveraging SiteCatalyst. These

may come from Omniture Consulting or directly from you! So as not to overwhelm those who are newer to SiteCatalyst, I will start with the basics, but promise to get more advanced soon so power users get value as well…

3. Do my best to answer questions you may have about SiteCatalyst features or answering key business questions you have via SiteCatalyst

What This Blog is Not…

It is equally important to state what this blog will not do. This blog will not cover conceptual web analytic topics. There are plenty

of smart people out there blogging about web analytic processes, theories, etc… so I will leave that to them. In addition, this blog

will not cover technical or implementation related topics since it is meant for people using SiteCatalyst vs. people

tagging/implementing SiteCatalyst. Finally, this blog will not cover Discover, Survey, Test & Target, etc… but if this blog is

successful, it may open the doors to similar blogs for those products. However, I will include Excel Tools, Data Warehouse, ASI,

VISTA and all other tools related to SiteCatalyst.

Lastly, I feel that the success of this blog will ultimately be determined by you. The more you share posts with co-workers, add

comments to posts and/or contact me with topics you want me to cover or questions for me to answer, the more successful it will

ultimately be. So here’s hoping for the beginning of a fruitful, mutually beneficial forum…Enjoy!

Traffic Variables (sProps) [Inside Omniture SiteCatalyst] Tuesday, 5 August 2008 @ 11:59, by Adam Greco

Like any software product you use, there are a few key elements that you need to understand to be successful. In working with

clients I have found that many do not have a good understanding of the three fundamental building blocks of SiteCatalyst: sProps,

eVars and Success Events. When I was an Omniture client, I will admit that I had much more important things to do with my time

than to learn about Omniture’s variable types and their capabilities. However, over time, I came to understand that these variables

are the foundation of all SiteCatalyst reporting, so if I wanted to use Omniture reports to measure my website success and/or justify

my re-design theories, I had better suck it up and learn about these three variable types. I hope you will do the same. In this post I

will review sProps and will cover the other two types in my next posts.

Traffic Variables

Traffic variables (known to old-timers as sProps) help to track page-by-page site traffic activity. Site Traffic is normally measured

via Page Views, Visits or Unique Visitors. The primary purpose of sProps is to allow you to breakdown Page Views, Visits and

Unique Visitors into meaningful buckets. While SiteCatalyst provides reports to see total Page Views, Visits and Unique Visitors for

your site, most web analysis needs to take place at a much more granular level. Without sProps, you would not be able to see such

things as which pages are the most popular or what percentage of pages were viewed in the USA vs. Canada, etc…. The following

is an example of the most commonly used sProp report, the Most Popular Pages report:

Not Persistent

An important thing to know about sProps is that they are not persistent. This means that they do not retain their value from one

page to the next, a concept that often confuses Omniture customers. I find that the easiest way to understand sProps is to think of

the most commonly used sProp: Page Name. Let’s assume a visitor to your site starts their visit on the Home Page and the value

“Home Page” is passed into the Page Name sProp. From the Home Page, the visitor clicks on a link and is taken to the “Contact

Us” page. You would certainly not want the value of “Home Page” to persist and be passed into the Page Name sProp on this next

page or it would look like the Home Page had two Page Views instead of each page having one Page View.

Pathing

Another important thing to know about sProps is that they are used for Pathing. Pathing is the ability to view the order in which

values are passed to a particular SiteCatalyst sProp for a specific Visit. For example, let’s say that each page on your site has a

pagename and the values passed to the Pagename sProp are Page A, Page B, and Page C respectively. If Pathing is enabled for

that sProp, SiteCatalyst would record the order in which the values were passed and allow you to view reports that show the

percentage for which all site users went from Page A to Page B, etc… I will definitely be talking more about Pathing in a future post.

Did You Know?

The following additional items related to sProps are worth noting:

1. Visits, Daily Unique Visitors, Weekly Unique Visitors, Monthly Unique Visitors and Quarterly Unique Visitors can be enabled

for any sProp (for an additional fee)

2. SiteCatalyst provides several “out-of-the-box” pre-defined sProps including: Pagename, Site Section, Server, Browser,

Country, etc… These are similar to all other (custom) sProps with the exception being the Pagename sProp which is somewhat special in that it captures the page URL if no value is passed to it.

3. Any two sProps can be “correlated” or broken down by each other

4. Pathing can be enabled for any sProp

5. Any sProp can be “classified” using SAINT

Real-World Example

In every post I will attempt to provide a real-world example of the topic at hand. Let’s say that we are working for Greco Inc., an

Omniture SiteCatalyst customer that owns several different types of web properties. One of Greco Inc.’s web properties has a

translation utility which allows each page of the site to be viewed in either English or Spanish. The CMO is working on a marketing

campaign targeting Hispanic customers and, as such, would like to get a feel for the percentage of all site Page Views viewed in

Spanish. To accomplish this, the client would pass the language that the current page is being viewed in to a custom sProp. For

best results, this sProp should be populated on every page so that the total Page Views in this report matches (or is close to) the

overall number of Page Views for the same timeframe. Doing this might produce a report that looks like this:

Thus, by using a custom sProp, Greco Inc. now has a new way to breakdown Page Views and can answer the specific business

question at hand.

Conversion (Success Events) [Inside Omniture SiteCatalyst] Friday, 8 August 2008 @ 6:00, by Adam Greco

SiteCatalyst Conversion Variables

Omniture SiteCatalyst breaks its variables into two types: Traffic and Conversion. As discussed in my last post, Traffic Variables

allow you to segment traffic metrics (i.e. Page Views) and utilize Pathing, whereas Conversion Variables allow you to quantify and

segment the success actions taken by your site visitors. The Conversion area of SiteCatalyst is made up of two distinct variable

types - Success Events and Conversion Variables (also known as eVars). In this post I will discuss Success Events, followed by

Conversion Variables in my next posts.

Success Events & KPI’s

Before exploring Success Events, it is worthwhile to discuss Key Performance Indicators (or KPI’s). Hopefully you are familiar with

the term, but just in case, KPI’s are the metrics used to determine the health or success of your website. If the goal of your website

is to get visitors to purchase things then your KPI’s might be Revenue, Orders & Units. Alternatively, if the goal of your website is to

generate leads, then you may monitor a “Leads Generated” KPI. The reason I bring up KPI’s here is because most website KPI’s

take the form of Success Events in SiteCatalyst so the two go hand in hand. When I begin working with an existing client, the first

thing I look at is whether the key actions they want visitors to take on their site are defined as Success Events and if so whether

these Success Events have data. Unfortunately, more often than not, I find that clients have done much more with their Traffic

Variables than they have with their Conversion Variables.

SiteCatalyst Success Events

SiteCatalyst Success Events are Conversion Variables that count the number of times site visitors complete an action on your site.

Unlike Traffic Variables which serve as dimensions or breakdowns of a Page View/Visit/Unique Visitor metric, Success Events are

always numbers. Through tagging, you tell SiteCatalyst when users have taken the action(s) that you want them to take and

Success Events are increased accordingly. Therefore, each SiteCatalyst Success Event has an associated graph that shows its

metric total for any given timeframe (see example below).

Success Events can be either Standard or Custom. Standard Success Events include a select few actions that are prevalent on

retail websites such as Revenue, Orders, Units, Cart Additions, etc… Custom Success Events are available for use for any site

action you deem worthy of tracking. Omniture provides the ability to have up to 86 Success Events, though many of these are

reserved for use in Genesis Partner integrations (future topic). As a rule of thumb, I tell my clients that if there is an action on the

website that is fundamental to the existence of the website, it should be tracked as a Success Event. If you or one of your co-

workers won’t get promoted (or fired!) based upon the outcome of the Success Event, it may not be worthy of being a Success

Event. In reality, I find that most of my clients use fewer than 20 success events, mainly to avoid “analysis paralysis!”

Conversion vs. Traffic

One area where I see clients get confused is in the relationship between SiteCatalyst Traffic Variables (also known as sProps) and

Conversion Variables. In SiteCatalyst, there is a clear distinction between these variable types such that each variable type has its

own specific purpose. When you think of Traffic Variables you should think about Page Views, Unique Visitors and Pathing. When

you think about Conversion Variables you should think about Purchases, Lead Form Submissions, etc…

In SiteCatalyst, you would never attempt to segment/breakdown Success Events by a Traffic Variable (You can do this in Omniture

Discover, but not in SiteCatalyst). For example, in my last post we saw an example where Page Views were broken down by

language (English or Spanish). In SiteCatalyst, you would not breakdown a Revenue Success Event by the Language Traffic

Variable to see Revenue where visitors preferred Spanish. This is because the primary purpose of Traffic Variables is to count

Page Views and enable Pathing, not break down Success Events. However, don’t panic because in subsequent posts we will learn

how Conversion Variables allow you to do this and much, much more!

Real-World Example

Let’s say go back to our fictitious Omniture client Greco Inc., which has one of its web properties in the Online Education space. A

key component of their online education website is to get visitors to view a demo of an online course so they can get a flavor of the

overall experience of being an online student. In this case, when the visitor clicks to view the Course Demo, Greco Inc.’s marketing

manager works with IT to set a Success Event and thereafter can track the progress of this metric using the associated SiteCatalyst

report:

In summary, this post covered the basics surrounding Success Events and when they should be used. In future posts I will cover

the following additional items related to Success Events:

1. Adding Success Event reports to dashboards for dissemination to website stakeholders

2. Downloading Success Event data to Microsoft Excel so it can be merged with other data

3. Using Success Event data in SiteCatalyst Calculated Metrics and Conversion Funnels

4. Setting Alerts to be notified when Success Event data changes

5. Ensuring Success Events are not set more than once (de-duplication)

6. More advanced uses of success events

Stay tuned for my next posts in which I will round out the conversation on SiteCatalyst variables by discussing Conversion

Variables…

Conversion Variables - Part I [Inside Omniture SiteCatalyst] Wednesday, 13 August 2008 @ 5:00, by Adam Greco

In the last two posts we have begun to learn about Omniture SiteCatalyst Traffic Variables and Conversion Variables (Success

Events). As previously discussed, Traffic Variables allow you to segment or breakdown Page Views, Visits and Unique Visitors,

while Success Events capture metrics around conversion actions taken by site visitors. In our Traffic Variable post we saw how we

could segment/breakdown Traffic metrics by Language, but learned that Success Event metrics are not broken down by Traffic

Variables in SiteCatalyst. So what if we want to be able to show the percentage of Lead Generation Form Submissions broken

down by Language? Perhaps we want to see Shopping Cart Additions broken down by Zip Code or Campaign Tracking Code.

There are lots of cases where you will want to segment/breakdown Success Events in a similar manner that Traffic Variables allow

you to break down Traffic Metrics. So how do we do this?

Conversion Variables to the Rescue!

The purpose of Conversion Variables (also known as eVars) is to allow you to breakdown Success Event metrics in a similar

manner that Traffic Variables allow you to breakdown Traffic metrics. While this sounds easy, Conversion Variables are actually

one of the most confusing topics for SiteCatalyst customers because there is a lot to learn about how they behave (which is why this

is only Part I). I will describe the key points here and then try to make sense of it all through some examples.

Unlike Traffic Variables, Conversion Variables are persistent meaning that once a site visitor gets assigned a value, that value

sticks with them until you (SiteCatalyst Administrator) tell SiteCatalyst to clear it out (unless the user deletes their cookies or uses a

different computer). For example, if you have a Conversion Variable that stores the visitor’s City, you can capture the City on page

three of their visit and have it remain there for several pages, days, weeks, months, etc…

Conversion Variables have a direct relationship to Success Events. I like to think of the two as “married” since they complement

each other. When a SiteCatalyst Success Event takes place (i.e. visitor takes an action that results in a Success Event being set),

SiteCatalyst assigns credit for the Success Event to one value in each Conversion Variable report (please re-read that once

or twice!). For example, if an Online Course Demo Success Event takes place, whatever value is currently stored for that visitor for

Conversion Variable 1 gets credit for that Success Event. Whatever value is currently stored for that visitor for Conversion Variable

2 gets the credit for that Success Event and so on until all Conversion Variable values are incremented. So let’s imagine you have

a website with only one visitor, where Conversion Variable 1 is used to capture City and we have used custom tagging to capture

the fact that this visitor is from the city of Chicago. If that one visitor subsequently launches an Online Course Demo and a Success

Event takes place, the Online Course Demo Success Event report would show a total of “1″ and the Conversion Variable 1 (City)

report would show a value of “1″ for the “Chicago” row (assuming that the Conversion Variable 1 report was showing the Online

Course Demos metric) as shown in this sample report:

As many more Success Events take place, different Conversion Variable values (Cities in this example) would get credit for the

various Online Course Demos that take place on the site such that, over time, the report would have many cities and the associated

number of Online Course Demos that took place for each. But, if Conversion Variable 2 represented the current visitor’s Age, then

at the same time each City is getting credit for each Online Course Demo in Conversion Variable 1, a specific Age value (say “18

Years Old”) is getting credit for the same Success Event in the Conversion Variable 2 report which would look like this:

Real-World Example

Phew! Let’s use one more example to help clarify things and in this example we will build upon the scenarios from our previous two

posts. In the Traffic Variable post, Greco Inc. wanted to know what percentage of Page Views was viewed in Spanish so they set a

Traffic Variable with the language on each page. In our Success Event post, we learned that one of Greco Inc.’s web properties is

in the area of Online Education and they began to capture the number of times visitors viewed Online Course Demos as a Success

Event. Now, Greco Inc. would like to see how many of its Online Course Demos were viewed in Spanish. To do this, marketers

would work with their IT department to pass the language value (”english” or “spanish”) to a Conversion Variable. Over time, Greco

Inc. can use the following Conversion report to see Online Course Demos broken down by Language:

Therefore, at this point Greco Inc. has passed a Language value to both a Traffic Variable and a Conversion variable. The Traffic

Variable is used to breakdown Page Views and the Conversion Variable is used to break down Success Events. Hopefully these

two examples will help you keep Traffic and Conversion Variables straight and understand when to use each. I recognize that some

of this can be a bit confusing, so feel free to re-read parts of this and post comments here so I can clarify as needed. Once you get

it, I promise you will never forget it!! Stay tuned for Conversion Variables Part II…

Conversion Variables - Part II [Inside Omniture SiteCatalyst] Tuesday, 19 August 2008 @ 6:00, by Adam Greco

In the last post we began to learn about Conversion Variables (also known as eVars), their special relationship with Success Events and how they differ from Traffic Variables (also known as sProps). In this post we will cover the remaining basic items related to Conversion Variables so we can begin to move onto some more advanced topics.

Persistence

As was previously discussed, Conversion Variables are persistent such that as visitors to your site get assigned a value for a

Conversion Variable, it stays with them for a designated time frame. For example, if a visitor fills out a form on your website and

indicate that they live in Chicago, we may pass the value of “Chicago” to Conversion Variable 1 for that user. You don’t need to

worry about where that data is stored, but rather just understand that it can be stored and applied to Success Events that take place

thereafter. However, this ability to store persistent values brings with it some complications. What happens if two values are

passed to a Conversion Variable before a Success Event takes place? Who decides which should get credit for Success Events?

Who decides how long SiteCatalyst should store the Conversion Variable values? Great questions and the answer is that you get

to decide! SiteCatalyst provides an Administration Console where you can adjust the settings of your Conversion Variables. This

tool allows you to specify the Conversion Variable Name, Allocation, Expiration, Type and Status as shown here:

Name

Name represents what your users will see as the “friendly” name for Conversion Variable in SiteCatalyst. In this preceding

example, we would name Conversion Variable 1 to “City” so SiteCatalyst users would know that anytime they want to view Success

Event metrics by City, they should open that report.

Allocation

Allocation is a way that you can tell SiteCatalyst if you want the first Conversion Variable value, the last Conversion Variable value

or all Conversion Variable values to be associated with subsequent Success Events. If you would like the first value that gets

passed to a Conversion Variable to get credit for subsequent Success Events you would choose “Original Value (First).” If you

wanted the last value passed to the Conversion Variable to get credit for subsequent Success Events, you would choose “Most

Recent (Last).” Finally, if you want multiple values passed to a Conversion Variable to get credit for subsequent Success Events,

you would choose the “Linear” option (However, please note that the linear option does not allocate across multiple visits so it is

only dividing credit amongst values passed to the Conversion Variable within one visit).

Expire After

Once a value for a particular user is stored in a Conversion Variable, you use the “Expire After” setting to specify how long it should

remain there. If your website is very Visit-focused, you may leave the default of “Visit” for many of your Conversion Variables.

Conversely, you may decide that once you capture the visitor’s Age in a Conversion Variable, you’d like to keep it as long as

possible so any future Success Events can be broken down by Age. Finally, you may decide that you want to keep Conversion

Variable values only until the point at which a user completes a specific Success Event. All of these options are available to you in

the Expiration area.

Since Type, Status and Reset are a bit more advanced and are seldom changed, I will cover those in a future post.

When Should Conversion Variables Be Set?

Another important thing to understand related to Conversion Variables is when they should be set. In order to associate a Success

Event with a Conversion Variable, the Conversion Variable must be set at the same time or before the Success Event. For

example, if you set a Success Event on the third page of your site, but don’t store the visitor’s City to a Conversion Variab le until the

fifth page, you will not be able to see that relationship in SiteCatalyst reports (you can, however, in Data Warehouse and Discover).

The “None” Row

One of the most frequently asked SiteCatalyst questions I get is: What is the “None” row in Conversion Variable reports and how

can I get rid of it? If there is no value stored in a Conversion Variable for a user at the time a Success Event is set, SiteCatalyst

gives credit to that event to “None” so that the Success Event metric total at the bottom of the Conversion report will match the

same total as the Success Event report. An easy way to remember this is to substitute the phrase “Instances in which SiteCatalyst

didn’t know the [Conversion Variable Name]” for “None” in each report. In the preceding paragraph where the City value wasn’t set

prior to the Success Event, that instance of the Success Event would be attributed to the “None” row in the City Conversion Variable

report since SiteCatalyst didn’t know to which City it should give credit. To reduce the numbers in the “None” row of Conversion

reports you can set Conversion Variables early in the visit and/or keep values stored for longer periods of time using the Expiration

setting described above. However, keep in mind that the “None” row can be extremely useful. For example, you may get a

question in which someone wants to know what percentage of time people completed applications without having come from any

online marketing campaigns. The answer to this question can be found by simply adding the Applications Completed Success

Event metric to the Campaigns report and looking at the percentage of the “None” row (14.61%) as shown here:

Real-World Example

So let’s go through another real-world example. Our fictitious client, Greco Inc. has a website where it places many internal

promotional banners. Each time visitors click on a promotional banner, they capture the ID# of that promotion in a Conversion

Variable that is set to expire at the end of the Visit and gives credit to the Most Recent (Last) ID# the user clicked. They use this

Conversion Variable to see which promotional banners, clicked within a Visit, get site visitors to convert. However, one of the

marketing managers believes that visitors who click on a promotional banner may convert a few weeks later. To test this theory,

she wants to learn which promotional banners are the first ones clicked by users and give credit for all Success Events taking place

for the next 30 days to that promotion. So how would she do this?

First, she must create a new Conversion Variable (let’s call it “First Internal Promotion”) in the Admin Console. Using the settings

mentioned above, she would set the Expiration to be “30 Days” and change the Allocation to be “Original Value (First).” Next, she

would work with IT to pass the same value passed to the previously mentioned Internal Promotion ID# Conversion Variable to this

new First Internal Promotion Conversion Variable. Even though many different values will be passed to this new First Internal

Promotion Conversion Variable, due to the settings chosen, SiteCatalyst will ignore all of them except the first value it receives until

30 days have passed (after which it will reset and then accept the next value passed to it). After this is complete and data has been

collected, the marketing manager will be able to open up the “First Internal Promotion” Conversion Variable Report, add any

relevant Success Event metrics and see the results as shown here. In this case, it looks like “promo456″ is the internal promotion

clicked most often prior to Lead Form Submissions and that “promo122″ is the internal promotion most often clicked first prior to

Application Completions.

In future posts I will cover more topics related to Conversion Variables such topics as:

1. Conversion Variable Subrelations

2. Standard Conversion Variables (i.e. Search Engine, Search Keyword, Entry Page)

3. Merchandising

Traffic Data Correlations [Inside Omniture SiteCatalyst] Wednesday, 27 August 2008 @ 2:00, by Adam Greco

Now that we have covered the basics of the three Omniture SiteCatalyst variable types, it is time to see how we can use them to our

advantage to do analysis. In this post we will learn about Traffic Data Correlations which allow you to leverage the work you have

already done by tagging your Traffic Variables (also known as sProps).

Traffic Data Correlations

So what is a Traffic Data Correlation? In the simplest terms, a Traffic Data Correlation is a SiteCatalyst report that breaks down one

Traffic Variable by another Traffic Variable. If you have populated a value in two different Traffic Variables, then it is possible to

see one broken down by the other. For example, let’s say that you have passed a Page Name value on each page to the Page

Name Traffic Variable. By default, SiteCatalyst captures the visitor’s Browser Height in a standard Traffic Variable. Therefore, you

can easily see the Browser Height for each Page Name by enabling a Traffic Data Correlation between these two Traffic Variables.

To enable Traffic Data Correlations, you simply use the Administration Console and select the Traffic Variables you want to

correlate as shown here:

When you “enable” a Traffic Data Correlation, SiteCatalyst creates a new data table dedicated to the Traffic Variables you have

specified. Once the Traffic Data Correlation has been created, you can access it by viewing either of the Traffic Variable reports

associated with that Correlation and clicking on the green magnifying glass icon as shown here:

In this case, if the SiteCatalyst user clicked on the report highlighted above, they would see a report that shows the Page Names

that were viewed by visitors having a Browser Height between 750 and 759 and their associated percentages:

However, when you create a Traffic Data Correlation, you get the ability to see two new reports, not one. This concept confuses

many of my clients. In the example shown above, we see a report showing Page Names for a specific Browser Height, but with the

same Traffic Data Correlation, we can also see the converse, which in this case, is a report that shows all Browser Heights for a

specific Page Name:

Other Things To Know About Traffic Data Correlations

The following are some important things to know about Traffic Data Correlations:

1. While not mandatory, it is recommended that you Correlate Traffic Variables that are both present in the same SiteCatalyst image request (normally a Page View). If only one of the Traffic Variables has a value, you will see an “Unspecified” value

in the Traffic Data Correlation reports.

2. While you can see Page View, Visit and Unique Visitor metrics for any Traffic Variable, SiteCatalyst only shows Page Views

in Traffic Data Correlation reports (other metrics can be seen in Omniture DataWarehouse or Omniture Discover).

3. Traffic Data Correlations come in several flavors such as 2-item Correlations and 5-item Correlations. You can enable up to

fifteen 2-item Traffic Data Correlations in the Admin Console and more can be purchased as needed. 5-item Traffic Data Correlations are a bit more advanced and give you the ability to break down up to five Traffic Variables by each other, but

have an additional cost.

4. SiteCatalyst provides the ability to create Traffic Data Correlations with many standard Traffic Variables out of the box such as

Browser, OS, Resolution, etc…

5. Enabling a Traffic Data Correlation allows you to correlate the two Traffic Variables from that point forward, but does not allow

you to see the data correlated retroactively.

6. Any Traffic Data Correlations for a Traffic Variable will also apply to any SAINT Classification (to be discussed in a future post)

for that Traffic Variable.

7. In Omniture DataWarehouse and Omniture Discover, all Traffic Variables are automatically correlated with each other!

Real-World Example

In previous posts we have been helping Greco Inc. do more with their SiteCatalyst implementation. One of the items Greco Inc. has

implemented is the passing of the Language that each website page was viewed in (”English” or Spanish”) to a Traffic Variable.

This allowed them to see the proportion of site Page Views that were viewed in English vs. Spanish. However, what if Greco Inc.

would like to see the specific pages that were viewed in English or Spanish? Unfortunately, nothing we have done so far would

enable them to see this. We can see Page Views for each Page Name and Page Views for each Language, but not one by the

other. This is why we need a Traffic Data Correlation. Since every page of the site has a Traffic Variable value for Page Name and

Language, enabling a 2-item Traffic Data Correlation will allow us to see Page Names broken down by Language and Language

broken down by Page Name. The result is a report that looks like the one shown here:

Conversion Variable Subrelations [Inside Omniture SiteCatalyst] Wednesday, 3 September 2008 @ 2:00, by Adam Greco

In our last post, we discussed Omniture SiteCatalyst Traffic Data Correlations and learned how they could be used to break one

Traffic Variable (also known as an sProp) down by another Traffic Variable. But what if you want to break down a

SiteCatalyst Conversion Variable (also known as an eVar) down by another Conversion Variable? Since these are not Traffic

Variables, Traffic Data Correlations cannot be used. Instead, we rely on Conversion Variable Subrelations which will be covered in

this post.

Conversion Variable Subrelations

So what is a Conversion Variable Subrelation? In the simplest terms, it is one Conversion Variable broken down by another

Conversion Variable. For example, let’s say you capture the current visitor’s City in one Conversion Variable, their Age in another

and also have a Subscriptions Success Event. You can use the City Conversion Variable to see Subscriptions broken down by City

and the Age Conversion Variable to see Subscriptions broken down by Age. But what if you would like to see Subscriptions where

users were from Chicago and 18 Years Old? To view this in SiteCatalyst, you would need to use Conversion Variable

Subrelations. In this example, you would work with your Omniture Account Manager to “enable” Subrelations on one of the two

Conversion Variables (City or Age) and from that point on, you can break one down by the other to see a report like this:

If you read the previous post you can see that this is very similar to the concept of a Traffic Data Correlation, only for Conversion

Variables. While there are some important differences, the general concept is very similar.

All or Nothing

One of the ways that Conversion Variable Subrelations are different from Traffic Data Correlations is that you cannot enable a

subrelation between just two Conversion Variables. A Conversion Variable can have one of the following types of Subrelations:

1. Full Subrelations - Conversion Variable can be broken down by all other Conversion Variables

2. Basic Subrelations - Conversion Variable can be broken down by any other Conversion Variable that has Full Subrelations

3. No Subrelations - Conversion Variable cannot be broken down by any other Conversion Variable (rarely used)

Therefore, Conversion Variable Subrelations is an “all or nothing” proposition. The number of Conversion Variables for which you

can enable Full Subrelations is specified in your Omniture contract. For this reason, it is important to think about which of your

Conversion Variables are the most important with respect to breakdowns. For example, in the scenario outlined above, if the

client feels that City is a much more important data point than Age, given the choice of enabling Full Subrelations on one or the

other, it should choose to enable it for City since it will then be able to break down every Conversion Variable by City.

Other Things To Know About Conversion Variable Subrelations

The following are some important things to know about Conversion Variable Subrelations:

1. By default, SiteCatalyst provides Full Subrelations on the Campaign Tracking Variable, the Products Variable and for Customer Loyalty.

2. Enabling a Conversion Variable Subrelation allows you to break down the two Conversion Variables from that point forward, but does not allow you to see the data retroactively.

3. In order to see two values broken down by each other in a Subrelations report, both Conversion Variables must have a data value for the same visitor prior to the Success Event being set. If no value is present, the report will show a “None” row.

4. Any Subrelations settings for a Conversion Variable will also apply to any SAINT Classification for that Conversion Variable.

5. In Omniture DataWarehouse and Omniture Discover, all Conversion Variables are automatically Subrelated with each other!

Real-World Example

In a previous post we learned that Greco Inc. was capturing the Language the current site visitor was using in a Conversion

Variable. Now the Marketing Manager is looking to augment this data by associating Language with Zip Codes to determine the

geographic location of Spanish-speaking visitors who are completing the initial Site Success Event (viewing Online Course

Demos). Prior to launching the Online Course Demo, site visitors are required to enter their Zip Code so the Marketing Manager

works with IT to pass this value to a new Conversion Variable. Since much of what Greco Inc. does is geography-based, they

decide to enable Full Subrelations on this new Zip Code Conversion variable so they can break down future Conversion Variables

by Zip Code. Once this tagging is done and Subrelations has been enabled, the Marketing manager can use the magnifying glass

icon to view Online Course Demos for a Language (in this example “spanish”) broken down by Zip Code (or vice versa):

One final “power user” tip. Instead of just breaking one Conversion Variable value down by another Conversion Variable, you can

use the little known “5 by 5″ icon (highlighted below) to see the top five values for each of the top five items in the Conversion report

you are currently viewing. This gives you a great way to see a lot of data all at once:

Classifications (a.k.a. SAINT) [Inside Omniture SiteCatalyst] Wednesday, 10 September 2008 @ 1:00, by Adam Greco

Classifications (also known by the acronym SAINT for SiteCatalyst Attribute Importing and Naming Tool), or the process of

classifying an Omniture SiteCatalyst variable, is a topic that tends to confuse many of my clients. Having been a customer myself, I

can understand why Classifications can be daunting, but the truth is that once you understand them, they are not very difficult and

can save you a lot of time. In this post I will cover the basics of Classifications and how you can use them.

What are Classifications?

So what exactly is a Classification? Technically speaking, when you “classify” a SiteCatalyst variable you are establishing a

relationship between a variable and meta-data related to that variable. Classifications are most frequently used in the Campaigns

area so I will use that as a way to explain them. Most clients send campaign traffic to their site using a tracking code. This tracking

code is an identifier that may represent a specific keyword purchased on Google, such as “goog123.” This identifier is passed into

the s.campaigns variable so you can see what site success events take place after visitors come to your site from that campaign

code. But what if, instead of viewing Campaigns just by the tracking code, you want to see campaign results by Search Engine or

Keyword or Campaign Channel? Do you have to create a new conversion variable for Search Engine, another for Keyword and yet

another for Campaign Channel? If so, you would use up many of your fifty variables on Campaigns alone! Thankfully, you can use

Classifications to make your life easier! Since each tracking code could have a Search Engine, Keyword or Campaign Channel,

you can simply create three Classifications of the Campaigns variable to represent each. You are essentially telling SiteCatalyst

that there is a direct relationship between the Campaigns variable and these three other “meta-data” values. By doing this,

SiteCatalyst will allow you to slice and dice site Success Events by all four variables with no additional tagging!

So How Does It Work?

To classify a SiteCatalyst variable, the first thing you (or someone with Admin rights) need to do is to set-up the Classification in the

Administration Console. To do this, you select the appropriate report suite(s) and then choose the variable you want to classify as

shown here:

In this case we will add the three previously mentioned items as Classifications of the Campaigns variable. Once you have added

the three Classifications, you should see this…

…and within SiteCatalyst you will see a new report for each classification like this:

Now that your classifications are set-up, you need to provide SiteCatalyst with the values for each tracking code for which you

expect to receive data. This is normally done by uploading a spreadsheet using a template provided by SiteCatalyst. If you have

more than 20,000 rows, it is recommended that you use the FTP feature to upload your Classification data (Information on using

FTP can be found in the user manual). To upload Classification data, simply go to the Admin area within SiteCatalyst (top-right)

and choose “SAINT Classifications” from the dropdown box. There you choose the variable for which you want the template and

click the download button to save the template to your computer like this:

Next, you can open the Classification template (I use Microsoft Excel) and fill in the data so that it looks like this:

Note that while it is recommended that as much data is uploaded as possible, it is not required that all data be filled out. In this

example, it does not make sense for the “CNN” line item to have a Search Engine or Keyword value so those are left blank. When

you are done completing the file, you can use the “Import File” tab to upload your spreadsheet and within an hour or so, all

Classification data will be available in SiteCatalyst.

After all of this is completed, you will be able to see the following four reports within SiteCatalyst:

Important Things To Know About Classifications

The following are some important things to know about Classifications:

1. Every Classification that you make will create a new SiteCatalyst report. These new reports show you the selected metrics using the Classification value. If no value is uploaded, items will be placed in a “None” row if Conversion Variable or omitted if

a Traffic Variable.

2. Classifications are retroactive. This means that if you make a change to the SAINT file above and re-upload, the new values

will overwrite the old values. For example, if for tracking code “msn998″ you realize later that the keyword was “VCR,” not “TV,” you can change it and re-upload and the Keyword report will then reflect “VCR.”

3. You can classify any Traffic Variable (sProp) or Conversion Variable (eVar) and there is no additional charge for doing this.

4. Any Traffic Data Correlation or Conversion Subrelation that is enabled for the variable you are classifying will also be enabled

for any Classification of that variable. For example, since the Campaigns variable comes with full subrelations by default, any classification of the Campaigns variable will have full Subrelations as well.

5. Pathing is not available on Traffic Classifications within SiteCatalyst (but is available in Omniture Discover). Many clients attempt to use Classifications on their Page Name Traffic variable as a way to apply “friendly” page names only to later find

out that they can only see pathing reports for the “unfriendly” name!

6. You cannot classify out-of-the-box SiteCatalyst reports such as Browser, GeoSeg Countries, etc… However, if this is

important, you can use a VISTA rule to pass this data to a custom variable which can then be classified.

Real-World Example

In this version of our real-world example, our company, Greco Inc. is focusing on its retail subsidiary. The online marketing

department would like to see what search terms visitors are searching upon to see which content it should spotlight. Using the

information from our previous post they decided to pass the internal search terms entered to a traffic variable as shown here:

However, in addition to looking at this laundry list of product-related terms, they would like to group the products being searched into

the Product Categories they use to structure the website. To do this, they enable an “Internal Search Term Grouping” Classification

for the Search Term variable and proceed to create/upload the following Classification file:

The result is a more streamlined report that allows Greco Inc. to view Search Terms by Product Category, as shown below, without

any additional tagging to the site! Based upon this, it is easy to see that the “Bed Bath & Table Linens” products are being searched

the most, a fact that was not apparent using the Search Term report…

Counter eVars [Inside Omniture SiteCatalyst] Wednesday, 17 September 2008 @ 8:19, by Adam Greco

At last year’s Omniture Summit, I brought up the topic of Omniture SiteCatalyst “Counter” Conversion Variables (also known as

eVars) and was surprised by how many people were unfamiliar with Counter eVars and/or not using them. Therefore, I want to take

some time to explain what Counter eVars are and when they should be used. I will also cover some “power user” aspects of this

feature for those looking to push the envelope of their SiteCatalyst implementation.

What is a Counter eVar?

In a previous post, I discussed the various settings related to Conversion Variables (eVars). One of these settings was the

“Type” which can be either “Text String” or “Counter.”

About 95% of the time, Conversion Variables will be “Text String,” but it is important to understand how you use the other “Counter”

type. A Counter eVar is a Conversion Variable that is used to see how many times something happened prior to a website

Success Event taking place. For example, let’s say that you wanted to see how many internal searches users conduct prior to

placing a product into the shopping cart. You can back into this number through some advanced analysis or formulas, but an easier

way to do this would be to use a Counter eVar. When you use a Counter eVar, you are incrementing a value in the eVar by “1″

each time you set the eVar (until the eVar expires). For example, let’s imagine that a website visitor comes to the site and conducts

a search on the phrase “shipping.” At this point the Counter eVar (with an expiration of 30 days) is set so the value persisted in

SiteCatalyst is “1.0″ for that user. Now let’s say that this same visitor comes back the next day and searches on the phrase “Harry

Potter.” Now the Counter eVar would be set again and the value for that visitor would be “2.0.” Next, our visitor adds an item to the

shopping cart and the “Cart Additions” Success Event is set. Since the current value stored in that user’s eVar is “2.0,” the phrase

“2.0″ would get credit for the Cart Addition and we would see a report that looks like this:

How can Counter eVars be used?

There are an infinite number of ways that Counter eVars can be used. Here are just a few ideas:

1. Track how many campaign codes are used prior to a purchase taking place

2. Track how many articles are read prior to registering on the site

3. Track how many blog posts are read prior to signing up for an RSS feed

4. Track how many flight searches a user conducts prior to booking travel

5. Track how many cars a visitor designs prior to requesting a quote from a dealer

As you can see through these examples, Counter eVars can be used in many ways and can be useful in understanding how visitors

use your website. This information can be extremely helpful in building a good user experience.

Important Things To Know About Counter eVars

The following are some important things to know about Counter eVars:

1. Counter eVars act like all other eVars with respect to expiration so they can expire based upon a fixed timeframe or a Success

Event taking place.

2. You can use Counter eVars in Subrelation reports just as you would any other Conversion Variable. For example, using the scenario above, you may want see which specific internal search terms visitors searched upon in situations where it took more

than one search to add something to the shopping cart. You would do this by enabling Subrelations on one of the Conversion Variables (I would use the internal search term!) and then you can break the two Conversion Variables down by each other. In

our preceding example, this would mean seeing that the phrase “Harry Potter” was the phrase searched upon where searches equals “2.0.”

3. You can classify Counter eVars just as you would any other Conversion Variable. Don’t want to see a report with values of “1.00” or “3.00?” Classify those values using SAINT to see reports where the value is greater than “3” or between “2” and “5”

4. Counter eVars are very useful as segment criteria in DataWarehouse or Discover (i.e. show me all visitors who performed more than two searches, etc…).

5. While the most common use of Counter eVars is to increment/decrement them by “1″ each time they are set, you can increment them by any number you want including decimals and negative numbers. I have not seen much use of this little

known feature, but would love to hear from anyone out there who has experimented with it. One idea I have thought about is using it track visitor engagement where you can increase or decrease the user’s engagement value throughout their visit

based upon what website actions they take!

Real-World Example

In this version of our real-world example, our company, Greco Inc. is focusing on its auto insurance subsidiary. The department

responsible for the online auto insurance quote pages would like to understand how often visitors are performing multiple quotes

prior to submission to determine if the user interface should be optimized for single quotes or modified to encourage multiple quotes

per session. To do this, they work with IT to set a “# of Quotes” Counter eVar that expires at the end of the Visit. Each time a

visitor creates a quote, the Counter eVar is set (see implementation manual for code syntax). After collecting a month’s worth of

data, Greco Inc. opens the “#of Quotes” report and adds the “Submitted Quotes” Success Event to see the results:

Based upon this data, it looks like visitors do prefer to complete multiple quotes prior to submitting the final one for approval and that

it would behoove Greco Inc. to facilitate this process rather than getting in the way of its users’ desired behaviors.

For those of you wanting “extra credit,” keep in mind that Greco Inc. can use what they learned in our Classifications post to classify

the “# of Quotes” Conversion Variable so that, in the classification report, the value of “1.00″ is on its own row and all other values

are combined into a single row named “Two or More Quotes” so that it is easy to see the various percentages.

Omniture ExcelClient [Inside Omniture SiteCatalyst] Tuesday, 23 September 2008 @ 11:39, by Adam Greco

While the reports and dashboards you can create within Omniture SiteCatalyst are great, there is no escaping the fact that power

web analysts have an affinity for Microsoft® Excel®. Microsoft Excel provides numerous ways to manipulate and view data that will

never be available in any web analytics tool. For this reason, Omniture provides access to a powerful “ExcelClient” (not a typo,

there is no space) which allows you to pull data from your Omniture SiteCatalyst data set into Microsoft Excel. This Omniture

ExcelClient is extremely powerful, especially when combined with advanced knowledge of Microsoft Excel, a tool well known to

traditional analysts. In this post I will familiarize you with what you can do with the Omniture ExcelClient and how it can be used to

simplify your web analysis.

What is the Omniture ExcelClient?

So what exactly is the Omniture ExcelClient and why should you care about it? In a nutshell, the Omniture ExcelClient is an Excel

add-on that allows you to define data queries (known as “Data Blocks”) of your SiteCatalyst data and embed them into Microsoft

Excel. Through a wizard interface accessed within Excel, you can add a report query to a spreadsheet and save it so that in the

future you don’t have to repeat the same query again. Instead, you can simply “refresh” the query since it already knows what data

you are looking for. So the first two benefits of the Omniture ExcelClient are that it allows you to easily push data from SiteCatalyst

into Excel and that it can save you time by not requiring you to re-create queries. But wait…there’s more! The best part of the

Omniture ExcelClient is that it allows you to tie parts of the data query to values in specific cells of the Excel spreadsheet. While

this may not sound very exciting, it is (I promise)! Using this feature you can:

1. Tie the SiteCatalyst report suite ID to a cell so you can view the same data block for different report suites by changing just one cell (assuming you have the same variable definitions in both)

2. Tie the start and end dates to cells so you can view the data block for different time ranges by changing one or two cells

3. Tie the number of rows you want to view in the report to a cell so you can modify the number of rows in your report by

changing one cell

4. Tie a search phrase to a cell so you can enter a term or phrase and have the report results filtered as you would using the

search box within SiteCatalyst. This feature recognizes both “include” and “exclude” phrases.

All of these options are shown in the following sample Excel spreadsheet:

In the example shown here, instead of tying a SiteCatalyst data block to a particular report suite, you can tie it to the report suite ID

found in cell “B1.” Instead of tying a data block to the month of August 2008, you can make it so the data block looks to cells “B2″

and “B3″ for the start date and end date and so on. Then, after you update these cells, all you need to do is click the “Refresh

Worksheet” button in the ExcelClient toolbar to pull the appropriate data from SiteCatalyst. This allows you to build very flexible

data blocks which can return different data sets based upon your current needs. Finally, in addition to all of the preceding items,

you get the ability to create as many charts and graphs as you want based upon your SiteCatalyst data and even merge

SiteCatalyst data with other data (i.e. offline data) that you pull into Excel. This means that if you or one of your associates is an

Excel guru, you can do virtually anything with your SiteCatalyst data. When I was an Omniture client, I had an excel workbook with

about 30 tabs and one summary sheet that had pretty graphs and data aggregations. Each morning, I would come to the office,

click the “Refresh All” button and go grab a morning drink knowing my summary report would be done by the time I got back!

How Do I Install and Get Started with the Omniture ExcelClient?

To use the Omniture ExcelClient, your organization must have a license and your user ID must be added to the appropriate

ExcelClient security access group by your SiteCatalyst administrator. Once this is in place, you can download the Omniture

ExcelClient by clicking the link within the SiteCatalyst tab (green arrow) as shown here:

Once you have installed the Omniture ExcelClient, open Excel and you will find it in the Excel toolbar or in the “Add-Ins” area of

Microsoft Excel (depending upon your version). Next, you click the “Insert Data Block” button, login using your SiteCatalyst

credentials and follow the wizard to create a data block:

Important Things to Know About the Omniture ExcelClient

The following are some important things to know about the Omniture ExcelClient:

1. You can add multiple data blocks to an Excel worksheet, but you need to be sure that you are not overlapping data blocks or

you will be in trouble. Keep in mind that you may choose to make the number of rows or columns be dynamic (i.e. tied to a cell) so be sure to take this into account when adding multiple data blocks to the same worksheet (A trick I use is to zoom out

to 25% in Excel and you can see where all of your data blocks are!)

2. There is a Microsoft enforced limit of time that data has to return on a worksheet (a few minutes). If you have many complex

data blocks on the same worksheet, you could experience a timeout so consider using multiple worksheets when appropriate. Note that you can refresh multiple worksheets at one time using the “Refresh All” button.

3. I have found that I sometimes encounter problems when my Excel filename and/or worksheet names have spaces in them. I believe that this has been addressed in newer releases, but I err on the side of caution and use underscores instead of spaces

in file/worksheet names to be safe.

4. Due to the interplay between Omniture and Excel, I have at times experienced situations where a spreadsheet will get

corrupted. For this reason, I recommend that you save historical versions of your spreadsheet just to be safe.

5. If you don’t know what your Omniture report suite ID’s are, look in report suites area of the Admin Console or ask your

SiteCatalyst administrator.

6. In a future post, I will discuss one of the more advanced Omniture ExcelClient features known as Publishing, which allows you

to upload your Excel spreadsheet and have it delivered to different people for different report suites on a scheduled basis.

Real-World Example

So let’s go through another real-world example to show you the power of the Omniture ExcelClient. In this example, a retail

subsidiary of our fictitious client Greco Inc. has two websites that are structured the same, but sell completely different products.

One (Electronics Plus) sells consumer electronics and the other (CoolFlowers) sells, you guessed it, flowers. An executive who

oversees both sites is currently getting different reports from the product manager of each site and it is making it difficult for her to

compare the two sites.

To solve this problem, the two product managers determine what information the executive needs to see on a daily basis and use

the Omniture ExcelClient to define the data that is needed. The first data block they choose to report is Revenue by Search

Keywords. They set-up the ExcelClient data block so that it has the correct report and tie it to the cells shown here:

The resulting report pulls the Revenue for the top Search Keywords for the specified timeframe and the selected report suite, which

in this case is ElectronicsPlus:

Upon looking at this report the executive asks to see the top 5 revenue generating Search Keywords that have the phrase

“computer” in them. Since the web analyst planned ahead and tied the “Top” and “Search” components of the query to cells in

Excel, all he needs to do is change the value in the “Top” cell to “5,” enter “computer” in the “Search” cell and refresh to see the

following:

After this slight digression, the executive asks to see the original Top 10 Search Keyword Revenue report he had seen for

ElectronicsPlus for CoolFlowers. To produce this, the web analyst simply changes the cells to have the appropriate report suite ID,

changes the “Top” value back to “10,” clears the “Search” cell and refreshes to see the following report:

As you can see from just this one data block, the ExcelClient provides the flexibility to see different types of data quickly. This

becomes even more powerful when multiple data blocks are added and charts and graphs are embedded into Excel based upon the

SiteCatalyst data.

Campaign Tracking [Inside Omniture SiteCatalyst] Wednesday, 1 October 2008 @ 16:27, by Adam Greco

One of the primary reasons companies utilize Omniture SiteCatalyst is to track the effectiveness of online marketing campaigns

(see step three in Avinash’s ”Nirvana” post). While this is an enormous topic, I will use this post to cover the most important things

you need to know to effectively track campaigns in SiteCatalyst.

What is a Campaign?

I usually define a marketing campaign as any instance where you are deliberately paying money or expending effort to drive

traffic to your website. I use this definition because in order to track the success of marketing campaigns you need to have a way

to identify the specific traffic you have generated. SiteCatalyst does this through a “Tracking Code” that is captured when visitors

arrive to your website from one of your marketing campaigns. While most marketing campaigns involve costs to generate traffic,

there are some cases, such as internal e-mail lists, that have minimal costs, but are still valuable campaign contributors. Most

clients have a team of people who are focused on creating/managing marketing campaigns and determining which types (Paid

Search, Paid Display, E-mail, etc…) are the best and which campaign elements within each campaign type produce the best

results. By using Omniture SiteCatalyst to identify the most cost-effective campaign elements it is possible to squeeze the most

value from your limited marketing budget.

How Do Campaigns Work in Omniture SiteCatalyst?

To use the Campaign feature of SiteCatalyst, the first step is to be sure your SiteCatalyst implementation is set-up to capture

campaign tracking codes when visitors arrive to your site. This is normally done by using a JavaScript plug-in that Omniture

provides to capture a URL parameter and place it in the campaign variable (s.campaigns). For example, if you buy the keyword

“books” on Yahoo, when the user clicks on that Paid Search link, they might come to your site with the URL of

“www.mysite.com?id=12345.” In this case, the code “12345″ would be placed in the SiteCatalyst campaigns variable for tracking

purposes. In many ways, understanding Campaigns is really a compilation of many of the things we have learned so far in previous

blog posts. The SiteCatalyst campaigns variable is simply a Conversion Variable which has full subrelations enabled which will

attribute any subsequent Success Events to the campaign tracking code stored in the current user’s cookie. As with any other

Conversion Variable, you can use the admin console to determine how long you want to keep the tracking code in the user’s cookie

and if you want to give credit to the first campaign tracking code or the last one.

Once your SiteCatalyst JavaScript file is set-up to capture campaign tracking codes, the next step is to assign tracking codes to all

links that will refer traffic to your site. This is the part of the campaign process in which Omniture SiteCatalyst clients make the most

mistakes. The key to assigning tracking codes to campaign elements is that they have to be unique. As long as the

same campaign tracking code is not associated to more than one campaign element you are in good shape. Using the example

above, the code “12345″ is now dedicated to the keyword “books” on Yahoo as a Paid Search element. If the company chooses to

buy the same keyword on Google, it should use a different tracking code so SiteCatalyst can differentiate between the same

keyword on Google and Yahoo. Unfortunately, I have seen many clients set the same tracking code for ”books” in multiple places

and then wonder why it is so difficult to show how the keyword performed differently on each site. Along these same lines, you will

have many campaign types such as Paid Search, Paid Display, E-mail, etc… While each of these are different types of campaigns,

they all need to have tracking codes and the tracking codes need to be unique amongst the entire spectrum. In this scenario, no

Paid Display or E-mail link can have the tracking code “12345″ or trouble will ensue.

Making Sense of Campaign Tracking Codes

So now let’s say that you are all set to capture campaign codes and have worked with your Paid Search, Paid Display and E-mail

vendors to add a tracking code to each destination link for which you are spending marketing dollars. As traffic begins to trickle in,

you can open up the Tracking Code report found in the Campaigns area and see Click-throughs and also what website Success

Events have taken place after visitors arrived from each campaign code:

This sample report shows which campaign tracking codes are getting the most clicks and leading to the most Application

Completions. But making sense of this report is not very easy since you probably don’t want to memorize every campaign tracking

code. If only there were a way in SiteCatalyst to add meta-data to a Conversion Variable so you could group items in different ways

(hint, hint!). Those of you who have read the previous posts, of course, know that Classifications provide this capability so the next

logical step in campaign management is to identify the ways you want to slice and dice your campaign tracking codes. For

example, you might want to group campaign tracking codes by:

1. Campaign Name (Spring 2008 Campaign, Summer Branding Campaign, etc…)

2. Channel/Type (Paid Search, Paid Display, E-mail, etc…)

3. Vendor/Website (Google, Yahoo, CNN.com, etc…)

4. Link Type (Text, Animated GIF, Flash, etc…)

5. Business Unit (Product Marketing, Acquisition, Customer Service, etc…)

6. Business Owner (Joe Murphy, Sue Smith, etc…)

As we learned in the Classifications post, you can choose as many attributes as you want and the best part is that Classifications

are retroactive, which means you can decide how you want to group campaign tracking codes days, weeks or months after the

campaign launches and change it as many times as you’d like. Doing this might produce a report that looks like this:

Important Things to Know About Campaigns

The following are some important things to know about tracking campaigns:

1. The campaigns variable (tracking code) comes with full subrelations by default so you can break every Conversion Variable

down by any tracking code and any Classification of any tracking code.

2. If you do a lot of Paid Search, creating thousands of unique tracking codes and inputting them into the various search engines

can be tedious and costly. Omniture’s SearchCenter product automates this process and provides many other incredible benefits so check it out.

3. The “Click-throughs” metric is only available in Campaign reports, though there are more advanced ways to implement this if more flexibility is needed.

4. You can upload the costs associated with each campaign tracking code to calculate the Cost per Click or Cost per [Success Event]. This is a bit more advanced, but if you are interested in this Omniture Consulting would be happy to assist you.

Real-World Example

Someone “Twittering” with me asked if I could show an example of how Greco Inc. (our fictitious company) could monetize the use

social networking so I am going to do my best in this week’s real-world example. In this scenario, we’ll imagine that the

CoolFlowers subsidiary of Greco Inc. has hired a young “go-getter” out of college who is a whiz at social networking. This individual

has done research and identified several blogs on the Internet that have active discussions about flowers and has also identified an

internal employee who knows more about flowers than anyone on the planet! Soon, he has his associate blogging on

CoolFlowers.com and commenting on a few key blogs placing links back to her CoolFlowers blog. As described above, a campaign

tracking code identifier is added to each link going back to the CoolFlowers site such as

http://www.coolflower.com?id=blogcomment. Now, as blog readers click on the link in her comments, they are routed to the

CoolFlowers website where Click-throughs and Purchases can be tied to the social networking initiative. Obviously, this represents

a rudimentary approach, since it lumps all blog comments into one tracking code, but if it wanted to, Greco Inc. could use

“id=blogcomment1,” “id-blogcomment2,” etc… to tie success to a specific comment. Either way, all of the social networking tracking

codes can later be grouped together using SAINT Classifications and compared to other marketing channels.

This same concept can be applied to programs like Twitter in which you can post links to your site with a campaign identifier and

then use tools like POPrl to shorten the URL but still record the click as a campaign. To see how this works, feel free to click on the

following link http://poprl.com/0cG which will take you to the Omniture Consulting page on omniture.com and indicate that you got

there because of my blog!

Pathing Analysis [Inside Omniture SiteCatalyst] Monday, 13 October 2008 @ 7:52, by Adam Greco

For most Omniture SiteCatalyst customers, Pathing Analysis is something with which they are pretty familiar. After all, one of the

primary reasons to use a web analytics package is to be able to see how site visitors are traversing the pages of your site.

Therefore, in this post, I will cover the basics of Pathing Analysis, but then outline some more advanced uses of pathing that you

may not be familiar with.

What is Pathing?

Traditional Pathing Analysis consists of viewing flow reports which show you how often site visitors go from Page A to Page B or

Page C on your site. By simply having Omniture SiteCatalyst code on your site pages, you will be able to see several different

pathing reports right out of the box. Pathing is commonly used to analyze key website process flows in hopes of identifying

opportunities for improvement. For example, you may notice that an unusually high number of site visits show pathing exits after

viewing the “Shopping Cart” page. After you have several months worth of data, you should be able to baseline your standard

pathing exit rates and then make changes to key pages and see if these changes have a positive or negative effect.

There are eighteen pathing reports available in SiteCatalyst, but there are a few that I tend to use the most:

Next Page Flow

This report allows you to see two levels of pathing from the selected page so you can visually see where visitors are going from the

selected page. The thickness of the bars is representative of the percentages.

Fallout Report

The fallout report allows you to add several pages to a canvas and see how often visitors viewing the first page in the canvas

viewed the second page and how often those viewing the second page viewed the third, etc… It is important to understand that the

visitors do not need to have viewed the pages in the exact order indicated on the canvas, but rather, need to have viewed them in

the specified order to be included in the fallout report. While you can only add a finite number of pages to a fallout report in

SiteCatalyst, you can add many more to the canvas if you use Omniture Discover.

Pathfinder Report

The pathfinder report allows you to add pages to a canvas, but also provides the ability to add wild cards and choose whether you

would like to include entries and/or exits in your analysis. This pathing tool is commonly used for understanding all of the different

ways visitors can get from Page A to Page Z on your site.

Important Things to Know About Pathing

The following are some important things to know about Pathing:

1. Pathing can be enabled on any Traffic Variable, not just Page Name. The most common uses of Pathing are Page Name and Site Sections (s.channel), but there are many creative uses for Pathing beyond this. For example, if you want to have an easy

way to see the order that site visitors view your products, you can pass the product name or ID# to a Traffic Variable on each product page and then enable pathing to see which products are viewed concurrently.

2. Pathing reports only consider that a path has changed when a new value is passed to the Traffic Variable. This is important, because, if you accidentally use the same page name for two different pages, you will not be able to see instances where

visitors went from one page to the other.

3. Pathing reports do not span multiple visits.

4. In SiteCatalyst, you cannot combine several pages into a bucket and view pathing to/from the bucket of pages, but you can do this in Omniture Discover.

5. Pathing reports are not available in Omniture DataWarehouse or the ExcelClient. In future posts I will discuss how you can use ASI (Advanced Segment Insight) to see paths for a subset of your audience.

6. You cannot view pathing on a Classification of a Traffic Variable (sProp) in SiteCatalyst (though you can in Discover). Therefore, you should take this into account when determining whether to capture data values directly into a variable or a

Classification.

7. Pathing reports cannot span across multiple SiteCatalyst report suites so if you want to see pathing for different sites, you

need to have a common tag on pages of both sites (known as multi-suite tagging).

Real-World Example

In this installment of our real-world example, let’s say that one of Greco Inc.’s subsidiaries is a Finance related media site and

its goal is to increase Page Views so it can increase paid advertising revenue. As part of its SiteCatalyst implementation, Greco

Inc. captures the ticker symbols visitors search upon in a Traffic Variable. It turns out that people are willing to pay top dollar for

Paid Display Ads served up on the ”Apple” ticker symbol (AAPL) results page. Unfortunately, many of the other ticker symbol

search results pages don’t command such a premium. Therefore, Greco Inc. would like to find a way to identify more “Apples” on

its site so it can increase overall advertising revenues. To do this, they decide to enable pathing on the Traffic Variable containing

the ticker symbols being searched upon. This allows them to see which ticker symbols are being searched directly before and after

(shown below) ”AAPL.”

Armed with this information, Greco Inc. can make a case to its clients that it can provide an almost identical audience as those

searching for “Apple” at commensurate price. From a usage standpoint, the best part is that the Ticker Symbol Traffic

Variable does not contain all of the site pages, which makes it much easier to follow and provides only the data that is needed.

Omniture DataWarehouse [Inside Omniture SiteCatalyst] Sunday, 19 October 2008 @ 17:48, by Adam Greco

Do you use Omniture DataWarehouse on a regular basis? I am surprised by how many of my customers don’t know anything about

DataWarehouse and what it can do for them. This is a big mistake, especially since you are probably paying for it! While Omniture

DataWarehouse is technically a separate product from Omniture SiteCatalyst, the majority of my customers have access to it and

the two products go hand-in-hand. For this reason, I am going to include it in this blog series and show you how you can take

advantage of it. In this post, I will explain the basics of DataWarehouse and in my next post, I will take it a step further by

discussing ASI (Advanced Segment Insight) which is part of DataWarehouse.

What is Omniture DataWarehouse?

Omniture DataWarehouse is a repository of SiteCatalyst data that stores information similar to that which you can see in

SiteCatalyst. While many customers think DataWarehouse is only a backup of their data, it is actually much more than that. To

understand DataWarehouse, you need to first understand how it differs from SiteCatalyst. When you use SiteCatalyst, the reports

you get are pre-defined so that they can return quickly in the browser. For this reason, you may notice that you can only perform a

small number of report breakdowns (Correlations and Subrelations) within SiteCatalyst and that you cannot breakdown Traffic

Variables and Conversion Variables by each other. The reason for this is that these more complex queries could take too long to

return, resulting in a browser timeout. SiteCatalyst is fine-tuned to provide you with speedy access to 80% of the reports you should

need on a daily basis. On the other hand, DataWarehouse stores the raw data which enables it to be used for much more complex

queries, but the results are not provided in real-time (normally within 24 hours).

Another key difference between SiteCatalyst and DataWarehouse is that DataWarehouse can provide deeper visitor segmentation.

For example, when SiteCatalyst is collecting information about a visitor, it is difficult for it to know that three months ago this same

visitor looked at Product XYZ and that two months ago the visitor began an application but did not complete it. That level of

information requires that Omniture sift through rows and rows of website data which is not easy to do in real-time within a browser.

DataWarehouse, however, contains all of this historical data and has a built-in visitor segmentation engine that allows you to create

segments that are meaningful to you and extract SiteCatalyst data for that specific segment. Common DataWarehouse segments

might include:

1. All Visitors who have added a product to the shopping cart, but not purchased

2. All Visits where visitors have viewed a product page, but not added anything to the shopping cart

3. All Visits where visitors came from a few select cities and added a few specific products to the Shopping Cart (see below)

The number of different segments you can create is limited only by your imagination. DataWarehouse provides a Segment Builder

that allows you to choose how you want to build the segment and a canvas that allows you to specify what data you want to see for

that segment. You can also choose the timeframe for the data set and whether you want the resulting report to be delivered one

time or on a recurring basis.

When Should You Use DataWarehouse

Once my customers have absorbed the preceding information, the next logical question they ask me is when they should use

SiteCatalyst and when they should use DataWarehouse. Here is how I respond:

1. Use DataWarehouse when you need to see data for a subset of your audience. If you need to see visitors from the US who have started the application process, SiteCatalyst will be more than adequate, but if you need to see 1st time visitors, using a

Google Chrome browser who have started an application at some point, and began their visit on a specific marketing landing page, all for the last 3 months, I would recommend using DataWarehouse (or Omniture Discover).

2. Use DataWarehouse if you need to see Traffic Variables and Conversion Variables broken down by each other and you do not have access to Omniture Discover. If these breakdowns are going to be needed on a recurring basis, I work with my clients to

capture the necessary data into both Traffic and Conversion Variables to avoid having to rely too much on DataWarehouse, but many times this is not feasible and DataWarehouse can really save the day.

3. Use DataWarehouse if you need to go beyond the two levels of report breakdowns offered in SiteCatalyst. DateWarehouse allows you to create an unlimited number of breakdowns.

4. Use Data Warehouse if you have a piece of data that has more than 500,000 unique values per month. While this doesn’t happen too often, there are cases where Omniture customers need to pass a user ID or some other unique values to a

variable which exceeds the recommended limit of SiteCatalyst. In these cases, the variable in SiteCatalyst is not useful since it shows a “Uniques Exceeded” value, but all of the data is stored correctly in DataWarehouse where you can build the

appropriate segments and extract a list of the relevant unique values as needed.

Important Things to Know About DataWarehouse

The following are some important things to know about DataWarehouse:

1. The more complex the DataWarehouse segment and the larger the time frame, the longer it can take for a report to be

returned.

2. The Unique Visitors metric provided in a DataWarehouse report is relative to either the overall time frame or specified report

granularity (Day/Week/Month if selected) in DataWarehouse reports.

3. DataWarehouse segments have an “exclude” function that allows you to eliminate data that you don’t want to be included in

your segment query.

4. Building too granular of a segment can often times return no data. My advice is to run a test report for one day of data to be

sure you have your segment correct before attempting to run it for months worth of data (learned the hard way from someone who waited a few days only to receive no data due to my own user error!).

5. DataWarehouse can be used to load historical data into Omniture Discover.

6. DataWarehouse is used by many Omniture Genesis integrations.

7. Most of the things you can do in Data Warehouse can be done in Omniture Discover in real-time.

Real-World Example

In this installment of our real-world example, we will focus on the CoolFlowers subsidiary of Greco Inc. In this scenario, the CMO of

CoolFlowers is looking to test a new re-marketing campaign and would like to identify all of its customers who have

purchased flowers in the past three months but submitted fewer than three total orders and are from the New York City metro area.

CoolFlowers captures an encrypted customer ID into a Traffic Variable (sProp) on each page after a customer logs into the site

and since SiteCatalyst captures orders and geographic location, this can be accomplished through a DataWarehouse request.

However, just to make things a bit more complicated, the CMO would also like to see what Products, if any, the visitors matching

this segment have looked at online, how many times and what city they are from within the New York City metro area.

To accomplish all of this, the SiteCatalyst power user (you), would build a segment as described above and then add the necessary

data to the reporting canvas which shows what the output file will look like:

Once you have your segment built correctly and have added the correct data on the canvas, you can schedule the report and it will

be delivered to the specified e-mail address or FTP site.

ASI (Advanced Segment Insight) [Inside Omniture SiteCatalyst] Monday, 27 October 2008 @ 20:45, by Adam Greco

This post on ASI (Advanced Segment Insight) is a continuation of the previous Omniture DataWarehouse post due to the fact that

ASI and DataWarehouse are very similar concepts. Therefore, if you haven’t already, I suggest that you review that post prior to

reading this one. I have found that many of my clients don’t use ASI simply because they don’t understand it or by the time they

learned about it in training their brain was overloaded! I can’t tell you how many times a client has said to me “If only I could see

this report for 1st time visitors” or “I wish I could see a comparison of this report for Yahoo vs. Google visitors.” When I respond to

them that they can using ASI, they often look at me like I am speaking a foreign language. Therefore, the goal of this post is to

make ASI understandable for all of you out there in hopes that you will begin to leverage this great tool.

What is ASI?

ASI is a component of Omniture DataWarehouse that allows you to create a data set similar to that of a report suite for a specific

segment of users. Whereas DataWarehouse allows you to build a segment and run a report for that segment, ASI takes this a step

further by allowing you to see all SiteCatalyst reports for a segment. While this may not seem like a big distinction, it is. ASI

allows you to see all Omniture SiteCatalyst out-of-the box reports and the many reports you create by setting Success Events,

Traffic Variables and Conversion Variables for any segment of your users that you desire. In addition, ASI (or Omniture Discover) is

the preferred way to view pathing reports for segments of users.

How Does ASI Work?

So how does ASI actually work? When you create an ASI slot, you give it a name, select or create a segment and then specify

whether the ASI should be for a fixed time frame or daily recurring. If the ASI slot is created for a fixed time frame, Omniture will

cycle through all data in that time frame, looking for data that matches the specified segment and include data accordingly. If you

choose a Daily Recurring ASI slot, Omniture will begin with the specified start date and do the same steps as just described, but will

continue to add one day of data every 24 hours.

Once you have submitted the ASI for processing, Omniture will begin processing the data that matches the time frame and segment

definition you have specified. Sometimes, I think of ASI as a time machine that goes back in time and recreates all of the web

behavior after the fact for a specific group of people of your choosing. When ASI has made it through the entire date range, you will

be notified via e-mail, though you can use the ASI slot while it is in progress if the time frame is large (one trick I use is to view the

Page Views report in the ASI slot which will show you which dates it has processed). Once the ASI slot is ready, you can use it just

as you would any other report suite that appears in your list of SiteCatalyst report suites in the top-left drop-down box.

Important Things to Know About ASI

The following are some important things to know about ASI:

1. You can re-use ASI slots when you are done with them. Let’s say you need to see a month worth of data for a specific

segment, but after you have done your analysis, have no use for it? Simply purge the ASI slot and after an hour or so it will be ready for re-use.

2. ASI slots can be used to download data to the ExcelClient. Want to have a data set that shows you all SiteCatalyst reports for 1st time visitors? Google visitors? Campaign visitors? All of this can be easily accomplished via ASI.

3. Any segments that you build in DataWarehouse are available for use in ASI (and Omniture Discover for that matter) since segments are tied to an Omniture user ID.

4. You can manage settings of ASI slots using the Admin Console just as you would any other report suite. To do this, select “All” in the Report Suites Manager area of the Admin Console. ASI slots will have report suite ID’s beginning with a “cyg.”

5. ASI’s can be used in A/B comparison reports just like any other SiteCatalyst report suite.

Real-World Example

In this installment of our real-world example, we will be working with Greco Inc.’s banking subsidiary. In this scenario, the website

design group is investigating alternative site designs based upon whether the site visitor is logged into the site or not. Their

hypothesis is that those who are signed in (customers) may be looking for different types of content than new visitors (prospects)

such that a one-size-fits-all approach is not justified. In order to test this theory, the design team worked with the web analytics

team to create two distinct ASI slots. One to contain only data for visitors who were logged in and the other being the converse,

containing only data for those who were not logged in when data was collected.

Once these ASI segments had been created and the ASI slots were built, the first thing the web design team wanted to see was

what search terms each user type had searched upon. To see this, they simply open the search term report, switch to A/B

comparison mode and select the two relevant ASI slots:

Next, the web design team wants to compare the pathing behaviors of both segments. The first report shown here provides pathing

information on those who had logged in…

…while the following shows the paths for those who had not logged in.

As you can see from these examples, ASI can be extremely helpful in comparing segments and extending your web analysis.

Segment Builder Best Practices [Inside Omniture SiteCatalyst] Wednesday, 5 November 2008 @ 16:03, by Adam Greco

In the past two posts, I have described how you can leverage Omniture DataWarehouse and ASI to enhance your Omniture

SiteCatalyst web analysis projects. Both of these tools use Omniture’s Segment Builder which is the mechanism for creating the

segments which select the visitors, visits and page views you want to analyze. Therefore, a good understanding of how to correctly

build segments using Segment Builder is critical to getting the most out of these tools (and Omniture Discover which also uses

Segment Builder). In this post I will share some tips and tricks that we at Omniture Consulting have learned in working with the

Segment Builder (I will pre-warn you that this post may take a bit to sink in since Segment Builder is a more advanced SiteCatalyst

topic, but I promise it is worth it in the long run!).

Understanding Segment Builder

To understand the Segment Builder, you first need to understand the various components that it uses to build a segment. As shown

in the image below, when you enter the Segment Builder, you will see Containers, Events and a Segment Canvas.

First, we will discuss the different containers:

1. Page Views - Dragging a Page View container to the segment canvas will allow you to define which Page Views you would like to include or exclude from the segment. When evaluating the Page View container, Omniture is, in effect, scanning

through each Page View it finds within the specified time frame and deciding whether it should be included or excluded. Therefore, it may be the case that two different Page Views from the same Visit may or may not be included in the segment.

For example, let’s assume that you are building a segment where you only want pages where the language was Spanish. It may be the case that a visitor viewed ten pages during their Visit, but only two of those ten were viewed in Spanish. Using a

Page View container, would mean that only these two Page Views would be included in the segment.

2. Visits - Dragging the Visits container to the segment canvas will allow you to define which Visits you would like to include or

exclude from the segment. When evaluating the Visits container, Omniture is, in effect, scanning through each Visit it finds within the specified time frame and deciding whether the entire Visit should be included or excluded. Therefore, if any of the

criteria are met within the Visit, all data from that Visit will be included (or excluded if using the exclude tab) in the segment. Using the preceding example, if the segment looking for pages viewed in Spanish were built using a Visit container, the entire

Visit would be included since at least one of the pages was viewed in Spanish (even though the majority were in English).

3. Visitors - Dragging the Visitors container to the segment canvas will allow you to define which Visitors you would like to include

or exclude from the segment. When evaluating the Visitors container, Omniture is, in effect, scanning through all data it has for each Visitor within the specified time frame and deciding whether at any time the Visitor met the criteria. If it finds that

the Visitor has met the criteria, all Visits and Page Views for that Visitor will be included in the segment. Continuing

the preceding example relating to pages viewed in Spanish, if a Visitor had six site visits within the specified time frame and in

one of those Visits viewed at least one page in Spanish, data from all six Visits would be included in the segment.

As you can see, the container you select can have an enormous impact on the data set that is returned in DataWarehouse or ASI.

This is why I cannot stress enough the importance of testing your segments before using them in production.

The next item that can be added to the segment canvas is Events. The Event containers represent the Success Events you have

identified for your website. If, for example, you have a Visit container and you add the “Order” Event to it, then you are indicating

that only Visits in which an Order took place should be included in the segment. You can also define the Success Event in more

detail, by clicking on its name and adding additional filter criteria.

The most difficult area of Segment Builder to understand is the Segment Canvas. To begin with, there are two tabs of the canvas,

one for Include and one for Exclude. When determining which data to include in your segment, Omniture first looks to the Include

tab and identifies all data that is to be included and then proceeds to eliminate any data matching the criteria of the Exclude tab.

Once you have successfully navigated the include/exclude tab, the next challenging part is to understand how to set conditions

within a container. To do this, you simply click on the underlined container name which brings up a window that allows you to

specify the parameters of that container. Here you can choose almost any data point and specify whether it should be equal to,

greater than, contains, etc… and then choose or enter a value. In addition, using the first drop-down box allows you to choose

whether all of these conditions need to be met (AND) or if just one need to be met (OR). Whatever you choose in this drop-down

box will change the criteria in the Filter below. In the image shown here, the user has chosen to use the OR clause so that a Visit

can come from either the United States or the United Kingdom. One point of warning: The #1 mistake clients make in this step is

that they forget to click the “Add” button when adding conditions so be mindful of this!

The final thing to learn in building a segment is the nesting of containers. Here are some important guidelines you should know:

1. Page View containers can only have nested Events

2. Visit containers can have nested Events and Page View containers

3. Visitor containers can have nested Events, Page Views and Visits

4. If an Event is added to the segment canvas with no Page View/Visit/Visitor container, the Page View container is used by default

5. It is not possible to add multiple Events to a Visit container such that they form an OR clause, but to get around this, you can add multiple Visit containers to the canvas and add one Event to each

The segment Builder will usually tell you when you are attempting to add an invalid combination, but it is good to learn what you can

and can’t nest within the segment builder. Finally, it is important to understand what the Segment Builder treats as AND/OR

clauses when building segments. If you want to add two or more items and have all of the conditions met (AND) then you want to

be sure that you nest them above the line of the container like this:

However, if you want to the segment to look for one condition or the other (OR), you would want to make sure that the items are

outside of the container line like this:

In the examples shown here, the former would include all Visits where the country was “United States” and an Order took place, but

the latter would include all Visits where the country was “United States” or an Order took place. This is probably the hardest part

and I encourage you to tap into Omniture Consulting when building complex segments.

Important Things To Know About Segment Builder

The following are some important things to know about Segment Builder:

1. Segments built using the Page View container will return data the fastest, followed by the Visit container and the Visitor container. Whenever possible, attempt to use the lowest level container needed to get the data you need to improve

processing time.

2. Classifications cannot be used as criteria in DataWarehouse or ASI Segment Builder segments. For this reason, if you believe

that you will want to use a data point as segment criteria, you may want to pass the data directly to a Traffic Variable or Conversion Variable instead of relying upon a classification. Classifications can be used as segment criteria in Omniture

Discover.

3. Segment Builder allows you to segment on how many times a Success Event takes place which is very powerful. For

example, if you set a Success Event each time a visitor conducts an Internal Search, you can build a segment that looks for cases where “Total Internal Searches is greater than 2″ to find repeat searchers.

Tips & Tricks

Since this post is really a subset of the DataWarehouse/ASI posts where we already provided some real-world examples, I am

going to provide some practical Segment Builder tips and tricks instead of a real-world example:

If you want to be sure you are including all data in your segment, you can add a Page View container where IP Address contains “.” since all data collected by SiteCatalyst contains an IP address and all IP addresses contain a “.”

If you want to build a segment using a wild card such that a SiteCatalyst variable has a value (is not blank), you can use a

“greater than !” in your segment definition as shown here.

Conversely, if you want to build a segment based upon the fact that a SiteCatalyst variable had no value you would use “less than !” in your segment definition as shown here.

Products Variable [Inside Omniture SiteCatalyst] Sunday, 16 November 2008 @ 22:17, by Adam Greco

In earlier posts, I described the three types of Omniture SiteCatalyst variables which are Traffic Variable (also known as sProps),

Success Events and Conversion Variables (also known as eVars). There is, however, one variable type that is a bit unique and

that is the Products variable. In this post, I will explain how the Products variable is different and share some interesting ways it can

be used (even if your website doesn’t promote Products!).

Understanding The Products Variable

As its name implies, the primary use of the Products variable is to store the name of the Product for which a website action is taking

place. For example, if you manage a retail website and a visitor views a Product Detail page, you might choose to set a Product

View Success Event so you can see how many Product Views your website had each day, week, month, etc… But if you want to

see which Products visitors were looking at, you would need to capture the Product name or a Product ID# in a variable so that you

can break down the Product Views Success Event metric by Product. For those who have read previous posts, your first instinct

should be to use an Conversion variable (eVar) to capture the Product Name, since eVars are used to break down Success

Events. While you could certainly do that, Omniture has assumed that many websites will have Products so it has created a special

Products variable for this exact purpose. Therefore, it is recommended that you capture the Product name or ID# in the Products

variable (s.products).

“What is the difference between an eVar and the Products variable?” is the next question I get from clients (which is why I am

writing this post!). There are some subtle differences between the Products variable and Conversion Variables (eVars) that you

need to understand. They are as follows:

Multiple Values

The Products variable allows you to pass multiple values to it whereas eVars are limited to one value. The importance of this

cannot be understated. When a Success Event is set in conjunction with an eVar, whatever value is passed to the eVar gets credit

for the Success Event. But if multiple Products are passed to the Products variable at the same time that a Success Event is set,

each value passed to the Products variable will get credit for the Success Event.

Not Persistent

Another way in which the Products Variable is different from Conversion Variables is that it is not persistent, meaning that it does

not retain its value from one page to the next. In this respect, it is somewhat similar to Traffic Variables. For this reason, if you

need to associate multiple Success Events with specific Products, you must set the Products variable every time you set

Success Events. For example, if a visitor adds three products to the shopping cart, you would pass all three to the Products

variable when you set the Cart Add Success Event, but if later the visitor purchases one of those products, you need to pass that

product to the Products variable again when you set the Purchase Success Event.

Special Parameters

Unlike Conversion Variables, the Products variable allows you to set some special parameters at the same time the Product value is

set. While this can be a bit confusing for newer SiteCatalyst users, I will do my best to explain this in non-technical terms. To

begin, it is important to see the full Products Variable String with all of the potential parameters that can be set:

s.products=[Category1];[Product1];[Quantity];[Total Price];[Incrementor];[Merchandising], [Category2];[Product2]; etc…

The following will describe each:

[Category] - This represents the Product Category. It is not recommended that you use this parameter due to the fact that it ties the

Product to the first Category that it is associated with and it cannot be changed. There are now better ways to assign Products to

Product Categories so this parameter is normally not set and remains primarily for historical purposes.

[Product] - This represents the name or ID of the Product. If you pass an ID, you can always use Classifications to upload friendly

names and roll products into Categories. If you will be passing a lot of Products at one time, it is recommended that you use ID’s

instead of full product names to limit the length of the overall product string so you do not exceed browser character limits.

[Quantity] - When used with the Purchase Success Event, this represents the quantity of the Product being purchased (i.e. visitor is

buying two memory cards)

[Total Price] - When used with the Purchase Success Event, this represents the total price for the Product being purchased (i.e. two

memory cards total $200 for both)

[Incrementor] - This is an advanced topic which I will be covering in the future, but in general, you can set an Incrementor Success

Event such that you manually pass a currency amount or number to it. For example, you charge $2.50 shipping for a product and

want to show that separate from Revenue, you can devote a Success Event to “Shipping Costs” and pass “2.5″ in this part of the

Product String to add $2.50 with each purchase.

[Merchandising] - This is another advanced topic which I will cover later, but in general, you can use this parameter to bind Products

to different eVar values for each Product instead of tying all Products to one eVar value. This is often used to capture which product

category the visitor used to find the Product.

So in a scenario where a visitor is buying two XYZ memory cards at $100 each, has to pay $2.50 shipping and found the memory

card product through the “Sale” section of the site, the Product string might look like this:

s.products=”;XYZ Memory Card;2;200;event18=2.5;eVar12=Sale”

Important Things To Know About The Products Variable

The following are some important things to know about the Products variable:

1. The Products variable has full subrelations so any conversion variable report can be broken down by Products and any

Classifications of Products.

2. If the Products variable is set with no corresponding Success Event, the “prodView” Success Event will be used by default.

This will appear in SiteCatalyst as the Product Views metric and only appears in Products reports. However, if Product Views is something that is important to your organization, it is a best practice to use a Custom Success Event to track Product Views.

3. The Revenue and Unit parameters are only valid when used in combination with the Purchase Success Event. They will be ignored in all other cases.

Real-World Example

In this week’s real-world example, I will illustrate a non-traditional way to use the Products variable. In this scenario, a subsidiary of

Greco Inc. would like to track the effectiveness of internal promotion banners on their site. They use these internal promotional

banners to promote specific products and for cross-sell. To do this, they would like to see how many impressions each internal

banner received and then how many clicks each received so they can calculate an “Internal Promotion Click-through Rate.”

However, this can be a bit tricky since one page on their site could have multiple internal promotion banners. While we might

normally think about using an eVar to capture the internal promotion codes, since there are multiple codes passed on one page, this

becomes problematic. The best an eVar can do is to concatenate the values into one string, which is not the easiest way to analyze

this data. Therefore, let’s see how they can use the Products variable to accomplish this.

To start, they would need to assign a unique ID# to each version of each internal promotion banner. When the page loads, they

would capture the ID numbers of all banners that appear on the page in the Products variable and set an “Impressions” Success

Event. The tagging might look like this:

s.events=event15;

s.products=”;promo:123,;promo:150,;promo:174″;

Doing this would produce a report that looks like this:

If a visitor clicks on one of the internal promotions (say ID# 174), they would set a “Internal Promotion Clicks” Success Event and

capture the clicked internal promotion in the Products variable again with tagging that looks like this:

s.events=event16;

s.products=”;promo:174″;

s.eVar18=”promo:174″;

Then they would create a calculated metric that divides Success Event 16 by Success Event 15 and then they can see a report that

looks like this:

As more internal promotions are shown and clicked, this report would receive more and more data so that over time, they could see

which internal promotions are clicked the most. In this situation, I started each product value with the phrase “promo:” since in

many cases you will use the Products variable for several things and having this prefix allows you to easily identify which values in

the Products report are actual products and which ones are internal promotions.

Finally, it is important to note that if they wanted to see which internal promotion clicks later led to visitors completing Success

Events on the site (i.e. purchases, sign-ups, etc…), the Products variable would not be ideal since it is not persistent like a

Conversion Variable. For this reason, you might choose to capture the internal promotion code ID# that is clicked in an eVar (as

shown above) so that you can see what internal promotions led to future success.

SiteCatalyst Widgets [Inside Omniture SiteCatalyst] Sunday, 23 November 2008 @ 9:47, by Adam Greco

Lately, there has been a lot of buzz around “Widgets” which allow you to take snippets of the data or content you want to see and

put it all in one convenient place. Based upon this and customer feedback, Omniture has created a SiteCatalyst Widget that allows

you to add reportlets from SiteCatalyst Dashboards to your aggregator/portal of choice (iGoogle, My Yahoo, etc…). In this post, I

will walk you through the steps required to take to see SiteCatalyst information through a Widget.

Step-By-Step Instructions for Creating SiteCatalyst Widgets

The following are the steps you would take to add SiteCatalyst Widgets to an aggregator’s web page. In this example, I will

add SiteCatalyst reportlets to an iGoogle page.

1. Create Dashboard

To begin with, you must create a SiteCatalyst dashboard. This is relatively straightforward and is done by viewing a report in

SiteCatalyst and clicking on the Dashboard icon, selecting a Dashboard name and saving (if you have not created a dashboard yet,

please refer to the SiteCatalyst User Guide or contact ClientCare).

2. Open SiteCatalyst Widget Page

Next, open SiteCatalyst and navigate to the Widget set-up page, which is found in the tools area drop-down arrow within the

Omniture Suite toolbar icon as shown here:

3. Choose Widget Type

Once on the SiteCatalyst Widget page, click the button of the vendor you would like to use. In this scenario, I will select Google. Be

sure that you have logged into your iGoogle page and consider creating a separate Omniture tab and having that open at the time

you click the button shown here:

4. Click Vendor Link

After you have clicked on the vendor link from within SiteCatalyst, you will be taken to the vendor’s page where you can click on a

link to add the widget to your page as shown here:

5. Select Dashboard Report

Once the SiteCatalyst Widget is added to your iGoogle page, you will see a list of Dashboard reportlets to choose from as shown

here:

Simply, select the one that you would like to see in the selected SiteCatalyst Widget and notice that you can use the “more” and

“previous” links to scroll through all of your dashboard items.

6. Rinse & Repeat

After your first widget is added, you can add more by clicking again on the Google link from within the SiteCatalyst Widget page or

by clicking on the down arrow from within the Widget and selecting “About this gadget” which will bring you to a page where you can

add a second Widget. You can repeat this process as often as you like and build an entire page of different report Widgets. When

you are done, you should have a screen that looks like this:

Important Things To Know About SiteCatalyst Widgets

The following are some important things to know about SiteCatalyst Widgets:

1. In addition to adding SiteCatalyst widgets to a Google or Yahoo pages, it is possible to add them to any web page, company intranet, Sharepoint, etc… Instructions for doing this can be found on the SiteCatalyst Widget set-up page shown above.

2. Keep in mind when attempting to share SiteCatalyst Widgets are tied to a SiteCatalyst user ID so users will only be able to see dashboards and bookmarks to which they have access in SiteCatalyst.

3. If you have several SiteCatalyst Widgets on a page, logging into one Widget will log you into all Widgets. Simply log into one and then refresh the page. On the flip side, logging out of one SietCatalyst Widget will log you out of all of them.

4. You can customize the appearance of SiteCatalyst Widgets by defining a custom CSS class.

5. For iPhone users, similar functionality exists through a custom iPhone application that has been developed. To download this

free application, simply search for “SiteCatalyst” or “Omniture” from within the iTunes App Store.

6. For Google Android users, similar capabilities exist as well. See press release for more details.

VISTA [Inside Omniture SiteCatalyst] Sunday, 30 November 2008 @ 20:00, by Adam Greco

When using Omniture SiteCatalyst, segmentation is one of the most important functions. As such, there are several tools at your

disposal to segment your visitors in SiteCatalyst. In previous posts, I discussed several methods of segmenting

visitors including Traffic Variables, Conversion Variables, Data Warehouse and ASI. Each of these provides a different level of

visitor segmentation which can be aligned to your needs. In this post, I will discuss another way that you can segment visitors

using a tool named VISTA (”Visitor Identification, Segmentation & Transformation Architecture”). While VISTA can be a complex

topic, I will do my best to provide the basics here, so you can understand what it is and how it can be used.

Understanding VISTA

When I first became an Omniture client, it took me a while to fully understand VISTA because it can be used to do so many things.

The way I like to explain VISTA is that it is a way that you can apply a rule or logic to your SiteCatalyst data after it is

collected, but before it is stored in Omniture’s data tables. For example, let’s say that you would like to send all website traffic

coming from within your company to an “internal” report suite so that it is not lumped together with customers and prospects hitting

your website. If you know the range of IP addresses that your company uses, you could use a VISTA rule to look for those IP

addresses and if a hit comes from an IP address in that range, send it to a separate SiteCatalyst report suite (commonly known as

IP exclusion). This is a good example to understand how VISTA works: 1) You work with Omniture to identify the definition for the

VISTA rule and 2) Once it is turned on, the VISTA rule scans every hit coming in and uses the VISTA rule definition to take some

sort of action. In this case the action is to move the split data into two different report suites, but there are many more things you

can have a VISTA rule do for you. Here are just a few examples of VISTA usage:

Add visitors to a Segment on the fly based upon data found in sProps, eVars or querystring parameters. For example, if your website has a form in which visitors are required to enter Birth Year, State and Gender, you can write an detailed VISTA rule that will evaluate the responses and assign the visitor into a segment by passing a segment name (i.e. “Middle-

Aged Midwestern Women”) to an eVar or sProp on-the-fly

Pass a value stored in one SiteCatalyst variable to other SiteCatalyst variables. For example, if you capture the Campaign

Tracking Code in s.campaigns, but later want to also pass it to a few other Conversion Variables that have different allocations or expirations, you can use a VISTA rule to pass the same value to all variables instead of having to do

additional tagging or JavaScript modification

Pass data found in GeoSegmentation or Technology reports to custom variables so it can be classified using SAINT Classifications

Set Success Events based upon a URL or a querystring parameter

Pass encrypted values into SiteCatalyst variables (i.e. customer ID, revenue) and use VISTA to decrypt the values back to

the original values to ensure secure data transfer

Prevent other “copycat” websites that may copy your website from sending traffic to your SiteCatalyst report suite

Look for potentially fraudulent orders (i.e. Revenue> $XX,000) and move them to a separate report suite so SiteCatalyst

data is not tainted

Send traffic from “bots” or internal monitoring tools (i.e. Gomez) to a separate report suite

Important Things To Know About VISTA

The following are some important things to know about VISTA:

1. VISTA rules have access to and can act upon any data point that is available on the page including IP address, referring URL,

querystring parameters, sProps, eVars, Success Events, etc…

2. Data Warehouse and ASI reports can be configured so that they run on pre- or post-VISTA rule execution

3. Omniture’s engineering services team has created a mechanism which allows clients to update their own VISTA rules (via FTP) after they have been deployed

4. While VISTA rules can be used to automate certain types of SiteCatalyst tagging, this is not recommended as a long-term

solution since changes in your site could have adverse affects on predefined VISTA rules

Real-World Example

In this week’s real-world example, I will describe an actual VISTA rule that one of my clients used to segregate their website

traffic. In this case, the client had pretty accurate information about whether the current site visitor was a Prospect or a Customer

and they wanted to use this to send data to different data sets. They also wanted to focus on a particular geography such that all

United States traffic was separated from non-United States traffic. Finally, they wanted exclude their own traffic and that of their ad

agency from external website traffic (phew!). So in all, they had three key elements they wanted to use to determine where

SiteCatalyst data went. To accomplish this, we designed a VISTA rule that used the following logic:

If traffic comes from an internal IP address, send data to “internal” report suite; else

→ if sProp1=”Prospect” and Country=”USA”, send data to “prospect_us” report suite; else

→→ if sProp1=”Prospect” and Country<>”USA”, send data to “prospect_intl” report suite; else

→→→ if sProp1=”Customer” and Country=”USA”, send data to “customer_us” report suite; else

→→→→ send data to “customer_intl”

As you can see, VISTA rules can become quite complex. The good news is that all you have to do is identify the rules that you

might want to apply to your data and Omniture can help with the rest.

In my next post, I will build upon the concept of VISTA by exploring its counterpart - DB VISTA.

DB VISTA [Inside Omniture SiteCatalyst] Sunday, 7 December 2008 @ 19:48, by Adam Greco

In my last post, I explained what VISTA was and some ways in which it could be used. In this post, I will explain the subtle, but

important, difference between VISTA and DB VISTA (also known as Database VISTA). If you have not read the last post, I strongly

encourage you to do so prior to reading this one.

Understanding DB VISTA

For the most part, there is very little difference between VISTA and DB VISTA. Both are used to alter or augment data that you

have collected via SiteCatalyst prior to it being placed into Omniture’s back-end data tables. Where DB VISTA differs from VISTA is

that it adds the ability to perform a look-up to a data table as part of the VISTA rule. This allows you to FTP data to Omniture

which can be accessed by the DB VISTA rule so that it can tap into this additional data when the VISTA rule processes. For

example, let’s say that you are a bank and it is against your privacy policy (and Omniture’s!) to store a customer account number in

SiteCatalyst. However, you have a ton of great demographic data stored in your back-end about each customer such as Age,

Gender, Zip Code, Marital Status, etc… and you would really like to have this non-personally identifiable data in sProps and eVars

for segmentation purposes. If only you could have Omniture temporarily use the customer account number so you could get all of

the rich demographic data and then somehow throw away the account number afterwards. Well guess what? You can using DB

VISTA! You can provide a secure FTP table for Omniture to do a look-up on the account number (or encrypted account number if

desired), retrieve the associated demographic data, place it in sProps and eVars and then discard the account number.

As you can see, DB VISTA is really the same thing as VISTA, with the one extra step of doing a look-up to a table that you provide

to Omniture. For you Excel junkies out there, you can think of it as a @DBLOOKUP function on a much larger scale! The following

are some other examples of ways you can take advantage of DB VISTA functionality:

If you have hundreds or thousands of IP address that you want to exclude (too many to manually add to a VISTA rule), you could upload a table of IP addresses to be excluded by a DB VISTA rule. This also has the advantage of allowing you

to add/remove/modify IP addresses as needed by updating the table instead of having to pay Omniture to update a static VISTA rule

If you want to assign a specific page value (which includes data from offline analysis) to a Revenue metric each time a page is accessed, you can have DB VISTA rule lookup the latest value from a table to upload to Omniture. Conversely,

instead of passing in a dollar amount, you could pass in a value or “points” for each pagename to a Counter eVar to create a very rudimentary (”poor man’s”) way to enter the world of visitor engagement

If you have customer scoring algorithms that calculate a current score for each registered customer, you could upload these scores daily and perform lookups to pass the current score to an sProp and eVar to see which pages or Success Events customers with high/low scores are accessing

If you know your campaign meta-data ahead of time and don’ want to deal with SAINT Classifications, you could use DB VISTA to pass campaign meta-data to eVars

Real-World Example

In this week’s real-world example, Greco Inc.’s retail division would like to incorporate product costs into its SiteCatalyst

implementation. To date, Greco Inc. has been using SiteCatalyst and SearchCenter to automate their paid search activities.

Currently, SearchCenter is using a Revenue based Return on Ad Spend (ROAS) as the main input to paid search keyword buys,

but Greco Inc. would like to take things to the next level by basing paid search purchases on Profit instead of Revenue. However,

they do not want to pass Product Cost information into SiteCatalyst through the JavaScript tag since it could be visible through

“debuggers” and “packet sniffers.”

To accomplish this, Greco Inc. works with Omniture to securely upload product cost information to a DB VISTA table such that each

Product ID has an associated Product Cost lookup value. Once this is in place, as site visitors purchase products, the DB VISTA

rule enters the Product Cost into an incrementor event based upon the Product ID’s found in the Products Variable string. This

produces a Cost of Goods Sold (COGS) metric that can be subtracted from Revenue to calculate Profit, which can then be used for

paid search purchases as shown here:

Obviously, these are just a few examples of how DB VISTA can be used to improve/augment your SiteCatalyst implementation.

Feel free to add a comment here with any ideas that you have on how you could see using this functionality…

If you want to learn more about VISTA or DB VISTA, here is a link to Engineering Services.

SiteCatalyst Interface Time-Savers [Inside Omniture SiteCatalyst] Sunday, 14 December 2008 @ 13:35, by Adam Greco

In this post I will mention some cool SiteCatalyst interface features that you may not be aware of, but could save you some time and

avoid stress (just in time for the holidays!). My hope is that there are more out there that you may have found so please feel free to

add them as comments at the end of this post.

Collapse Left-Navigation Menu Bar

Ever looking at a report with a lot of metrics and wish you didn’t have to scroll? Many people out there don’t know that you can

collapse the SiteCatalyst left-navigation bar to increase your report screen size. Simply click on the “minus” sign above the menu to

collapse and the “plus” sign to expand:

Double-Click to Add/Remove Metrics

Most of you should already know this, but in SiteCatalyst v14 you can double-click to add/remove metrics in the “Add Metrics”

window. For those of you using v13.x, hold down the CTRL key down when clicking on metrics to get the same result.

Double-Click to Rename Dashboard Reportlets

Ever want to change the name of a reportlet on a SiteCatalyst Dashboard? Bet you didn’t know that you could double-click on it to

rename it!

View Reports in Trended View

Most SiteCatalyst reports allow you to switch from the default “Ranked” view to a “Trended” view which shows you the context of the

data. This is useful for seeing if things are heading in the right direction. You can let SiteCatalyst pick the Top 5 items to trend or

you can specify the five items you want to trend. If you want to see more than 5 of your data points trended, you can do this by

using the ExcelClient.

Add Targets to SiteCatalyst Reports

While it is nice to look at your SiteCatalyst reports and see that the trends are going up or down (depending upon which way you

want them to go), sometimes that is not enough. Out in the real-world, there are mean bosses who want to hold you accountable

for your metrics! If this sounds familiar, you might want to check out a seldom used feature of SiteCatalyst called “Targets.”

Targets allow you to define metrics for specific timeframes and then show you how you are performing toward the targets that you

set. Let’s say I showed you the following graph:

You would most likely say that it looks like things are going pretty well. Revenue is trending up and there are not many situations

where you want Revenue to go down! It may be time to head out early, take a well deserved vacation or ask for that raise you have

been longing for!

But what if I then showed you the same graph, but with a Target added to show you where your boss expects your metrics to be…

Uh-oh, suddenly you are not feeling so confident! This is why Targets are important since in web analytics, context is king! You

can set SiteCatalyst Targets manually through the interface or import them using an Excel Spreadsheet. I encourage you to dig into

the user manual and learn more about Targets when you have the time.

Reorganize Menus and Hide Menu Items

Did you know that you could completely re-organize the left-navigation menus of SiteCatalyst? Does the notion of Traffic vs.

Conversion Variables not seem intuitive to you? Do you want to hide some SiteCatalyst reports that you don’t think your

organization will care about? You can do all of this and more in the Admin Console by creating your own menus and

adding/removing items. Simply select the report suite(s) you care about and open the “Menu Customization” tool. For example,

below you can see that there are a few Traffic reports related to “Day Parting” (time of day, day of week) buried within the Custom

Traffic 1-10 report folder:

You can easily create a new “Day Parting” folder and drag these reports there instead of having to hunt for them under the Traffic

reports folder. When you are done, it looks like this:

Upon saving, all users will see the menus the way you arrange them and you can use the “Restore Defaults” button to return to the

original menu structure if it is ever needed. For obvious reasons, this functionality is limited to Administrators.

Save Custom Reports

Have you ever opened a Conversion (eVar) report, added the exact metrics you wanted, chosen the perfect graph and sorted on

the perfect metric? It is a great feeling when you get a SiteCatalyst report exactly the way you want it. Once you have done this,

why would you ever want to have to go through all of that work again? While you can add the report to a dashboard or as a

bookmark, you would then have to take the additional step to share it with co-workers. If you are ok with everyone seeing this

report, you can save it as a “Custom Report.” To do this, simply create the report as you’d like it to be seen by others and click the

“Custom Report” icon from the toolbar and give it a name and save:

Once you have one or more Custom Reports, they will show up in a folder at the bottom of the left-navigation bar.

Of course, you can also move these Custom Reports anywhere you want in the menu structure using the Menu Reorganization tool

described above.

Create Global Calculated Metrics

Have you ever created a Calculated Metric that you wanted everyone at your organization to know about? Perhaps you and your

counterparts have different definitions for Bounce Rate which drives your superiors crazy. Using Global Calculated Metrics, you can

create Calculated Metrics and push them out to your organization. As long as the user has Administrator privileges, these Global

Calculated Metrics can be created on the fly from the Metrics Builder…

…or through the Admin Console:

Limiting Results in ExcelClient

One of the more powerful things you can do with the ExcelClient is to narrow down items that appear in reports by using the search criteria boxes. You can use these boxes to limit results to those matching a particular phrase which can be a real time-saver. Besides not taking advantage of this feature, many clients don’t realize that they can combine multiple elements in their search criteria. The following will demonstrate this functionality. The first step is to create cells in which you will enter your search criteria. I mainly use the “OR” and “NOT” items so I will focus on these in this post. Once you know which cells you want to use for your criteria, you assign those cells to your data block (click link labeled “Top 1 -50″) as shown here:

Once this is done and you have saved your data block, I normally run my report with no criteria in these cells to be sure I have the data I am looking for. In this case, I ran a report for Blog Post Titles, saw that they all appeared correctly and then entered my first search criteria. The thing that most people don’t know about is that you want to use a space as the separator. In this case, I

would like to see any posts that have the phrase “SAINT” or “VISTA” in them. After I enter these terms and refresh my data block, I would see the following:

As you can see, three items were returned all of which matched one or the other of the items in my search criteria. If I had wanted both to be present, I would simply use the “AND” cell instead or the “OR” cell. Now let’s say that I want to narrow my focus to items

that contain “SAINT” or “VISTA,” but for some reason I don’t care to see any items that contain the phrase “DB.” In this situation, I would keep my “OR” criteria as I had it before and add “DB” to the “NOT” criteria. Here you can see the criteria and the resulting data set after the data block is refreshed:

You will notice that the results are similar to those above except the item related to “DB VISTA” is no longer shown. Finally, let’s use the space as a separator again and this time exclude items that contain “DB” or “SAINT” so that we only look at items that contain “VISTA.” Below you will see the criteria entered and the resulting data set:

SiteCatalyst Dashboards [Inside Omniture SiteCatalyst]

Monday, 29 December 2008 @ 21:34, by Adam Greco

As a web analyst, you can do the best requirements gathering, site tagging and report suite set-up, but if no one at your

organization looks at the data you are producing, all of your effort is wasted. For this reason, Omniture does its best to enable you

to share the information stored in SiteCatalyst with as many people as possible in as many forms as possible. In the

Omniture ExcelClient post, we saw how you can push SiteCatalyst data to Microsoft Excel, but there are many other ways to share

SiteCatalyst data. SiteCatalyst data can be sent out via e-mail, viewed on the iPhone/Android mobile devices, shared through

Internet Widgets and displayed within SiteCatalyst in Dashboards. In this post, I will cover the basics of SiteCatalyst Dashboards

since these are used the most often and also what is leveraged to view reports on mobile phones and in Internet Widgets.

Understanding SiteCatalyst Dashboards

Hopefully, the concept of Dashboards is not new to most of you and there is a common understanding that Dashboards are

collections of reports or reportlets (mini reports) meant to communicate data to a specific target audience. Most Omniture clients

have several dashboards segmented by target audience so that they are sharing different data with different stakeholders

throughout the organization. Determining what data each person should have access to and how often will depend upon the person

and your organization.

Creating SiteCatalyst Dashboards

Creating a SiteCatalyst Dashboard is relatively straightforward. To begin, you simply open a report that you would like to add to a

Dashboard and click the “Add to Dashboard” icon:

In the resulting “Add Reportlet” window, the first thing you do is give the reportlet a name and then choose the Dashboard to which

you would like to add the report. If this is a new Dashboard, enter a name in the blank text box.

The next step is to select the date range. Click the Calendar icon to bring up the data selection screen and select a start and end

date. Notice that you can choose whether the dates are fixed or rolling. One handy thing I do is to make the start date fixed and

then make the end date rolling so each day I get another day’s worth of data.

Next, choose the content you want to appear in the reportlet. Start by choosing the size (Small, Medium or Large). If you have

more than one metric showing in a report, I suggest you use Medium or Large. Then choose if you want to show the graph, the

details table or both. If you choose to include the details table, select how many rows of the table you want to show in the

dashboard. Keep in mind that users viewing the Dashboard online will be able to click a link to see the full report. When you have

completed all of these steps, click the “Save” button and you will be taken to the Dashboard where you can see the added reportlet:

Sharing Dashboards

Once you have created a SiteCatalyst Dashboard, you have the ability to share it with other users in your organization. To share a

Dashboard, click on the “Dashboards” link from within My Account as shown here:

From within the subsequent window, check the boxes next to the Dashboards that you would like to share as shown here:

Once this is done, other SiteCatalyst users can enter the same screen using the instructions above and then check the boxes in the

“On Menu” column to have these dashboards appear in their Dashboard menu:

Important Things To Know About SiteCatalyst Dashboards

The following are some important things to know about SiteCatalyst Dashboards:

1. You can create an unlimited number of SiteCatalyst Dashboards

2. You can re-size Dashboard reportlets once they are on the Dashboard by clicking on the edit icon

3. Dashboards can be scheduled to be delivered on a regular basis

4. You can use “Publishing Lists” (to be covered in a future post) to have the same Dashboard deliver data from different

SiteCatalyst Report Suites to different people

5. Many of the settings for Dashboard reportlets cannot be changed once the report is added to the Dashboard such as graph

type, numbers vs. percentages, trended vs. ranked, metrics displayed, metric sort order, A/B comparison, correlation filters, search filters. Therefore, be sure you like the settings you have prior to adding the report to the Dashboard.

Real-World Example

In this week’s real-world example, since this post is a bit more on the “how to” side, instead of giving an in-depth case study, I

thought I would simply give you a glimpse into part of the SiteCatalyst Dashboard I use to view activity related to this blog.

Clicking on the image below will show an excerpt from a quick SiteCatalyst Dashboard I created to view the following:

1. Blog Post Views per Day

2. Day of the Week in which Blog Post Views took place

3. Hour of the Day in which Blog Post Views took place

4. The names of my Blog Posts and the number of Views for each in the selected time frame

5. The “Daypart” in which Blog Post views took place (which I created by using a SAINT Classification)

Incrementor Events [Inside Omniture SiteCatalyst] Sunday, 11 January 2009 @ 15:00, by Adam Greco

A while back, I discussed Success Events which are part of the Conversion area of Omniture SiteCatalyst. More recently, in the

Products Variable post, the term Incrementor Event surfaced. In my experience, many Omniture clients are not familiar with

Incrementor Events, so I thought I would spend a few minutes explaining what Incrementor Events are and how they can be used.

Understanding Incrementor Events

I find that the most difficult part of understanding Incrementor (you may also see it referred to as Incrementer) Events is getting over

their name! I am not sure how the name came to pass, but I find it confuses many clients so I prefer to simply focus on what they

do, memorize the name and move on! The purpose of Incrementor Events is to provide a way to pass a currency or numeric

value of your choosing to a Success Event as a metric. For those of you who have been reading the blog for a while, you will

know that normal (Counter) Success Events move up one value (notice I resisted the urge to say increment!) each time the Success

Event is set. For most Key Performance Indicators (KPIs) that is what you want to happen, but there are times when you want to

pass a numeric value to Omniture so that it can be totaled as a metric in reports and in calculated metrics. This functionality is

similar to what clients use the Revenue metric for through the use of the purchase event.

So when would you want to use an Incrementor Event? In the Products Variable post we saw an example where the client wanted

to capture a Shipping Cost associated with an order separate from the Revenue metric. The following are some other example

uses of Incrementor Events:

Pass Tax information as a distinct metric from Revenue

Capture a Discount Amount as a distinct metric from Revenue

Capture a page value or score

Pass estimated Advertising Impression Revenue to an “Ad Revenue” metric separate from Revenue generated by product sales

Enabling Incrementor Events

So how do you enable Incrementor Events? Like other Success Events, you enable Incrementor Success Events through the

Administration Console. Simply open the Success Events definition page, click the “Add New” link after your last Success Event,

enter a Success Event name and then choose the Event Type drop-down box as shown here:

When selecting the Event Type, even though there are several choices, the main ones used are Counter, Currency and Numeric

(for now, you can ignore the options with no subrelations). Counter Events are the default and used for most Success

Events. Incrementor Events are created when you select either Currency or Numeric. As the names indicate, you select Currency

if the values you will be passing are related to Currency, otherwise you select Numeric. The only difference between the two is that

Currency Incrementor Events have the Currency settings associated with the report suite applied to them (i.e. show localized

currency symbol in reports and have currency conversion applied if appropriate).

Important Things To Know About Incrementor Events

The following are some important things to know about Incrementor Events:

1. Incrementor Events are normally set from within the Products Variable (see previous post for syntax)

2. Most metrics passed into the Conversion area through Data Sources are passed to Incrementor Events (I will cover Data Sources in an upcoming post)

Real-World Example

In this week’s real-world example, we will show how a banking subsidiary of Greco Inc. uses an Incrementor Event. In this

scenario, the bank would like to understand the value of home loan mortgages site visitors are requesting so they can compare it to

the loan amounts that are ultimately provided. For example, if it is the case that the bank consistently ends up loaning out 79% of

the amount of home loans that are requested online, it can use this information for future estimates.

During the loan application process, applicants fill out a form and are required to enter a loan amount as shown here:

Greco Inc. would set-up an Incrementor Success Event (Currency) as shown above and use the Products Variable to pass the

Requested Loan Amount to the Incrementor Event using the following syntax:

Now that the Requested Amount values have been captured in an Incrementor Success Event, the bank is ready for step two in

which they import the actual amount of loans that were made to customers. Since the actual Loan Amount is not known during the

online session, Greco Inc. uses Omniture SiteCatalyst Data Sources which is a tool that can be used to import non-website metrics

into SiteCatalyst (I will cover Data Sources in greater detail in a future blog post). For now, all you need to know is that Greco Inc.

will import all closed loan amounts and associate them with the Product for which the loan amount is related. As was mentioned

above, metrics imported through Data Sources must be set-up as Incrementor Events so Greco Inc. would create a second

Incrementor Event (Currency) and then use Data Sources to upload the data.

When all of this is completed, Greco Inc. can create a calculated metric that divides the two Incrementor Event metrics and then

view all three metrics by Product in the Products report as shown here:

Participation [Inside Omniture SiteCatalyst] Tuesday, 13 January 2009 @ 13:09, by Adam Greco

Falling into the bucket of SiteCatalyst features that many clients are not familiar with, Participation is a handy feature that can help

you determine which of your site content elements are leading to success and which are not. In this post, I will explain Participation

and then illustrate some advanced uses of it that even those familiar with it may not have tried.

What is Participation?

In order to fully understand Participation, I find that it is helpful to first understand Allocation (also known as Linear Allocation). If a

visitor to your website clicks on ten pages and then completes a Success Event, SiteCatalyst “allocates” or divides the Success

Event into equal parts and gives each preceding page credit. If the Success Event is a purchase of $100, all ten pages viewed prior

to the Success Event and the page on which the Success Event takes place would be given credit of $10. If the Success Event is a

Counter Event, then each page would receive .10 credit. These values are aggregated, rounded and displayed in the Pages report

if you add a Success Event metric as shown here:

Most people never notice Allocation because when they look at the Pages report they are looking at Page Views, Visits or Unique

Visitors. You can add multiple Success Events to the Pages report and see the different page allocations for each Success Event

metric (note: this functionality is unique to the Pages report). While Allocation metrics can be useful, they have an obvious

downside. The more pages visitors view in a visit, the more diluted Allocation is for each page. For example, if a second visitor

views 20 pages and then completes the same Success Event, each page would get only .05 credit. Therefore, Allocation tends to

reward visits with smaller number of clicks and punish visits with many clicks. Depending upon your business model and/or site

objectives, this can be a positive or a negative.

Having covered Allocation, let’s now get back on topic and define Participation. Participation is a feature that assigns equal

credit to each item that “participates” in the flow leading to a Success Event. So in the examples above, whereas Allocation

would divide the $100 Success Event, Participation would assign full credit of $100 to every page the visitor viewed up until the

point that the Success Event takes place. When customers first hear about this, they are taken aback since the Participation values

are inflated and report totals will not match actual Revenue (or equivalent for a Counter Success Event). The key to Participation is

to focus the Participation values of various items in the report to see which produces the most success. Since this can be a

bit tricky, I will go through another example:

In the above report, we can see a few pages of the Omniture Blog, the associated Page Views and Blog Post View Participation. In

this case, Omniture sets a Success Event each time a visitor views a Blog Post and through this report you can see how often

each page leads to Blog Post Views. For example, the “Adam Greco” page had 30 Page Views, but only was viewed in the flow

leading to 27 Blog Post Views (my awful head shot must have scared some folks off!). In other words, the Participation metric is

indicating that there were 27 Blog Post Views, in the time frame of this report, in which the visitor viewed Adam Greco’s page prior

to opening a Blog Post.

Finally, I like to take this a step further by creating a calculated metric that divides a Participation metric by Page Views. When

doing this, the higher the resulting number, the more that item (page in this case) generates Success Events for every Page View it

gets (efficiency). I use this to do a “hidden-gem” analysis where you are looking for pages that may not get the most traffic, but

when they do, convert at higher than average rates. In the example we have been using, you could call this calculated metric “Blog

Pull-Through” and add it to the pages report as shown here:

Of the pages shown in this report excerpt, the “ASI” post had the most “Blog Pull-Through” in that it was able to get 30 Blog Post

Views out of only 8 Page Views or 3.75 Blog Post Views/Page View.

Important Things To Know About Participation

The following are some important things to know about Participation:

1. Participation can be turned on for most SiteCatalyst Success Events (excluding some forms of Data Sources). To enable Participation for a Success Event contact your Account Manager or ClientCare. Once Participation is turned on for a Success

Event, you add Participation metrics to traffic reports by using the drop-down box in the “Add Metrics” dialog box

2. Participation is calculated after the Success Event takes place, but affects pages viewed prior to the Success Event

3. Participation is calculated on a per Visit basis

4. In SiteCatalyst, Participation Metrics are not retroactive so they only show data from the point at which they are turned on

5. Participation metrics are available for most Success Events by default in Omniture Discover

6. Participation metrics are primarily used with Traffic Variables (sProps), not Conversion Variables (eVars)

7. By default, Participation metrics are tied to the s.pagename (Pages) variable, but there are more advanced ways to use Participation by tying Participation metrics to custom sProps (see example below)

Real-World Example

In this week’s real-world example, I will attempt to explain a more advanced version of Participation (not for the faint of heart!). In

this example, a manufacturing subsidiary of Greco Inc. has a website containing thousands of products and the Product team wants

to understand which products site visitors are looking at and, more importantly, which products get visitors to look at the most other

products. The first question is answered pretty easily by setting a custom “Product View” Success Event and capturing the product

ID# in the Products Variable. The web analytics team’s first attempt to answer the question of which products get visitors to look at

other products was to pass the product ID# to a custom sProp and enable Pathing. While this provided some good information,

there were far too many products to effectively use Pathing analysis. The second attempt to answer the question was to enable

Participation on the “Product View” event as described above, but the issue they ran into was that there were so many pages on the

website that it was difficult to analyze the Participation metrics for product amongst all of the other pages contained in the Pages

report.

At this point, Greco Inc. turned to Omniture Consulting for guidance (shameless plug!). Their Omniture Consultant informed Greco

Inc. that they could enable Participation on any sProp, not just s.pagename. A nice thing about enabling Participation for the

custom sProp (Product sProp in this case) is that it removes all of the clutter surrounding non-product pages which can be really

helpful. Since they already had product ID#’s in a custom sProp, they could tie Participation to that sProp. (Concentrate here

because this is about to get complicated!) By doing this, each time a Product View took place, the Product View Success Event

metric would be increased and the product ID# passed to the sProp on the Product View page would get one Product View

Participation credit (for itself). If, within the same visit, visitors viewed a second product, a Product View Success Event would take

place for the second product and the second product would get one Product View Participation credit (for itself), but more

importantly, the first product they looked at would get a second Product View Participation credit since it was in the flow of

another Product View Success Event (I told you it was going to be tricky!). For those keeping score at home, here is how the count

stands so far:

Just to make sure you get it, let’s go one step further and assume that the same visitor looks at one last product and exits. At this

point, the third product gets one Product View Success Event, one Product View Participation (for itself) and the first two products

get one more Product View Participation bringing the new totals to:

Once Greco Inc.’s heads stop spinning, they implement this according to the Omniture Consultant’s instructions and by the next day

they can see the following report by opening the “Product” sProp report and adding the following metrics:

Now Greco Inc. can look at products by Page Views, Product View Participation (how many times each was in the flow of another

Product View) or they can create a calculated metric to divide Product View Participation by Page Views to see which products have

the most Product Views/Page View which can show you which products get visitors to look at other products. Note that

Participation will only count each element once so, in this case, if a user views the same Product more than once, it will get a

second Page View, but no more Participation. If you anticipate this happening a lot, you can substitute Visits for Page Views in the

above Calculated Metric. All of this can be useful in answering their question as to which products get visitors to look at other

products.

Data Sources [Inside Omniture SiteCatalyst] Sunday, 25 January 2009 @ 10:57, by Adam Greco

While more and more business is taking place on the web each day, we online marketers cannot forget about successes and/or

conversions that take place beyond the website. While Omniture SiteCatalyst can capture all of your online success, there are

times when you need to couple this with business metrics that take place offline or in other channels. To do this, Omniture

SiteCatalyst provides a Data Sources feature. In this post I will briefly explain what Data Sources is and how it can be used.

Understanding Data Sources

So what is Data Sources? Data Sources is a mechanism to manually import additional metrics and metric dimensions into

SiteCatalyst. The primary reason that customers choose to import this data is to compare online metrics to these non-website

metrics. The following are some examples of situations in which you might want to use Data Sources to import data:

1. Import historical traffic data from log files or a previous vendor

2. Import offline success metrics unrelated to the website or taking place after a visit to the website

3. Import metrics from a separate channel such as e-mail or call center so you can compare them to online metrics and create calculated metrics

4. Import metrics from other products through Omniture Genesis such as e-mail or CRM metrics (most Genesis integrations use Data Sources behind the scenes)

In all of these cases, clients are looking to supplement their online data with related data so they can get a more complete picture of

their business. I find a good way to understand Data Sources is through a practical example. Let’s say that an Omniture customer

decides to start an e-mail marketing program. They select a vendor and the vendor happens to be part of Omniture’s Genesis

network. As part of the Genesis integration, the client begins receiving some new metrics in SiteCatalyst via Data Sources including

E-mail Sends, E-mail Opens, etc… Each of these metrics appears alongside existing online Success Events. Therefore, the client

can view key e-mail statistics from within SiteCatalyst without having to look two places. Finally, the client can create a calculated

metric that divides Submitted Online Leads by E-mail Sends and many others. All of this is accomplished through Data Sources.

How Do I Enable Data Sources?

While I won’t go through the detailed steps required to set-up Data Sources, the following is a brief overview of the process of

setting up a Data Source:

1. Most Data Source imports use Incrementor Success Events so you must create these ahead of time through the

Administration Console. You will need one Success Event for every metric that you plan to import

2. Create any desired Conversion Variables (eVars). In addition to importing metrics, you can optionally choose to import eVar

values associated with those metrics. For example, if you track online activity with a Campaign Tracking Code, and have Campaign Tracking Codes for the offline metrics, you can import the metrics with Campaign Tracking Codes. This will allow you to view both online and offline metrics in Campaign reports. If you do not import Data Sources metrics with an

associated eVar value, you will not be able to view Data Source metrics broken down by eVars, but rather, will only be able to

see total metrics (please re-read as this confuses many clients).

3. Go through the Data Sources wizard which will help you to create a Data Sources file import template and FTP site. As you

go through the wizard you will need to know the Success Events and eVars for which you want to import data. Please note that the wizard only allows you to select a few Success Event Metrics and a few eVar dimensions which can be confusing, but

rest assured that you can add more metrics and eVars directly to the template afterwards (Omniture Consulting or ClientCare can show you how to do this).

4. Once you have the template and the FTP site, you are ready to import data. Most clients will do the first few uploads manually and then find a way to automate the FTP upload process on a daily or weekly basis.

Important Things To Know About Data Sources

The following are some important things to know about Data Sources:

1. Once you import Data Sources data into SiteCatalyst, it cannot be undone or removed. For this reason, you need to be very careful and make sure you have done thorough testing and have a good process in place for automated data uploads. Always

test within a development report suite!

2. All data imported via Data Sources is tied to a date so it does not matter when it is imported. Obviously, the sooner it is

imported, the more accurate your overall SiteCatalyst data set will be

3. You cannot have more than 50 Megabytes of data in your Data Sources FTP account at a time (not 50MB per file, but in total

across all files) or it will become “locked” so it is recommended that you feed the data to SiteCatalyst accordingly

4. Each row of data imported via Data Sources is charged ($$) as an image request (”hit”) at your contracted rate

5. Some types of Data Source imports allow you to see the imported data in SiteCatalyst only, while others allow you to see

imported data in SiteCatalyst, DataWarehouse, ASI and Discover. For this reason it is important to be sure you select the correct Data Source Type (for more information read the Data Sources user manual found in Knowledge Base article # 527)

Real-World Example

In this week’s real-world example, we will look at a scenario for one of Greco Inc.’s electronics subsidiaries. In this situation, Greco

Inc. is doing its best to sell printers online, but at the time that the sale is completed, it is not able to accurately determine the exact

shipping cost, which can vary based upon a few post-sale factors. In addition, Greco Inc. would like to add the Cost of Good Sold to

SiteCatalyst so it can create some more realistic calculated metrics for judging Campaign success and other analyses.

To accomplish these two goals, Greco Inc. sets up two new Incrementor Success Events (COGS & Shipping Costs) and then

determines how it would like to break down these new offline metrics. For its online sales, Greco Inc. does most of its analysis by

Tracking Code, Order Number, Brand, Product Type and Coupon (if used). It already has eVars created for these and regularly

looks at online metrics such as Orders, Units and Revenue by these dimensions. After going through the Data Sources wizard,

Greco Inc. has an FTP account set-up and the following Data Sources import template (shown here with one sample line of offline

data):

Once all testing is done, Greco Inc. can begin importing the offline data via Data Sources and can then see a SiteCatalyst report

that includes both online and offline data:

There is a great deal more to learn about Data Sources including different types (Integration, Full Processing, etc…), but these are

more advanced topics to be saved for a future post. If you are interested in digging into Data Sources, Omniture provides a special

user manual on the topic (Knowledge Base article # 527) which I suggest you check out.

Transaction ID [Inside Omniture SiteCatalyst] Tuesday, 27 January 2009 @ 18:21, by Adam Greco

In our last post on Data Sources, we discussed how you can augment your online data by injecting offline (or non-web online

data) into your SiteCatalyst data set. This post will build upon this topic by covering one of the most powerful new features of

SiteCatalyst, Transaction ID.

What is Transaction ID

So what is Transaction ID? Transaction ID allows you to connect online and offline data by establishing a “key” that can tie the

online visit to the offline success. For example, let’s say that you are a retailer and you sell three iPods to Joe Smith today.

However, a week from now, what if Joe Smith returns two of the iPods. All of your online numbers will be inflated since they do not

reflect product returns. In addition, you have a lot of online data about Joe including his Visit Number, which Campaign Tracking

Code he came from, etc… All of these reports are now suspect since they don’t include product returns. So how do you fix this?

One way would be to use Data Sources like we discussed in the last post, but you would have to manually identify Joe’s Visit

Number, Campaign Tracking Code, etc… What a pain, especially since Omniture SiteCatalyst already has all of this information

right up until the point that Joe purchases the three iPods. Wouldn’t it be great if there were a way for SiteCatalyst to store all of

that data somewhere so if we tell SiteCatalyst that Joe had a return, SiteCatalyst could, in effect, reverse out part or all of his

transaction in all of these reports? Well, that is exactly what Transaction ID can do!

How Does Transaction ID Work?

So how does Transaction ID work this kind of magic? It’s not as hard as you would think. Using the example above, when Joe

completes a purchase online, your developers would pass a unique “Transaction ID” (hence the name) to a special SiteCatalyst

variable. When that happens, SiteCatalyst stores all known data for that Visitor in a separate table and uses the Transaction ID as

the “key.” Later, when there is offline data related to that same Transaction ID uploaded (the product return in this example), all of

the conversion data (i.e. Campaign Tracking Code, Visit Number, etc…) is associated with the newly uploaded metrics. This saves

you the work of having to upload all of this supplemental data with the offline metrics like you would using traditional Data Sources.

Please note, that the example here is one of many ways you can use Transaction ID functionality. Here are a few more examples:

A visitor fills out a lead form on your website and later purchases a product by phone. If you can connect the user’s online session and phone call together using an ID (i.e. e-mail address), you can see what online campaigns or referral sources led to the phone call, which led to the sale. This helps you justify your investment in online advertising.

A visitor to a bank site completes a loan application online, but the bank needs a few weeks to determine if it will give them the loan. Using Transaction ID, the bank can upload the results (Loans Approved or Loans Declined) and see what

campaigns or referral sources lead to Loan Approvals vs. Loan Declines in order to maximize online advertising budgets.

A rental car company wants to see which campaigns lead to online car reservations vs. which lead to actual car rentals

(offline)

A retailer wants to test a new joint affiliate landing page so they ask visitors on that site to print off a digital coupon and bring it to their brick and mortar store. Using Transaction ID, they can associate each sale made at the store with the

online source.

As you can see, there are many ways to use this feature, but the common theme is tying together online and offline behavior.

Important Things To Know About Transaction ID

So now that I have you all excited about Transaction ID, here are some of the caveats:

1. Because Omniture has to store an extra table of data to make Transaction ID work, there are some additional fees involved. Your Account Manager can discuss this with you in more detail.

2. By default, all Transaction ID data is stored for 90 days. This means that you have up to 90 days from the time you set the Transaction ID online to upload the related offline data. This timeframe has been adequate for most of my clients and can be

extended if needed for a surcharge.

Real-World Example

In this real-world example, we will look at a banking scenario. Let’s assume that a banking subsidiary of Greco Inc. (First Bank

USA) is making a major push for new credit card customers. They are spending lots of money on paid search and display

advertising. As a result, they are generating tons of online leads, representing visitors filling out credit card applications. Below is a

report that they see from within SiteCatalyst:

As you can see, the “Lowest Rates” campaign is performing the best and the “Switch to First Bank USA” campaign is the most

expensive. Based upon this information, the online marketing manager begins to spend more and more money on the “Lowest

Rates” campaign and abandons the “Switch to First Bank USA” campaign.

However, after a few weeks, the marketing manager gets a report that their numbers for new credit card customers have not

increased as expected. Given the high number of new leads, this doesn’t make sense, so they decide to dig into things further.

Around this time, a marketing intern happens to read a cool blog about SiteCatalyst’s Transaction ID functionality and convinces

First Bank USA decides to pass the application ID to the Transaction ID variable and then upload the results of each credit card

application using the application ID as the “key.” After doing this, they looked at the same campaigns report, but included the newly

created metric of “Approved Applications” and then created calculated metrics for “Approved/Completed Conversion %” and “Cost

per Approved Application:”

Once they did this, they were able to see that the different campaigns had varying degrees of application approval such that some

campaigns generated a lot of submitted applications, but not applications that First Bank USA deemed to be credit-worthy. In fact,

when looking at the same campaigns as before, it was found that the “Lowest Rates” campaign that looked so promising before,

actually had the worst Cost per Approved Application and that “Switch to First Bank USA” campaign that they stopped investing in,

had the lowest Cost per Approved Application! By basing their analysis on only the online piece of the conversion process, First

Bank USA had wasted much of its online marketing dollars on credit card leads that it didn’t want and stopped investing in

campaigns that led to worthy candidates.

Hopefully this example shows you how important it is that you know about Transaction ID and how it can impact your online

analyses. If you have other inventive ways you can think of to use this feature, please leave them here as comments…

Plug-ins [Inside Omniture SiteCatalyst] Tuesday, 27 January 2009 @ 18:22, by Adam Greco

One of the topics I discussed in my SiteCatalyst Summit presentation last year was JavaScript plug-ins. Not being super-technical

myself, the best I can do to explain these plug-ins is that they are additional snippets of code you add to your SiteCatalyst .js file

that allow you to add functionality. One of the advantages of being associated with the Omniture Consulting group is that you get to

work with a lot of talented people who come up with these plug-ins to solve unique customer issues. In fact, many of the features

you use today in SiteCatalyst originated from plug-ins written by the consulting team. In this post, I will share with you some of my

favorite plug-ins and explain how they are used.

Get Query Parameter Plug-in

This is the most commonly used plug-in since it is essential to Campaign Tracking. This plug-in looks for parameters in the URL

and assigns them to the SiteCatalyst variables that you designate. For example, when a visitor arrives at your site from a paid

search keyword, the campaign tracking code is normally extracted using this plug-in and placed in the s.campaigns Conversion

Variable (eVar). However, there are many other uses for this plug-in since it can grab any query string parameter. I will often use

this to grab the search term used in an internal search query on a client’s site. For example, on this website, when the user

conducts an internal search, the phrase they used is passed in the URL of the results page such that the text found after the “q=”

can be programmatically passed to a Traffic Variable (sProp) or Conversion Variable (eVar):

Previous Value Plug-in

This plug-in allows you to pass a value that was stored on the previous page to a variable on the current page. I find this plug-in to

be extremely useful, especially when it comes to Traffic Variables which do not have persistence. A common use of this feature is

to pass the pagename value from the previous page to a custom sProp on the current page, in effect, storing the referring

pagename in a custom sProp on the current page. Why is this useful? Let’s say that you want to see what page the user was on

when they searched on the term “eurodollar” as shown in the example above. Unfortunately, there is not a straightforward way to

do this, but if you have the search term in an sProp (as shown above) and the previous page in an sProp (through the plug-in) all in

the same image request being sent to SiteCatalyst, you can then create a Traffic Data Correlation between the two. Through this

Correlation, you can see all of the pages that users were on when they searched for “eurodollar” and you can see the converse,

which is the ability to see all of the terms that users searched for while they were on a particular page (i.e. the Home Page). By

combining the Previous Value Plug-in and a Correlation, you can get some pretty powerful data for very little work.

Get & Persist Plug-in

This plug-in is very basic, but has many powerful uses. All it does is pass a value stored in a variable on one page to all

subsequent pages. It saves you the time/effort of storing values in your own cookie and lets your SiteCatalyst .js file do the work for

you. When would you want to do this? Let’s say that you have registered users on your site who log-in to use the site. Upon login,

you capture their User ID, but it would be great if you could pass that User ID to a Traffic Variable on every page of the visit. If you

did that, you would be able to create a Traffic Data Correlation between the User ID and the s.pagename variable so you could see

all of the pages that each User ID viewed on the site. The Get & Persist plug-in makes doing this much easier and lets your IT staff

focus on more important tagging work.

Time Parting Plug-in

This plug-in allows you to store the Day of the Week and Time of Day in SiteCatalyst Traffic and Conversion variables so you can

break data down by time segments. There are a few nuances with this plug-in (needs to be updated each year and ties data to one

time zone), but overall, I have found that it provides useful information to factor into your analyses. The following is an example of

how I use Time Parting to see when visitors access this blog:

Visit Number Plug-in

This plug-in passes the current visit number for the active visitor to SiteCatalyst Traffic or Conversion variables. While these metrics

are provided in a few out-of-the-box SiteCatalyst reports, I find having it in custom metrics provides more flexibility for use in

Correlations and Subrelations. The main caveat with this plug-in is that the data is subject to cookie deletion.

Days Since Last Visit Plug-in

This plug-in is similar to the Visit Number plug-in except it passes one of a few set values based upon when the active visitor had

been to the site last. Some of the values are “Less Than 7 Days” or “More Than 30 Days.”

Time To Complete Plug-in

This plug-in allows you to track how much time elapses between two Success Events of your choosing. This is handy when you

want to see how long it takes for users to progress through a conversion flow on your site. The following is a sample report using

this plug-in:

Dynamic Object ID Plug-in

This plug-in allows you to improve the accuracy of ClickMap by assigning unique ID’s to the objects found on your webpage.

Important Things To Know About Plug-ins

The following are some important things to know about Plug-ins:

1. Many of the plug-ins described here involve implementation and, as such, should be used in conjunction with an Omniture

Consultant who can educate you about usage and maintenance.

2. Adding plug-ins to your SiteCatalyst JavaScript file will increase its “weight” so you should be sure to test thoroughly,

especially if using services that rate page load performance.

Event Serialization [Inside Omniture SiteCatalyst] Tuesday, 27 January 2009 @ 18:24, by Adam Greco

While there is not much to the topic of Event Serialization, I have run into numerous clients who did not know that it existed so I

thought that it would merit a brief mention here on the blog. This short post will cover the main things you need to know about

Event Serialization.

What is Event Serialization?

Event Serialization is the process of de-duplicating the firing of Success Events. As you know, when a normal counter Success

Event is set, SiteCatalyst increases the Success Event metric by one and associates the success with any values currently existing

in Conversion Variables (eVars). However, there are many cases in which a user’s action can trigger a Success Event multiple

times (inadvertently or intentionally). For example, a user may log into your website several times a day, making your “Logins”

metric unrepresentative of unique Logins. Alternatively, a visitor may hit the “back” button in their browser while in the conversion

process triggering a second “Cart Add” event to be fired. Most of the time, these duplicated Success Events are nominal, but as a

web analyst, part of your responsibility is to safeguard the metrics you report so that you can trust them to make sound business

decisions so there may be cases where you need to ensure this is not happening. That is where Event Serialization comes into

play. Through Event Serialization, you can ensure that only the first instance of a Success Event will be counted in Success Event

and Conversion Variable (eVar) reports.

How Does Event Serialization Work?

The implementation of Event Serialization is very simple. Everything is the same as setting a normal Success Event except that

you include a unique alphanumeric string after the Event Number in the syntax. For example, instead of the normal syntax of

s.events=event12

You would add a “:” and a unique string (20 characters or less) so that your syntax looked like this:

s.events=event12:123456789

If SiteCatalyst sees any Success Events come through with the same event number and serialization string, it will ignore it. For

those of you who sell goods/services online, the concept is somewhat similar to the idea of Purchase ID, but in this case is meant

for custom events.

Important Things To Know About Event Serialization

The following are some important things to know about Event Serialization:

1. As mentioned above, the string must be alphanumeric and less than 21 characters

2. Serialization strings persist forever so be careful when creating them to avoid excluding Success Events unintentionally

3. You can also use Event Serialization with Incrementor Events

Real-World Example

In this example, a media subsidiary of Greco Inc. has a site that is heavily focused on video consumption. For this site, they want to

see how often logged-in visitors watch all of the various videos hosted on the site. To do this, they set a series of video-related

Success Events, such as “Video Starts” and “Video Completions” and use an eVar to track the “Video ID.” While it wants to see a

raw count of Video Starts and Completions, one of their business requirements is to see how many “unique” Video Starts and Video

Completions take place such that the same logged-in visitor is not counted as seeing the same video more than once. By doing

this, Greco Inc. can compare the de-duplicated metrics to the raw metrics to see how often videos are being watched repeatedly.

To accomplish this, Greco Inc. creates four Success Events, two for raw data and two for de-duplicated data. Since it knows the

User ID of the logged in visitor, Greco Inc. decides that it can use that as part of the serialization string, but there is a problem. If it

uses the User ID to serialize the Success Events that would make it so any videos beyond the first one for that User ID would not be

counted since the user would always have the same serialization string (their User ID). This is where Event Serialization can get a

bit tricky! Instead, Greco Inc. would need to combine the User ID with a unique string for each video so that the combination of the

User ID and Video ID would only be counted once! Hence, if the current User ID is “123456789″ and the first video they watch is

Video ID “news119987,” the syntax might look something like this:

s.events=event13,event14:123456789-news119987

By doing this, if User ID “123456789″ ever views Video ID “news119987″ again, it will be ignored by SiteCatalyst in “event14,” but

will be counted again in “event13.” The same would apply for the Video Completions events with one being set normally and the

other being serialized using the same string shown above.

Calculated Metrics [Inside Omniture SiteCatalyst] Tuesday, 27 January 2009 @ 18:26, by Adam Greco

In this post, I will review SiteCatalyst Calculated Metrics to be sure that all of you out there know about them and how they can be used. What Are Calculated Metrics?

Calculated Metrics are SiteCatalyst metrics that are derived from existing metrics within your report suite. Using common operators such as addition, subtraction, multiplication and division, you can create new metrics from existing metrics for use in your analyses. Personally, I would say that 80% of my Calculated Metrics are ratios using division as I divide two existing metrics to create a third metric. There are several ways to create Calculated Metrics, but the most common way is to create them is through the “Add Metrics” link within a report. Once you click this link, you can select the Metric Type drop-down box and choose “Calculated” to see a list of all existing Calculated Metrics:

From the next screen you choose the “Create New Metric” button and you will see the screen below (you can also create new

metrics by clicking on the colorful icon next to the drop-down box). In this screen, you can give the Calculated Metric a name,

choose its type and specify the formula to be used. In this case, I want to see how many Blog Post Views take place per Visit as a

percentage:

Once you save this, you will be taken to the previous screen where you will now see the newly created Calculated Metric in the list.

One important thing to note is that from this screen, you can choose to make a Calculated Metric “Global” such that it appears to all

SiteCatalyst users. This is a powerful way to standardize your organization on common metric definitions.

Using Calculated Metrics

Once you have created a new Calculated Metric, there are several things you can do with it. To begin with, you can add it to a

report as a metric as you would any other metric. For example, if I have a Blog Author eVar report, I can add the newly created

Blog Post Views/Visit metric:

As you can see here, since we had data for the two components of the Calculated Metric, SiteCatalyst can easily provide the ratio

for each of the eVar report elements.

The next thing you can do with Calculated Metrics is to view the overall metric itself without breaking it down by a Traffic Variable or

Conversion Variable. This type of report is identical to what you would see when looking at the raw data of a SiteCatalyst Success

Events. You open this report by clicking on the “My Calc Metrics” area in the SiteCatalyst toolbar and selecting the metric you want

to review. The resulting report will show you the Calculated Metric data in a similar format to a Success Event Metric:

Calculated Metrics can be also used in ExcelClient data blocks, though many times I find it easier to calculate these formulas in

Excel.

Finally, in addition to creating/editing Calculated Metrics from within the Add Metrics window, you can also modify them from within

the Admin Console as shown here:

Alerts [Inside Omniture SiteCatalyst] Tuesday, 27 January 2009 @ 17:02, by Adam Greco

While Alerts are not overly complicated, I am amazed how many customers I meet who are not using them. After all, once you set a

large number of metrics by which to evaluate your online business, who wants to spend all day checking to see if they go up or

down when you can have SiteCatalyst automatically inform you of unusual activity? In this post I will cover the basics of Alerts in

hopes that those who are not taking advantage of them will begin to do so.

What Are Alerts?

SiteCatalyst Alerts are a mechanism for you or your business users to be alerted when something positive or negative happens

related to SiteCatalyst metrics you care about. Alerts can be set in many different types of SiteCatalyst reports using an icon in the

toolbar as highlighted below:

Unfortunately, Alerts can get a bit complicated because their functionality is different depending upon the type of report you are

looking at when you click the above icon. The following will explain what you can do with Alerts in the various report types:

Site Metrics Reports

Alerts for the Site Metric Reports are the easiest to understand since they involve raw numbers only. As a refresher, the Site Metric

reports include Page Views, Visits, Unique Visitors, Purchase, Orders and all of your Custom Success Events. When you choose to

set an alert on these reports you will see a sub-screen like this:

In this screen, your only options are to choose a time frame (Hour, Day, Week, Month) and whether you want to be alerted if a value

is Above, Below or Changed by a specified percent. As is the case with all Alerts, you can also specify if you want to be alerted via

e-mail or mobile device and can assign a name to the Alert. Video, Mobile and GeoSegmentation Reports are the same as Metric

Reports when it comes to Alerts.

Non-Site Metrics Reports

Alerts for the other reports in SiteCatalyst are a bit more tricky since, in general, non-site metric reports allow you to choose which

metrics you want and display many different values associated with those metrics. For example, any Conversion Variable (eVar)

report allows you to add almost any metric to it and then displays the various eVar values associated for those metrics. In the case

of a blog site with an “Author” eVar report, adding the “Blog Post Views” metric will display a list of Authors that had Blog Post Views

and the number of Blog Post Views for each Author in the metric column. Hence, it would make sense that when attempting to set

an Alert for an eVar report, you would need to specify the metric and the eVar value to which you want the Alert to be tied.

Therefore, when clicking the Alert icon in such a report, you will see a slightly different screen that looks like this:

In this situation, you will notice that there are two additional items to select for the Alert. The first is the Metric and the second is the

Value. Both can be set by using the drop-down boxes. In the Metric drop-down box you select the metric for which SiteCatalyst will

check to see if values rise or fall. This metric list is the same as the list of metrics that you can add to the current report using the

Add Metrics link. The Value drop-down box allows you to specify for which Values the chosen metric will be evaluated. The default

is “All Items” which is the equivalent t the total at the bottom of the eVar report and will alert you if this total rises or falls above or

below your criteria. The next option in the Value box is “Top 1000″ but I can’t recall a time when I have ever used this. The last

item in the list is “Specific Item” and this is extremely useful. This option allows you to choose specific eVar values for which the

selected metric will be evaluated. In the example above, we could select “Adam Greco” as the Author and Blog Post Views as the

Metric and specify that we want to be alerted anytime the daily Blog Post Views change by more than 25%. However, in reality, I

tend to set Alerts on a weekly basis since choosing Daily will often end up sending you e-mails every Saturday and Sunday!

Important Things To Know About Alerts

The following are some important things to know about Alerts:

1. It is not possible to set Alerts on Pathing reports and some Visitor Retention reports

2. You can send an alert to multiple people by adding e-mail addresses separated by a comma

3. You can view all of your Alerts and make changes to them in the “Alerts” area found under the My Account drop-down at the

top-right of the Omniture Suite toolbar. In this area you can also enable or disable the Alert as you wish if you only want to use the Alert sporadically

4. When you receive an Alert e-mail, there is always a link at the bottom that allows you to disable the Alert so those you send Alerts to will not be “spammed” forever by you including them on an Alert

5. You can set Alerts on Calculated Metrics by clicking on the Alert icon from within the specific Calculated Metric report about which you want to be alerted

Integrating Twitter Into Web Analytics [Inside Omniture SiteCatalyst] Monday, 23 February 2009 @ 13:33, by Adam Greco

At last week’s annual Omniture Summit, there was a lot of buzz about social media and Twitter specifically. In my SiteCatalyst

Power User session, one of the things I covered was an idea about how you can leverage Omniture SiteCatalyst to monitor your

company’s brand reputation in tools like Twitter. This concept seemed to really resonate with the Summit audience, so much so,

that I was given an opportunity to share it at the closing session. The following will describe the concept in greater detail for those

who could not attend my Summit session. DISCLAIMER: What I presented is a “proof of concept” and is no way a formal

introduction of a new Omniture product.

Business Scenario

So this idea started with me thinking about how cool Twitter is and how it could be used for marketing purposes. As an Omniture

Twitter ambassador (Omni_Man), I see people talking about Omniture all of the time on Twitter. Sometimes this chatter is positive,

sometimes it is negative. I usually try and send my colleagues at Omniture “tweets” that I think might be relevant to them, but this

can be very time consuming. So I said to myself, “SiteCatalyst has a Data Insertion API that is used to inject non-website data into

SiteCatalyst and Twitter has an API associated with its search.twitter.com website, so if you put the two together, why couldn’t you

pass Twitter information into SiteCatalyst?” Doing this would allow you to do many cool things which I will describe below. I

enlisted the help of one of our Omniture Consulting folks (thank you Shawn Reed!) and within 24 hours, we had a working

prototype. The following examples of this functionality will use Comcast (who I co-presented with) as an example, but these

represent test data and is not meant to imply that Comcast is using this functionality. In my session, I posed the following

hypothetical business scenario: You are the web analytics manager at Comcast and your CMO returns from an executive retreat

where he/she has learned all about Twitter and believes that Comcast needs to do everything it can to monitor what its customers

are saying on social media sites. The CMO calls an emergency “all hands” Marketing/PR meeting and demands to know the

following:

1. How often Comcast is mentioned on tools like Twitter

2. If there is ever a spike (positive or negative) in brand-related terms (in a week, day or even hourly)

3. Who are the people most often mentioning Comcast on social media tools and who are they communicating with the most?

4. When are people on social media tools mentioning key Comcast product/service features that Product Managers should

know about

So at this point, the CMO turns to you and asks if there is anything you could do to help… What would you say? Not sure? Let’s

tackle them one at a time…

Monitoring Brand Comments

As stated earlier, the key to this solution is leveraging the SiteCatalyst Data Insertion API and the Twitter API. For those of you not

familiar with the SiteCatalyst Data Insertion API, it is used to send data to SiteCatalyst when a JavaScript tag is not an option. By

combining this with the search.twitter.com API, we can set a SiteCatalyst Success Event for every “Brand Tweet” by pumping the

results of a “Comcast” Twitter search into SiteCatalyst. This allows us to see a metric chart of “Brand Twitter Comments” so we can

track it by month, week, day or hour. However, why stop there? SiteCatalyst has a built-in Alert feature that allows you to be

notified via e-mail or mobile device when a Success Event metric hits a threshold or changes more than a specified percentage.

Why not take advantage of this feature and send yourself (or others) an Alert when your brand is mentioned 25% more this hour

than last hour or decreases significantly day to day? This would allow you to stay on top of what is going on in Twitter without

having to constantly monitor Twitter every day/hour! Below is a screen shot where you can see the “Brand Twitter Comments”

Success Event and an Alert related to it being set:

Who’s Tweeting?

The next thing your CMO wanted to know who are the most active Twitter users that are tweeting about your brand. Are there

some really good brand advocates out there? Are there people who are repeatedly bashing your brand? Are any of your

employees “going rogue” and confusing the marketplace with mixed messages? Again using the API, it is possible to extract the

Twitter user name associated with every tweet. In our proof of concept we did our best to extract the author and the recipient, with

the latter being more difficult since there are times when there is no recipient or multiple recipients (we are still working on this).

However, by placing both in separate Conversion Variables (eVars), we could breakdown the “Brand Tweet Comments” Success

Event metric by author to see who is twittering about your brand the most. We decided to take this one step further by creating a

Conversion Subrelation between the author and the recipient so you could break one down by the other (note that if there is no

recipient we used “[No Recipient]“). This allowed us to see who was tweeting with each other the most often. I imagine that this

could be useful to see what types of people have formed virtual communities and some companies might consider contacting the

key members of this virtual community to gather product feedback/suggestions or to leverage them for brand promotion. You could

also use SAINT Classifications to group Authors into meaningful buckets once you knew who they were (i.e. Customers, Vendors,

etc…). The following is a screen shot of the subrelation report we created:

Mining Important Product Keywords

The final thing the CMO tasked us with was discovering when, in addition to our brand name, social media users were mentioning

specific keywords that are product or service related. For example, if someone “tweets” about Comcast and in the same tweet

mentions “speed” it is likely that this tweet is related to high-speed internet access and could be interesting to the Internet product

manager. Alternatively, if a “tweet” mentions Comcast and also mentions “Tivo” or “DVR” it is likely they are expressing an opinion

in the digital TV recording arena that would interest the associated product manager. So you have millions of opportunities to read

what your customers are saying, but who wants to scan through all of those “tweets” to find the relevant ones, especially if this has

to be done manually?

This got me thinking about SiteCatalyst’s search functionality. If we had all of the “tweets” in SiteCatalyst, you could perform a

keyword search and let SiteCatalyst find all of the comments that mention a specific keyword. For example, let’s imagine we use

the Data Insertion API to pass all Comcast “tweets” to a Conversion Variable (eVar) and then conduct a search for the phrase

“Tivo.” SiteCatalyst would isolate those “tweets” and then you can bookmark that report and schedule it to be e-mailed to the

appropriate product managers at whatever time interval you desire (hourly, daily, weekly, monthly, etc…). This way, no one at your

organization would ever have to use or look at Twitter, but instead, the information they need to see would be pushed to them

automatically. Best of all, there is no limit on how many searches and bookmarked reports you can create so you can create

hundreds of different keyword searches and send them to different groups of people using Publishing Lists. The following screen

shot provides an example that shows “tweets” having been sent into SiteCatalyst and a user entering the phrase “Tivo” in the

search box and a highlighting of one “tweet” that would be found:

As you can see, if you know a lot about SiteCatalyst including API’s, Conversion Variables, Subrelations, Searching, Bookmarked

Reports, etc… you would be able to amaze your CMO by answering all of his/her questions and be a rock star!

Track Multiple Brands

Another concept related to this that we have explored is the idea of tracking multiple brands. There is no reason why Comcast, in

this example, could not also capture “tweets” about its competitors or subsidiary brands to see them side by side. This would

require the use of an additional eVar or potentially some additional Success Events, but we got this working in our prototype.

Next Steps

As mentioned previously, all of this was done as a proof of concept, but as you can see, the concept has great potential. We at

Omniture are going to explore this topic more and hope that you do the same. We hope to add more information about this to the

Developer Connection. We will also continue to explore new ideas related to this, but I encourage you to leave comments here with

your ideas on how this concept can be extended.

Publishing Lists [Inside Omniture SiteCatalyst] Sunday, 1 March 2009 @ 10:23, by Adam Greco

Have you ever created a SiteCatalyst report or an ExcelClient Dashboard only to find out that you need to make several different

versions of the report/dashboard for different audiences of people? Perhaps you have different geographies/countries in your

business and they need the same exact report, but the data needs to come from a different SiteCatalyst report suite (i.e. show

Germany its data and France its data). Or, it may be the case that executives can see more data than managers. Regardless of

the situation, duplicating the same dashboard over and over again, only to tie the different versions to different report suites is no

fun! To solve this problem, Omniture created a Publishing List function which can save you hours of work and make you look like a

dashboard machine!

What Are Publishing Lists?

A Publishing List is deceptively simple, yet very powerful. It is nothing more than a grouping of e-mail addresses broken down

by report suite, which can be used to distribute different data sets to different people. When you create a SiteCatalyst

Publishing List, you do the following:

1. Give the Publishing List a name

2. Select a Report Suite (cluster of data)

3. Assign one or more e-mail addresses who should receive data for the selected report suite

Therefore, if I intend to create a sales report, but want to send it with different data to different country sales people, I would create a

“Sales” Publishing List and define it with the different people by country report suite as shown below:

After doing this, you can create a report to be delivered on a regular basis and then associate it with the Publishing List. This will

cause SiteCatalyst to do the following:

1. Open the report

2. Select the first report suite

3. Refresh the data (or data blocks if it is an Excel Dashboard)

4. Send the report with the refreshed data to the recipients associated with that report suite

5. Repeat steps 2-4 above for each subsequent report suite in the Publishing List

Using Publishing Lists

So how do you use a Publishing List? Before you can use a Publishing List, you need to create a SiteCatalyst report. Simply open

any report in any report suite and customize it the way you would like. I tend to start with a report I have already bookmarked.

Once you are in the report, click the “mail” icon which will bring up the delivery configuration screen where you can click the

Publishing List link to see the following:

Keep in mind that what you have just done in the example above is told SiteCatalyst that you want this report sent out periodically to

all of the people in the “Sales” Publishing List, but that each person on that list should get the same report layout, but with different

data depending upon what report suite they are associated with. Therefore, the report structure/format will be the same, but the

Germany sales folks will see data from the Germany report suite and the US sales folks will see data from the US report suite, etc…

So how do you associate an ExcelClient Dashboard with a Publishing List? There are a few key differences when you apply the

preceding concept to an Excel Dashboard. First, when you create data blocks for your Excel Dashboard, there is a check-box that

you must check off to indicate that you want the report suite associated with the data block to be variable based upon a Publishing

List. This is what you will see on the report suite selection screen of the ExcelClient data block wizard:

Once you have created an Excel Dashboard with data blocks assigned as variable, save your Excel workbook and click the

“Publish” button in the ExcelClient toolbar. From there you will be able to upload your workbook and indicate which Publishing

List(s) should receive it:

After you have scheduled both SiteCatalyst reports and Excel Dashboards, you can see them in the Scheduled Reports Manager

and SiteCatalyst will show you the format, schedule and let you edit the Publishing Lists or timing, etc…

Important Things To Know About Publishing Lists

The following are some important things to know about Publishing Lists:

1. Currently, it is not possible to make SiteCatalyst Dashboards variable by report suite since you can add reportlets from

many different report suites to a SiteCatalyst Dashboard. This functionality may be coming in an upcoming SiteCatalyst

release.

2. A person can be associated with two different report suites in the same Publishing List such that they will receive multiple

copies of the same dashboard, each containing different data

3. When creating Publishing Lists with ExcelClient Dashboards, you are required to have Excel 2007 or the free Excel 2007

converter and all required updates. Those receiving Excel Dashboards shoudl be fine with Excel 2003 or Excel 2007.

4. When using Publishing Lists with ExcelClient Dashboards, it is important to note that upon publishing, Excel formulas

will not be refreshed since the refreshing is done server-side. This means that if you use formulas to specify date ranges

for data blocks, they will not work. Therefore it is recommended that you stick to relative or hard-coded date ranges when

creating data blocks to be used with Publishing Lists. There is an art form in creating relative date ranges that applies here

which I hope to cover in a future post.

Instances [Inside Omniture SiteCatalyst] Sunday, 8 March 2009 @ 10:25, by Adam Greco

I have found that one of the rites of passage for SiteCatalyst users is the day that you understand what the heck “Instances” are in

SiteCatalyst reports. For those of you who have been through this, you will know what I am talking about. For the rest of you, my

hope is that this post will pre-empt your confusion/frustration by explaining what Instances are and why you should not lose sleep

over them!

What Are Instances?

So what are instances? Instances is SiteCatalyst’s way of telling you how many times a Conversion Variable has received a value.

Doesn’t sound too hard does it (just wait…)? So before we dig deeper, let’s start by coming face-to-face with the Instances metric.

To do this, open any eVar report you have in your report suite. Once you have opened the report, click the “Add Metrics” link and

you will see a metric named Instances in the list. You can add this to the report by itself or alongside other Success Event metrics.

In this case, I have added the Instances metric to a report showing Blog Post Views for the Blog Post Title eVar. In this case, the

Instances metric matches the Blog Post Views metric because that Success Event is set every time, but there will often be cases

where an eVar will have Instances (have a value set), but no Success Event takes place:

So what does this report tell you? It is basically saying that, in this example, the value of “Plug-ins [Inside Omniture SiteCatalyst]”

was passed to this eVar 217 number of times. Not all SiteCatalyst users utilize the Instances metric in eVar reports, but there are

times when the Instances metric magically transforms into other metrics that are useful which I will describe next.

Instances = Searches

When using SiteCatalyst Search Engine and Search Keyword reports, you may have used the “Searches” metric to see how many

searches your site generated from each search engine and keyword. The Searches metric in these reports is really the Instances

metric with a different name. It acts just like the Instances metric and can be added to reports as needed. In fact, if you want to see

a SiteCatalyst “magic trick,” you can open a report like the one shown above for a custom eVar and then click to a Search Engine or

Keyword report and you can see the Instances column name magically change from Instances to Searches!

Instances = Product Views

This same concept applies to Product Views when looking at the Products report. When viewing a Products report, SiteCatalyst

renames the Instances metric to “Product Views.” I have seen many clients get confused when they see a new Success Event

named Product Views that they don’t recall setting!

Instances = Click-Throughs

Finally, the same concept applies to Click-throughs in the Campaign reports. Click-throughs is the Instances metric in the Tracking

Code report and all related campaign Classification reports.

So What?

So why am I telling you all of this? Unfortunately, there are times when the Instances metric can cause problems. The following are

some problems I have encountered and how you can avoid them.

Instances, as a metric, is not the same as a true custom or pre-defined Success Event (such as Orders or Cart Additions). True

Success Event reports have eVar values tied to them when the Success Event is set, but Instances does not. For this reason, as

you get more advanced in SiteCatalyst, you may choose to set custom success events instead of relying on the Instances metric.

For example, a long time ago, I was trying to create an eVar Subrelation report for a client so I could see credit card product views

broken down by City and Age, only to find out that it wouldn’t work since I was using the Instances metric. After thinking about it for

a while, it made sense since SiteCatalyst had Instances for City and for Age, but did not have a table defining the intersection of

City and Age for Product Views. To create the report that I was looking for, I needed a custom Success Event for Product Views

that I set when a visitor viewed a Product Page. Once this was in place, SiteCatalyst would assign the Age and City to that custom

success event and I can create subrelation reports to my heart’s content.

Another “gotcha” is that Instances metrics can wreak havoc on Calculated Metrics. This is due to the fact that Instances are tied to

the specific report you are looking at. At some point, you may have created a Calculated Metric and see a metric in the list that

says “Visits (Report-Specific)” and wondered what that meant. Using what we have learned here, you can see that what this is

really saying is that if you are in the Products report and you want to create a Calculated Metric that divides Registrations by

Product Views, where you are using the Instances version of the Product Views metric, you can do this, but when you open that

Calculated Metric in a Search Engine report, it will really be dividing Registrations by Searches (the Instances metric of that report).

In effect, the denominator in this formula will change based upon the report in which you are viewing the Calculated Metric. If you

were to add the same Calculated Metric to the City eVar report, you would be viewing Registrations divided by the Instances of

each eVar value (Chicago, New York, etc…) in that particular eVar report (I told you Instances can get confusing!).

Let’s clarify this through an example. Let’s say you are looking at the Natural Search Keyword report and viewing Searches and

Blog Post Views as shown here:

So in this case, the natural keyword “omniture” drove people to the site 60 times and resulted in 12 Blog Post Views. So now let’s

say that we want to create a calculated metric that divides Searches by Blog Post Views. Unfortunately, as shown below, when we

attempt to create the calculated metric, you will not see a “Searches” metric in the list since it is really the Instances metric for that

report:

However, since we see the “Report-Specific” in parentheses, we know that the numerator will change depending upon what report

you are in. Finally, if viewed outside of an eVar report (as a general calculated metric), the metric will default to Visits.

For both of the reasons above, just to be safe, I tend to set custom Success Event metrics for Instances metrics that I plan to use a

lot such as Product Views and Campaign Click-throughs.

Customizing Report Metrics [Inside Omniture SiteCatalyst] Sunday, 26 April 2009 @ 9:05, by Adam Greco

Every so often on Twitter, I see Omniture customers posting a variation of the same question:

How can I customize which metrics appear in each SiteCatalyst report?

The customer then goes on to say that every time they open up an eVar report, they always see metrics that mean nothing to them

or the dreaded “No Data Match This Criteria…” message which scares their users into thinking all of their data has disappeared! In

this post, I will show you a trick to make sure the metrics you want will show up every time you open up your eVar reports (and it is

not Default Metrics so keep reading!)

Default Behavior

By default, when you open an eVar report, SiteCatalyst shows the metrics selected in the “Default Metrics” area of the Admin

Console. In this post, I showed how you can change these “Default Metrics.” However, even knowing how to set these default

metrics will not always help you since those metrics are chosen for all eVar reports and often times you want to have different

metrics by default for different eVar reports. It is also important to understand that once you change metrics in any report using the

“Add Metrics” button, those newly selected metrics will override the default metrics for that SiteCatalyst session. Finally, for those

that see the “No Data Match This Criteria…” message, keep in mind that this is SiteCatalyst’s way of telling you that the metrics

currently added to the eVar report have no data. Changing the metrics to ones that do have data will resolve this issue. For bonus

points, keep in mind that if there is data for the selected metrics, but no associated eVar values, you will see the “None” row instead

of the message above.

Report Customization Trick

So understanding the preceding information, we can now move on to the trick to solve this riddle. Our goal is to setup each eVar

report with its own set of default metrics that will not be overridden by the default metrics or the metrics added to the preceding

report. As is usually the case, those who have kept up with this blog have already been educated on the tools needed to solve this

riddle, but may not know how to combine them to accomplish this goal. The two tools needed are Custom Reports and the Menu

Customizer. Here are the steps to customize metrics in Conversion reports:

1. Open a Conversion (eVar) report

2. Add/Remove the metrics that you would like all of your users to see when they open this eVar report (note that you can

add more than the three normally allowed!)

3. Make any other setting changes you would like to the report (i.e. graph type)

4. Save the report as a Custom Report using the icon in the toolbar (see below) being sure to name the report as you would

like it to appear in your menu structure (you can make it similar to the default eVar report name if you’d like)

5. Open the Admin Console and select the appropriate report suite(s) and navigate to the Menu Customization area

6. Hide visibility of the current eVar report in the menu structure

7. Drag the newly created custom report (found in the Custom Reports folder) to the eVar report area and next to the newly

hidden eVar report and save the changes

8. Repeat steps 1-7 for any other eVar reports for which you’d like to customize the metrics

Traffic Reports

While most of the questions I have received are related to Conversion reports, you can follow the same process to customize which

metrics appear in Traffic reports. Keep in mind that traffic reports generally have fewer metrics to work with, but the process is

identical.

Success Event Pathing [Inside Omniture SiteCatalyst] Sunday, 3 May 2009 @ 12:29, by Adam Greco

This week, I was working with a client and mentioned an idea that I have implemented at a few clients which I call Success Event

Pathing. This is just a concept that I thought up and is by no means a proven “best practice,” but I thought I would describe it here

and see what you all think about it. Please review the concept and add a comment below stating if you like it or hate it…

What is Success Event Pathing?

As described in the Success Event post, Omniture customers set SiteCatalyst Success Events when visitors perform an action on a

website (or within a widget). We use these Success Events to measure how well our online property is performing against

predefined business goals. However, for those who are designers or information architects of an online property, sometimes we are

less concerned with how often something happens as we are in when it happens. For example, if the goal of our website is to get

visitors to view videos and read blogs, in hopes that they will submit a lead generation form, it would be interesting to understand

the order in which visitors perform these actions. The order these events take place may impact the way we design navigation or

think about the various levels of the website. We may have questions such as:

1. What is the first Success Event visitors tend to take?

2. What is the most common order that all visitors perform our website Success Events?

3. What is the success event most often performed directly before our primary “money” Success Event?

Below is an example that will show you what Success Event Pathing looks like when implemented. Let’s imagine that you have

Success Events for Blog Post Views, Video Views, Product Views, Newsletter Sign-ups and Lead Generation Form Submissions.

Once implemented, you would like to see pathing reports showing the pathing order as shown here:

Determining the order in which Success Events take place using page-level pathing can be very difficult since the same Success

Event can take place on many different pages (i.e. Product Views) and many pages don’t have any Success Events. Therefore, my

concept is to provide Success Event Pathing which is a pathing report that only contains entries representing your website’s define

Success Events so you can see, at a 20,000 foot level, how visitors perform these actions. Make sense?

Implementing Success Event Pathing

So how do you implement this idea? Well the first step is to make sure you have properly tagged all of your site Success Events.

Once this is done, you have to pass the name of the Success Event to a Traffic Variable (sProp) on the page in which it occurs.

There are a few ways to do this:

Use JavaScript to look for a Success Event being set and pass a predefined name to the new custom sProp at that time

Use a VISTA rule to set the custom sProp value when each Success Event takes place

Regardless of how you set it, the ultimate goal is to simply add a value (name) to the custom sProp for each Success Event that

makes sense to you and your users when the Success Event takes place. Once completed, speak to your Account Manager or

ClientCare and have pathing enabled for that sProp and you will be able to see reports like the one above. As is always the case

with pathing, keep in mind that the reports are for Visits only (not across multiple visits). If you need to see this information across

visits, please speak to your Account Manager who can put you in touch with our advanced solutions team. Finally, if the same

Success Event takes place on more than one page and you have a need to differentiate between them, you could concatenate the

pagename and the Success Event into the sProp (or a second sProp).

That’s it. Useful? Worthless? Please let me know what you think?

Foreign Language Reporting [Inside Omniture SiteCatalyst] Sunday, 10 May 2009 @ 12:04, by Adam Greco

Recently, I received the following question from a blog reader:

We offer our website in multiple languages, as such we want to track which language a user was viewing on a particular page.

There is no URL difference, as that value is stored in session. What is the best practice for recording this metric, and reporting on it?

Can the real time reports in SC 14 make use of this metric as well (example: Page view per day by language)?

Therefore, I thought I would answer this question here in case any of you out there are in a similar situation and offer website

content in multiple languages.

Se Habla Español? Parle Italiano?

As we move to a global marketplace, providing content in multiple languages is becoming more and more common. However,

adding foreign language capabilities to your website can be a difficult, time-consuming effort. Hence, over time, you might want to

use SiteCatalyst to see if these efforts are paying off or if adding this functionality is not contributing to the bottom line. The

following will show how I have dealt with this in the past.

Pagenames and Pathing

The first item in this area I tackle is the Pagename variable since it is so important and drives page-level pathing. Obviously, the

first question here is whether you should have a different page name for each page in each language. While I can see reasons for

doing this, I am a strong believer that you should have only one pagename for each page - regardless of which language it is in.

This allows you to see the true pathing of pages without regard to language. Another reason I advocate this is based upon the

simple fact that you may have 20,000 pages on your site and if you translate them all into 10 languages you will now have 200,000

pages to deal with in your pages and pathing reports!

However, I concede that there may be cases where you want to see how visitors looking at pages in Spanish differ from those

looking at pages in Chinese. The easiest way to do this is to use Omniture Discover where you can easily segment on a language

variable and then view the pathing reports differently for each language (or even combine a bunch of languages together!). But if

you are not fortunate enough to have Omniture Discover, there is still a way to see pathing differences by language. To do this,

simply concatenate the language and the pagename (i.e. spanish:home page) and place that value into a new custom Traffic

Variable (sProp) and enable pathing. Doing this will allow you to find any page in any language and then view pathing behavior

taking place before/after that page as shown here:

Success Events by Language

The next question I get from customers is to show them which of their website Success Events take place in each language. For

example, of all lead forms that are filled out, how many were submitted by a user using the Spanish language pages. While you can

derive this information by looking at various page reports as described above, the easiest way to do this is through the conversion

area. On each page, simply set a Conversion Variable (eVar) with the value indicating in which language that page is being

viewed. By having this value in an eVar, you can the open up that eVar report and add any Success Event metric you wish and see

the percentages associated with each language as shown here:

Pages by Language

There are two other “traffic” related items that I like to show clients related to languages. The first is which pages are most often

viewed in multiple languages. To do this, I pass the language the page is being shown in to a Traffic Variable (sProp) and then

create a Traffic Data Correlation between it and the Pagename variable. For the former, I simply pass the same value being passed

to the eVar to a custom sProp. Once you have this done, you can use the correlation to find any page on your site and then break it

down by language to see how often it is viewed in each foreign language as shown here:

The final thing you can review is how many pageviews and/or visits involve foreign languages. Using the same sProp describes

above, you can open up the sProp report and use Pageviews or Visits (if enabled) as metrics to see the overall usage of each

language as shown here:

Any other cool things you have done to answer questions related to foreign languages? If so, please comment here…

Video Reporting 101 [Inside Omniture SiteCatalyst] Sunday, 17 May 2009 @ 12:32, by Adam Greco

Editor’s Note: This post was written by Omniture Consulting’s video guru’s!

Over the past 12-18 months, video has quickly become one of the fastest growing and effective forms of rich media on the internet.

And just like all other online marketing opportunities, it should be monitored and optimized to maximize your return on investment.

In this post, we’ll provide insight not only into the importance of online videos but also how Omniture can help you extract maximum

ROI.

Why Online Video Reporting?

Why is online video so important to your online business? For content providers, such as media companies, video provides a

lucrative monetization stream as well as a rich engaging tool for visitors. Pre-roll advertisements, for example, command higher

CPM’s than their static content counterparts. Knowing how much video is consumed, what the optimum video length for your

audience is, and which parts of your video are most watched allow you to optimize your ad sell space.

Retailers use video for product review or demonstration purposes, with the hope that customers who view videos will become more

likely to purchase a product or service. Service providers can use video to reduce support costs by providing an informative, highly

engaging self service support tool. The same can be said for any number of online businesses with goals including lead generation,

micro-conversions, and brand awareness. Knowing which of your videos lead to the most online conversions can allow you to

effectively allocate money and resources creating them.

Clearly video can be an important part of your online strategy, and Omniture can help you make the most of it. Though not an

exhaustive list, here are a few critical questions that Omniture SiteCatalyst can help you answer:

Most Popular Videos/Video Categories

What are my most popular videos or categories? The report below tells you at a glance which videos are your most popular for the

specified time period. You can also see that average view time and how many users watch 70-100% of your video (the reporting

percentage displayed can easily be configured). If you notice that a video is very popular but has a poor completion rate, then that

video may need to be shortened or the video title may not match your user’s expectation what the video should be.

In addition to video views, other metrics like video visits tell you how many overall visits to the site included at least one video view.

And like most other Site Catalyst Variables, you can classify on the video title so that you can report these metrics by relevant

categories like topic, video creator, publish date etc.

Optimal Video Length

Are my videos the optimal length for my audience? Continuing the example above, let’s say that you notice a popular video has a

particularly low completion rate. To determine why, you could pull a video segments viewed report to see where the drop off

occurs. In the report below, it looks like more than half of the audience drops off within first 30 seconds of the video. Past the 30

second mark the remaining audience tends to stay to the end. What is it about the first 30 seconds of our video that could be

contributing to this drop off? Are all the points of interest in the first 30 seconds of the video? Perhaps there’s a technical issue that

makes the video jerky or load slowly. Is there a critical mid-roll commercial that contributes to abandonment? These are all

questions that we can investigate further for our key videos.

Video Contribution

Do my videos contribute in a positive way to my site success? The report below shows which videos were viewed in the same visit

as a purchase. Site Catalyst allows you to attribute revenue anywhere from the last video viewed or up to the last 10 videos viewed

before the purchase.

Viral Video Tracking

If I have videos that I put out on popular video sharing sites such as YouTube, Viddler, and Yahoo! Video, can I know how widely

they are being viewed in an easy fashion? SiteCatalyst can help here as well. Omniture has just announced an exclusive new

feature that is now available as a beta to the general Omniture customer base. This new tool that allows you to monitor your videos

across all the popular video sharing sites and, in one report, see the total number of views. You can also create custom video lists

that you want to track. If you are interested in joining this Beta program, please contact your Omniture Account Manager or

Consultant for more details.

Getting Started

So how do you get started? The answer to this depends on your media player and how custom you need your implementation to

be. Omniture code can be used to track any Quicktime, Windows Media, or Real Player videos. Plus SiteCatalyst can be used to

track flash based video players, including any third-party vendors (such as BrightCove and Maven) that allow their customers to add

custom code their players.

To get started, log into Site Catalyst then go to Supporting Docs>> Manuals. The first entry under the Implementation Guide

column is the Media Tracking and Action Source manual. This is a manual that will give you direction on tracking videos, using both

JavaScript and Flash, in addition to tracking flash applications in general. You can also search the knowledge base for any white

papers that may be helpful. See the Media Tracking manual for more details on what kind of effort would be involved for your

particular player.

How custom does your video implementation need to be? If you only need to see video data within the video reports of

SiteCatalyst, then a basic implementation should be enough for you. However, if you want to see more granular video data or that

data in relation to your other custom eVars, props, and events, then a little more customization should be done. You can learn more

from the implementation guide.

Finally, how much will this cost? Video tracking is based on the number of server calls being sent to Omniture. There is no cost to

enable the video reports in your report suite or to obtain the code from your Account Manager or Consultant. The only incremental

cost is the additional number of server calls sent during video play. As part of the out-of-the-box tracking option, a server call is sent

at video begin and end (2 server calls per complete video watched). To get more granular viewing information, we recommend that

you send update server calls throughout video play. You can send as few or as many as you like. The more frequent the updates,

the more detailed that data and vice versa. Omniture code allows you to send updates at custom percentage complete milestones

(such as 25%, 50%, or 75%) or for number of seconds watched (every 30 seconds, for example). So the number of server calls

sent in per video is completely dependent on the cost benefit of additional server calls per video view. Other factors such as video

length, video content, and your audience will help determine the right number of server calls per video for your site.

As always, you can engage with an Omniture Consultant for more advanced help and to discuss options related to pros/cons of

more granular video tracking.

The Mobile Opportunity [Inside Omniture SiteCatalyst] Thursday, 24 May 2009 @ 15:12, by Adam Greco

Author’s Note: This post was written by our advanced mobile team…

For years mobile has been touted as the next big opportunity. Now with 1 billion mobile applications downloaded from Apple’s iTunes store, 3G topping 25% of total subscriptions in Europe and the United States (80%+ in some parts of Asia), and worldwide Smartphone sales comprising 12% of all handset sales, businesses around the world are scaling up their mobile investments. If your enterprise isn’t currently investing in mobile or has recently launched mobile initiatives here’s one approach to determ ining if the timing is right for your organization to start investing:

Estimate Opportunity Size/Gauge ROI

Many businesses begin investing in mobile by rolling out a mobile optimized version of their site. To take this step, you will need to justify the opportunity cost and ROI. Here’s a simple way to size the opportunity for your business:

Step 1: Log in to SiteCatalyst and pull total page views for the site in question. You will want to make sure the date range is

sufficiently narrow to factor out recent growth in the market but wide enough to account for daily fluctuations. A range between one and four weeks should be OK. Total page views for the comparison week (4/12-4/18) were 134,499.

Step 2: Navigate to the mobile device reports for the same site and date range and pull the total page views for a specific Smartphone with good JavaScript support. For the purposes of this example, we’ll use the iPhone.

During the comparison week (4/12-4/18) page views generated from iPhones were 1,340.

Step 3: Estimate iPhone market share for your industry and demographic. A recent Gartner report puts iPhone sales at 13% of total

smartphone handset sales. Based on data from Omniture customers, page views from iPhones are running between 10% and 20% of total page views.

Step 4: Estimate the mobile optimization opportunity by dividing iPhone page views by estimated market share for the iPhone:

1,340/.15 = 8,933.

Step 5: Estimate the mobile segment size by dividing the mobile optimization opportunity size by total pageviews: 8,933/134,499 = 6.6%.

Step 6 (Optional): Repeat Steps 1-5 for subsequent date ranges to discover the mobile adoption trend for your business.

In this example, launching a mobile optimized version of the site will positively impact the user experience for over 6% of the page views. Estimating the optimization opportunity can also be performed for other performance indicators (e.g. revenue, leads, etc.) using the same methodology. Given the poor experience visitors coming to the site on a mobile device may be having, the lift to KPIs for your business may be significant. For example, at one site I visited recently using a mobile device; I was prompted to “upgrade my browser” and was unable to proceed past the warning.

As a caution, using the steps above to estimate the mobile optimization opportunity will understate the true opportunity because (1) accelerating future growth is not factored in-consider the chart below where the customer’s mobile views climbed 73% in five months (2) mobile promotion efforts may quickly extend the opportunity beyond current levels-for some customers, mobile drivers to key KPIs account for more than 30% of the total.