Multi-Suite Tagging [Inside Omniture SiteCatalyst]
One topic that I find confuses many of my customers is Multi-Suite Tagging. For this reason, I wanted to devote a post to this and provide some basic information about what it is and when it should be used.
What Is Multi-Suite Tagging?
Multi-Suite Tagging is a fancy name for sending SiteCatalyst data to two or more report suites. So when would you want/need to use multi-suite tagging? I have seen Multi-Suite Tagging used most often in the following situations:
- A company has a similar website in different geographic locations and wants to compare the same metrics for each region
- A company has a similar website, but many different brands and wants to compare the same metrics for different brands
- A company wants to provide a subset of data to one group. For example, the customer service group can only see customer service page data, but other groups can see all website data
The value of Multi-Suite Tagging can best be seen through an example. Let’s imagine that Greco Inc. is a holding company that has various retail brands under different names. Both retail brands (let’s say Brand A & Brand B) provide similar products and most people don’t know that they are both owned by Greco Inc. The CEO of Greco Inc. would like to see website data for each business separately, but also have a combined view so he can see performance across all of Greco Inc.
To accomplish this, each page on Brand A would send data to the “greco_brand_a” and “greco_global” report suites, while each page on Brand B would send its data to the “greco_brand_b” and “greco_global” report suites. Therefore, each page on both sites is sending two image requests to Omniture – one for the Brand site and one to a Global site that consolidates all data.
So how is this done? There are two different ways to implement Multi-Suite Tagging:
- Modify the “s_account” value in your .js file to include more than one report suite ID
- Utilize a VISTA rule to route data to additional report suites
Here is an example of item #1 above from Omniture’s Implementation Manual:
(NOTE: The data collection subdomain, shown above as ‘suite1,’ is populated using the s.visitorNamespace variable, and is typically not specific to individual report suites. The example above is provided for the purpose of illustrating the comma-separated list of report suite IDs in the image request URL, and is not meant to suggest that your data collection domain should be changed when using multi-suite tagging. In the vast majority of cases, you should not change the s.visitorNamespace variable when implementing multi-suite tagging.)
Regardless of the method used, the result is that all data collected on a page is sent to more than one data set within SiteCatalyst.
Using Multi-Suite Tagging
So building upon the previous scenario, we can now see how Greco Inc. can take advantage of Multi-Suite Tagging. Let’s say that the Greco Inc. CEO’s first priority is to see Revenue by Marketing Channel. Since there are two separate report suites involved, it is now possible to use the “Compare to Site” feature within most SiteCatalyst reports to run the same report showing two different data sets. In this case, Greco Inc. would open the Brand A report suite, navigate to the Marketing Channel report (a SAINT classification of Campaigns) and then add Revenue as the desired metric. This will display all Brand A Revenue broken down by Marketing Channel. From there, all that is needed is to select the “Configure Report” option and then select “Compare to Site” and select the Brand B report suite. The result is a report that looks like this:
Of course, it is possible (and often necessary) to add the normalization option when metrics are different between report suites.
But wait…there’s more! Since Greco Inc. has decided to create a Global report suite, all visitors to either the Brand A or Brand B website have the same SiteCatalyst “Visitor ID” in the Global report suite. This means that as far as the global report suite is concerned, Omniture SiteCatalyst considers Brand A and Brand B to be one massive website with different URL’s. This is important because it enables you to do the following:
- See paths that visitors took from the Brand A site to the Brand B site (and vice-versa). This allows you to see if the same person is visiting both of your brands which can be interesting information (especially if you foster “co-opetition”)
- Get a de-duplicated count of unique visitors among all of the sites that you own. For example, let’s say that Brand A has 20,000 monthly unique visitors and Brand B has 15,000 monthly unique visitors (for a total of 35,000 monthly unique visitors). That sounds great, but if you look in the Global report suite, you might see that you only truly have 30,000 monthly unique visitors if the same visitor went to both sites (5,000 such visitors in this example).
- Create Segments using criteria from multiple websites (i.e. Show me visitors who looked at a product on Brand A’s site and brought something on Brand B’s site)
- Utilize Participation to see what pages on Brand A’s site lead to success on Brand B’s site (and vice-versa)
- Utilize Campaign Tracking at a higher level to see what marketing campaigns led to success across multiple sites
With Great Power, Comes Great Responsibility…
The preceding example underscores one of the most important things to consider when using Multi-Suite Tagging:
It is critical that most or all SiteCatalyst variables be consistent amongst any report suites that are Multi-Suite Tagged
In the example above, it is somewhat easy since Revenue is always set in the same manner in SiteCatalyst. But imagine that one of the items the Greco Inc. CEO wanted to see was Website Registrations. If Brand A’s website stored this in Success Event #1 and Brand B’s website stored Registrations in Success Event #4, it would be impossible to compare the two from within SiteCatalyst (you would have to use the ExcelClient instead).
The situation gets even worse when you consider the Global report suite. If you recall, we mentioned that data for both Brand A and Brand B was combined in a Global report suite. Now imagine that Brand A is counting Website Registrations in Success Event #1, but Brand B is counting E-mail Subscriptions in Success Event #1. Now the Global report suite has two different metrics being combined (Brand A Website Registrations + Brand B E-mail Subscriptions) into the same metric. That renders Success Event #1 useless in the Global report suite and defeats its entire intention! In fact, I have often had to be the bearer of bad news to clients who have made business decisions based upon a Global report suite metric, only to have me show them that the numbers they were looking at all along were incorrect.
Therefore, using Multi-Suite Tagging, while extremely powerful, requires advanced forethought about your set-up and coordination between different brands and/or geographic locations. If you are interested in avoiding common mistakes, I strongly recommend you contact Omniture Consulting and consider their Corporate Governance consulting project which is designed to help clients avoid the common pitfalls of large, multi-site implementations.
Important Things To Know About Multi-Suite Tagging
The following are some important things to know about Multi-Suite Tagging:
- Since Omniture is storing additional data for you through Multi-Suite Tagging, you have to pay for the additional server calls (though Omniture charges a reduced rate for these)
- Omniture also provides something called a Global Rollup Suite that aggregates data from multiple individual report suites. These are more cost-effective than Multi-Suite Tagging, but do not provide inter-site pathing, de-duplicated unique visitors, Traffic Data Correlations, DataWarehouse, etc…
- It is not possible to create a Multi-Suite Tagged Global report suite using historical data so it is best to plan for this ahead of time or pick a date at which you plan to coordinate your sites and launch the Global suite.
Have a question about anything related to Omniture SiteCatalyst? Is there something on your website that you would like to report on, but don’t know how? Do you have any tips or best practices you want to share? If so, please leave a comment here or send me an e-mail at firstname.lastname@example.org and I will do my best to answer it right here on the blog so everyone can learn! (Don’t worry – I won’t use your name or company name!). If you are on Twitter, you can follow me at http://twitter.com/Omni_man.