(Estimated Time to Read this Post = 5 Minutes)

Unless your website is very basic, odds are that you use some sort of navigation to help visitors find website content.  Usually navigation is in the header or left side of web pages.  Inevitably, there will be times when you are asked how often and in what ways visitors are using navigation.  In this post I will cover some common navigation questions and how to answer them.

Common Questions
So what are the common questions you may get around navigation.  Here are some that I have been asked over the years:

1. Which individual navigation links are clicked the most?
2. Which navigation areas are clicked the most?  This is usually related to the main section area, not individual links.
3. From which pages are visitors using each navigation link?
4. For what percent of website visits is navigation used?
5. In what order do website visitors use navigation links?
6. Which navigation links lead to key website success milestones being accomplished?

The following will show how to answer each of these questions:

Which individual navigation links are clicked the most?
In this scenario, people are looking to see which detailed navigation links are clicked the most.  In the image below, this would represent such links as “Sales Cloud 2,” “Service Cloud 2,” “Custom Cloud 2,” etc…

To answer this question, you should have your developer write code that will pass the name of the link to a Traffic Variable (sProp) when a visitor clicks on each link in your navigation.  In addition, I highly recommend that you have them include the high-level navigation area in the value passed to the sProp.  For example, when a visitor clicks on “Sales Cloud 2″ in the example above, I would pass the value of “products:sales cloud 2″ (I always use lower case since sProps are case-sensitive) to the sProp.  Passing the high-level area will ensure that your data is clean as there are times when the same link can occur more than once in a navigation structure.  When this is complete, you can view a report that looks like this:

Which navigation areas are clicked the most?
In this question, people are generally asking to see (in the example above) if the “Products” section is clicked more than the “About” section and if so, by how much.  The good news is that if you have done the previous step correctly, you can answer this question by creating a SAINT Classification which rolls up the values in the preceding report into higher-level buckets.  You can create this classification easily by exporting the above report to Microsoft Excel and splitting the column by the separator and using the first part as the high-level navigation name.  Here is what your SAINT file might look like:

After you create and process this SAINT file you will be able to see a new high-level navigation report that looks like this:

From which pages are visitors using each navigation link ?
In this scenario, people at your company may want to know what is the most common top navigation link clicked from the home page or from another page on your site.  To see this, you need to have setup a Previous Page sProp.  This sProp passes the name of the previous page to the current page which allows you to create Traffic Data Correlations between it and any other Traffic variable.  In this case, once we have a Previous Page sProp, we can correlate it to the Top Navigation Link sProp shown above to see what navigation links are clicked from each page.  For example, I can open up the Previous Page sProp within a report suite and then break it down by the new Top Navigation sProp…

…to see a report like this:

In this case, we can see that the “customers:india customers” Top Navigation link was only clicked 482 times from the home page.

In addition, since this uses a correlation and correlations are bi-directional, you can also use this to find out all of the pages from which visitors clicked on a specific navigation link:

In this case, we can see that the “customers:india customers” link was clicked a total of 957 times and then see the breakdown of pages visitors were on when they clicked it.  This can help your content people understand when visitors are reaching for the navigation…  Finally, if you look closely, you can see that the “SFDC:in:homepage” shows the same 482 clicks referenced above, but in this case we can see that it accounts for 50% of all clicks this link gets across the entire website…

For what percent of website visits is navigation used?
In some cases, you may be asked how often website navigation is used (in general).  One easy way to figure this out is to look at the the total Page Views from the first SiteCatalyst report shown in this post and divide it by the number of website Visits.  This can be done easily using the ExcelClient where you can pull a Visits data block and the report above and divide the two.  However, if you think you might need this on a recurring basis and if trending is important, I will show you another way to do this.  When visitors click on navigation links, in addition to passing the link name to a Traffic Variable as shown above, set a “Navigation Clicks” Success Event.  Once you have a Success Event, you can create a Calculated Metric that divides Navigation Clicks by Visits as shown here…

…which will allow you to see a report like this:

In what order do website visitors use navigation links?
If you are redesigning your navigation, a useful piece of data is the order in which visitors click on navigation links.  Do they always click on the first items in the list?  The ones that are farthest to the left?  Fortunately, if you have implemented the items above, you can see this by simply enabling Pathing on the new Navigation Links sProp created above.  This will allow you to view the Pathing reports including a Next Page Flow and Previous Page Flow just for navigation items:

Which navigation links lead to key website success milestones being accomplished?
Finally, I will occasionally be asked which navigation links are contributing to success.  To answer this question, all you have to do is enable Participation for your key metrics on the Navigation links sProp described above.  This will allow you to add a Participation metric to the first report shown above to see which links were in the flow of your key website Success Events.

Final Thoughts
Well, there you have it.  Everything you wanted to know about tracking your website navigation, but were afraid to ask!  If you have any comments/questions, use the form below.

Adam Greco is the Director of Web Analytics at Salesforce.com.  You can read his previous Inside Omniture SiteCatalyst blog at http://blogs.omniture.com/author/agreco/ and can follow him on Twitter at http://twitter.com/adamgreco.  You can also hear Adam on the BeyondWebAnalytics podcast.  Please send questions and comments to adam@the-omni-man.com.

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

(Estimated Time to Read this Post = 4 Minutes)

