Join us January 15th for an AMA with Champion Achaia Walton, who will be talking about her article on Event-Based Reporting and Measuring Content Groups!
I would like to see the custom segmentation variable types combined so everything is an eVar, but with Pathing optional. sProps would simply be eVars with Pathing enabled and an expiration of “Page View.” This would also include the combining of Correlations and Subrelations.
I have to have Weekly Unique Visitors to understand my business on a weekly basis. If it were possible to have one set of measures that included weekly unique visitor counts along with commerce settings on these values, that would be awesome.
Another option is to include the weekly, monthly, quarterly counts along with the daily and visit counts for the commerce variables.
This would make the complex eVar vs. prop issue disappear. You ever try explaining this to someone new to Omniture....I want to poke my eyeballs out!!
props=eVar instances
props also have
-visits
-daily, weekly, monthly, etc. visitors
-pathing
-participation
These items should just be a feature to enable on an eVar if needed.
Also eVar visits/visitors does not equal prop visits/visitors. If an eVar value persists past the visit it is counted as a visit the next time that same visitor comes to the site, even if the eVar value is not set in that visit. This is because eVar visits is determined from the post eVar column not the eVar instance column, eVar visitors is basically daily unique visitors. So if eVars and props are combined there would have to be a new metric of "post visits" as well as the normal "visits"
I would like this to be taken a step further and get rid of numbered variables altogether. Adobe introduced contextData variables a long time ago. I would like to set contextData['foo'] and then in the interface, create an entry for "foo" where I configure pathing, expiration, etc.. (and while we're at it, allow to specify multiple expirations and first one wins, e.g. expire on eventX or visit whichever comes first)
What I like about this is it makes the variable instantly recognizable, instead of needing to remember eVarX is searchTerm. Also, I agree that it would be helpful to have a LOT more than 200 variables. Last, giving us the ability to decide what functionality a variable provides us would make things easier to implement, especially list variables (i.e., arrays), since we only have 3 at the moment.
Bonus would be the ability to create our own objects similar to the products string where we could determine the types of elements that make up each column, which could include events and conversion variables.
Just thought I'd check back on this one. This would give us a whole new world of freedom to manage the data coming into our implementations. I'm sure it would make things more interesting for Clickstream downloads, but honestly, I think it would make it easier for the data scientists consuming those feeds. It will also make it a LOT easier for us to manage report suite consolidation. If we had the ability to rename eVar1 to the associated context variable in one report suite, we could then more easily map that same variable to its counterpart in a sister report suite. A lot of the work that many of us are considering would be made a whole lot easier.
