Multi-Suite Tracking & Report Suites

Short post today to explain two things that have been mentioned on this blog a couple of times but never really explained. Bad blog!

“Report Suite”

The concept “report suite” is pretty important in Adobe Analytics. I have mentioned it a lot but only ever gone into a little bit of detail in the post about the configuration section of the s_code.js file. Let’s go deeper.

As mentioned, a report suite is sort of a separate data storage. While it is not a database, strictly speaking, you can think of a report suite almost as if it was. It is an isolated storage space for your data.

Each report suite has settings that are independent of all other report suites. Some of the things your friendly marketer sees in the interface are attached to the report suite, for example “Bookmarks”, “Schedules” or even the menu structure and semantics of the different “variables”.

It makes sense to think of a report suite as a completely independent tracking environment.

As a user of Adobe Analytics, you can have as many of these as you need.

A lot of people use one report suite per market (country or region), or maybe one for the desktop site and another one for mobile.

Whether you track different sites or apps into a single report suite or separate ones depends on two factors:

1. People — who is looking at the data? Who should be able to see it? Example: If you have a marketing team per market, it makes sense to have a report suite per market to mirror that.
2. Site goals / functionality — two sites that do vastly different things should not be tracked into the same report suite. Example: the goals for your investor relations site are likely totally different from those for your B2C site. The tracking should follow the goals and because the configuration of the tracking is specific to the report suite, you should have different report suites here.

The people aspect is often overlooked, but I think it is the more important aspect here. Why? Because data only makes sense if the right people see it. And those people should see exactly the data that matters to them, no more, no less.

“Multi-Suite Tagging”

Very simply put, multi-suite tagging allows you to send the same tracking data to more than one report suite.

Why would you do that?

Again it comes down to people, and the right data for the right person.

If your company is structured hierarchically (chances are it is, unless you work for Zappos, of course), then there will be teams responsible for regions or other parts of the business. Those teams or individuals need data relevant for their remit.

There will also likely be someone responsible across regions or business units. That someone also needs relevant data, but that data obviously includes multiple regions or units.

So one web site (say the retail site for Belgium) may send tracking data into a specific report suite. But it may also send data into an over-arching report suite for EMEA, or maybe one for all retail.

That is called multi-suite tagging or sometimes multi-suite tracking.

How?

Real easy: just add the additional report suite ID (“rsid”) to the s_account variable in the configuration section of the s_code.js file, separated with comma.

Make sure you have no extra spaces!

That’s it.

Really.

You can check whether you’ve done it right by looking at the URL of the tracking call that your browser makes. If you can see your list of rsids then everything should be good.

Alternatives

If you don’t want multi-suite tracking or for some reason you can’t do it, there are 2 alternatives: rollups and VISTA Rules.

Let’s start with VISTA Rules, because the effect is pretty much the same as with multi-suite tagging.

The only difference, really, is that instead of putting multiple report suite IDs into s_account, you ask Adobe to do it for you in the back end.

Now the big drawback here is that you pay for creating that VISTA Rule, while doing it yourself only costs your time.

But depending on how development works in your team, it might be valid and/or faster to use the VISTA Rule rather than changing the s_code.js file.

The other alternative is to use rollup report suite(s).

They work slightly differently, so depending on what your friendly marketer needs they might or might not be the way to go.

A rollup is configured in the back end. It “contains” two or more report suites. Every day at midnight, all data from the previous day is “copied” over into the rollup.

The differences, from your marketers’ point of view are:

• Data is one day behind in rollup vs. real-time with multi-suite tagging
• Rollups are free, multi-suite incurs secondary server calls
• Data in rollups is just added up whereas with multi-suite, metrics like Visits or Visitors are deduplicated

The last one needs some explanation, I think.

Imagine I read an article on “Blog A” and one on “Blog B”. Both are tracked and on both my interactions will show up as 1 Page View, 1 Visit and 1 Visitor. Per site, of course.

Now if both “Blog A” and “Blog B” are tagged to track into a common report suite, looking at this common data I would see 2 Page Views, but still 1 Visitor. We call that deduplication, and multi-suite tagging can do it, while rollups can not.

Whether deduplication is important for your marketer or not depends largely on the sites they are looking at and whether visitors are supposed or likely to hop between those sites.