If you are in the Web Analytics space, besides tracking what people do on your website, hopefully you are actively doing testing and content targeting to try and improve your conversion.  If you are an Omniture customer, you might be using their Test&Target product or you may be using Google’s Website Optimizer.  If you are just getting into the testing area, you may simply be using an eVar to see how your tests are performing.  Regardless of what tool you are using, there is a common question that arises in the testing/targeting area.  Here is the scenario:

1. You come up with a great hypothesis you want to test
2. You run a test and see awesome results (say a 10% uplift in conversion)
3. You broadcast it to your company only to hear the inevitable “well that was just a test…how do you know we’ll see the same result in real life?”

As a web analyst, this can be infuriating and can be compounded by the fact that you often cannot simply run with the winning recipe and show the results in your testing tool because:

• You may be running multiple tests and things can get confusing
• You may want to apply what you have learned from the test to many places on your website which may or may not have the required “MBoxes”

In reality, it may take time for you to take your awesome test and let it out “into the wild” and when you do so, how can you prove that the uplift you saw in your test will actually occur over the next year on the website?  The following will tell you exactly how you can do this and hopefully put the naysayers in their place!

How To Prove Your Test Results
So now that I have framed the situation, let’s learn how to do it.  Our objective is to prove the long-term results of a test we did using our chosen testing/targeting tool.  In this example, let’s imagine that your website has twenty forms on it and you have just done a test showing that if you reduce the number of fields on a form, you can see a 15% uplift in Form Completion Rates.  This test was conducted using Test&Target for three weeks with a high level of statistical confidence (+95%).  Now you want to go ahead and take five of the twenty forms and remove the same fields you did in the test for the next three months and see what happens.  One way to do this would be to add lots of “MBoxes” and use Test&Target to deploy the winner in hopes of seeing the same lift results, but in this example, let’s assume that your conversion team has closed the books on this test, moved onto other tests and has told you that you now need to work with the web team to reduce the fields on your five forms.

So what do you do?  How will you know if these five forms will really see a 15% uplift over the next three months?  All you need to do is the following:

1. Create a new Testing eVar (not the T&T eVar)
2. On each of the five forms you modify on your website, pass in the name of the the test that it was based on to this new eVar.  This may be the name of the winning T&T recipe or you can use any descriptive name you’d like.  In this case, we’ll pass in the value “Remove Form Fields Test”
3. Set the eVar to “Most Recent Value” and expire “Never” in the Admin Console

That’s it.  Now when you open this new Testing eVar report, you can see how these five new forms are doing with respect to Form Completion Rate (assuming you have the right Success Events set – in this case Form Views and Form Completes).  When you look in this new eVar report, all forms that were not modified based upon a testing initiative will fall into the “None” row so you can easily compare those forms that are based upon testing with those that are not:

In the preceding example, we can see that the “Remove Form Fields Test” seems to have about a 17% uplift in Form Completion Rate after it was fully deployed so we are doing even better than the 15% expected!  What’s better, is that if you repeat this process every time you make changes to things on your website based upon testing, you can see how each is doing:

And, if you look at them all together, you can show your boss at the end of the year how much uplift you have been responsible for overall!  In this example, if we look at all of the tests we have implemented, we are seeing a cumulative uplift of 16.2% over forms that are not based upon any testing.  This is a great way to show the value of your conversion efforts and justify more headcount, get promoted, get more budget, etc…  In fact, you can show your boss, that if all of the “Form Views” on your website were, in this case, seeing optimized forms, you could produce 5,800 Form Completes instead of the 5,000 you are currently getting at the lower Form Completion Rate.

The only downside of this solution is that it might actually show you that something you expected to have an uplift, in reality didn’t.  For example, in the preceding screen shot, the “Form Headline Bold” change doesn’t seem to be pulling its weight (losing against the control)  and may need to be revisited.  However, even though this is disappointing, it is great information to have since it might prompt you to do some further testing in Test&Target and abandon the losers.

Finally, if you want to get a little more advanced, you could also apply SAINT Classifications to this new Testing eVar and group your tests into types (i.e. “Field-Related Tests” or “Color Related Tests”) so you can calculate the uplift of each type and see which ones you may want to focus on going forward.

Final Thoughts
So there you have it.  As a rule of thumb, I would build a step for passing in the Test Name a change was based upon into a Testing eVar into your conversion testing process so that you can look at how your tests ultimately perform.  While this will add one small step to your overall process, I think that in the long run you will be happy that you have this variable to show how your team is doing…

Adam Greco is the Director of Web Analytics at Salesforce.com.  You can read his previous Inside Omniture SiteCatalyst blog at http://blogs.omniture.com/author/agreco/ and can follow him on Twitter at http://twitter.com/adamgreco.  You can also hear Adam on the BeyondWebAnalytics podcast.  Please send questions and comments to adam@the-omni-man.com.

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

Recently, Omniture released its latest version of SiteCatalyst (version 14.7) in which there were a bunch of new features added.  Below are a few links to other blog posts that describe some of these new features:

• New Dashboards
• Day of Week Trending, New User E-mails, Default Dashboards, Transfer of User Settings

However, one of my favorite new features was the addition of Alerts on Classifications.  In the past, you could set Alerts on Success Events and on eVar and sProp values, but not on Classifications of those eVars and sProps.  While this new feature doesn’t sound all that impressive, it can be quite powerful.  In this post I will demonstrate how it can be used.

Example – Traffic Driver Type Classification
For the purposes of this post, let’s imagine that we have an eVar or Campaign variable that captures individual Traffic Drivers (Sources).  These sources of traffic might be SEO keywords, Paid Search Keywords, E-mail links or clicks from Social Media sites.  However, in this case, we don’t want to be notified every time there is a increase/decrease for a specific Traffic Driver, but rather, we would like to know if there has been a significant change to one of the higher level types (SEO, SEM, Social Media).  Before this new version, doing that would be basically impossible, but this is easy now if you have used SAINT to classify your individual Traffic Drivers.

Let’s say that your boss wants to be alerted if there is a significant change in Social Media referrals to the website from one week to the next.  To be alerted about this, you would simply open up the Classification version of the Traffic Driver report (we’ll call it Traffic Driver Type) and click the Alert icon.  Doing this brings up the screen below which is basically the same as the Alert screen you may have used previously.  Once here, you can give your Alert a name, choose the time frame, pick your metric and then select the specific item you want to be alerted about (in this case I have selected Social Media).  Next, you set the type of Alert – in this case I have chosen a percent change of over 15% and then tell SiteCatalyst how you woudl like to be notified (e-mail or mobile device).  That’s it!

Other Uses
There are an infinite number of ways you can use this powerful feature.  Here are just a few that I can think of off the top of my head:

• Classify internal search terms into buckets and be alerted when a specific type of keywords hits a threshold or changes significantly
• Classify countries or cities into regions and be alerted when a metric related to a specific one changes
• Classify search engine keywords into Branded/Non-Branded and be alerted when each changes significantly
• Classify videos viewed on your website and be notified when a video type changes significantly
• If you are using the Omniture Twitter Integration, all of the Twitter data points are based upon Classifications so you can set an Alert when a particular person Tweets or if a specific Twitter keyword experiences a spike

These are just a few examples, and I am sure you will find many ones unique to your business that can prove beneficial.

Now, if only Omniture could combine this new feature with this future idea, then we will really be in business!  In the meantime, if you think of some really interesting ones, feel free to leave a comment here…

Adam Greco is the Director of Web Analytics at Salesforce.com.  You can read his previous Inside Omniture SiteCatalyst blog at http://blogs.omniture.com/author/agreco/ and can follow him on Twitter at http://twitter.com/adamgreco.  You can also hear Adam on the BeyondWebAnalytics podcast.  Please send questions and comments to adam@the-omni-man.com.

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

[Warning: Some elements of this post are meant for advanced SiteCatalyst users so read at your own risk!]

Last week, Ben Gaines (@OmnitureCare) wrote a great blog post about the getPercentPageViewed JavaScript plug-in, which he had demonstrated in his Summit presentation.  This plug-in is very fun and I have enjoyed using it.  While this topic is fresh in people’s mind, I wanted to throw out some additional/advanced uses of this plug-in in case they are relevant to those out there using it or thinking about implementing it.

Beyond % of Page Viewed
When I first started using the aforementioned plug-in, my goal was like most, to see the total % of each website page that my visitors viewed.  I found the Browser Height report to be too limiting (shows pixels, not % of page viewed) and this plug-in helped provide some additional insight.  However, after using the plug-in, and correlating % of Page Viewed to pages, I realized that there were a few more things that could be done with this concept.  The next question that popped in my head was “I wonder what % of the page, for each website page, can be attributed to scrolling?”  After all, the % Page Viewed plug-in really only shows you how much of the page they saw in total, but not how much of the page they initially saw vs. saw because they scrolled.  This line of thinking drove me to ask what else could be learned from this plug-in such as:

1. Total % of Page Viewed by Page Name
2. % of the page that users tend to scroll by Page Name
3. Initial % of Page visitors tend to see before they start scrolling (to get around the pixel limitation of the Browser Height report)

As I mentioned earlier, Ben’s post covered item #1 above, so in this post, I will show you how to solve items #2 and #3.

How Much Are Users Scrolling on each Page?
To see how much visitors are scrolling on each page, I asked my developer if he could calculate the actual % of the page that users scroll through the plug-in.  Through his supreme awesomeness, he told me that he could.  That meant that we would have the total % of the page that was viewed and the % representing scrolling (both available on the next page as described by Ben).  From there, we decided that we would concatenate the two values into an sProp.  This means that the sProp Ben described would be slightly different such that instead of having raw number values (i.e. 100, 95, 56, etc…), it would have two values concatenated together as shown below [TOTAL % OF PAGE VIEWED]|[TOTAL % VISITOR SCROLLED]:

(Before you get scared, bear with me as I will show you how to deal with these strange looking values in the next few paragraphs!)

Once you have these concatenated values in the sProp, it is time to classify them using SAINT Classifications.  To do this, you create the following classifications of this sProp:

• Total % Page Viewed.  This is the first of the two values and this classification replicates what Ben blogged about.
• Scrolling %.  This is the second value and represents the % of the page the visitor scrolled to see.

When you are done with this, you can see the report Ben showed in his post, but can now see the following additional report:

