Even More SiteCatalyst Variables

Fascinating. As much as possible, can you help me understand what is causing you to use up all 150 custom variables? Is there anything (video, social, mobile stuff) that demands a large number of custom vars in the implementations you're designing? Or are you being required to use up one dimension here, one dimension there until they're gone?

At CBS we are struggling. The main area we hit this issue is managing consistent variables across many sites, apps, video, mobile sites, TV apps. When using a roll-up report suite we need to avoid overlapping variables and as such it's quite easy to start running out of variables. Take for example the new mobile integration it uses around 15 variables so once you start reserving variables and avoiding overlap.

I'd agree with Tim on this one.  Having many different report suites and trying to keep the same variables track the same data across report suites is tricky, and when new report suites are added that need new dimensions, you don't want to / can't use the other variables for consistency's sake.

I can't think of any one solution that takes up too many variables (social, video, etc), but it's more of using one here and one there.  Also, I wouldn't add 75 of each to get a total of 150, since you can't really treat it that way due to the functionality.  The eVars took a huge step with v15 with adding some traffic variables.  I'd still treat this as 75 since typically you use one of each for custom variables, but lately I've found I only use props if I need a correlation with another traffic-only variable (such as the Pages report) or if I need pathing or some of the pathing metrics.

Apart from Tim's point, I've noticed those that are mature in their use of SiteCatalyst and have had it for several years find more and more to track, especially on larger sites.  Data is becoming more and more important, and 75 dimensions (although awesome) is now becoming too few.  We've gotten to the point that some variables have been repurposed, and most everything else has been filled, and now every variable that is filled is important and we can't figure out which one to cut, and our methods for using variables as smart as possible is running out.

Thanks for your consideration on this.

I actually need more and more events (as well as some more eVars). Also there is only one "purchase" event which is hard for us in cases where we have a "subscription"  shop and a "product" shop.

I'm with Tim and Adam...  Intel runs into the same difficulty for the same reasons.  They have gotten around this a little by having a set of "have to be the same across all suites" variables and then a set of "freebies" that can be used for individual suite needs.  This works ok with the understanding that some of the reports within the global suite will be garbage due to the fact that every suite uses the variable differently, but allows them to maintain consistancy across the variables defined for core "global" metrics.  Even so, more would help to resolve this and would prevent the need for "creativity" when using a global or roll-up suite across many individual and unique sites.

I agree with the other posters here.. we work with several clients that are quite large.  Hundreds of report suites dedicated to specific sites, markets, countries, regions, etc.  Keeping things consistent all the way up to the global rollup is a daunting task.  A lot of it boils down to red tape.  Lots of stakeholders with their knife in the pie.  Quite often you end up having to burn an eVar one one little thing on one site out of hundreds, and that has to bubble up all the way to the global rollup to keep things consistent.  As MikeHaymond mentioned, it helps to have "wild card" vars that individual stakeholders can use, that make group/global rollups look like garbage, but even that only goes so far. 

I will admit that this probably isn't a problem for a lot of clients out there.  Indeed, we have plenty of clients who only use a handful of vars and will likely remain that way until the end of time.  But I wouldn't call this an "edge case" scenario.  This is an issue that keeps coming up for enterprise level, true global companies.  And considering SiteCatalyst is supposed to be an enterprise level solution..