When to Use Both eVar and Prop in Adobe Analytics

[priyankagupta20]

Dear Team,

In which cases, it makes sense to capture the same value in both an eVar (conversion variable) and a prop (traffic variable) to get the best of both tracking methods. 

And When to Use Only eVar

And When to Use Only Prop

Could you please guide with example, thank you

[Jennifer_Dungan · Accepted solution]

Honestly, there is very little need to pass the same value to both a prop and an eVar.. that was a popular implementation method back when we only had Reports and Analytics, and you we didn't have full correlation... with Workspaces, that barrier is gone...

However, that said, there are still a few considerations... let's first look at the fundamental differences between props and eVars:

Props

• Hit level only
• Max Characters: 100
• Supports "lists" (full list plus delimiters limited to 100 characters)
• Supports "Entry PropX" and "Exit PropX" (basically the first and last value tracked into the prop during a visit)
• Back in the history of Reports and Analytics, Props were also the only dimension that could be used in the Pathing Reports, but the Flow diagrams in Workspace don't adhere to that restriction
• 75 Available Props

eVars

• Custom Expiry (including Hit, so you can make it work like a prop)
• Max Characters: 255
• Includes an "Instance" metric when the value is set (this can be used to distinguish between a set value and a persisted value)
• Up to 250 available eVars (depending on your contract)

Lists

• Essentially "special" list eVars
• Max Characters: 255 per item (so you can pass as many items as you want)
• Same expiry options as eVars
• Only 3 available list dimensions

So, given the above, unless you really need to have access to the first value collected in your dimension (not necessarily your entry hit), or you need the last value collected (not necessarily the last hit of the visit), you can do pretty much anything you can do with props with your eVars (except for lists... but the 100 character limit makes this more subject to issues).

