Combine Traffic Variables (sProps) and Conversion Variables (eVars)

@adamgreco0 They could technically consider this delivered with CJA.  😁

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.

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.

This idea is duplicated by No more eVar/Prop/List, just give us 200+ custom variables​, adding an additional 21 votes here.

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)

Subsequent Visit. I like that metric!

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"

And give me about 200 of them.

Adam,

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.

Dylan