Always eVars and Never Props?

[skatofiabah]

Hi All,

I'm trying to understand when you would ever use a prop? It sounds like eVars can just be set on everything (page and link calls). I don't see the point where I would ever need to use a prop in analysis...

Thanks!

[Achyuth19]

@skatofiabah eVars track something over multiple pages or sessions, like a campaign or user action that lasts a while. Props are for capturing data on a single page or event, and they don't stick around after that. Props are useful for quick insights and understanding the flow of users on your site, while eVars are better for tracking things that matter over time

[skatofiabah]

Hi @Achyuth19 ,

You can still do page pathing and single page and event analytics with eVars though and they are more specific and better. So I'm having trouble understanding the use to ever choose a prop over an eVar.

[prads]

Hi @skatofiabah ,

1. Props can collect data instantly and available for reporting. You can use props in real-time reports. eVars take at least 30 minutes to appear in reporting.
2. Props have the ability to become list props, which accept multiple values in the same hit. List eVars are a separate variable, and there are only three list variables available.
3. Props use pathing. which helps your organization to know how the user visited your site.

[skatofiabah]

Hi @prads,

I read this on the prop analytics documentation. It still sounds like an eVar can do all of that and what a prop can do.

[yuhuisg]

Nope. @prads  #1 and #2 points are features that are exclusive to props.

[bjoern__koth]

The limitation to 3 list vars (does anyone actually know why there are only three?) can be worked around with e.g., prefixing values like s.list3="tag:product page,language:German,..."

You will obviously have to filter the values for your namespaces, but technically this gives you flexibility to work around this limitation.

And about real-time reports: I don't think many people are using them anymore since they are just a pain to set up and use and not really comparable to what the competition has to offer.

[Jennifer_Dungan]

I assume it's limited to 3 because of some of the original architecture of the system... CJA you can do as many as you want....  I just use the prefix method myself lol.

[Jennifer_Dungan]

@skatofiabah you are correct, eVars can do most of what props can do... you can set them to hit expiry, you can use your flow diagrams.

Some of the points that @prads makes is that props are available immediately (I have not seen that... maybe for the real time reports (which need an overhaul) or the old "Reports and Analytic" which is now gone, but Workspace always has the same delay on showing the content (prop or eVar), and if you are using processing rules, you need time to let those process anyway.

List props are a good example, if you need another list, and you know it will be under 100 characters in total, a "list enabled prop" is a good option. The three "list" vars you get can take as many items as you want, so long as each item is under 255 characters, you could pass hundreds of items... but there is only 3 available (but using prefixes and classifications you can make 1 list handle multiple items....)

As for pathing... that only pertains to the now sunset Reports and Analytics... as Flows can be used with any dimension.

The way I see it, for complex implementations, ones that I know will use a lot of dimensions, I will continue to use the 75 props available to me for small page level dimensions, then use Props (set to Hit expiry) for large page dimensions, as well as eVars for attribution, and eVars for Merchandising dimensions... 

You don't have to of course... that is your prerogative... if you know you won't exceed your eVar limits, then you can do most of everything with eVars.

[bjoern__koth]

Fully agree with @Jennifer_Dungan 

We had this discussion a while back, based on my question. I try to implement eVar-only setups for all of my new clients and have not yet had the need for a single prop. Just make sure to set the expiration to Hit and you're good.

And yeah, real-time reporting has never really worked reliably for me. At least not remotely comparable to what Google provided. Would be amazing if Adobe could come up with anything similar in the future. Until then, if the requests contains the data, I typically trust what I am seeing in the payload, but can also fully understand that especially newbies are having a harder time (been there year ago before all the fancy browser extensions existed)

[gmadala]

Well I am gonna give you a different perspective. 
Lets say you start doing everything with Evars in implementation and you will run out of the number of evars thats allotted. So rather try to evaluate when is it best to set the prop vs evar. 

[Jennifer_Dungan]

Well I did allude to that... Not all sites / implementations will need all the available eVars... they might, especially if the needs grow over time... 

However, I have had a few smaller sites on our accounts that didn't need more than 20 dimensions... I have others that I absolutely need to maximize my dimension usage...

So I agree about using what you have smartly... if you aren't sure where a site might evolve to, then using your props effectively from the start is definitely a good idea. Though, while not ideal, if you need to, nothing is technically set in stone.. it may be an annoyance, and a lot of redone work... if in a few years you run out of dimensions, you can rework those eVars to use Props so that you can make use of the conversion variables.... 

I don't advocate for that of course... even in small implementations, I use the props where I can... but for some sites, I knew from the start they would never run out of eVars (and could have, had I chosen to do so, used all eVars without worry)

[skatofiabah]

Hi @Jennifer_Dungan ,

Thank you for the quick response. The safest bet seems to just use eVars and keep it as short as possible. And if it needs to expire on hit like a prop, then do so. Otherwise, we are good?

[Jennifer_Dungan]

Well there are exceptions to every rule, but if you are unsure, test our scenarios in a Dev environment. See what data you get, build reports on that data, make sure you are accommodating your needs. It's hard to give a generic answer without seeing your site, or your requirements, or know how your site might grow.