evars and props best practices

[scottt6073095]

I was just curious if anyone else assigns evars for pageName, domain and other props and on a hit expiration versus visit expiration? and does anyone not even use an evar for props? I know its based on the requirement however, I am trying to put together a list of best practice evars and props you always want to make sure to create regardless of requirements.

[Gigazelle]

I'll let others weigh in here, but with the new features Adobe Analytics continually gets, omitting props altogether becomes more and more enticing. You don't need to worry about having to explain the differences between props and eVars to colleagues - they're all just custom variables (eVars). Pathing for eVars is available in workspace, list vars are way better than list props, and if you need a variable that doesn't persist, you can simply tell an eVar to expire after hit.

In the implementations I manage, eVar1 is always page name, and eVar2 is typically URL just so we have those dimensions and don't have to deal with the weird attribution that the regular page name variable has. I find the eVar page name to be much more reliable, especially as I'm able to use it in link tracking calls (page name is otherwise stripped from link tracking calls).

[gflare]

^this, exactly!

From my standpoint of usage, there are only two big roadblocks remaining. These are the last obstacles that stop eVars from completely taking over the world:

1. Workspace pathing

     a. It still uses a querying shortcut, so it doesn't compute correctly when hit based segments are used in workspaces.

          (this should be known to the product team already, I walked through it with someone back in Q4.  But I'd gladly demo it again to help achieve an accurate pathing tool in future versions).

     b. It doesn't have a post-processing option to 'remove repeated values', (Yet ! )

2. List variables are a limited quantity. (hopefully on the roadmap to allow more at some point)

Aside from these two items, eVars have really become the universally applicable/flexible variable type.

[Jennifer_Kunz]

I'd say duplicating things in an eVar AND a prop used to be a common (even a best) practice but agree with Gigazelle​ that it isn't needed as much anymore, because Adobe is continually removing barriers that used to exist between "traffic" and "conversion" information. Because they aren't needed to get around those barriers any more, I'd say I actually prefer things NOT to be duplicated- having multiple dimensions with the same name can be really confusing to users.

As already mentioned, eVars can do pretty much everything a prop can, but props CAN'T do everything an eVar can.... so in many cases, props just aren't needed. The only reasons to still use a prop for something are:
1, you're running out of eVars and have some data that doesn't need to persist, so you'll save an eVar by using a prop.

2, you do need some of the old pathing reports ("flow" visualizations in workspace are great but they haven't entirely replaced pathing, especially for stuff like "time spent on..." or pathfinder)

I agree again with Gigazelle, that having pageName in an eVar is often necessary (I'd set it to visit, not hit, so that it can apply to custom links), and URL in an eVar is better than a prop because of character length limitations (256 chars vs 100 chars).
I often put troubleshooting info ("D=mid", the DTM/Launch library name or build date, etc) into props just to save on eVars, since those are usually not used for analysis beyond spotting issues.