When most of us talk about or plan a SiteCatalyst implementation, we tend to focus on data collection.  If you’re doing it right, you’ll start by defining your business objectives and creating a web measurement strategy.  You’ll probably discuss how to build your JavaScript beacon.  You may explore the option of using the Data Insertion API or integrating an email or ad serving vendor.  These are all vital components, but there is another area that usually doesn’t receive the attention it merits.

Data Organization is Important Too

You capture the data on your website or from your application, then it goes to Omniture for processing, but where exactly does it go?

All the data that Omniture receives and processes is stored in a Report Suite.  One of the bits of data that Omniture collects on every request is the report suite ID, which ultimately determines a data point’s final resting place after it is processed along with the rest of the click stream.  The size of the report suite determines the scope of all the data within in it.

Buckets and Buckets of Data

It may help to think of a report suite as a bucket that holds the data you’re interested in.  You might have a bucket for your US site, one for your French site, one for your German site etc.  The country manager responsible for the business in France is critically interested in every little detail of what’s happening on the French site (yes, I did the illustrations myself, how did you know?).

She’ll want to know how much revenue or how many leads are generated.  Which campaigns, keywords, and referring domains are generating those events.  Is the new microsite driving traffic to the multimedia?  Which of the homepage promotions are most popular?  Did they watch any videos or take the survey that we invited them to participate in?

She wants answers to each of these questions as it relates to the French site.  The US and Germany are peripheral because those sites fall outside the scope of her responsibility.  Data collected from these other countries is only an obstacle in her way.  We want to organize our data collection and processing so that she gets all of the data she needs and none of the data she doesn’t.  We need to organize our data in a way that France can be easily separated from the other countries.

Bigger Questions Need Bigger Buckets

In contrast to a country manager who wants to know every detail about an individual country, a CMO is interested in the big picture items across the whole globe and probably isn’t too concerned about an individual campaign running in Japan.  Trying to aggregate data from each individual country site is painful, time consuming, and introduces problems with data accuracy.  A CMO wants to look in a single location for data that spans the entire organization.  We need another bucket of data that has everything in it.

Architecture

When we talk about a Report Suite Architecture, we’re talking about the hierarchical layout of the report suites (or buckets) within a company.  It is the blueprint that tells Omniture how to put all your data together when it is received.  It determines how big each report suite is, where it fits in relation to the others, and which data goes into it.  You can organize a hierarchy around many dimensions, but the right one has to do with your organization and how your stakeholders think about their business.

Organization Techniques

In my experience, there are 3 primary lines along which an analytics program manager  will choose to organize report suites:

  1. Geography
  2. Site/Section
  3. Product Line

If you think about how the chain of command runs in your organization, it’s likely that one of these three dimensions is a good fit already, and a logical choice.

You can use JavaScript to direct your data into 1 or many report suites by comma-separating report suite IDs in the s_account variable.  Another common technique is to let VISTA do the work by looking for particular values in the page URL or a country variable that you’re coding.

The Omniture Suite

Within the Omniture suite, we’ve laid out our report suites by Product Line.  Each individual product report suite rolls up into the Omniture Suite report suite (I’ve not pictured them all to save on space).

Product managers and engineers can get data about product and feature usage, product adoption, etc., the individual report suites, while the global level provides a holistic view of customers across the whole online marketing suite.  If you’ve seen the product wheel when you login into SiteCatalyst, that happens to be a pretty fair representation of how we’ve organized our report suites (raise your hand if you noticed that Insight was recently added to the wheel).

Architecting a hierarchy for your report suite helps you deliver the right information to the right people, without drowning them with the unnecessary pieces.  In my next post, we’ll take a deeper dive into the report suites themselves to discuss making the most of the individual data points.

2 comments
Ben Robison
Ben Robison

Reuben, If there are business questions that require a hierarchy like that, then it's a great idea. I've seen hierarchies that go up to 4 & 5 levels deep. If the regional GMs need the detailed metrics at the deepest levels of granularity, then three or four levels of a hierarchy may be the best solution. If they only need aggregated high-level metrics, then you might be able to answer the questions at hand with a prop or an evar, which is less complex than managing multiple levels of a hierarchy.

Reuben Poon
Reuben Poon

Great post, Ben! What are your thoughts about more advanced segmenting of these "buckets"? For example, what if a company wants to do multiple levels? Let's say that the organizational technique is geography. But above individual country, there are regional GM's that want to see collections of countries. So you might have EMEA that wants to see all of Europe combined. Then APAC, Americas, etc. This would be a three tiered report suite structure. What are the pros and cons of doing it this way? What are the alternatives?