Through this clever classification, you can see how often people on your website tend to scroll.  In this case, it looks like 73.2% of visitors don’t reach for that scroll bar!  However, as Ben stated, all of this data is more valuable when viewed by Page Name.  Since this Scrolling % report is really a classification of an sProp that is correlated to the Previous Page Name sProp, any classifications of it will also be correlated to Previous Page Name (if you understand that in one reading you are a true SiteCatalyst ninja – if not, re-read it a few times).  This means that you can break the above report down by Page Name, or in other words, you can look at any page on your website and determine how often visitors are scrolling.  To do this, simply open your Previous Page Name report, find the page you care about, and break it down by the Scrolling % (classification of the Percent of Page Viewed sProp).  In the following example, we can see how much visitors scroll when looking at the Home Page:

In this case it looks like about half of the time visitors are scrolling on the Home Page.  Finally, if you want, you can bucket these Scrolling percentages into more meaningful groupings by adding additional SAINT classification columns as Ben described.

What % of the Page Do Visitors See Upon Page Load?
So the other thing I wanted to see was the percentage of the page that visitors see before scrolling.  I don’t like looking at Browser Height pixels, but would rather simplify things and see the exact % of the page my visitors are seeing – period!  Unfortunately, there is not an easy way to do this in SiteCatalyst.  However, when I was looking at the above items in this plug-in, I realized that the answer to this question was a side-benefit of doing the SAINT Classification shown above.  Think about it…we have the Total % of the Page Viewed and the Total % that visitors scrolled, both concatenated in an sProp as shown above.  If you subtract these two values, you are left with the percent of the page that visitors saw before scrolling (in other words, upon page load)! For example, if the value in the sProp is “58|10″ (see first row of example above), then we know that the visitor saw a total of 58% of the page and they scrolled 10% of it, so they must have seen 48% of it initially (good thing web analysts like math!).

Therefore, when you are classifying the sProp shown above, you can add a new Classification of the Percent of Page Viewed sProp named “Initial % of Page Viewed” and simply subtract these two values and add that as a new classification (no new data to collect!).  When you do this, you end up with a new report that shows you the total % of pages visitors tend to initially see like this:

Here we can see that, in general, about 60% of visitors are essentially seeing the entire page without having to scroll.  Again, we can group these values into more meaningful buckets using SAINT, but the real power is seeing this Initial Page Viewed % classification by a specific Page Name.  Again, using the Home Page as an example, the following report shows how much of the Home Page most visitors see before scrolling:

What’choo Talkn ‘Bout, Willis?
OK…I know this sounds complicated, but really all you need to do is slightly modify the code (see below) that Matt Thomas  (of Omniture Consulting) created and that Ben alluded to in his post to add one concatenated value (% Scrolled).  The majority of the hard work is in building the SAINT classification file to get all of these cool, new reports.  Well the good news there is, that I have already created the file which you can use as a starting point for these extra reports.  All you have to do is to download it by clicking here (save .TAB file to your hard drive).  Simply save this file and add the values to your own SAINT template after you have created the Classifications mentioned in this post.

So there you have it…a few additional ideas for you to ponder while you have % of Page Viewed on the brain…  If you have other ideas or questions, please leave a comment here…Thanks!

FOR OMNITURE GEEKS ONLY!
Here is the “enhanced” JavaScript code that modifies the great code that Matt Thomas (from Omniture Consulting) created and is in the Omniture KnowledgeBase.  This is not currently supported by Omniture so use at your own risk!

Adam Greco is the Director of Web Analytics at Salesforce.com.  You can read his previous Inside Omniture SiteCatalyst blog at http://blogs.omniture.com/author/agreco/ and can follow him on Twitter at http://twitter.com/adamgreco.  You can also hear Adam on the BeyondWebAnalytics podcast.  Please send questions and comments to adam@the-omni-man.com.

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

Last week I shared a way to capture the various traffic sources (i.e. SEM, SEO, E-mail, etc…) so you could calculate the Bounce Rate for each of these Traffic Source types.  In this post I am going to build upon this and show you another cool way you can leverage this to have what I call Cross-Visit Traffic Source Attribution.

What is Cross-Visit Traffic Source Attribution?
As an online marketer, one of the things I want to see is how each traffic source leads to online success.  Within a visit, it is relatively easy to see which Traffic Source types lead to success.  Normally this is done by capturing the various campaign elements and using SAINT Classifications to roll these up into Traffic Source types.  However, what many marketers want to see is the overall mix of Traffic Source types that lead to success over several visits.  For example, maybe Paid Search is always the last thing your visitors are doing before placing an order, but maybe the first thing they did was to click on an SEO keyword.  I touched upon this a bit in an old blog post on Cross-Visit Participation which you can review here.  If your organization has a desire to see a high-level view of which combinations of Traffic Source types lead to success, then Cross-Visit Traffic Source Attribution may be your answer.

Implementing Cross-Visit Traffic Source Attribution
If you have followed the instructions I laid out in my last blog post, then you have already done much of the work required to enable this feature in your SiteCatalyst implementation.  Now that you have an sProp that contains the Traffic Source type set on the first click of each website visit, all you have to do is the following:

1. Pass this value to an eVar (Most Recent Allocation)
2. Implement the Cross-Visit Participation plug-in
3. Have the eVar expire when your primary success event takes place (i.e. Orders)

