Archive for 'General'

While we like to think of ourselves as fun guys who know a lot of people in our awesome #Measure community, we have to admit that we were completely overwhelmed by the fact that our planned San Francisco ACCELERATE event sold out in 36 hours! There is no shortage of web analytics events taking place throughout the year, but the concept of ACCELERATE seems to have hit a nerve (in a good way!).

Therefore, we are looking to capitalize on this momentum and are already planning our next ACCELERATE events for 2012. Since we had many people register from outside the San Francisco area, we’d like to get your input on where we should have the next series of events.  Please click on the link below and fill out the form to indicate your interest and city.  While we can’t make any guarantees, we will use the responses we get to help us plan our next events.

We encourage you to use Twitter, LinkedIn, Facebook, Google+ and E-mail to spread the word to folks in your city so you can increase the chances of us making it our next ACCELERATE venue (“I think #ACCELERATE 2012 should come to _____ in 2012! #measure”).  We will also give special consideration to the comments you add to the form as to why you think your town would be a good spot for us to host the event!

As always, thanks for your support and we look forward to seeing you at one of our events in the near future!

Eric, John & Adam

I recently blogged a list of my top Omniture SiteCatalyst implementation “Pet Peeves.” While the response to my post was very positive, one reader agreed with most of what I said, but disagreed with a few of my assertions or felt I had made some omissions.  First, let me state that I always encourage feedback and comments to my blog posts since that helps everyone in the community learn.  In general, the reader was making the point that my post only took into account an implementer’s perspective vs. the perspective of the web analyst.  Personally, I don’t like to divide the world into implementers and analysts, since some of the best implementers I know also have a deep understanding of web analysis and vice-versa.  Having been a web analytics practitioner using SiteCatalyst at two different organizations, I feel that I am in a good position to know if items I suggest (or discourage) will lead to fruitful analysis.  I always try to write my blog from the perspective of the in-house web analyst who has to deal with things that I dealt with in the past, such as adoption, enterprise scalability, training, variable documentation, etc… In fact, I attribute much of my consulting success to the fact that I have been in the shoes of my clients and that they appreciate that my recommendations are based upon actual pains that I have experienced.

Since my original post was a very quick “Top-10″ list and didn’t provide an enormous amount detail, and given the interest that it generated, I thought it would be worthwhile to write this follow-up post to address the concerns raised related to my post and to elaborate on the rationale behind some of my original assertions.  In the process, it will become clear that I don’t necessarily agree with the concerns raised to my original post, but I am always cognizant of the fact that every client situation is different and every SiteCatalyst implementer has experiences that color their own implementation preferences.  I don’t see it as my place to say which techniques are right and which are wrong, but rather to do my best to state what I think is/is not “best practice” and why based upon what I have seen and experienced over the past ten years and let my readers decide how to proceed from there…

Tracking Every eVar as an sProp

The first pet peeve I mentioned is when I find clients that have duplicated every eVar with a similar sProp.  I stated that there are only specific cases in which an sProp should be used including a need for unique visitor counts, Pathing, Correlations and to store data that exceeds unique limits for accessing in DataWarehouse.  The reader seemed to think I was being hard on the poor sProp and listed a few other cases where they felt duplicating an eVar with an identical sProp or adding additional sProps was justified including:

1. Using List sProps – The reader suggested that I had made an omission, by not mentioning List sProps as another reason to consider using an sProp in an implementation.  I maintain that the use of List sProps was justifiably covered in my statement of other sProp uses that are “few and far between.” I don’t use List sProps very often because I feel that there are better ways to achieve the same goals.  As the reader stated, List sProps have severe limitations and there is a reason that they are rarely used (maybe 2% of the implementations I have seen use them).  I have found that you can achieve almost any goal you want to use List sProps for by re-using the Products variable and its multi-value capabilities instead.  By using the Products variable, you can associate list items to KPI’s (Success Events) rather than just Traffic metrics.  Using the reader’s own example of tracking impressions, illustrates the differences perfectly.  You can store impressions and clicks of internal ads and calculate a CTR using the Products variable and two success events.  This also gives you charts for impressions, clicks and the ratio of the two which can be easily added to SiteCatalyst dashboards.  I have found that doing this with a List sProp is difficult, if not impossible and reporting on it is tedious.  For more information on my approach, please check out my blog post on the subject.
2. Page-Based Containers & Segmentation – Here the reader suggested that the need to isolate specific pages using a Page View-based container is important to the life of the web analyst.  Ben Gaines from Omniture also commented about this on my original post and I do agree that this can be useful for some advanced segmentation cases.  I did not include this in my original list because I find it to be a much more advanced topic than I intended to cover for this quick “Top 10″ post.  While there may be cases in which you want to set an sProp to filter out specific items using a Page View-based segment container, I find that I often do this using the Page Name sProp which is already present.  I do not see too many cases where a client is storing an eVar (let’s say Zip Code) and will say, “I am going to duplicate it as an sProp for the sole purpose of building a Page-Based container segment to include or exclude page views where a page is seen where a Zip Code equaled 123456.” Maybe that happens sometimes, but I still think it falls out of the scope of the primary things you should be considering when deciding whether to duplicate an eVar and I think it is a stretch to say that this functionality establishes the line between those who care about implementation and those who care about web analysis.
3. Correlations – With respect to Correlations, the reader suggested that users correlate as often as they can since cross-tabulation is so essential to the web analyst.  This is exactly why I included Correlations in my list!  I also mentioned that this justification for using an sProp may go away in SiteCatalyst v15 where all eVars have Full Subrelations.  Also, one of the reasons I prefer Subrelations to Correlations is that Correlations only show intersections (Page Views) and do not show any cross-tabulation of KPI’s (Success Events).  Personally, I would disagree with the reader about over-doing Correlations, since in my experience, implementing too many Correlations (especially 5-item or 20-item Correlations), with too many unique values, can cost a lot of $$$, lead to corruption and latency.
4. Pathing – In the area of Pathing, I think the reader and I are on the same page about its importance which is why I have published so many posts related to Pathing such as KPI (Success Event) Pathing, Product Pathing, Page Type Pathing, etc…  Again, I might differ with the reader in that I don’t think enabling Pathing on too many sProps is a good idea since it can cost $$$ and produce report suite latency, which is why I prefer to use Pathing only when it adds value.

At the end of the sProp duplication section, the reader stated that there was no downside to duplicating every eVar as an sProp since it has no additional cost.  To this, I would reiterate that my post was not advocating abandoning the use of sProps, but instead, attempting to help readers determine when they might want to use sProps so as to avoid over-using them when they will not add additional value.  Even after years of education, I still find that many clients get confused as to whether they should use an eVar or an sProp in various situation, and most people I speak to welcome advice on how to decide if each is necessary.

However, I disagree with the reader’s assertion that duplicating every eVar as an sProp has no costs.  Maybe it is due to the fact that I have “been in the trenches,” but in my experience I have seen the following potential negative ramifications:

• Over-implementing variables and enabling features unnecessarily can cause report suite latency
• Over-implementing variables can increase page load time, which can negatively impact conversion
• Over-implementing variables and features can cost additional $$$ as described above (e.g. Pathing, Correlations)
• When you implement SiteCatalyst on a global scale, you often need to conserve variables for different departments or countries to track their own unique data points.  This means that variables (even 75 of them!) are at a premium.  Therefore, duplicating variables has, at times, caused issues in which clients run out of usable variables.
• Most importantly, however, is the impact on adoption.  Again, I may be biased due to my in-house experience, but here is a real-life example:  Let’s say that you have duplicated all eVars as sProps.  Now you get a phone call from a new SiteCatalyst user (who you have begged/pleaded for six months to get to login!).  The end-user says they are trying to see Form Completions broken down by City.  They opened the City report, but were only able to see Page Views or Visits as metrics.  Why can’t they find the Form Completions metric?  Is SiteCatalyst broken?  Of course not!  The issue is that they have chosen to view the sProp version of the report instead of the eVar version.  That makes sense to a SiteCatalyst expert, but I have seen the puzzled look on the faces of people who don’t have any desire to understand the difference between an sProp and an eVar!  In fact, if you try to explain it to them, you will win the battle, but lose the war.  In their minds, you just implemented something that is way too complicated.  You’ve just lost one advocate for your web analytics program – all so that you can track City in an sProp when you may not have needed to in the first place.  In my experience, adoption is a huge problem for web analytics and is a valid reason to think twice about whether duplicating an sProp is worthwhile.  While I’ll admit that duplicating all variables certainly helps “cover your butt,” I worry about the people who are at the client, left to navigate a bloated, confusing implementation…

Therefore, for the reasons listed above, I remain steadfast in my assertion that there are cases where sProps add value and cases where they just create noise.  While there will always be edge cases, I think that the justifications I laid out in my original post are the big ones that the majority of SiteCatalyst clients should think about when deciding if they want to duplicate an eVar as an sProp or use an sProp in general.

As an aside, while we are revisiting my original post, I thought of a few more items I wish I would have included so I will list them here:

1. One other justification for setting an sProp I should have mentioned is Participation.  There are some fun uses of Participation that can improve analysis and I find that sProp Participation is easier to understand for most people than eVar Participation so I would add that to my original list.
2. If you do find a need to duplicate an eVar as an sProp, but it is only for “power users,” keep in mind that you can hide the sProp variable from your novice end-users through the security settings under Groups.
3. Finally, I see Omniture ultimately moving to a world where there will only be one variable so if you want to be part of that world, please vote for my suggestion of doing this in the Ideas Exchange here.

VISTA Rules

Another pet peeve I mentioned is that I often find clients who are using VISTA rules too often or as band-aids.  The reader stated that VISTA rules are a good alternative to JavaScript tagging since they can speed up page load times.  I think this is another situation where my time working at Omniture and in-house managing SiteCatalyst implementations may bias my recommendations. While I agree that page load time is important, most Omniture clients I saw never mentioned using VISTA rules as a way to decrease page load time, but rather as a way to avoid working with IT!  Usually, when I find a client that has many VISTA rules, it is because they have a bad relationship with IT, who doesn’t want to do additional tagging, rather than to save page load time.  However, if I were to address the reader’s point of page load speed, I would agree that there are cases where using VISTA rules over JavaScript can decrease page load time, but I certainly do not think this should be the primary deciding factor. Great strides have been made in tagging including things like dynamic variable tagging and tag management tools which have greatly reduced page load speeds.  I suggest readers check out Ben Robison’s excellent post on VISTA vs. JavaScript which discusses not only page load speed, but also the many other important factors to consider before jumping into VISTA rules.

Another point I’d like to make about VISTA rules is that, in my experience, they have a high likelihood of breaking and leading to periods of bad data.  VISTA rules are like Excel macros.  They do what you tell them to do, but if something changes, it can easily throw off a VISTA rule and cause incomplete or inaccurate data to be reported in SiteCatalyst.  In this point, perhaps I am a bit jaded because I have seen so many different VISTA implementations go awry while I was at Omniture.  In fact, it is rare that I find clients that have a VISTA rule that has worked for several years without ever having an issue.  And if you do encounter an issue, you will have to pay Omniture around $2,000 to update it – every time.  Want to make an update to the VISTA rule?  $2,000.  Want to turn off the VISTA rule or move it to a different report suite?  $2,000!  Consultants don’t have to write these checks, but guess who does – the in-house people do!  This is why people are so excited about the new V15 processing rules and emerging tag management vendors.  It is this tendency to break and the risk of bad data that makes me a bit gun-shy about using VISTA rules simply as a replacement for JavaScript tagging.  Moreover, since the reader’s overall premise was that one must keep the web analyst in mind during implementation, I would be cautious about being overly-reliant on a solution like VISTA that is so prone to causing data issues which could thwart the analyst’s ability to do web analysis.  I have seen companies that have 20+ VISTA rules and I promise you that they are not huge fans of VISTA right now (though they should really blame themselves not the tool!)!  If you do pursue VISTA rules, my advice is that you consider using DB VISTA over VISTA.  DB VISTA rules cost a bit more, but do offer more flexibility since you can at least make updates to the data portion of your rules without having to pay Omniture additional $$$.

One additional point to think about when it comes to VISTA rules is the impact they can have on report suite latency. Having too many VISTA rules can slow down your ability to get timely data in SiteCatalyst and I have seen many large organizations have severe (several days) report suite latency due to multiple VISTA rules acting on each server call.  This impacts the web analyst’s ability to get the data they need and should be factored into decisions about VISTA rules.

As I stated in my original post, I have nothing against VISTA rules, but do find the overuse of them to be a potential red flag when I look at a new implementation.  I often find that excessive use of VISTA Rules can be a symptom of bigger problems which merit investigation.  Just like I don’t advocate duplicating sProps or enabling Pathing when not necessary, I don’t advocate the use of too many VISTA rules since it can be great in the short term, but bad in the long term.  Now that I am a consultant again, it would be easy for me to recommend VISTA rules left and right, but since I like to have long-term relationships with my clients, I don’t do this since I know what it is like to be around later if/when they have issues!

Final Thoughts
I hope this post provides some good food for thought and more in-depth information about some of the items I listed in my original post.  If you would like to discuss any of the above topics in more detail, feel free to leave comments here or e-mail me.  Thanks!

Over the years, when I have consulted clients who use the SiteCatalyst product, I have encountered some strange implementation items that made me scratch my head.  In the beginning, when I saw these odd implementation quirks, I was mildly entertained, but as I saw them more and more, they were soon elevated to “pet peeve” status.  Therefore, I thought I’d share some of these items with you to make sure that you are not doing any of them, and also because I am curious to see what other “pet peeves” you may have.  Please check out my list (which is by no means exhaustive!) and if you have items that you have seen that bug you, please leave them here as a comment!

Tracking Every eVar as an sProp

I would say that my biggest pet peeve is when clients have an sProp for every eVar they have set (or vice versa).  When I see this, it is an early warning sign that the client doesn’t fully understand the fundamentals of SiteCatalyst.  While there are definitely cases where you would capture the same data in both an eVar and an sProp, they are usually few and far between.  As a rule of thumb, I only set an sProp if:

• There is a need to see Unique Visitor counts for the values stored in the sProp
• There is a need for Pathing
• You have run out of eVar Subrelations and need to break one variable down by another through the use of a Correlation (which will go away in SiteCatalyst v15)
• There will be many values (exceeding the unique limits and you just want data stored so I can get to it in DataWarehouse or Adobe Insight

For the most part, that is it… Beyond that, I tend to use eVars and Success Events for most of my implementation items.

This is why I shudder when I see 40 eVars set and the same 40 sProps set.  I find that this only confuses users since most don’t really understand the difference between the two variable types to begin with!  Therefore, my advice is to make sure you understand the difference between eVars and sProps and make sure you use the right variable for the right purpose.

Pathing Enabled Unnecessarily

Another item I have seen a lot is when a customer will have Pathing enabled on an sProp that doesn’t change in a session.  For example, let’s say you have people log into your website and you store the Customer ID in an sProp.  That Customer ID is designed to be the same for each visitor during the entire visit.  However, I often see clients who enable Pathing on this Customer ID sProp.  My hunch is that they think this will show them the paths of that Customer ID, but the truth is that it will show no paths for each Customer ID so it is a complete waste of time.  Keep in mind that pathing is only useful if values change in the same session.  If you pass the same value in on every page of the session, SiteCatalyst will see that as a Bounce of 100% for every Customer ID!  Since Adobe (Omniture) will only let you have so many variables with Pathing enabled, you need to make sure you are using them wisely!

No Friendly Page Names

The next pet peeve is when clients don’t pass any values to the Page Name variable and use the default of the URL.  This really makes my blood boil!  There are so many downsides to doing this when it comes to the Pages report since it impacts Page Views, Unique Visitors and Pathing.  For better or worse, the Pages report tends to be a very popular one and I feel that, even if just for the perception of the integrity of your web analytics implementation, you need to take the time to make sure this report is accurate and understandable.  For more information on this topic, please refer to my Page Naming Best Practices post by clicking here.

Passing Query Strings to Page Name Variable

On a related note, I have another gripe related to the Page Name variable and it has to do with query string parameters.  Many times I find that companies are including query string parameters in the Page Name variable.  This is a really bad idea.  Here are two common things I see:

• When a visitor arrives to the website from a campaign, the URL will have a campaign code in the query string parameter and pass this to the Page Name variable (i.e. zyz corp:home:homepage:cid-12345)
• A company will have a search results page and include the keyword/phrase that the user searched upon to get to that page in the Page Name (i.e. zyz corp:search:searchresults:user manual)

Both of these examples involve the company having one page name essentially split out into hundreds (or thousands) of versions of the Page Name due to the query string parameter.  Creating many versions of the same page has the effect of losing Visits, Unique Visitors and Pathing for the true Page Name.  Most of the time this situation can be solved by using one Page Name and passing the query string parameter to another variable and using a Correlation.  If you really need to have these extra query string parameters associated with pages, I recommend using another sProp instead of the Page Name variable…

Reports with No Data

Another thing I see quite often are implementations that have tons of variables labeled, but that have no data.  As a rule of thumb, I recommend you disable any variables that have no data or at a minimum hide them from the menus using the Admin Console.  There is nothing more frustrating to an end-user than opening up a report, getting excited to see the data and then realize that there is none!  Besides being annoying, it hurts the credibility of your web analytics program.  When I am in the midst of a new implementation and things are in flux, one thing I do is to put all reports that are coming, but have no data in ALL CAPS or I add the phrase “(COMING SOON)” after the variable name.  This helps me see which variables are left to do and which ones I can begin to QA.  However, once the implementation is semi-stable, I urge you to hide variables that are not coming for a while so you don’t annoy people unnecessarily!

No Menu Customization

On a related note, how many SiteCatalyst implementations have you seen where they use the default menu structure?  Why would you want to tell users to look in “Customer Conversion 1-10″ to find the report they are looking for?  Not very helpful is it?

Instead, you should customize your menus so they make sense for your users.  This will help in your adoption and make training much easier.  For some great tips on how to customize your menus, check out Brent Dykes’ post by clicking here.

No Variable Standardization

The next one is when you have a situation where you have multiple report suites that are really the same website, just for different business units and/or locations and none of them are set-up consistently.  I see many clients who are tracking some things in the US, but not in the UK or Japan, even though the websites are identical.  When this happens and you select multiple report suites in the Admin Console, here is what you see in the variable screen:

I call the “Multiple Madness” due to what you see in the Admin Console and it is not a good thing!  You should make sure that as many of your report suites are as consistent as possible so you can minimize your development time and roll-up data into higher-level report suites.

Wasting of Variables

This next one is a minor one but it is related to wasting variables.  Even though there are more variables available now, it doesn’t mean that you should track everything or that every piece of data requires its own variable.  For example, I recently ran into a client that was tracking Salutation (Mr., Mrs., Dr., etc…) in an eVar.  This makes very little sense.  How are you going to do cutting-edge analysis on that?  Gender maybe, but I don’t think Salutation is worthwhile.  Just because you know it, doesn’t mean you need to track it.

This leads to the other type of waste I see – not using SAINT Classifications to save variables.  There are many cases where you can accomplish the same analysis objectives by using SAINT Classifications and save variables along the way.  Using the prior example, instead of storing Salutation as an eVar, if you really need it, why not store a Customer ID value and then add Salutation as a classification value of that Customer ID?  That saves you one eVar and if you happen to have Full Subrelations on that eVar, you get them on the classification of that eVar as well (which will be less of an advantage when using SiteCatalyst v15 since all eVars will have Full Subrelations).

But here is my favorite example since I see this all of the time!  One of Omniture’s common JavaScript Plug-ins is the Time Parting plug-in.  This allows you to see data segmented by Day of Week and Hour of Day.  However, many clients also store an sProp and/or eVar for Weekday/Weekend through this plug-in.  It makes sense that you might want to segment data by Weekday/Weekend, but why use an entirely new variable just to track the binary values of Weekday vs. Weekend?  You can easily do a one-time classification of Day of Week and lump Mon-Fri into “Weekday” and Sat-Sun into “Weekend.”  That will allow you to achieve the same goal, but saves a variable.  Again, this is a minor annoyance, but it is the principle that counts.  You can extrapolate this concept by thinking back to the Customer ID example I mentioned above.  What if there were ten data points related to a customer that you chose to store in ten separate eVars?  You might be able to make these classifications and save ten eVars!

My advice here is to just be thoughtful when assigning variables and if you have cases where there is a direct relationship between two variables that won’t change very often, consider using a SAINT classification and also think about whether you will ever use that data point for an analysis before tracking it in the first place.

VISTA Rule Chaos

The final pet peeve I will mention is related to VISTA Rules.  Let me start by saying that VISTA and DB Vista rules are not bad.  They can be very powerful, but it is also true that they can be easily misused and wreak havoc on a SiteCatalyst implementation.  When using VISTA rules, it is critical that you and your entire team understand WHEN the rules are being used and WHAT they do in terms of setting variables.  I have seen many cases where a developer will change a variable not knowing that there are VISTA rules impacting it.  You need to make sure VISTA rules are heavily documented and as you change your site or implementation, they need to be factored into the equation.  One suggestion I have is to add the phrase (SET VIA VISTA) in the name of any variable that is set via a VISTA rule in your documentation so there is no missing it!

The other pet peeve I have related to VISTA rules is when they are used as a “band-aid” to avoid doing real tagging.  In the long-run, this always comes back to haunt you.  I see many clients creating band-aids on top of band-aids until things fall apart.  I am ok with companies using Vista rules to get things done quickly, but I recommend that, over time, you phase out as many VISTA rules as you can and move their logic to your regular tagging so you have all of your logic in one place.

Final Thoughts
Well, there you have it.  Not all of my implementation pet peeves, but a bunch of them that popped into my head.  I am sure you have seen some fun ones out there and I’d love to hear about them…Please leave them as comments here!

NOTE: For more details on these points, check out my follow-up post here.

These are just a few of the many reasons that auditing your implementation makes sense.  One important note: this Operational Audit does not include a technical audit of JavaScript tagging (which can be equally as important!).

Recently there has been some rumor buzz about Google releasing a “paid” version of Google Analytics (beyond what is currently available through Urchin).  Assuming, for a second, that something like this is coming in the future, the real question is whether this is a good or bad idea.  In this post, I’ll examine some of the pros and cons to this potential move by Google.

Why Google Should Offer a Paid Version

So what are some of the reasons that Google should offer a paid version of its web analytics offering?  I can think of the following:

• There will always be a group of web analytics users that want advanced functionality and are willing to pay for it.  These advanced features are often resource-intensive and I could see Google wanting to recoup some money to enable these features or the additional data storage they necessitate.
• There are millions of websites using Google Analytics for free and if Google can extract even a small amount of revenue from these, it can add up quickly.  Since I don’t think Google is hurting for revenue, I assume that the money generated would be filtered back into the product which would mean even more enhancements to a product that pretty robust already.
• One of the reasons Google may be thinking about offering a paid version of the product is to open the door to its sales team to cross-sell other Google products and services.  By being free, Google Analytics has infiltrated millions of websites which creates an easy entrée for a Google sales rep to say: “I see that you are using Google Analytics, did you know that Google also offers Google Ad Words, Google Apps, etc…”  While they can already do this, if a company has already started paying for Google Analytics (and it has made it through procurement!), that makes the cross-sell so much easier.  It also helps weed out the companies that are serious, which will often be the ones willing to pay.
• Services baby!  It is no secret that professional services are a huge money maker.  When I was at Omniture, we had a sizable consulting group and there are a host of other firms (including Web Analytics Demystified of course!) offering services around web analytics.  While I am not sure if it would be a good move or not, Google could offer paid-for services around a paid-for web analytics tool itself or through its certified partners.
• Competition!  I love competition.  I think it helps drive innovation.  In my opinion, the consolidation of the web analytics industry over the last few years has reduced the amount of innovation and I think Google having a paid product will ultimately mean that everyone in the industry gets more.

Why Google Should Be Careful About Offering a Paid Version

So what are the pitfalls that Google might want to look out for?  Here are a few worth considering:

• Too much functionality!  One of the strengths of Google Analytics is its simplicity.  Since it is a free tool for most users, it has not been beholden to the axiom that more features must always be added to continue justifying the investment.  Like all software products, as time goes by, more features are added to meet the needs of the most advanced users, which often results in casual users leveraging 10% of the functionality.  While it looks like Phil & Nick have done a great job adding the features their users want to date, once someone is paying you money, the balance of power tends to shift in a big way (think difference between privately held vs. publicly traded company).  I hope that Google will not lose its simplicity “mojo” that got it to where it is today.
• Customer Support?  One of the biggest expenses for software products is the cost associated with supporting its customers.  When I worked at Omniture, we had a massive customer support organization of account managers and client care that grew exponentially.  If Google has paid clients, I would imagine that it would need to provide support at a level that far exceeds what it is offering today.  This is not an easy task and Google is known for being somewhat hands off for most of its products.  When your product is free, people accept that they are going to be on their own more than when they are paying for something and if support isn’t good, I could see Google Analytics losing a bit of its current luster.  I also imagine that Google loses quite a bit of money on Google Analytics (which I assume it makes up for on the AdWords side), and this will be even worse once it has to staff up to support users unless it can find a way to get its partners to offer that support.
• SLA’s (Service Level Agreement).  Paid-for vendors have legal requirements around the availability of the product and the handling of product issues.  To date, it is my understanding that Google Analytics has not had SLA’s since it is a free product, but I would imagine Google would need to provide a reasonable SLA for the paid side.  SLA’s are never fun and usually end up costing time and money…
• What happens if no one buys it?  Google has done a lot of things that have changed the market and some that have not done quite as well (i.e. Google Wave).  Google shook up the web analytics industry in a huge way with free Google Analytics, but what would it say if only a small % of companies decide to pay for its product?  Does this serve as a boost to its paid competitors?  I guess the real question comes down to this.  If I am a Fortune 500 company and am currently using Google Analytics and a paid product from Omniture, Webtrends, Coremetrics or Unica (which is very often the case!), what features will Google Analytics add to its paid product that will get me to only use Google Analytics and get rid of my other paid vendor?  I would guess that the things I would be looking for are 1) my own dedicated servers so I know my data is really my data and can be kept as long as I want, 2) knowledge that Google is not seeing any of my data and using it in its search algorithms, 3) support and SLA’s at the same caliber I am getting from my other paid vendors and 4) 90% of the features I can get from my other paid vendor.  If Google can deliver on these items (and I am sure it can), I think it will make a compelling case as to why companies should standardize on Google Analytics, but I don’t think this will be something that happens overnight.

