Last week we looked at different ways to organize your report suites to provide the proper level of information to your different stakeholders. This week I’d like to take a deeper look at the inside of single report suite and how its layout fits into the overall scheme.
Personalizing Your Data
All of the reports in SiteCatalyst correspond to a database table somewhere. Some of these are populated out-of-the-box and some are left to the discretion of a company to decide what to use them for and how to collect the data.
Among these personalized variables are props, evars (also here), and events. That provides a lot of room for customizing the data you collect and making sure that you’re meeting all the goals laid out in your measurement strategy.
When you organize your report suites into a hierarchy, you have to keep in mind that a single data point is likely going to end up in multiple locations. A Video Start on the US site will also end up in the global site. It sounds pretty straightforward, but there are some important effects that we’ll take advantage of.
1. Some Of Your Data Is Only Important At The Top Level
There are some reports that are only important inside the upper levels of your hierarchy. Inside the Omniture Suite for example, we capture Product in prop4/evar4. Every time data is sent to the collection servers, prop4 and evar4 contain a value that simply identifies which product is being used: SiteCatalyst, Test&Target, Discover, etc.
Within an individual report suite, the value is limited, but at the global level, where all the data is, this is extremely valuable. It provides me a single report that tells me how much usage each product is getting. Interesting insights are available from watching this trend over time.
This concept will hold true regardless of whether you’ve organized your hierarchy by country, by product, by site section, or something else. Some of your data is only important when you look from the top down.
2. Some Of Your Data Is Only Important At The Bottom Level
We keep track of the usage of bid rules used for ad spend optimization, but SearchCenter is the only product that uses them. An active campaign in Test&Target is its own event and isn’t repeated 
anywhere else throughout the suite. We obviously want to keep track of these features, how people use them, and how effective they are.
We keep track of these kinds of things at the bottom level of the hierarchy, but we don’t need to expend the effort to measure them at the top level. There is no added value in looking at this data at the top level, therefore, there is no need to track it at the top level. In fact there is no need to even turn these variables on at the top level.
Now here’s the neat trick. Since we don’t roll these values up to the global level, it means that the lower levels can re-use the same variables to mean different things without corrupting any of your data.
3. Some Of Your Data Is Just Plain Important
This follows logically from points 1 and 2, but I thought I’d call it out just to be explicit. Some of your data makes sense and provides value at the top, at the bottom, and everywhere in between.
Takeaways
When you determine that you need to measure a particular data point, you must decide where it has value, and at which level you need to keep track of it.
If a data point falls into category 1 (provides value at upper levels only), then you must ensure that every report suite underneath implements that data point consistently. This means they must pass the same values (or kinds of values) as every other report suite, and they must remain constant over time.
If a data point falls into category 2 (provides value at lower levels only) then record it in a way that is consistent within that report suite, and do not even enable that variable at the upper levels. This reduces risk of latency and also ensures that your users do not waste time trying to derive value from reports that have none.
Inside the Omniture Suite
As an (extremely simplistic) example, the diagram below shows a layout of our variables inside a report suite. If it’s listed on a report suite, it’s being recorded there. Orange text is unique to a given report suite and not recorded at a global level. Faded text are the ones you would pay less attention to on a given level.
Category 1 — Inside the Omniture Suite, we have dedicated about half of our variables (props, evars, and events) that must be used consistently across all products. There are global standards for implementing these variables so that the values mean the same thing and that they look the same when they come in. Product Name is an example.
Not all 35 data points apply to every product, but they do apply to more than one. If a particular data point does not apply to a product, we simply leave it alone. Report Suite ID is one example. We obviously want to record that for SiteCatalyst, Genesis, Discover, etc., but it just doesn’t apply to Test&Target or Insight. File Format is another example. We want to know what formats are most popular when people download and schedule reports, but you can’t do that in Test&Target. So Test&Target just doesn’t set that variable.
Category 2 — The variables that are not used in category 1 get used in category 2. These are customized to the needs on an individual product and are not enabled at the upper level. SearchCenter bid rules, Discover workspace segments, and Test&Target active campaigns are good examples. Again, note that within this category, I can reuse the same variable to mean different things since they don’t roll up to the global level.
Category 3 — You can actually treat these as a subset of category 1 because the same rules apply. They must be implemented consistently through space and time for all products. Login Company is an example that provides value at the individual level and at the aggregate level.
It was Benjamin Franklin that said “An ounce of prevention is worth a pound of cure.” A week or two ago I mentioned the measure-once-cut-twice philosophy that could be restated by a web analyst to say that “an ounce of planning is worth a pound of development.” Or maybe it’s worth a pound of headache. Maybe it’s worth more.