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

[#1]

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.

[#2]

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

[#3]

And give me about 200 of them.

[#4]

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"

[#5]

Subsequent Visit. I like that metric!

[#6]

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)

[#7]

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

[#8]

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.

[#9]

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.

[#10]

@adamgreco0 They could technically consider this delivered with CJA.