Obviously, all of this is still speculation, but I, for one, look forward to seeing what Google does and how they address some of the items I have described here.

I highly recommend you check out this YouTube video on disruptive innovation.  I think it is very cool to watch this and think about Google being the “entrant” and the other paid web analytics vendors as being the “incumbents” described in the video.  This video talks about what Google has done to the other paid vendors and how Google could one day become the incumbent and fall prey to even newer entrants (or reincarnations of the old incumbents!).  Fascinating stuff!

So what do you think?  Will they do it?  Will people buy it?  What things do you think Google needs to do to make it successful?  Please share your thoughts by adding a comment here…

(Estimated Time to Read this Post = 4 Minutes)

One of the funny things about SiteCatalyst (you will notice I can’t yet bring myself to call it Adobe SiteCatalyst!) is that there are some really cool features that are hidden.  In some cases, it almost seems like someone has gone out of their way to hide them, but I like to look at these “hidden gems” as a sort of rite of passage.  In this post I will share some of the ones I have found and hope that maybe you know of others so that all of us can learn!  Also, if you haven’t read my old blog post on SiteCatalyst Time Savers, I encourage you to do so!

The Magic Triangle and Checkboxes
If you are like me, it may seem like you spend most of your day adding/removing metrics from reports!  This can be a very time consuming process, so you might as well be as efficient as possible.  However, I often find that new SiteCatalyst users add extra steps to the process because they don’t know a few easy tricks in the Metrics window.  The first trick is that you can change the column that is used for sorting by clicking the [very] little triangle next to each metric.  It amazes me how many people add metrics, wait for the report to load and then click on a column to sort and wait for the report to load again!  Multiply that by twenty reports and it becomes a real time suck!  Instead, simply click the triangle until it turns green (soon to be Adobe red?) and you are done!

But wait!  There’s more…You will also notice that there are a bunch of check boxes next to each metric.  Those check boxes are used to choose which metrics you want to graph with your report.  You don’t have to graph every metric in the report, which may confuse your audience.  Also, I find that many clients don’t take advantage of the fact that you can display two graphs per report.  To do this, all you need to do is check off one of the boxes on the left and right side.  This is helpful if some of your metrics are numbers and them are percentages.  It is the closest SiteCatalyst comes to a secondary axis you may be used to in Excel.

Remove Subrelation BreakDowns
If you frequently use  eVar Subrelation reports, you may find that after breaking one eVar down by another eVar, you want to go back to the report before it was subrelated.  For example, let’s say you have opened aTraffic Driver report and broken it down by Offer Type as shown here:

Now let’s say you change the date range and some other report settings and then decide you want to just see Traffic Driver Type by itself again.  Unfortunately, if you use the trusty “Back” button in your browser, you will have to re-do all of those customized settings.  However, there are actually two ways to remove this subrelation without losing any work.

The first way to do this is to click on the “Broken Down by:” link shown in red above.  Once you click on this, you will see a list of all of your variables and you can choose the bottom-most one labeled “None.”  The other way is to click the green magnifying glass icon you used to create the Subrelation and do the same thing as shown here:

Double Your Searching Pleasure
Another thing I have noticed that a lot of SiteCatalyst users don’t know is that you can add search criteria to two different variables if you are using a Subrelation report.  To do this, click on the Advanced Search link and then you can use the drop down boxes to choose which variable/search term combination you want:

In this case, I have chosen to filter for all Traffic Driver Types containing “SEO” and can proceed to enter my search criteria for Offer Type…

Inherit Segments
If you use DataWarehouse or ASI, you probably spend a lot of time creating Segments.  If so, you may find times where you want to re-use some parts of a segment you have already created.  When I first started using SiteCatalyst, I did this by printing out my segments and re-creating them manually.  This is both time-consuming and prone to error, so I found the trick to do this more efficiently:

There it is!  See how easily you can copy an existing segment?  Do you see it?  If not, would you believe me if I told you that there are actually two different ways to re-use segments on the above screen?

The first way to do this is to click the icon to the right of the Segment title.  This will pop-up a new window which allows you to pick an existing segment you want your new segment to be based upon.

The second way to do this is to use the Segment Library.  You can access the library by clicking its name next to the “Components” item.  The Library is used to store commonly use segment building blocks.  In the example below, I have created a Page View container that looks for Pages where the IP Address Geography is in the United States.  By dragging this over to the Library, I can re-use this anytime I am creating a new segment.

