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.

[Screenshot]

Finding the Report Suite ID

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.

About

German expat living in Switzerland (formerly UK and France). Consultant and member of the Multi-Solutions Group at Adobe, working with the Digital Marketing Suite. Father of 4 girls.

Tagged with: , ,
Posted in Principles
12 comments on “Multi-Suite Tracking & Report Suites
  1. André Bade says:

    Thanks for the nice overview! I’m using rollups a little bit but mostly I’m just adding up data on a country base with the report builder too. But of course it would be nice to see the “real” number of unique visitors, so I’m thinking about multi-suite tagging. One question: What about on-click events? Can you simply add another rsid? Fot instance:

    My Page

    Thanks,
    André

    Like

  2. […] checked the settings, they looked good. I checked for VISTA Rules on the Report Suite and found one, but it didn’t modify this prop or eVar. Then I looked at the Processing Rules […]

    Like

  3. […] you know why Adam suggests sending “logged-in traffic” into a separate report suite. That report suite will give you only “her” data, unspoiled by anonymous […]

    Like

  4. […] I neglected to mention one important characteristic of Adobe Analytics: with each Report Suite, you get 75 props (traffic variables), 75 eVars (conversion variables) and 100 […]

    Like

  5. […] the very top of visitorAPI.js you have to configure two or three lines. You will need to add your report suite ID into the first line and your tracking server into the second (and potentially tracking server […]

    Like

  6. […] am assuming that this is the first app, so we’ll create a new Report Suite for the tracking data. I am sure that if you have done this before I won’t have to explain […]

    Like

  7. […] the visitor IDs), or technical data about the hit itself (such as the time it was received, the rsid or the version of your s_code.js/appmeasurement.js/Mobile […]

    Like

  8. […] rather something like “jexnerinstructional.nonsense_2014-08-05.tsv”, a combination of report suite ID and date of the data inside. But for this posting, I’ll call it hits.tsv otherwise the lines […]

    Like

  9. […] but not least, there is a bunch of methods that allow you to manipulate all sorts of things around report suites. The list is actually too long to fit on one screen (at least on mine). Pretty much every single […]

    Like

  10. […] I write “Global” Report Suite, I mean one that gets data via multi-suite tracking, i.e. the app or site sends hits to more than one report suite. That implies “secondary […]

    Like

  11. […] you have followed this blog, you already know that Adobe Analytics has a concept called “Report Suite“, which is sort of a data container. You might also have grasped that the Tag Management tool […]

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 1,398 other followers

%d bloggers like this: