Some SiteCatalyst Implementation Pet Peeves [SiteCatalyst]
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.
I chuckled a little when I read about capturing salutation. I guess if you don’t have much other interesting data to capture, and you’ve got 75 eVars. . .
I had to laugh. Your first pet peeve is exactly what our Omniture implementation specialist had us do. LOL
@ Dave – Snap! We got exactly the same advice for our implementation.
If the experts don’t get it then what hope have the rest of us got?!
Adam,
The difference has to do with segmentation. If you use a Page View container and segment by an eVar, you’ll get the page view where the eVar was set AND all subsequent page views where the eVar persisted. If you use a Page View container and segment by a prop, you’ll get only the page views where the prop was set, a functionality that cannot be duplicated in any other way.
Thanks,
Ben
Adam, I can see the point behind the menu customization, but it sure makes troubleshooting an implementation very difficult for somebody who’s trying to find a report in the first place! Yes, there is the search bar for finding reports, but that can go only so far when multiple reports have the same name
I always like to append either the full name of the variable that populates the report or an acronym (for the events) to the end of the variable/report name. For example:
“Product Finding Methods (eVar1)”
“Search Term (eVar2)”
“Page Type (prop1)”
“Email Subscriptions (e1)”
“Shipping Revenue (e2)”
etc.
That way, if you have a variable map but the menu is customized, you can search for the report by *variable* in the search bar and get the report you want very easily.
And regarding the salutations, it’s important to know how many doctors visit the site. You’ll never know whether you should be selling golf clubs without this type of information! 🙂
In SiteCatalyst 15, you’ll also now have visitors for all eVars. So there’s even another reason to not use a prop for that.
Jason – Agreed…I think if SiteCatalyst ever lets you do pathing on an eVar, it may be able to phase out sProps one day…
Ken – I do like the idea of putting variable numbers in variable names (especially when people have duplicated every variable as an eVar and sProp!). That would be in my opposite blog post of implementation items that make me happy! Also, not sure if you have used this, but there is a feature in SiteCatalyst (under “Report Settings” that lets you override custom menus with the default ones if you want. It doesn’t work for me 100% of the time, but I believe its purpose is to let you go back to the default report menus…
Adam – I’ve always heard that the difference between pros and eVars will go away one day. I’d imagine pathing for eVars will happen eventually. Reading your post here is making me critically evaluate my own SDR right now for an upcoming implementation!
Adam, great post as always.
Another common reason that I see people using s.props is for list values (multiple values on the page). Unfortunately you can’t do list eVars and passing the data into the products variable is not always practical.
I do have a story to share about turning on pathing on customer ID. One of our early clients suspected that some of their visitors were using multiple customer IDs in order to give points to each other and cheat the system (a social gaming site). By turning on pathing for the prop, they were able to see exactly which users were logging back and forth with different customer IDs. In one instance the same person had over 30 customer IDs.
I know this is uncommon but though I’d share.
Great list, Adam – thanks!
With version 15 having arrived I must say I completely agree with your comments on when props should be used. Pathing (and the metrics that come with enabling Pathing) and Unique Visitors are the only reason to be using props: eVars FTW!!
To comment about your hatred of reports that are not populated with data I completely agree. Plus: I wish there was a way to quickly check every report in Omniture to see if there is data populated. This would be my first step in every audit I ever did. In fact, it’s still one of the first steps I do while performing audits, it just takes too long. Wouldn’t it be nice if the Admin Console provided you with some information like a Checkmark if data has been populated to each variable within the last 30 days? Hmm… I’m taking that to ideas.omniture.com!
I also believe that SAINT de-duplication is a new feature of v15, so that should even further prove your points about minimizing the number of variables used. SAINT is our friend!!
If I had a pet peeve to add to your list, I’d suggest customers who never use Custom Links but have highly dynamic and interactive sites. Come on people – Custom Links are a great feature, use it!
Thanks, and keep up the great posts!
Ali – Thanks for sharing that use of pathing on a Customer ID. That obviously makes sense and uses the pathing function correctly…
Copying an eVar to a prop may remain relevant in both a Discover and/or SC15 environment.
Depending on the allocation/expiration of an eVar, I find props prove quite useful for segmentation.
Granted, this is not true for every eVar set.
Joe –
Why would copying an eVar to an sProp be relevant in Discover and SiteCatalyst v15? In Discover, you can break eVars down by eVars or sProps, so I am not sure why they would need to be duplicated. Since you can expire an eVar at a Page View, you can make an eVar act like an sProp as far as SiteCatalyst v15 is concerned. I’d love to hear concrete examples why duplicating an eVar to an sProp is valuable to v15 or Discover…Thanks!
Adam
Adam,
I agree we can replicate the functionality of props with the proper allocation/expiration.
Many of my eVars persist until one specific conversion event. However, I frequently need to look at the same data in ways where this persistence is a detriment.
This would not be an issue with additional eVars or (preferably) allocation/expiration variable at the report level.
Thanks,
Joe
Ben – Great point…I don’t use PV containers all that often, but I could see how that is useful. Thanks!
Another pet peeve candidate is setting eVars on every page and blowing the Instances metric.
Then there’s the absence of the Instances metric in DW
I’m not familiar with the concept of a pageview container. Can you guys further explain or link me to an explanation?
Thanks!
Here is a link that goes into more detail on segments: http://blogs.omniture.com/2008/11/05/segment-builder-best-practices-inside-omniture-sitecatalyst/
ah thanks. Completely missed how Ben changed the conversation to Discover/Data Warehouse/Version 15 Advanced Segments 🙂
Understanding that makes Ben’s comment make much more sense!
@eric – like your idea for the Audit. Is this in the Ideas exchange as I’ll vote for it?
@Adam,Ben,Joe: In Discover you can also use the very powerful “eVarX Instance” metric to only get the PV/Visit in which the variable was populated. No need for an s.prop.
The “every s.prop in an eVar” situation can be an indicator of the point in implementation lifecycle, though. I saw several implementations started with s.props only (eVars are harder to understand). Then the implementation matures, people use events instead of visits as KPIs and the focus shifts from traffic to conversion variables. So lots of eVars are copied to eVars. I’d say it’s the step before new requirements are gathered and a “re-structure the implementation” project is done. This time with a better understanding of eVars.
so long
nic
Adam,
I really enjoyed reading this post.
I only identified one pet peeve on your list that I’m guilty off (weekday/weekend) so not doing bad.
I think having props equal to evars is still useful even if you have Discover simply because most end users won’t have access to Discover. Or the Discover licence does not cover all report suites.
In the past year I’ve managed a pretty extensive implementation for one of my clients. Upon completion I reflected on many of the variables captured thinking “did we really need them all?”.
However, we are now using more and more of them as the organisation’s insight needs mature.
My (obvious) point is: it is hard to balance current insight needs with potential future needs, especially if you have one shot at it.
Thanks,
Michael
I think you are a bit off on the clients who have matching props and eVars. Adobe implementation consultants stress that it is a best practice. It seems that your peeve should be with them instead the clients.
_
In your Pathing blog entry on Adobe’s site you mention that you use the Pathfinder Report for your analysis. That’s going away in version 15 and “they” say there are no plans to add it back. Sometimes nothing else works as well.
Andrew,
Thanks for the comment. I can’t speak to what Adobe Consultants recommend now, but it wasn’t that way when I was there. They are welcome to comment here any time.
As for Pathfinder in V15, that is something you should raise with Adobe. Maybe a blog post on why you like it?
Adam,
as usual great post.
Only thing I personally disagree is disabling unused vars if you have a standardized set of variables across a lot of suites. Disabling can be a problem if you update code and forgot to enable them again because you thought they are “standard”. But I’m totally with you that hiding in the interface is an alternative.
Thanks
Andreas
Thanks Andreas…I guess I was referring to disabling variables that are not used in ANY reports suites. If they are used in some, but not others, you can also just hide them in the menus…
Adam
should i be concerned that i have a “full house” of pet peeves?
Barry,
List them here…
Good info here. Thank you Adam. BTW, are you guys still using spreadsheets for creating tracking codes? We started using Taglynx since it works with Omniture/Adobe Analytics and enforces a naming convention: http://ta.gl/ndxRSn