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

Avatar

Avatar

adamgreco0

Avatar

adamgreco0

adamgreco0

11-02-2010

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.

8 Comments (8 New)
8 Comments

Avatar

Avatar

dylanlewis

Avatar

dylanlewis

dylanlewis

12-02-2010

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

Avatar

Avatar

rodan32

Avatar

rodan32

rodan32

21-02-2010

And give me about 200 of them.

Avatar

Avatar

hi_nick

Avatar

hi_nick

hi_nick

07-09-2010

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"

Avatar

Avatar

jchuck5612

Avatar

jchuck5612

jchuck5612

28-09-2017

Subsequent Visit. I like that metric!

Avatar

Avatar

joshd7227840

MVP

Avatar

joshd7227840

MVP

joshd7227840
MVP

07-11-2017

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)

Avatar

Avatar

Gigazelle

Employee

Total Posts

1.9K

Likes

458

Correct Answer

734

Avatar

Gigazelle

Employee

Total Posts

1.9K

Likes

458

Correct Answer

734
Gigazelle
Employee

10-05-2018

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

Avatar

Avatar

jeff_bloomer

Avatar

jeff_bloomer

jeff_bloomer

29-08-2018

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.

Avatar

Avatar

jeff_bloomer

Avatar

jeff_bloomer

jeff_bloomer

19-09-2018

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.