My Latest SiteCatalyst Wishlist Items [SiteCatalyst]
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.