As a refresher, the Cross-Visit Participation plug-in stores a list of elements, in this case Traffic Sources, with each visit so when a Success Event takes place, you can attribute the success to the current string of cross-visit values.  For example, if someone comes to your site three times, first from SEO, second from E-mail and third from SEM and then places an order, the current value in the eVar would be “SEO|E-mail|SEM.”  As time goes by, and you have more website visitors, the combinations that occur most frequently will rise to the top (web analytics darwinism?).  Usually the single Traffic Sources will be at the top (i.e. SEO by itself or SEM by itself), but what I look for are the combinations that are at the top of the list.  I sometimes even hide the individual items using the advanced search feature (Tip=Show if it Contains “|”) so I can see only multiple session Traffic Sources:

The only warning I will give about using this functionality is that it might burst the bubble of some of your co-workers who think that their Traffic Source type is the “end all, be all” of success.  In my experience, many people bounce around quite a bit and the results can surprise you!

First Touch, Last Touch
When it comes to attribution, many talk about First Touch, Last Touch and All Touch, meaning which Traffic Source was the first that visitors saw in a sequence leading to success, the that visitors saw last or a list of all of the Traffic Sources that influenced the success.  In SiteCatalyst, the easiest way to implement First Touch and Last Touch is to use two separate eVars.  Both capture Traffic Sources, but one has Original Allocation and a long expiration (never or say 6 months), while the other eVar is set to Most Recent Allocation and expires at the Visit.  However, you can also use the new Cross-Visit Traffic Sources eVar shown above to do this.  Simply download the above report to Excel and then isolate the first Traffic Source or the last Traffic Source and add up the Orders (or use a Pivot Table) to see the total for each Traffic Source.

Traffic Source Influence (All Touch)
For me however, I am most interested in seeing the total influence of a specific Traffic Source (All Touch).  While this is not readily available in SiteCatalyst (since Linear eVar Allocation only works within one visit), you can use the new eVar mentioned above to quantify the potential impact/influence of a specific Traffic Source Type.  Here is how you do it:

1. Download the report above to Excel (you decide if you want to include the single Traffic Sources or only when multiple exist – as shown above)
2. Use an Excel Formula to set the Traffic Source Type for a specific Traffic Source Type (i.e. SEO) in all rows where it is found (see green column below)
3. Create a Pivot table off this new column (i.e. SEO) and look at the total Success Events (Orders in this example) that are associated with a row that contains the Traffic Source Type you chose in step two (in this case 754,328)
4. Take that total (i.e. SEO Influenced Orders in this case) and divide it by the Total Orders (in this case 76.07%).  This will show you how much SEO influenced Orders such that SEO was involved in a visit that ultimately led to an Order.

Finally, if you want to see Cross-Visit Attribution of individual Campaign elements (Tracking Codes) instead of Traffic Sources, you can apply the same principles shown in this post and my last post.

Hopefully, between this post and my last post, you will be able to answer the nagging Traffic Source questions that come up from time to time and help your organization better understand where it should use its precious marketing dollars…

Adam Greco is the Director of Web Analytics at Salesforce.com.  You can read his previous Inside Omniture SiteCatalyst blog at http://blogs.omniture.com/author/agreco/ and can follow him on Twitter at http://twitter.com/adamgreco.  Please send questions and comments to adam@the-omni-man.com.

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

One of the holy grails of online marketing teams is to find a way to track and measure a company’s Brand Awareness.  There are many different approaches to do this including the use of products like comScore, Compete, Twitter, but more often than not, it takes place offline in research studies.  While this trend is not going to change anytime soon, as a web analyst, you may be looking for data that you can collect to provide an estimate of your Brand Awareness.  Therefore, in this post, I wanted to share a “quick and dirty” way to use online data to see and trend the popularity of your company brand.  While this will not be a comprehensive approach, it might provide a basic starting point into the larger “Brand Awareness” puzzle.

Why Track Brand Awareness?
There are many schools of thought on whether it is even worthwhile to try and track Brand Awareness.  While people like us try to track everything, sometimes, there are things that are just not meant to be tracked.  If you own a website that sells stuff, then there is so much you can do with Web Analytics that tracking Brand Awareness is probably way down on the list.  However, there are many companies (i.e. B2B) that don’t sell products directly and inevitably the question arises:

“What is the true purpose of my website?”

If you are part of one of these companies, the above question is often followed with a spirited debate about whether success should be judged by lead counts, unique visitors, visitor engagement, etc…  At some point one Marketer will say that the website should be used to build Brand Awareness so success should be judged by increasing Unique Visitors, only to be countered by another saying that Unique Visitors don’t mean anything if they aren’t the right types…After about an hour of this, there is rarely a consensus on how to judge the success.  Soon you can see why this is not a popular topic in Web Analytic circles!

Amid all of this confusion, I think that people sometimes forget the real reason that people care about Brand Awareness.  At the end of the day, you want to measure how often consumers that are interested in a product/service that you provide think of you when the time comes to research or buy that product/service.  If you are doing a really good job at branding your company such that you are top of mind when consumers are at this stage, then one way or another you have done something right.  This is why I think there is some value in trying to quantify this and trend it over time.

So What Can Be Tracked?
So building upon the previous section, let’s assume that you don’t sell a product directly on your website, but that there are consumers out there who need your product/service (and have a blank checkbook in hand!).  Do you think they would:

1. Come to your office and ask to see your salespeople?
2. Pick up the Yellow Pages and give you a call?
3. Mail you a letter asking for information?

Maybe in the 1980’s, but not today!  Most are going to go to a Search Engine and a few savvy ones will go to Twitter.  So if the bulk of these will go to a Search Engine, and you are truly “top of mind” from a branding standpoint, they would probably search for your company name or the name of one of your products.  For example, if the consumer is looking for a “CRM” product they might search for “CRM.”  But if you are doing your job and have an awesome brand such that the first thing people think of when they think about “CRM” is your company brand (I don’t know…maybe something like “salesforce.com” ), then you would know that your brand is alive and kicking!

Following this logic, you can see that one interesting way to track your brand awareness is to quantify how often people are coming to your website from a list of “Branded” keywords of your choosing.  This list of keywords would include your company name, product names, key executive names, etc…  If you can aggregate these SEO keywords (I wouldn’t include Paid Search Keywords), then you have a number that you can trend over time.  Keep in mind that this is not an exact way to track brand awareness, but the logic behind it is that the more people [organically] search for your key brand phrases, the more pervasive your brand is out there.  In my consulting experience, I have often found that the number of SEO Brand Searches has a direct correlation with other key website success metrics.

So How Do I Implement SEO Branded Keyword Tracking?
In a perfect world, it would be great if there were an easy, reliable way to track how often your brand keywords were searched on all of the major search engines.  Companies like comScore try to estimate this, but it is not always accurate due to the panel-based methodology.  Another way I have tried to get at this data is through Google Trends, but I have not found ways to automatically export that data through API’s (if you know how please let me know!).

That being said, if you want to use SEO Branded Keywords to track your brand, take the following steps:

1. Work with your Marketing team to identify the list of keywords that everyone agrees are “Brand Keywords.”  In order to not distort the trend, it is important that you not continually add to the list so try and get an exhaustive list and stick to it for an extended period of time (i.e. readjust yearly).
2. The next step is to isolate these Branded Keywords in your SEO reports.  One way to do this is to add each one to the advanced search criteria for your SEO Keywords report (in the interface or ExcelClient), but if you have a lot this can be difficult.  My preferred approach is to pass SEO Keywords to a custom eVar.  Once you have done this, you can use SAINT to classify these keywords as “Branded Keywords” and then use the trended view of reports.  If you are using the Channel Manager plug-in or the Unified Sources Vista Rule, you should already have the data you need in a custom variable.
3. Once you have these branded keywords isolated, you can create a report that looks like this:

In addition, if you have specific products that are brands of their own, you may want to apply the same technique to the SEO Keywords that represent those brands and chart the Brand Awareness of your different products amongst each other (maybe inspire some competitiveness?).  For example, at Salesforce.com, we group our products into “Clouds” so you might chart the SEO Keywords related to the various “Clouds” on a graph to see how each is doing (shown with sample data here):

Don’t Forget About Twitter!
As mentioned earlier, another way to look at how your brand is doing is to look at Twitter.  This can be done using the Omniture Twitter Integration I proposed last year.  Implementing this provides you with a way to see how often your brand is being talked about so you can see a chart like this:

If you want to get fancy, you can even measure how your brand compares to the brand of your competitors on Twitter.  The graph below shows what I call “Twitter Competitive Share” and is calculated by the following formula:

Branded Tweets / (Branded Tweets + Competitors Branded Tweets)

The result is a chart that looks like this:

Final Thoughts!
Well there you have it, definitely not world peace, but if you are looking for some different ways to leverage your web analytics data, hopefully these ideas give you some food for thought.  If there are other ways that you are using web analytics data to track Brand Awareness, please leave a comment here as I’d love to hear about it…

Adam Greco is the Director of Web Analytics at Salesforce.com.  You can read his previous Inside Omniture SiteCatalyst blog at http://blogs.omniture.com/author/agreco/ and can follow him on Twitter at http://twitter.com/adamgreco.  Please send questions and comments to adam@the-omni-man.com.

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

In this post, I am going to talk about how Data Quality can kill an Omniture (or other Web Analytics) implementation.  I will share some of the problems I have seen and show some ways that you can help improve Data Quality…

Sound Familiar?
So you have been managing an Omniture implementation for a while.  You have your KPI’s lined up.  You have been sharing some dashboards and reports with people throughout your company.  People are starting to realize that they should talk to you before making website business decisions.  Suddenly, you find yourself in the executive suite to answer some key website questions.  Then, just as you are wrapping up your web traffic overview, an executive starts to calculate some numbers on a notepad and determines that the increase you show in Paid Search traffic doesn’t look right given other data they have seen from the SEM team.  She also questions the rise in traffic data for EMEA, knowing that his VP in the region told you traffic has been down over the last few months.  Suddenly, you are in a web analytics death spiral.  In a split second, you have to decide, do you defend your Omniture data and risk your reputation or do you back-pedal saying you will re-check the web analytics data and live to fight another day?

Hopefully this hasn’t happened to you, but it has happened to most of us who have been around the web analytics space for long enough.  Unfortunately, you only get so many chances to be wrong  about data you are presenting and even if your data is right, if you aren’t confident enough to stand by it, it might as well be wrong.

