Adam Greco's Blog at Web Analytics Demystified

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!

Posted Tuesday, July 12th, 2011 | 4 responses | Share, Save or Email

Have you ever had someone run a report in SiteCatalyst and come running to you saying something like this?

This report doesn’t make sense…There is obviously a tagging issue and you need to fix it ASAP!

If I had a dollar for every time this happened to me, I’d be a rich man!  The truth is, that after many wild goose chases, the problem is not usually tagging related (note you can use tools like ObservePoint and DigitalPulse to verify).  But if it ever was tagging that caused the issue, it was usually related to the release of a new JavaScript file.  That has been the culprit many times for me over the years.  Therefore, in this post, I will share a trick you can use to easily find out if data issues you might be experiencing might be related to a new JavaScript file release.

Tracking Your JavaScript File
So how can you use SiteCatalyst to determine if a new JavaScript file you released is wreaking havoc on your data?  For example, let’s imagine a scenario where the morning of May 18th, you started seeing some strange data irregularities (possibly by checking Data Quality as described here!).  Here is what you need to do:

1. Each time you create a new version of your JS file, assign it a version number (i.e. 0.5, 0.8, 1.2)
2. Pass this version number into a tool that can store it and let you know when it sees the version number change
3. Look at a report that shows you when the version number value has changed (what date it changed and at what time)

Sounds easy right?  If only we knew of a tool into which we could pass data, have it be time-stamped and report upon changes in version number values…Hmmm….Where would we find such a tool??

Obviously, we already have that tool and it is SiteCatalyst!  We can use the tool we know and love to track each version of the JavaScript file by simply passing in the version number of the file into an sProp on every page (and yes, I get the irony that we are using a JavaScript file which sets a beacon to enable tracking to track itself!). By doing this, we will have a historical record of when each JavaScript file was released.  After you pass in the JavaScript File version you will see a report like this:

Here we can see the distribution of page views related to each JavaScript file version.  In this case, we have been busy and have had four JavaScript file changes in one month!  However, this report isn’t super-useful in answering our initial question: Were the issues we saw on the morning of May 18th related to a new JavaScript file release?

To answer this question, all we have to do is to switch to the “trended” view of this report and we will see a report like this:

Now we can start to see the flow of JavaScript file updates.  Looking at this report, we can see that we moved from version 0.5 to version 0.7 (poor version 0.6!) on May 18th… This might support our hypothesis, but to be sure, we can look at this report by hour on May 17th & 18th and see this:

 

Now we can narrow things down to an hour and it looks like the JavaScript file did, in fact, change around 9:00 am on May 18th.  As you can see, the simple action of taking the administrative step of keeping your JavaScript file in an sProp can provide an easy way for you to do some sleuthing when you are in a pinch!

Additionally, if you want to further test your hypothesis, you can isolate data that is related to a specific JavaScript file to see if it represents the issue you are seeing.  To do this, simply use DataWarehouse to create a segment that only pulls pages that had data collected using a specific JavaScript file version as shown here:

 

Final Thoughts
So there you have it.  Just a quick tip that you should consider adding to your SiteCatalyst implementation the next time you make an update.

Posted Wednesday, July 6th, 2011 | 5 responses | Share, Save or Email

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 PageName 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.

Posted Monday, June 27th, 2011 | 29 responses | Share, Save or Email

One of the features that I find deceptively difficult at times in SiteCatalyst is the use of the Search feature.  I feel like there are many times I use this and end up messing it up.  Therefore, I decided to do my best to share what I have learned about what works and doesn’t work in the hopes that it will save you aggravation and time!  I also hope that many you can add a comment to this post with your tips and tricks so we can all learn something…

The Basics
First, let’s start out with the basics.  Hopefully if you are a SiteCatalyst user you know that the search function is used to filter results in eVar and sProp reports.  You simply enter a value and SiteCatalyst will look for those values in the active report and return those rows.  This is handy because you can bookmark reports, make custom reports or add reports to dashboards after you have created the filter so that you never have to apply it again.

For example, let’s start with a Pages report like this:

Obviously we have pages from all sorts of countries, but if we only wanted to look at pages from England, all we would have to do is enter “SFDC:uk:” in the search box (top-right) and we would then see a report like this:

But what if we wanted to see pages from England or France?  At this point we have two options.  You can either enter “SFDC:uk: OR SFDC:fr” in the search box or use the advanced search editor.  Here is what it would look like with the OR statement in the regular search box (look at the top-right portion):

However, believe it or not, if you change the “OR” to be a lower case “or” you will get no results!  I kid you not!  I call that an “Omniture-ism” and you just have to remember it…

The other way to get to the same report is to use the Advanced Search tool.  You get there by clicking on the Advanced link to the right of the search box.  Once there, you would enter the appropriate phrase in the first box, click the “+” sign to add another search criteria and then enter the second phrase so it looks like this:

However, it is important that you change the top drop-down box from the default of “if all criteria are met” to “if any criteria are met” or you will get no results.

If you wanted to look for cases where there were pages on the UK website that had the phrase “form” in the pagename, that would be a case where you would use the “if all criteria are met” option and your query should look like this:

This would result in a report like this:

Finally, we can come full-circle and get more advanced and use an “AND” statement in the standard box to get the same result.  Here is what the search box would look like:

Again, keep in mind that the “AND” is case-sensitive…

More Difficult Searches
So now that we have covered the basics, let’s get a bit more advanced.  First, let’s keep going with our example and say that we need to find all pages in the UK or France that have the word “form” in them.  This gets a bit tricky because we are mixing OR and AND statements.  Using the Advanced Search query builder, here is how you would enter it:

Conversely, if for some reason we wanted to see any UK Pages that had the phrase “form” in them and all France pages (not sure why, but this is just an example), we would enter this:

Which would result in a report like this:

Note that in this case we had to change the drop-down box back to the “any criteria” option since we did the AND statement within one of the criteria (hey…I told you this was the difficult part!).

The trick here is to combine any OR and AND statements into each row since each of the individual search criteria have to be either an “AND” or “OR” clause.

On a separate note, in the advanced search area, you can change the drop-down which defaults to “Contains” to “Does Not Contain” so if, for example, you wanted to see all UK pages, but exclude those that had “login” in the name you would enter the following criteria:

Note that for this instance, we need the “all criteria are met” option…

Finally, just for fun I entered the following phrase in the “simple” search box…

…and miraculously it produced the same results!!  I decided to stop here before I broke anything, but you can feel free to see how far you can push this!!

But wait…There’s more!  I have been amazed by how few people I meet know this next one…  Imagine that you are looking at an eVar report and you have broken it down by another eVar via Subrelations.  Here is an example where I have taken the Site Locale eVar and broken it down by Internal Search Term:

Now, let’s say that you wanted to do a search filter to only see items that mention “Outlook.”  The easy way to do this is to just enter the phrase “Outlook” in the search box and SiteCatalyst will show any rows that have that phrase.  But what if you wanted to see the phrase “Outlook” in just United States or Japan?  No matter what you put in the search box, you will not get the results you are looking for (i.e. outlook AND “united states” OR japan).  Would you know how to do this?  Most people I meet don’t.  Here is how…

When you are using a Subrelation report, you have to keep in mind that SiteCatalyst is running two reports and it doesn’t know which report you want to filter on.  Therefore, we need to tell SiteCatalyst which report we want the search term to be associated with.  You can do this in the Advanced Search area.  When you have a Subrelation report, and you click on the Advanced Search area, you will see a new option that allows you to select one of the two reports being subrelated like this:

Most people haven’t ever noticed this new option so now that we know it is there, all we have to do is select the right report and then enter the search term in the right report and we can get our results.  For the example above, we would enter “Outlook” in the search box next to Internal Search Term and “United States OR Japan” in the search box next to Site Locale like this:

Now, since we have been a bit more specific, we can get a nice, clean report like this:

Just keep this handy feature in mind the next time you are trying to search in a Subrelations report and pulling your hair out because you can’t get the results you think you should!

Even More Difficult Stuff
Phew!  If you’ve made it this far, you are really devoted to your craft.  We’re almost there so hang on…

The next thing that is important to know is that you can use wildcards in your searches.  To do this, you use the “*” symbol in the search query.  For example, if we wanted to find any pages in the UK that has the phrase “landing” somewhere in the name, we could simply do a search like this:

The next thing to know is that Omniture can be a bit quirky when it comes to the [SPACE] separator in the search box.  Let me illustrate.  If I enter the phrase “home page” in the search box, here are the results I get:

This seems strange to me since none of these pages have a space in them.  That would make you think that a [SPACE] is a valid separator and that this query is the same as “home OR page” right?  But if I use that logic and enter this phrase “SFDC:uk: SFDC:fr:” which is really just two phrases separated by a space (just with a colon in the phrase), I get no results.  I am sure there is a logical reason for this, but I am not sure what it is.  Maybe if SiteCatalyst sees a “:” or a “|” it acts differently (maybe Jorgen can enlighten us on this)?

To be safe, I use the next feature – using quotes – whenever possible. My advice is that if you ever have phrases with spaces in them that you enclose them in quotes and stick to using OR statements.  In the preceding example, if I change my “home page” query to be “home page” in quotes, I get the expected result which is no results.  Another lesson to be learned here is that you should, whenever possible, avoid putting spaces in values that you think you will search upon.  I do my best to remove all spaces from page names since that is the variable I search on the most!

Finally, you can use the “-” sign to remove things from search results.  This produces the same effect as using the “Does Not Contain” feature in the advanced search area.  As in the previous example, if I want to see all UK pages, but not ones that have the phrase “login”, I can enter the following in the search box:

To see UK pages that do have login in the name, you can also enter this phrase:

But when the results come back, it will mysteriously remove the “+” sign and just uses space as the separator producing the same results.

Final Thoughts…
So there you have it!  Pretty much everything I know about using search and advanced search in SiteCatalyst.  Do you have any additional tips or tricks?  If so, leave a comment here…Thanks!

Posted Thursday, June 16th, 2011 | 14 responses | Share, Save or Email

A few weeks ago I was at the European Adobe (Omniture) Summit in the UK and had the pleasure of being in another one of Brett Error’s “what features are we missing” sessions.  I find these sessions to be good and bad at the same time.  The good part is that people are expressing what they need and others can validate or invalidate ideas in real-time.  The bad part is that I often feel that the features that get voted up are the ones that are easy to understand (like Bounce Rate as a standard metric!), but that there are many features that people SHOULD want, but don’t know it yet.  I don’t mean that to come out as sounding pretentious, but the fact is that many people have been using the product for only a few years and it is natural that the needs of those who have been using the product for many more years will have some more advanced feature requests.  Unfortunately, many of these advanced features, no matter how important, will be trumped by more basic, globally understood feature requests.

The creation of the Ideas Exchange has been a great help in getting ideas big and small into the product and I am so pleased to see that many of the ideas in there have been added to the product and for that I commend Adobe (Omniture).  I think the positive feedback around SiteCatalyst v15 is a direct result of people seeing their ideas manifested in the release.

In this post, I wanted to highlight a few ideas that are in the exchange that might not get as much “play” as they should and why I think they should be undertaken.  If you agree and have a Login ID to SiteCatalyst, please feel free to login and vote for them!

SAINT Auto-Classifications
One of the ideas that came up in the UK session I mentioned earlier (and received the most votes!) was the notion of SAINT Auto-Classifications.  This idea was submitted by Ben Gaines (probably as an initial test of the Idea Exchange!) the day the exchange came online.  As most users know, SAINT Classifications are a way to add meta-data to values you have already captured in SiteCatalyst.  It is similar to a pivot table in Microsoft Excel.  However, SAINT Classifications have to be uploaded manually and it becomes very tedious over time.  The feature request is to provide a way where administrators could set-up rules to auto-classify items or classify them on the fly (as reports open up).  For example, if I have a report of campaign tracking codes and a bunch of them start with “seo|,” I could set something up where these would all be automatically classified as “SEO” in the Marketing Channel classification I have set-up.  This is just one example, and the possibilities are endless.

The great news is that this idea has recently been changed to “Under Review” and geniuses like Sean Gubler have started playing around with tools to do this so I feel like it is only a matter of time before we see this.  Keep your fingers crossed and vote for the idea by clicking here.

Multi-Session Attribution (Allocation)
The next idea is related to eVar attribution.  Currently, you can attribute success to eVar values for First Touch, Last Touch.  There is an option for Linear allocation, but that only works within one session so it is rarely used.  The closest thing available for multi-session attribution is the Cross-Visit Participation plug-in which is really just a “hack” that concatenates eVar values into one string.  This plug-in can be useful at times, but has some serious drawbacks.

