Adobe recommends using eVars, not props

[danielwalo]

From the props documentation page:

Adobe recommends using eVars in most cases. In previous versions of Adobe Analytics, props and eVars had advantages and disadvantages to each other. However, Adobe has improved eVars to where they fulfill almost all use cases for props.

This one puzzles me. eVars work with events because eVars persist, while props don't perisst. For instance, when building hit-based segments for traffic reports, I would use props because I know I won't include unwanted hits due to an eVar still being set.

What are your thoughts on this recommendation? Do I use an out-dated understanding of how eVars and props work?

[PratheepArunRaj · Accepted solution]

Dear Daniel,

Adobe recommends eVars over Props because if you set eVar expiration to Hit, it behaves as a Prop. The earlier version of Adobe Analytics had advantages related to segmentation (As you said), Pathing, Participation, etc.

Even if you build a segment in eVar, now you have the option to select Default (Repeating), Instance, and Non-Repeating as attributions, so you can use eVar now instead of Prop.

Pathing is available in Workspace for all the dimensions.

Attribution modeling made all the attributions possible.

If you think about everything, an eVar can replace Prop easily and thus Adobe Recommends it. 

Thank You, Arun.

[danielwalo]

Hi Arun. In the eVar docs, it says: "After the eVar expires, it no longer receives credit for success events." So I assumed that setting an eVar expiration to "Hit", it could not by default be combined with success events in subsequent service calls. Is that assumption still correct? I had not explored Attribution in Workspace before. Does the "Use non-default attribution model" setting override expiration-based crediting, such that a Hit-expired eVar will be credited with subsequent success events?

[PratheepArunRaj]

Hello Daniel, Yes. If you set the expiration of eVar to Hit, it will not get the credit for success events in the subsequent server calls. But this is applicable for default attribution only. If you change the attribution using Workspace, you can attribute based on the models. That is why both prop and eVar is same now!

[danielwalo]

Ok, that starts to clear things up. Another way would be to define a Calculated Metric with a non-default model and set the original event's visibility to "Hidden", I suppose. So since eVars can now have pathing through the Flow visualization and get Participation by default, that's why there may not be a need for accompanying props? (Unless we need real-time or more than 3 list dimensions?)

[PratheepArunRaj]

Hello Daniel, yes you are right!

[danielwalo]

Thanks, this was very helpful.