Filter Report Suites
If you have Admin rights to your SiteCatalyst implementation and deal with a lot of report suites, the Admin Console quickly becomes one of your best friends.  One of the most time consuming Admin Console tasks is finding the report suites you are looking for among all of your report suites.  I frequently see people scanning up and down over and over hunting for the report suites they need.  Fortunately, there is a much better way that is somewhat hidden – using the “Saved Searches” feature of the Admin Console.  Using this feature you can create a filter to find report suites such that even if you add new ones, they will be added to your saved search if they meet the criteria.

Here is a real-life example.  When I joined Salesforce.com, we had a lot of report suites and I began creating new report suites.  When I created the new report suites, I simply added the phrase “New” to my new report suites titles.  Once I did this, I clicked on the “Add” link within the Saved Searches area of the report suite manager and created a “Saved Search” rule like this:

Keep in mind that this is a very basic rule.  You can actually add multiple criteria items and can build rules that take into account any of the following report suite criteria:

Lastly, if you are an Admin, be sure to read my past blog post with even more Admin Console Tips.

Final Thoughts
So there you have it.  As you can see, none of these items are critical showstoppers, but I have found that knowing them can help speed up your day and give you SiteCatalyst bragging rights!  Do you know of others?  If so, please share them here as comments!

Robots are cool.  I like robots when they build cars, try to plug oil spills and clean carpets.  The only types of robots I don’t like are the ones that hit websites repeatedly and throw off my precious web analytics data!  Do you have a problem with these types of robots?  Would you know how to see if you do?  I find that many web analytics customers don’t even know how to see this, so in this post I will share what I do to monitor robots and hope that others out there will share other ways they deal with robots.

Why Should I Care About Robots?
This is often the first question I get.  Who cares?  Here are my reasons for caring about minimizing robots hitting your site:

1. If you use Visits or Unique Visitors as part of any of your website KPI’s (i.e. Revenue/Unique Visitor), you should care because robots are inflating your denominator and dragging your conversion rates down
2. If you are tasked with reducing Bounce Rates on your site, you should care as robots will often be seen as bounces
3. Omniture (and other web analytics vendors) often bill you by website traffic (server calls) so you may be paying $$$ for junk data
4. Often times web analytic KPI’s have razor-thin differences month over month and having a lot of garbage data can mean the difference between making a good and bad website business decision

Do I Have a Problem?
The first step is to identify if you have a problem with robots.  Unfortunately, SiteCatalyst does not currently have an “out-of-the-box” way to alert you if you have a problem (@VaBeachKevin has added this to the Idea Exchange so please vote!), but in the meantime, here is my step-by-step approach to determining this:

• Create a recurring DataWarehouse report that sends you Page Views and Visitors for each IP address hitting your site (If you store the Omniture Visitor ID in an sProp, I would use that in place of IP address).  This can be daily, weekly or monthly depending on how much traffiic your website receives.  I sometimes add the Country/City as well (you’ll see why later).

• When you receive this report, it should look something like this:

• Once you have the data, I create a calculation which divides Page Views by Visitors and then sort by that column (if you have a lot of data from different days/weeks, you can create a pivot table).  The result should look like the report below where you will start to see which IP addresses are viewing a lot of pages on your site per visitor.  Keep in mind that this doesn’t mean they are all bad.  It is common for small companies or individuals to share IP addresses.  The goal of this step is just to identify the IP addresses that might be issues.  In the example below, you can see that the the top two IP addresses appear to be a bit different than the rest.  While it may make you feel good that these unique visitors liked your website so much they viewed thousands of pages each, you might be fooling yourself!

• Once you have this list, I like to do some research on the the top IP Address offenders.  You can do this via a basic Whois IP Lookup or you can invest in a reverse IP lookup service.

What Do I Do If I Find Robots?
If after reviewing the top offending IP addresses you find that you do, in fact, have a robot hitting your site, you have a few options:

1. Work with your IT group to exclude these IP addresses from hitting your website.  This is your best option since it will be the most reliable and reduce your web analytics server call cost.
2. Work with Omniture’s Engineering Services team to create a DB Vista Rule that will move these website hits to a new report suite so it will not pollute your data.  The best part of this option is that you don’t have to engage with your IT team and you can add/remove IP addresses anytime you want via FTP.  Unfortunately, you will still be hit with server call charges for this (not to mention the cost of the DB Vista Rule!), but if you also pass data to Omniture Discover, you might save money there by not passing bad data to Discover.
3. Work with Omniture’s Engineering Services team to build a custom solution for dealing with robots…

Employee Traffic
While I don’t want to imply that your co-workers are robots, I wanted to mention employee traffic in this post as well since it is tangentially related.  I find that many Omniture customers don’t exclude their own employees from their web analytics reports.  This can be a huge mistake if you have a lot of employees or have employees who actively use the website.  For example, at my employer (Salesforce.com), we use our website to log into our internal systems which are all run on Salesforce.com!  This means that we have thousands of employees hitting our website every day to log in to our “cloud” applications and that traffic should not count towards our marketing/website goals.  Therefore, we manually exclude all employee traffic from our reports by IP address to minimize the impact of employee traffic impacting our KPI’s.  While we don’t consider this to be robot traffic, we address it in the same manner by passing employee traffic to its own report suite.  One cool by-product of placing employee traffic in its own report suite is that you can see how often your own employees are using your website so you can show management that the dollars they give you serve multiple audiences!

Final Thoughts
As I stated in the beginning of this post, this is just one way to investigate and deal with robots.  If you have other techniques, please share them here!  Thanks!

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 = 2.5 Minutes)

From time to time, I hear people talking about Data Extracts in SiteCatalyst (especially on Twitter).  In this post, I thought I’d review them in case you are unsure of what they are and how they are used.

What Are Data Extracts?
The good news is that if you know how to use the SiteCatalyst ExcelClient then you are essentially an expert in Data Extracts, you just may not know it!  Behind the scenes, Data Extracts are really just a different way to access the engine that powers the ExcelClient data blocks with which you are already familiar.  The main difference between the ExcelClient and Data Extracts is that Extracts are normally used to have a report e-mailed on a regular basis without having to go into Excel (especially good for Mac users!).  Any report for which you can create a data block in the ExcelClient can also be accessed using the Data Extract icon in the SiteCatalyst toolbar:

If you cannot see the icon shown above in a SiteCatalyst report that means you cannot create a Data Extract for that report.  Once you click the icon, you will see a new screen that looks like this:

If you have used the ExcelClient, this should look familiar and you use this screen to choose how much data and what metrics you’d like to see.  Whatever settings you choose on this screen are what you will be stuck with (except for date which I believe is floating).  Finally, in the example below, notice that Data Extracts (and the ExcelClient for that matter!) have access to the same Classifications, Correlations and Subrelations that are available when using the normal SiteCatalyst user interface (click the green magnifying glass icon).  In this example, I am showing a correlation between Day of Week and Hour of Day:

Once you have configured your Data Extract, the last screen will ask you if you want to have it send via e-mail, added as a bookmark or both.  In a minute I will share with you why it is advantageous to store Data Extracts as bookmarks, but I recommend keeping any Data Extracts you create in an “Extracts” folder in case you ever need them again.

That’s it.  You’re done.  If you have e-mailed yourself the report, it will arrive shortly thereafter.  However, I have to explain something that often perplexes folks.  If you chose to add a bookmark, inevitably at some point you will open that bookmark using your bookmark toolbar and be facing a screen that looks like this:

If you are like me the first time I saw this, you might be a bit confused.  I expected to see the actual report, but that will never happen.  This screen is only to be used to modify your Data Extract and to open it so you can re-send it to yourself or others.  At first, I decided that this devalued my decision to store my Data Extract as a bookmark, but don’t despair because SiteCatalyst makes up for this by allowing you do something really cool with bookmarked Data Extracts.  If you open the ExcelClient and choose to insert a new Data Block, you can create a new one or you can choose from any Data Extracts you have created (or shared ones) as shown here:

Notice that the new Data Extract we just created appears here.  All we have to do is to click the “Insert” link and it will add the data block to our Excel spreadsheet and run the query:

This saves you having to re-create it in the ExcelClient and you can still edit it to suit your needs after it has been inserted.  The only bummer is that you cannot tie the Data Extract data block to cells in Excel so if you are ever looking for dynamic data blocks, start them in Excel, not as Data Extracts.

So that is pretty much all you need to know about Data Extracts.  One final note – it is my understanding that Data Extracts do not work with the new Omniture ReportBuilder, but perhaps something similar will be rolled out in the future.

(Estimated Time to Read this Post = 2.5 Minutes)

In my last few posts I have been delving into Web Analytics & CRM (Customer Relationship Management) integration.  In my first post I described how you can pass Web Analytics Data to your CRM system to help your sales people.  In my last post, I described how you could pass CRM data like Leads, Opportunities and Revenue into your Web Analytics tool.  In this post, I will round out the trilogy by describing how you can use CRM data as Web Analytics meta-data to enhance your Web Analytics reporting.

My Golf Handicap Story
Since most people don’t often like talking about meta-data, I will begin by sharing an easier to understand story which first taught me how interesting integrating CRM and Web Analytics data could be.  Back when I managed the website for the CME, we had situation in which we were trying to sell tickets for a major golf tournament.  Unfortunately, the event was nearing and we still had lots of tickets to sell.  At the time, I recalled that, for registered website users, we had golf handicap as one of our CRM fields in our Salesforce.com system (our customers were traders and spent a lot of time golfing!).  I had recently worked on capturing each customer’s website ID in SiteCatalyst and also placing it in our CRM system.  Suddenly, the light bulb went on in my head…why not upload golf handicap as a SAINT Classification of the website ID I had in an sProps and eVar in SiteCatalyst?  I created a SAINT Classification table that passed in the raw handicap and also grouped it into buckets like this:

Whereas previously I could see what pages each website ID had viewed on the website, I could now expand that to see the same data for this new golf handicap Classification of that variable.  The result was a report like this, in which I could see the most popular pages for website visitors by golf handicap:

From there, all that was left to do was to target some ads on those pages and voilà, the tickets were soon gone!

For me, this was more experimental than anything else, but it was the catalyst (no pun intended!) which helped me see the power of  integrating CRM and Web Analytics.  Of course back then there were no API’s to help pass data between systems, but nowadays, this is much easier (i.e. Genesis integrations).  With this in mind, let’s take a look at a few more examples of how you can take advantage of this concept.

Examples of Passing CRM Meta-Data to Web Analytics
Now that you get the general idea, I’ll walk you through some other examples of enriching your Web Analytics data by bringing in CRM meta-data.  Let’s assume that you have done the steps outlined in my last post and have made a connection between your Web Analytics visitors and your known CRM prospects/customers.  Using the primary key described in my last post, you can export whatever CRM fields you care about from your CRM system and import them into your SiteCatalyst implementation as SAINT Classifications.  Here, you can see that I have decided to export Industry, # of Employees, Lifetime Value and a Lifetime Value grouping (to make my reports more readable) from my CRM system and import them using the following SAINT file:

Now that I have done this, I can open my Lead Gen ID report in SiteCatalyst and look at any of these CRM fields as Classifications.  Here is a view of some of my Success Events by Industry:

Here is the same data viewed by # of Employees:

Here is the same data viewed by Lifetime Value:

The same concept can apply if you are using other Web Analytics tools.  Here is an example of viewing reports in Google Analytics by Job Title (in this case filtering for CIO’s):

Final Thoughts
As you can see, once you have made the connection between your Web Analytics and CRM system, there are lots of creative things you can do with respect to augmenting your traditional web analyses.  I know a lot of people also do this in tools like Quantivo or Omniture Insight, but I hope this was helpful to see some of the ways to do this if you only have access to SiteCatalyst.