Minimizing Data Quality Risk
So how do you avoid this situation?  The first step is to realize that there is no way to be sure that all of your web analytics data is correct.  100% Data Quality is not only unattainable, but also not worth the time and effort it would take to achieve.  Therefore, I use a philosophy of risk minimization in which I try various techniques to minimize the key things that cause data quality issues.  The following will show you some of the ways to do this:

Ensure all Pages are Tagged
This is easier said than done.  As we all know, IT is usually used to deploy JavaScript tags and they often have more important things to do than to guarantee that every website page has a the [correct] JavaScript tag.  Fostering a good relationship with IT helps, but at the end of the day, new website pages are created all the time, and tags will be missing.

Use Technology
As you can imagine, where there is a need, there are technology vendors.  The main vendors that I have worked with or heard the most about are WASP and ObservePoint.  Not completely coincidental, ObservePoint was founded by John Pestana who was one of the co-founders of Omniture.  In a great blog post, John Pestana talked about getting rid of asterik’s in web analytics reports.  I am sure there are many other vendors out there offering similar products, but the gist of the technology is that it can spider your website and let you know which pages are missing JavaScript tags so eliminate any obvious omissions.

Blood, Sweat & Tears
Unfortunately, the main way that I have minimized web analytic data loss is by downloading data and looking for anomalies.  I normally do this by taking advantage of the Omniture SiteCatalyst Excel Client and downloading key data blocks by day or week and then using formulas to compare yesterday to the same day last week or last week to the week prior.  Once you have the data in Excel, you can do any type of statistical analysis you want on the data to see if anything looks “fishy.”  One thing I like to do is to use Excel conditional formatting to spot data issues.

The following is a screenshot example of using Excel to spot potential data issues.  In this example, I am looking at Page Views from one week prior to each day and if there is a change of more than 20%, I highlight it in red:

Uh-oh… It looks like our daily data quality report indicates that we may have lost a tag on Friday for the Login page and something suspicious took place related to the Search Results page the same day.  Obviously, the downsides of this approach are that it is extremely manual and that it is in arrears.  As you know, once you miss a time slot of data in SiteCatalyst, there is no easy way to get that data back.  While this approach can minimize the data loss to a day, it won’t help you get the Login Page data back in the example above.

Therefore, the way I employ this approach is to focus on the top items within each variable.  This means, I focus on the pages with the most Page Views, the Form ID’s with the most Form Completions, the Orders for the most popular products, etc…With the Excel Client, you can download multiple data blocks at once and then use conditional formatting to easily spot the issues.  Done intelligently, Data Quality for 80% of your data can be done in under a few hours each day.  By doing this, you can feel more confident when your VP questions your data knowing that if something were significantly off, you would have known about it ahead of time.

Special Cases
I have found that there are a few other situations that commonly lead to missing or bad data so I quickly wanted to bring them to your attention so you can apply some additional effort to ensure they are tagged correctly:

1. “Lightbox” pages where a new HTML page is often not loaded.  These often times are created as a window within a window and many times developers forget to put SiteCatalyst code within them.
2. Flash/AJAX pages where the page changes dynamically or you have an entire site/page developed in Flash.  By extra careful around these as they often are missing tracking code (especially when done by an outside agency!).
3. Dynamically generated content, such as a page that shows historical stock price data after a user enters a ticker symbol.  Often times, these dynamic pages are tagged as one single page, but might be better as unique pages from a web analytics viewpoint.

SiteCatalyst Alerts
If you have read my previous blog post on Alerts, you may figure out that you can use Alerts to help with Data Quality as well.  Alerts can be used to look for changes in key metrics by Month, Week, Day (or Hour in some cases).  These alerts can be handy to be notified when data is off  by more than x%.  However, I have found that if you want to look a more granular data (as in the example above), the current Alert functionality can be a bit limiting.  You can set alerts for specific sProp and eVar values, but not as easily as you can by using Excel.  Therefore, I would use Alerts as an early warning system an employ the previously mentioned techniques as your main defense against missing data.

Classification Data
Finally, when  thinking about data quality/completeness, don’t forget about SAINT Classifications.  If you have key reports that rely on SAINT Classifications, even if you have the source data collected perfectly, if you are missing key SAINT Classifications for that source data, your reports will be incorrect and indistinguishable from poor data quality in the eyes of your users.  You will know if you are missing SAINT Classification data if your classified reports have a large “None” row.  So how do you ensure your SAINT Classification data is complete?  What I do is create Excel data blocks for each Classification and isolate the “None” row for key metrics.

In the screenshot below, you can see that I have created a data block that looks for “Unspecified” Site Locale Full Names (the Excel Client doesn’t use None, but it uses “Unspecified” instead for some reason).  In this scenario, I store a 2-digit website country identifier in an  eVar and use a SAINT Classification to provide a full name.  I filter on “Unspecified”  where the metric is Visits, Form Views and Form Completes.

After running, you will see a succinct report that looks like this:

In this case, there are no Form View or Form Complete Success Events missing a Full Site Locale SAINT Classification, but there are some Visits missing the classification.  You can then easily go into SiteCatalyst or Discover, open the Full Locale Name report and break it down by its source to find out what values are left to be classified.

Finally, if you want to earn “extra credit” you can do this for all of your SAINT Classifications in one Excel workbook and make a summary screen like the one below which pulls the percentages that are unclassified into one screen so you can see how you are doing overall.  What is cool about this is that you can use the “Refresh All” feature of the Excel Client to check all of your Classifications while you get coffee and when you get back, you have a fully updated view of your SAINT Classifications.  In the above below, I have shaded some items in black that are OK if they aren’t fully classified, items in green that are acceptable and items in red that require attention:

Final Thoughts
As you can see, Data Quality is a HUGE topic so it is hard to cover it all in one post, but hopefully some of the pointers here will get you thinking about how you can improve in this area.  One last thing I will mention is that like most things related to web analytics, tools are good, but qualified people are better!  Therefore, I think that any serious web analytics team will have a resource who has Data Quality as one of their primary performance objectives.  Without this, Data Quality tends to fall by the wayside.  Try to do whatever you can to convince your management that having a full or part-time person devoted to Data Quality will pay hefty dividends in the future…

Adam Greco is the Director of Web Analytics at Salesforce.com.  You can read his previous Inside Omniture SiteCatalyst blog at http://blogs.omniture.com/author/agreco/ and can follow him on Twitter at http://twitter.com/adamgreco.  Please send questions and comments to adam@the-omni-man.com.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Adam Greco is the Director of Web Analytics at Salesforce.com.  You can read his previous Inside Omniture SiteCatalyst blog at http://blogs.omniture.com/author/agreco/ and can follow him on Twitter at http://twitter.com/adamgreco.  Please send questions and comments to adam@the-omni-man.com.

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

This week I will round out my Pages in Conversion trilogy by discussing a # of Pages Viewed Counter eVar.  Two posts ago I discussed some of the benefits of setting a Page View Success Event and in my last post I showed some of the cool things you can do by setting a Page Name eVar.  While this post will not be as “meaty,” I wanted to share a quick tip that can help you out for a few cool analyses.  If you haven’t already, I suggest you read my last two posts as it might be helpful.

Counter eVar Refresher
About a year ago I blogged about what a Counter eVar was in the following Counter eVar post.  If you are unfamiliar with Counter eVars, I suggest you review that post before continuing.  In a nutshell, a Counter eVar allows you to increment an eVar with a numeric value (usually incrementing by one) when a specific action takes place.  For example, if you would like to count how many times website visitors conduct searches on your website prior to adding an item to the shopping cart, you would use a Counter eVar to store a numeric value in each website visitor’s cookie so that when the Cart Addition Success Event takes place, you can associate that number of internal searches with that Cart Addition.

# of Pages Viewed Counter eVar
OK.  So now let’s get into this week’s topic.  I often like to set a Counter eVar on each page of the website so I have a running count of how many website pages the current visitor has viewed.  Setting this is pretty simple as you only need to set a Counter eVar to “+1″ on each Page View and if you are setting a Page View Success Event it can be done concurrently.  So what does setting this # of Pages Viewed Counter eVar get you?  Well, no matter what Success Events take place on your website, it may be interesting to see how many pages the active visitor has/had viewed prior to that Success Event taking place.  For example, let’s say you are trying to drive website Lead Capture Form Completions and you want to know if Forms are being completed relatively quickly (after 1-3 pages) or taking more time (after 10 pages).  This is not easy to do with out-of-the-box SiteCatalyst reports.  You can see Average Page Depth of each Form Page, but I find that very limiting.  Using this Counter eVar, you have a simple, clean way to see how many pages visitors had seen prior to completing a Form (in this example):

However, you get more than just this.  Since all eVars break down all Success Events, this one Counter eVar will work with all of your Success Events so you can see any Success Event broken down by # of Pages Viewed.  All you have to do is add a different Success Event to the report above and you can see how many pages it took visitors to perform that action.  In the following example, we can now see how many pages visitors see prior to performing an Internal Search:

In this case, we can see that about 50% of all Internal Searches are taking place in the first four pages that visitors see.  This could be expected, but if your goal is to improve page content and navigation, this might be an indicator of how well your changes are doing over time…

Use with Subrelations
As they used to say in the commercials: “but wait…there’s more!”  The above reports only scratch the surface of what you can do with this new Counter eVar.  For example, let’s imagine in the first example above that we now want to see how many pages it takes to get visitors to complete a specific website form.  If you are capturing the name of the Forms on your website in another eVar and it has Full Subrelations, you can see the following:

Again, the same concept would apply to other Success Events so in the Internal Search example above, you can use subrelations to see how many pages website visitors had viewed prior to searching on a specific phrase.

Don’t Forget Classifications
One quick little enhancement to the # of Pages Viewed eVar is that you can use SAINT Classifications to bucket pages viewed into more manageable groupings.  For example, you can see the same Form Completions report above in more concrete buckets by using SAINT to see the following:

Final Thoughts
That is the quick overview of setting a # of Pages Viewed Counter eVar.  Here are a few final things to keep in mind:

1. As with all eVars, you need to determine when it will expire.  I tend to like to keep the # of Pages to an expiration that is longer than a visit so if a visitor comes back multiple times, you can see how many total Page Views they had done across more than the current visit.  You can use “Never” to see all Page Views or if you have one key Success Event, you can expire the eVar at that event and then start the counter over.
2. You can use the same SAINT Classification file for all Counter eVars so if you create it once, be sure to re-use it.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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