I use many eVars with Hit level expiry, making them function like props... but it allows me to store more characters... this is very handy for tracking things like my URLs or replication Page Names (which can be longer than 100 characters, but also I need to collect this value on my actions, which the standard s.pageName doesn't do).

I still use props for shorter values, that are at a Hit level, we collect a lot of dimensions, so I don't want to waste my eVars.

Back in the day, it was popular to use a prop to track the "explicitly set" value, and the eVar to track the set and persisted values... but with the "Instance" metric this is not needed... now, a lot of "old school" people still think of instances as a "avoid at all costs" / "these are bad" metric, but that's not the case... the inherent problem with instances was the old Reports and Analytics deferring to instance instead of the selected Page View when looking at correlations, so this often led to inflation.... but when you are using the metric correctly, these are powerful metrics...

Let's say you are tracking a campaign code... you have an eVar collecting the value, with a Visit Level expiry.

The "eVar Instance" will be where the campaign code was explicitly set, the Page Views will be the page views (including where it was set) for the remainder of the visit (or until a new value is set), and the Occurrence will include all page views and actions (i.e. clicks, orders, etc) for the remainder of the visit....

Even the segment builder has logic for how to handle eVar attribution:

Repeating is everywhere there is a value (i.e. the persisted value), Instance is limited to where the value was explicitly set, and Non-repeating Instance looks at the instances, but then further excludes concurrent values (i.e. A > A > B > A > C only the bolded values will be returned in this instance, the second A is excluded because the previous value was also A)

There are of course many ways to do your implementation.... you have to figure out what works for you and your business users.

[priyankagupta20]

Jennifer, Thank you very much.
Could you please share any real example. 

[Jennifer_Dungan]

For me, I need a lot of hit based variables... more than can be covered with 75 props... so shorter for values like "page type" or "asset id", I use props. For longer values, but still something I only need at the hit level, I track in eVars with Hit expiry, but make use of the longer 255 characters such as "Full URL", "Canonical URL" (this is because we have 30 news sites that share content, I track the originator of the content), "Page Name" (this is also tracked on actions, something the standard "Page" doesn't do), etc.

When I need to leverage the persistence feature, such as internal campaigns (ITMs), external campaigns (UTMs - this I handle in the standard 1 week "Tracking Code" dimension, but then also have individual eVars with Visit expiry as well). 

Then, Mandy brought up a good point about Merchandising eVars, in our Products Notation, I use a lot of Merchandising eVars to collect additional information about each item...  so in our case, we sell subscriptions, so I track things like the package name, the package period (monthly or yearly), etc... but then I also use s.products to track more than just our "purchases", because of the nature of merchanting eVars being able to explicitly connect data to each "product" or "asset" individually, I use this to track our Subscription Walls and Popups, etc... Tracking information about what wall was shown and what rule triggered it (collecting both names and unique guids), etc.

Every implementation will be different, and if you are starting out, not everything you do upfront will work out.. you have to see how it works in prod, and then make tweaks or improvements... or go back to the drawing board completely... other things may work out great and be a staple for years or decades.

[MandyGeorge]

Props and evars do slightly different things. Props expire on the hit, but they also have entry and exit dimensions attached to them that are good for pathing. Evars persist beyond the initial hit based on the allocation/expiry. You can set up an evar to expire on the hit so it acts like a prop, but an evar won't have entry/exit dimensions regardless of how it is set up.

When to use evars:

You want to use these when you have a dimension item that you want to persist and be able to attribute conversions/success events to it. For example, something like a search term. This would fire when a customer does a search on the site, by persisting the value (or even by making it a merchandising evar and tying it to specific products), you can remember this search term all the way until a purchase is made, and then give credit for purchases to different search terms. You could also use it for something like a product finding method, such as capturing whether customers found the product through search, browse, a carousel, etc. You can set this up as a merchandising evar, with either product or conversion syntax, so that the finding method binds to the specific product, then when the product surfaces later, such as in cart/checkout you can get credit for those values seen earlier.

When to use regular evar vs merch evar:

Merchandising evars are used when you want to tie a value to specific products. Something like customer group (new vs returning) would just be a regular evar, you wouldn't tie that to products. But something like search term or product finding method, something that directly relates to products, you could set up as a merchandising evar. That way the credit it gives is tied to the specific product and not the hit in general. For example, if you have two products in your order, a regular evar value would get credit for both, but a merchandising evar could give credit to different values for each product in the order (such as if one product was found through search and one found through browse).

When to use props:

Props are used when you don't want the value to persist past the initial hit or when you want to be able to use pathing. Something like 'previous page' I always set up as a prop. I want to know what the previous page was for the next page only, so making sure it doesn't persist will ensure that the previous page value is always the exact previous to the one I'm looking at. Or if you want to know where people enter or exit your site. For example something like page type or site section, so you can see where people are coming in or leaving.

When to use both:
You would use both when your use case falls into both sections. If you want to be able to attribute success events to it and you also want to see entry/exit items. For myself, all of my props are also evars so that I can see conversions if I need to, but not all of my evars are props, because there are fewer use cases for those. One other reason why is that props can only hold up to 100 characters, whereas evars have 255 characters. So any strings that are long (like URLs) are less likely to be cut off/truncated when they are in an evar.

[priyankagupta20]

Thank you very much.
Could you please share any real example. 

[PoornimaThakur5]

Hello @priyankagupta20 ,

I have categorized the pointers and attached example scenarios for each. Let me know if this helps!

--> Only eVar

Use case: Internal search term
Example: A user searches “wireless earbuds”

• You want to know which search terms lead to conversions.
• You set eVar1 = wireless earbuds and let it persist through the session.
• Later, if the user makes a purchase, you can attribute the conversion to the search term.

Why only eVar?
You don’t need pathing or entry/exit. You just care about conversion attribution.

--> Only prop

Use case: Previous page name
Example: A user goes from the "Product Listing Page" to a "Product Detail Page"

• You set prop2 = Product Listing Page when the user lands on the PDP.
• This is helpful to know the immediate previous page and do page flow/pathing.

Why only prop?
You don’t want this to persist : it's hit-based, and you want pathing insights.

--> Merchandising eVar

Use case: Product finding method
Example: A user finds Product A via search and Product B via browse

• You set up a merchandising eVar so the finding method is tied per product
• At checkout, if both products are purchased, you can attribute Product A’s sale to search, and Product B’s sale to browse.

Why merchandising eVar?
Standard eVars can’t attribute different values to different products in the same hit. You need per-product attribution.

--> Both eVar and prop

Use case: Page category or site section
Example: A user visits the "Men’s Shoes" section

• You set eVar2 = Men’s Shoes to attribute revenue from purchases made after browsing this section
• You set prop3 = Men’s Shoes so you can also see entry/exit and pathing reports

Why both?
You want to do both attribution (eVar) and pathing analysis (prop).

Hope this helps!