One or multiple report suites in Adobe Analytics
19 Jul 2015 » Analytics Tips
Back in the old days, before SiteCatalyst 15 was released, the limitation in segmentation meant that, usually, you needed multiple report suites. You would usually have a combination of JavaScript and VISTA rules to do that segmentation (in case you are wondering, the S in VISTA stands for Segmentation), sending the data to different report suites. After that, you would also need a rollup to try to get an overall picture.
With the introduction of SiteCatalyst 15, segmentation became much more powerful. You could have one single report suite and use segments in SiteCatalyst to analyse the data. The segmentation interface received a massive improvement with the May 2014 release of Adobe Analytics.
However, there are still many valid reasons why you would want separate report suites. My friend Jan Exner gave his point of view some time ago: one or two report suites. I would go one step further and talk about more than just two and other reasons why you would want many.
- Mobile apps. You will probably want to put all mobile apps in a separate report suite, with the Mobile UI enabled. Having a single report suite will probably create some headaches, as some features are mobile app specific and others, web specific. If you need totals, you can use Report Builder and create the totals in Microsoft Excel.
- Multiple currencies. If you are selling in different currencies and you need an accurate reporting for each currency, then it might be better to have one report suite per country or region. However, you can stick to one single report suite, you can track both in the standard location of the s.products string and in a numeric event, and copy the currency code to an eVar. With this approach, you can report on the report suite default currency and in the local currency in which the transaction occurred.
- Multiple time zones. As with currencies, if you sell in very different time zones and need accurate intra-day reporting, you might have to create multiple report suites, depending on the time zones. However, generally speaking, reports tend to span more than just one day and the differences in time zones is less noticeable.
- Different teams. Some large organisations prefer to have the data separated in different report suites, so that it is possible to give permissions to access the data in a more granular way. It is then possible to give the least amount of privileges to the web analysts, so that they only have access to the data they need. For example, I was working with a customer that had completely different teams analysing Android and iOS data and these teams did not even talk to each other.
- Legal requirements. This might not be very common, but if certain information should only be accessed by a limited number of people for legal reasons, then you need to have many report suites and grant access to the report suites depending on the needs, just like in the previous case. As an example, I was working with a supermarket and they were selling both their own white brand together with other brands; the analytics of their own brand, for obvious reasons, are not allowed to see the information of the other brands; this solution required a VISTA rule.
- Multi-suite tagging. If your budget allows for it, the best solution is to go for both worlds: one global report suite and multiple local report suites. For lack of a better word, I use local not a geographical meaning.
- Different SDRs. Well, this is a sin you should avoid at all costs, but if you have inherited implementations that use different SDRs, then you need different report suites unless you are willing to redesign all Adobe Analytics implementations.
- IP address segmentation. If you need to segment by IP address, with a granularity finer than what the geolocation reports can provide, then you need a VISTA rule and multiple report suites. For example, if you have a call centre that actually uses the website, you do not want to “pollute” the main report suite with call centre data; instead, you want the call centre to be reported in a specific report suite.
- Human vs non-human interactions. In a previous job, we had a Web services API that offered very similar information to the website. In fact, the information from the API was presented on third party websites, but we were not allowed to add any tagging to these websites. The solution was to track server-side the API usage, obviously, using a separate report suite.
I would like to hear your ideas on this topic or situations that you have found, which have led you to one or multiple report suites.