v15 Segmentation vs. Multi-Suite Tagging [SiteCatalyst]

With the arrival of SiteCatalyst v15, one of the most intriguing questions is whether or not clients should take advantage of segmentation and replace the historic usage of multi-suite tagging. This is an interesting question so I thought I’d share some of the things to think about…

Multi-Suite Tagging Review

As a quick refresher, if you have multiple websites, it has traditionally been common to send data to more than one SiteCatalyst data set (known as report suites). The benefits of this multi-suite tagging were as follows:

1. You could have different suites for each data set (i.e. see Spain data separately from Italy data)
2. If you sent data to many sub-suites and one global (master) report suite, you could see de-duplicated unique visitors from all suites in the global report suite
3. If you wanted to, you could see Pathing data across multiple sites in the global report suite to see how people navigate from one website to another
4. You could create one dashboard and easily see the same dashboard for different data sets in SiteCatalyst or in Excel
5. You want to see metrics at a sub-site level, but also roll them up to see company totals in the global report suite

As you can see, there are quite a few benefits of multi-suite tagging and most large websites tend to do this as a best practice. Of course, where there is value, there is usually a cost! Since you are storing twice as much data in SiteCatalyst, our friends at Omniture (Adobe) have always charged extra for doing this, but normally these “secondary server calls” are charged at a dramatically reduced rate.

Along Comes Instant Segmentation

However, once SiteCatalyst v15 came out, it brought with it the ability to instantly segment your data. Suddenly, you have the capability to narrow down your focus to a specific group of visitors. Therefore, many smart people started asking themselves the following question:

“If I track the website name on every page of every one of my websites, why can’t I just send all data to one global report suite and build a segment for each website instead of paying Omniture extra money to collect my data twice through multi-suite tagging?”

If you look at the list of multi-suite tagging benefits above, you can see that you can accomplish pretty much all of them by simply creating a website segment. For example, if you currently pass data to a global report suite and an Italy report suite, you could simply pass the phrase “Italy” or “it” on every page and build the following Italy segment:

Doing this would narrow the data to just Italy traffic and you don’t have to pay Omniture any extra money! Most clients I have spoken to are very interested in this concept since it will allow them to move some budget to other things they might need (like more analysts or A/B Testing). I think many companies are taking a “wait and see” attitude to this while they get comfortable with SiteCatalyst v15. However, I expect that in the next twelve months, many large enterprises will decide to go this route in order to save a little money and simplify their implementations (one can only dream about not having to keep 50-100 report suites consistent in the Admin Console!). To date, I have not heard Omniture’s stance on this, but I expect that they are not opposed to companies doing this, but will probably not broadcast this concept too loudly since they will lose some recurring revenue as a result.

Any Downsides?

While it is still early days for SiteCatalyst v15, I have tried to think about what, if any, the downsides might be from throwing away multi-suite tagging in favor of an instant segmentation approach. While I hate to rain on the parade of those who want to move forward with this, I have found a few potential downsides that I think you should consider. I don’t think any of these will dissuade you, but I like to present both sides of the story so you can make an informed decision!

The first downside I can see is that moving to one global report suite will make the creation and usage of segments inherently more difficult. For example, let’s say that you create an Italy segment as shown above. That works well if you are in Italy and want to see all Italy traffic. But what if you are in Italy and want to see all first time visitors from a specific list of keywords who have abandoned the shopping cart. That is a semi-complex segment and you have to be careful to include the Italy part of the segment at the same time! Creating segments is tricky enough, but if you use segments to split out countries (or brands), you have to build even more complex segments to take these into account. Should you use an AND clause, an OR clause, combine Visit containers, use a Visitor container, etc? These are tricky questions for everyday end-users, while having a separate report suite (data set) for each country allows you to simplify your segments and just segment within that report suite and not worry about the additional country container. For advanced SiteCatalyst users, this nuance shouldn’t be a showstopper, but it can definitely trip up novice users and is something that should be considered.

Another downside is a lack of security around your data. While you can add security controls to report suites, you cannot do the same when it comes to segments within one master report suite. This means that if you use the one-suite approach, anyone who has access to that suite can see any data within it. You can lock down success events and sProps in the Admin Console, but that is the limit of what you can do. Security remains one of the key reasons why companies continue to use multiple report suites.

Lastly, if you work for a multi-national company, individual report suites allow you to use a different currency type for each suite. This means that a german-based site can use Euros, while a British site can use Pounds. When you send data to a global report suite, these currencies are translated into the one used for the global report suite (i.e. US Dollars). However, if you use only one suite and segmentation, you lose the ability to see data in different currencies. You can use the report settings feature to translate what you see in the interface into your own native currency, but this is much different than seeing the data collected in a native currency. The former simply translates historical data using today’s exchange rate, while the latter uses the currency rates associated with the date that currency was collected. Obviously, the latter is the more accurate approach.

Final Thoughts

So there you have it. Some of my thoughts on this monumental decision that many large SiteCatalyst customers will have to make over the next year. What do you think? Will you take the plunge? Have you thought of any other benefits and/or downsides of making the switch? If so, leave a comment here…