Archive for 'Classifications'

(Estimated Time to Read this Post = 4 Minutes)

Every once in a while, as a web analyst, I get frustrated by stuff and feel like there has to be a better way to do what I am trying to do. Many times you are able to find a better way, often times you are not. In this case, I had a particular challenge and did find a cool way to solve it. You may not have the same problem, but, if for no other reason than to get it off my chest, I am writing this as a way to exhale and bask in my happiness of solving a web analytics problem…

My Recent Problem
So what was the recent problem I was facing that got me all bent out of shape? It had to do with Lead Generation forms, which are a staple of B2B websites like mine. Let me explain. Many websites out there, especially B2B websites, have Lead Generation as their primary objective. In past blog posts, I have discussed how you can track Form Views, Form Completes and Form Completion Rates. However, over time, your website may end up with lots of forms (we have hundreds at Salesforce.com!). In a perfect world, each website form would have a unique identifier so you can see completion rates independently. That isn’t asking too much is it? However, as I have learned, we rarely live in a perfect world!

Through some work I did in SiteCatalyst, I found that our [supposedly unique] form identifier codes were being copied to multiple pages on multiple websites. While this causes no problems from a functionality standpoint – visitors can still complete forms – what I found was that the same Form ID used in the US was also being used in the UK, India, China, etc… Therefore, when I ran our Form reports and looked at Form Views, Form Completes and Form Completion Rate by Form ID, I had no idea that I was looking at data for multiple countries. For example, if you look at this report nothing seems out of the ordinary right?

However, look what happened when I broke this report (last row of above report) down by a Page Name eVar:

At first, I thought I was going crazy! How can this unique Form ID be passed into SiteCatalyst on eleven different form pages on nine country sites? This caused me to dig deeper, so I did a DataWarehouse report of Form ID’s by Page Name and found that an astounding number of Form Pages on our global websites shared ID’s. Suddenly, I panicked and realized that whenever I had been reporting on how Forms were performing, I was really reporting on how they were performing across several pages on multiple websites. In the example above, I realized that the 34.669% Form Completion Rate I was reporting for the US version of the form in question was really reporting data with the same ID for forms residing on websites in Germany, China, Mexico, etc… While the majority was coming the the form I was expecting, 22% was coming from other pages! Not good!

The Solution
So there I was. Stuck in web analytics hell, reporting something different than I thought I was. What do you do? The logical solution was be to do an audit and make sure each Form page on the website had a truly unique ID. However, that is easier said than done when your web development team is already swamped. Also, even if you somehow manager to fix all of the ID’s, what is preventing these ID’s from getting duplicated again? We looked at all types of process/technology solutions and then realized that there is an easy way to fix this by doing a little SiteCatalyst trickery.

So what did we do? We simply replaced the Form ID eVar value with a new value that concatenated the Page Name and the Form ID on every Form Page and Form Confirmation Page. By concatenating the Page Name value, even if the same Form ID was used on multiple pages, the concatenated value would still be unique. For example, the old Form ID report looked like the one above:

But the new version looked like this:

With this new & improved report, when I was reporting for a particular form on a particular site/page, I could search by the form pagename and be sure I was only looking at results from that page. Also, a cool side benefit of this approach is that you could add a Form ID to the search function to quickly find all pages that had the same Form ID in case you ever did want to clean up your Form ID’s:

Implementation Gothca!
However, there is one tricky part of this solution. While it is certainly easy to concatenate the s.pagename value with the Form ID on the Form page, what about the Form Confirmation page? The Form Confirmation page is where you should be setting your Form Completion Success Event and that page is going to have a different pagename. If your Form ID report doesn’t have the same Page Name + Form ID value for both the Form View and Form Complete Success Event, you cannot use a Form Completion Rate Calculated Metric. For this reason, you need to use the Previous Value Plug-in to pass the previous pagename on the Form Confirmation page. Doing this will allow you to pass the name of the “Form View” page on both the Form View and Form Complete page of your site so you have the same page name value merged with the Form ID.

A Few More Things
Finally, while the Form ID report above serves this particular function, it is not very glamorous and it might not be the most user-friendly report for your users. If you want to provide a more friendly experience you can do the following with SAINT Classifications:

1. Classify the Form ID value by its Page Name so your users can see Form Views, Form Completions and the Form Completion Rate by Page Name
2. Classify the Form ID value by the Form ID if for some reason you want to go back to seeing the report you had previously

Final Thoughts
Well there you have it. A very specific solution to a specific problem I encountered. If you have Lead Generation Forms on your website, maybe it will help you out one day. If not, thanks for letting me get this out of my system!

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

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

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

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

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

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

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

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

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

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

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

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.

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

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…

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

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…

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…

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…