SiteCatalyst Variable Naming Tips

One of the parts of Adobe SiteCatalyst implementations that is often overlooked is the actual naming of SiteCatalyst variables in the Administration Console. In this post, I’d like to share some tips that have helped me over the years in hopes that it will make your lives easier. If you are an administrator you can use these tips directly in the Administration Console. If you are an end-user, you can suggest these to your local SiteCatalyst administrator.

Use ALL CAPS For Impending Variables

There are often cases in which you will define SiteCatalyst variables with a name, but not yet have data contained within them. This may be due to an impending code release or you may have data being passed to the new variable, but it hasn’t yet been fully QA’d to the point that you are willing to let people use the data. Of course, you always have the option to use the menu customization tool to hide new variable reports until they are ready, but sometimes it is fun to let your users know what types of data are planned and coming soon. Anther reason to enter names into variable slots ahead of time is to make sure that your co-workers don’t re-use a specific variable slot for a different piece of data, which can mess up your multi-suite tagging architecture.

So now, let’s get to the first tip. If you have cases in which you have variables that are coming soon, I use the Administration Console to name these variables in ALL CAPS. This is an easy way to communicate to your users that these variables are coming soon, but not ready to be used. All you have to do is explain to your SiteCatalyst users what the ALL CAPS naming convention means. Below is an example of what this might look like in real life:

I have found that this simple trick can prevent many implementation issues. For example, I have seen many cases where SiteCatalyst clients open a variable report and either see no data or faulty data. This diminishes the credibility of your web analytics program and over time can turn people off with respect to using SiteCatalyst. By making sure that reports that are not in ALL CAPS (proper case) are dependable, you can build trust with your users. When you are sure that one of your new variables is ready for prime time, simply go to the Administration Console and rename the variable to remove the ALL CAPS and you will have let your end-users know that you have a new variable/report that they can dig into.

Some of my customers ask me why I wouldn’t simply use the user security feature of SiteCatalyst to only let administrators and testers see these soon to be deployed variables. That is a good question. It is possible to hand-pick which variables each SiteCatalyst user has access to using the Administration area. Unfortunately, you can only limit access to Success Events and Traffic Variables (sProps). For reasons unbeknownst to me, you cannot limit access to Conversion Variables (eVars), which are often the most important variables (I have requested the ability to limi access to eVars in the Idea Exchange if you want to vote for it!). But you can certainly use this approach to limit access to two out of the three variable types if desired. Another approach I have seen used is to to move all of these impending ALL CAPS variables to an “Admin” folder using the menu customizer.

Add Variable Identifiers to Variable Names

As you learn more about SiteCatalyst, you will eventually learn the differences between the different variable types (Success Events, eVars and sProps). I have even seen that some power users end up learning the numbers of the specific variables they use for a specific analysis, such as eVar10 or sProp12. While normally, only administrators and developers care about which specific variable numbers are used for each data element, I have found that there are benefits to sharing this information with end-users in a non-obtrusive manner.

For example, let’s say that you want to capture which onsite (internal) search terms are used by website visitors. You would want to capture that in a Conversion Variable (eVar) to see KPI success taking place after that search term is used, but you also might want to capture the phrases in a Traffic Variable (sProp) so you can enable Pathing and see the order in which terms are used. In this case, if you create an eVar and an sProp for “Internal Search Terms” and label them as such, it can be difficult for your SiteCatalyst users to distinguish between the eVar version of the variable and the sProp version of the variable (which is even more difficult if you customize your menus).

Therefore, my second variable naming tip is to add an identifier to the end of each variable so smart end-users know which variable they are looking at in the interface. As you can see in the screenshot above, I have added a “(v24)” to the Internal Search Terms eVar and “(c6) to the “Internal Search Term” sProp as well as identifiers for all other variables. This identifier doesn’t get in the way of end-users, but it adds some clarity for power users who now know that internal search phrases are contained within eVar 24 and sProp6. Being a bit “old school” when it comes to SIteCtaalyst, I use the old fashioned labels from older versions of the JavaScript Debugger as follows:

• Success Events = (scAdd), (scCheckout), (e1), (e2), (e3), etc…
• Conversion Variables = (v0) for s.campaigns, (v1), (v2), etc…
• Traffic Variables = (s.channel), (c1), (c2), (c3), etc…

Obviously, you can choose any identifier that you’d like, but these have worked for me since they are short and make sense to those who have used SiteCatalyst for a while. Another side benefit of this approach is that if you ever need to find a report in a hurry and you know its variable number, you can simply enter this identifier in the report search box to access the report without having to figure out where it has been placed in the menu structure. Here is an example of this:

Front-Load Success Event Names

When you are naming SiteCatalyst variables, you should do your best to be as succinct as possible as having long variable names can have adverse effects on your menus and report column headings. However, there is one issue related to variable naming that is unique to Success Events I wanted to highlight. Let’s imagine that you have a multi-step credit card application process and you want to track a few of the steps in different Success Events. In this case, you might use the Administration Console and set-up variables as shown here:

In this case, the variable name is a bit lenghty, but more importantly, the key differentiator of the variable name occurs at the end of the name. So why does this matter? Well let’s take a look at how these Success Event names will look when we go to add them to a report in SiteCatalyst:

Uh, oh! Since the key aspects of these variable names are at the end, they are not visible when it comes to adding metrics to reports. This makes it difficult to know which Success Event is for step1, 2, 3, etc… You can hover over the variable name to see its full description, but this is much more time consuming. I have asked Adobe repeatedly to make the “Add Metrics” dialog box horizontal instead of vertical but have not had any success with this (you can vote for this!). In this case, I would suggest you change the names of these Success Events to something like this:

Which would then look like this when selecting metrics:

Keep in mind that there is no correlation between the length of the variable definition box in the Admin Console and when the Success Event name will get cut-off in the Add Metrics dialog box so don’t get tricked into believing that if it fits in the box you will be ok!

Final Thoughts

These are just a few variable naming tips that I would suggest you consider to make your life a bit easier. If you have other suggestions or ideas, please leave them here as comments so others can benefit from them. Thanks!