Adobe Analytics eVar Expiration

[Rafael_Sahagun]

Hello team,

We all have heard that the line between a sProp and an eVar is blurring.

From what I can think, an eVar with hit expiration is technically a sProp. And an eVar to be used/useful has to have an expiration longer than a hit.

I'm auditing a site with eVars are set as hit/last touch and there are some sProps too (which could have taken care of the hit based). I don't recall any other implementation I audited seeing eVar hit expiration.

Would be great to know advantages of doing so, as well as to get some scenarios where each expiration is good idea, specially the useful yet un-intuitive ones.

Does it matter now that Adobe offers applying diverse attribution methods to the same call.  That is attribution but still the expiration question is pending.

Kindly point me to some blog article if there is one, if not I think would be a great topic, and a segue to how it will be in CJA without props and evars and more of hit or event, visit or session and person or people, etc.

Thanks!

[igupta]

Using eVars without persistence are indeed using them like props! Though I wonder what you are saying about attribution. I think that way an eVar can only respond to only Same Touch attribution model?

[Rafael_Sahagun]

I'd think last touch is current touch for a hit based eVar.

[Jennifer_Dungan · Accepted solution]

I second this... eVars with Hit expiry act just like a prop.. I have many such eVars, I also still have props.

Here are some of the biggest considerations that I follow:

Props

• These are hit based, with a max character count of 100.
• Props can be made into "lists", so long as the overall count does not exceed 100 characters, you should be safe to do so.
• Props also support the calculated Entry and Exit value (i.e. the first value tracked during a visit and the last value tracked during a visit)

eVars

• These can be configured to the attribution of your choice, they have a max character count of 255.
• eVars cannot be made into lists, but there are three reserved "List" dimensions that have attribution settings like eVars...
• eVars do not support Entry and Exit values
• eVars can however be set up as merchandising eVars, tied into your Product Notation, or be configured as "Conversion Syntax" meaning that that last value (or first if set up that way) will be stitched into the Product data based upon a binding event  (such as "add to cart" or "purchase", etc)
• eVars can also be set up as "counters".. they still hold the values as text, but you can use notation such as "+1" to increase the value based on the last value that Adobe saw...  (the first instance would be "1", then "2", then "3", etc)

Lists

• Lists are basically a more advanced version of the prop list, but act like eVars, as they can have attribution applied
• More importantly, each item in the list can hold 255 characters, but there is no limit to how many items can be passed

For me, to maintain a lot of historical needs (particularly since changes would cause ripples right to the data lake), I still use our props... but even if I was starting a suite from scratch, items that I know I want at the Hit level, as well as values that I know don't need more than 100 characters, I still use props... but I use a lot of Hit based eVars for data that I don't want truncated (or at least reduce the impact of truncation), such as tracking the current URL, or a replication of my Page Name (which allows me to maintain the value on actions as well as page views - something the default "page" cannot do).

If I need attribution (such as internal campaign tracking, or even my visit level external campaign tracking) I will use those properties to my advantage with my eVars. And of course, when dealing with Products List, I use Merchandising eVars to ensure I have all the details needed to provide context.

[Rafael_Sahagun]

Thanks @Jennifer_Dungan 

As I understood it, if you fire a page name eVar on a page view and then an again on an action on that same page, can run a conversion page name report showing pageviews and actions on 2 columns of the same report?

The truncated characters reason makes sense too.

[Jennifer_Dungan]

Yes. I use the data in a lot of ways..

If I pair my "replication page name eVar" with Page Views, it will match the values of "pages" report.

I can also correlate this eVar with any of my actions to see what page the action occurred on... also, as you said, you can also set up columns... PVs and Actions (you can use the Custom Link Instance to isolate actions, or maybe you have custom events set up on different actions, occurrences of course is a combination of PV and Actions). 

For page name, I know that some people like to use attribution to maintain the value onto the actions, but I prefer HIT to ensure that if the action occurs before the page view, the correct value is tracked (instead of the previous page's value). I usually prefer to use my attribution where it really makes sense... values that should be persisted through to conversions (like campaigns for instance). Though, everyone has their preferred methods.

Then of course, I can use these values in my segments as well (while "default" and "instance" will be the same, I could use "Non-consecutive Instances" if I really need to get more isolation on the values) 

[Rafael_Sahagun]

great info @Jennifer_Dungan !

[Jennifer_Dungan]

I should add... when it comes to CJA, basically you can just configure your variables with the properties and attributes as needed... they basically have done away with the specific naming conventions of "prop" or "eVar".. 

The most important aspect is ensuring that you are using the correct attribution for your needs (though I believe that CJA can control the attribution on the fly, an evolution of the custom attribution available in AA)