In today’s world of people bouncing between websites and social media, you cannot count on the visit that people convert being the same one in which they came from a marketing campaign.  Therefore, you often have cases where a visitor comes from an SEO keyword, does some product research, leaves the site, comes back the next day from a paid search ad, leaves the site and then comes back a third time just typing in the URL and then converts.  This string of traffic sources is difficult to track and analyze using the eVar allocation feature set available today.  What I feel is needed is a way to simply have SiteCatalyst extend its Linear Allocation feature to include multiple visits and make that a legitimate setting in the Admin Console.  I’d even pay more for it if needed, since not everyone will need that level of sophistication.  I personally think that attribution will become a bigger issue in the future as the current browser model fractures so I think this will be an important feature for all web analytics vendors going forward.  You can read some of my partner Eric Peterson’s thoughts on appropriate attribution in this white paper.  If you’d like to see SiteCatalyst go deeper with attribution, please vote for this idea by clicking here.

Multi-Session Pathing
Along the same lines, the next idea I’d like to suggest is the notion of multi-session Pathing.  I suggested this to the Ideas Exchange over a year ago and was surprised to see that it only has 7 votes!  Currently, pathing reports are limited to one session.  However, it is often the case that visitors come to your website multiple times before they convert.  Wouldn’t you want to see paths that span multiple visits for the same person?  I realize that this can be data intensive, but even if it is for a subset of data, I think it would be interesting to pick a subset of visitors and see what they do over multiple visits.  Currently, you can’t even do this in Discover.  While I am not sure of the exact way the feature should be implemented, I feel that having some insight into multi-session pathing is important and should be somewhere on the roadmap.  If you agree, you can vote for this idea by clicking here.

Expire eVars Based Upon Event or Time
The last feature request I’ll mention has to do with expiring eVars.  Currently, you can expire an eVar based upon a time period (like Visit or 30 Days) or a Success Event but not both.  So why is this important?  Imagine that you have a situation where you have an eVar set to expire at the Purchase event.  A person could come to your website from a specific campaign code and then not return for an entire year and then convert.  In that scenario, the campaign code they came from a year ago would get credit for the conversion.  However, there are cases in which you would not want that to happen so it would be great if it were possible to have SiteCatalyst expire the eVar at the Purchase event or after 30 days – whichever comes first.  That would offer much more flexibility and tighten up eVar attribution across the board.  Someone also added a comment to this idea with the idea of allowing an eVar to expire at Success Event X or Success Event Y.  That would also be helpful.  If you’d like to see this implemented, please click here to vote for it.

Final Thoughts
As I mentioned at the beginning of this post, there are some features that could have a big impact if added to SiteCatalyst, but they are ones that only those who have been through some big battles would know are needed.  My hope is that you will think about these features and support them with your votes so we can all benefit.  Thanks!

If you have any questions or want to learn more, feel free to contact me for more information.

Posted Friday, June 10th, 2011 | 8 responses | Share, Save or Email

EDITOR’S NOTE:
Since joining Web Analytics Demystified, the most common email/comment I have received goes something like this:

“When are you going to get back to blogging about cool, advanced stuff you can do in SiteCatalyst?”

While in my new role, I am vendor-agnostic, I will do my best to keep sharing the SiteCatalyst tips & tricks I used to on my old blog.  My hope is that as I work with clients using all web analytics vendors, I will branch out and share tips & tricks for all technologies.  However, as I always tell people, the goal of my blog posts are to introduce concepts that can be applied to all web analytics tools…

Now on with a new tip/trick…

Dealing With Time of Day (Time Parting)
One of the analyses that I have done from time to time is Time Parting Analysis.  Time Parting Analysis consists of looking at the time of the day (or day of week) that website success takes place in order to better understand its importance.  While I don’t usually put a whole lot of stock into the time of day, there can be times where websites do much better/worse in the morning vs. evening.  Knowing this can be used when planning advertising so you can “strike while the iron is hot,” so to speak.

If you think Time Parting might be important to your business, you should capture the time of day in some manner into variables in your web analytics tool.  For example, if you use Omniture SiteCatalyst, you might use the Time Parting Plug-in to pass the time of day (in half-hour increments) to an eVar or sProp.  Doing this allows you to look at a report that might resemble the one shown here:

As you can see, this report allows us to see what the action is taking place on our website down to the half-hour increment.  If you are not already doing this type of analysis, it may be worthwhile since you can glean some new insights and use this data point for visitor segmentation.

Time Zone Hell!
However, inevitably you will run into a few problems with the above report.  First, someone at your organization will ask you which time zone the above report is related to.  Therefore, the first thing I recommend is that you clearly label your Time Parting reports with the time zone that the JavaScript file is using to capture the data.  In the example above, the “Hour of Day” report was labeled do be PST (Pacific Standard Time) so it can be easily interpreted by everyone using it.

The next problem you will encounter is that of multiple time zones.  If you work at a global organization and have people focusing on business in various locales, the above report is pretty much useless to many of your internal customers.  If they happen to be good at math and can calculate time zone differences in their head, then you’ll be ok, but most people have trouble interpreting web analytics reports without the added labor of doing on-the-fly time zone translation!

Want to see this problem in action?  Take a closer look at the report above.  Do you notice anything strange?  If you look closely, most of the Visits and Form activity took place in the evening.  People might like your product(s), but not so much that they are willing to spend their evenings looking at them!  The reason the above report looks strange is because it is for an Australian website, but the time zone is Pacific Standard Time.  If you are a web analyst in Australia, seeing your website success events in the Pacific Time Zone is not super-helpful!

So how do we fix this?  All it takes is a bit of creativity and meta-data.  Keeping in mind that there is a direct relationship between time zones, you can take the above report and apply meta-data to it to adjust for alternative time zones.  If you are using Omniture SiteCatalyst as in the example above, this means using SAINT Classifications.  By applying a different SAINT Classification for each time zone you care about, you can create new reports for each time zone.  Here is an example of what the SAINT file might look like for a few additional cities:

As you can see here, we took the data that was already being collected (the Key column, which in this case is PST) and added meta-data for four additional cities.  You can add as many cities as you want and each column you add will create a new report for that city time zone.  Once you have done this, you can see a new version of the report above adjusted for each time zone.  Now if we look at the same report above, but use the Sydney Time Zone classification report, we see a report like this:

You will notice that now we are seeing the same exact data as the first report, but now the times of the website successes are adjusted for the Sydney time zone.  This makes the report look a bit more normal for the Australian web analyst as the success events are now shown as taking place during more realistic business hours.  The best part of this solution is that anyone using the standard Time Parting plug-in Omniture provides can use the same SAINT Classification file.  It just needs to be adjusted so the “Key” column is the time zone for which you are collected the data.  If you are using the PST time zone, you can download the file I showed above.  If you are in a different time zone, you can still download the file and adjust it as necessary.

Caveats
As always, there are a few caveats with any “hack,” so here are mine:

• I take no responsibility for daylight savings time which can wreak havoc on time zone translations, but even in that worst case, your data will be an hour off…
• Time Parting reports can also be used to track Day of Week.  This is harder to adjust for than is time zone unless you are time stamping using the actual date and are willing to have a massive, multi-year SAINT Classification file.  This is not a bad approach, but is much more involved.  Contact me if you’d like to explore this.
• It is possible to collect time zone data using different time zones for each report suite.  For example, it may be better for you in the long run to have your Sydney data collected in the Sydney time zone and your London data in the London time zone, but I have often seen clients have issues with this and if you don’t start doing this from the onset, you can have issues going to it later.  Please consult your account manager for more details.

Final Thoughts
So there you have it, a few thoughts on Time Parting and a fun trick to make it more useful if you do business in multiple time zones.  Give it a whirl and let me know what you think…

If you have any questions or want to learn more, feel free to contact me for more information.

Posted Monday, March 28th, 2011 | 3 responses | Share, Save or Email

Posted Monday, March 21st, 2011 | 2 responses | Share, Save or Email

Posted Wednesday, March 9th, 2011 | 15 responses | Share, Save or Email

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!).  If you are interested in scans of your site code there are solutions to investigate such as ObservePoint or for a more in-depth review of your coding practices, whether they support your overall strategy, your JavaScript tags, and most importantly whether your tags introduce future inaccuracy or integrity issues we suggest contacting our partners at Keystone Solutions.

Posted Wednesday, February 23rd, 2011 | No responses | Share, Save or Email

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…

Posted Monday, February 7th, 2011 | 15 responses | Share, Save or Email