When to Use Variables vs SAINT in Adobe Analytics
In one of my recent Adobe SiteCatalyst (Analytics) “Top Gun” training classes, a student asked me the following question:
When should you use a variable (i.e. eVar or sProp) vs. using SAINT Classifications?
This is an interesting question that comes up often, so I thought I would share my thoughts on this and my rules of thumb on the topic.
As a refresher, SiteCatalyst variables like eVars and sProps are used to store values that break down Success Events and Traffic Metrics respectively. For example, if you have a metric for onsite searches, you should be setting a Success Event and if you want to see that Success Event broken down by onsite search phrase, you might use an eVar to see the number of onsite searches by search phrase. SAINT Classifications allow you to apply meta-data to eVars and sProps so you can collect additional data or group data values into buckets. For example, you might use SAINT Classifications to group onsite search phrases into buckets like “Product-related terms” or “SKU # terms,” etc…
However, there are many cases in which you have a choice to capture data in a variable (eVar or sProp) or to use a SAINT Classification. Let’s look at an example to illustrate this. Imagine that you have a website and many of your customers have a Login ID that they use prior to ordering products. You are passing the Login ID value to an eVar so you can see all of your Success Events (i.e. Searches, Orders, Revenue) by Login ID in your SiteCatalyst reports. One day your boss approaches you and says that she wants to see your website KPI’s by the City visitors live in and that City is one of the attributes your back-end folks have related to each Login ID. At this point, you have two choices, one is to have your IT folks pass in the City to a new eVar using the Login ID value (if they can’t do this in real-time you could also pass this to SiteCatalyst via DB VISTA). The other option is to upload the City value for each Login ID as a SAINT Classification of the existing Login ID eVar. Both of these options would meet the objective of your boss, but which one is the right approach?
If I were a betting man, I would guess that most of you mentally chose option#2 which treats City as a SAINT attribute of the Login ID eVar. Does that sound right? Why not? It saves you tagging work and helps you avoid working with IT, which usually has delays associated with it. However, would it surprise you to know that I would NOT choose option #2 in this case, and instead would pass the City to a new eVar? Before I tell you why, let me review some of the things I consider when making a decision like this:
Advantages of SAINT Classifications
- Conserves Variables – One of the key advantages of using SAINT Classifications is that they allow you conserve variables, especially eVars, which tend to run out before any others
- No Tagging Required – SAINT Classifications don’t require additional tagging
- Retroactive – SAINT Classifications are retroactive so if you mess up when assigning a value, you can always fix it later by simply updating the SAINT data or fixing your rules if using the SAINT Rule Builder. For example, if you incorrectly assign a campaign tracking code to a Campaign Name, you can easily updated this after the fact. If you had passed the campaign name to an eVar, there wouldn’t be much you could do to fix historical data. However, the retroactive nature of SAINT Classifications can also be a negative at times (more on this later)
Advantages of Variables
- Data Stored Forever – Once you pass data into a variable (eVar or sProp), it is there forever (for better or worse). This is useful if you want to forever document the value at the time a KPI took place
- sProp Pathing – If you are passing data to an sProp, you can enable Pathing on the variable to see the sequence in which values were collected. Unfortunately, Pathing is not available on SAINT Classifications in Adobe Analytics (though it is in Discover, now known as Ad Hoc Analysis)
- Data Feeds – Many companies use Data Feeds to export Adobe SiteCatalyst data to other data warehouses and Data Feeds only contain data that is organically passed into SiteCatalyst, which excludes SAINT data
As you can see, there is more than meets the eye when it comes to deciding which approach you should use when collecting data. Do you need data in a Data Feed? Do you need Pathing? Do you need to be able to update values after the fact? For each situation, I find the preceding items to be a useful checklist to keep handy.
And Now Back To Our Story…
So now that you have seen my list of considerations, can you see why I suggested using a new eVar for City in our scenario? In this case, the item I focused on was the retroactive nature of SAINT Classifications. In this case, if you were to treat City as a SAINT Classification of Login ID, things would probably work out ok initially, but might have issues in the long run. Let’s say that Adam Greco visits your site, logs-in using ID#12345 and then completes an order for $200. At some point you have uploaded a SAINT file that correctly associates Adam’s Login ID with the city of Chicago. At this point, you can use the SAINT Classification “City” report to pivot the data and see an order of $200 for the city of Chicago. However, now let’s imagine that Adam decides to move to San Francisco (something I have done twice in my life!). Your back-end data would at some point learn that Adam has changed cities, and the next time you upload your SAINT file, Adam’s Login ID will be associated with San Francisco. Since SAINT Classifications are retroactive, this will have the impact of changing all activity associated with Adam’s Login ID to look like Adam has always lived in San Francisco, even though all of his KPI’s to date were done in Chicago. This means that your “City” report is inaccurate since it is inflating metrics for San Francisco and deflating metrics for Chicago (and for those who say that the answer is to use Date-Enabled SAINT Classifications, I wish you luck as I have never seen a company have the time to keep those updated!).
This scenario shows why it is so important to review my list of considerations above. While it is a shame to have to waste an eVar for City, in this case when you can make an association between Login ID and City, using a new variable may be the right thing to do if you want to see what City the Login ID was associated with at the time that the KPI took place and lock that value in forever. In my experience, the retroactive issue is the one that I see companies make the most mistakes with and many don’t even know that they have made a mistake until I point it out to them. Therefore, I will share another rule of thumb I have learned over the years:
Consider whether the data attribute is inherent to the eVar/sProp value or whether it can change. If meta-data is inherent to the value being classified or it can change and it won’t disrupt your data, use SAINT Classifications. Otherwise, use a new variable. When I say “inherent,” I mean that it will most likely not change. For example, if one attribute you have for Login ID is “Gender,” there is a strong likelihood that this can be a SAINT Classification, since it is unlikely that this value will change for each Login ID (outside of a very complicated surgical procedure!). Another example might be birth date which will never change for each Login ID. However, if you have a loyally program and treat different Login ID’s as Basic, Gold or Silver members, that can easily change over time, so that would be a candidate for a new variable so you are documenting their status at the time that the KPI took place.
As you think about how many attributes you may currently be incorrectly storing via SAINT (it happens to the best of us), you may wonder how you will have enough variables to capture all of these attributes. Keep in mind that just because I am suggesting that you set variables instead of using SAINT for data that is affected by retroactivity, it doesn’t mean that you need to store each of these data points in their own variable. For example, if you decide to capture Member Status, City and Zip Code as variables instead of SAINT Classifications of Login ID, if they are all available on the same page (server call), you can concatenate them into one eVar (i.e. Gold Member|Chicago|60603) and then apply SAINT Classifications to that eVar. In this case, you are still capturing the actual value you need to make sure you are not burned by the retroactive nature of SAINT Classifications, but you can conserve eVars by capturing multiple values in one eVar and splitting out the data using SAINT later. In fact, if you capture the data in a methodical manner, you can even use RegEx in the SAINT Classification Rule Builder to do this automatically.
So there you have it. Some things that you should consider when deciding whether you should use a new variable or SAINT Classifications when collecting new data attributes in your Adobe SiteCatalyst (Analytics) implementation. If you would like to learn more tips like this about Adobe SiteCatalyst, consider attending my next Adobe SiteCatalyst “Top Gun” training class at our ACCELERATE conference in Atlanta this September. Thanks!