using evar when we look into the # of traffic

[kr8tive]

hi

this is just an elementary question. It is a well-known fact that props are traffic variables and evars are conversion variables.

let's say there are two variables for a page which are a prop and an evar.

when I want to know the CTR of a button, I use the # of clicked visits from the segment with page(evar) and visits from the prop variable

It is the same when I want to make a sequential segment that is for # of traffic on a certain page with preconditions

preconditions

then

page(prop) = A

My colleagues suggest that it might be more accurate to use a different variable when tracking traffic, as the page(evar) variable is typically focused on actions

so we strictly distinguish cases for using props and evars.

then I saw this from Adobe's documentation that says

"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."

does this mean it is better to use eVars when we make custom variables even that are related to traffic?

what if there is only a variable for a page that is evar, then is it wrong if we look into the # of visits with evar? (because it is the conversion variable)

also, it seems the # of visits to page(evar) is always higher than page(prop), what are the possible reasons for this?

I understand why evar is used for conversion variables but when it comes to traffic, I am a bit confused.

thanks in advance

[Jennifer_Dungan · Accepted solution]

Honestly, duplicating props and eVars hasn't been common practice for many years now. With the ability to cross correlate props and eVars in Workspace, and the ability to set the expiry of an eVar to Hit (like a prop) the lines between props and eVars are much more "blurred".

Adobe has said on multiple occasions that they have considering sunseting props altogether.. nothing official has been announced, and due to the number of users still using Props I doubt it will happen... with CJA not referring to the dimensions as "prop" or "eVar" is likely just the direction they will go... let Analytics continue to use the two, until clients eventually move to CJA which is getting more and more features that Analytics has now, eventually CJA will be the only package (but that is many, many years away)

I use the two interchangeably... with only 75 props and 250 eVars, I needed more than props could cover.

Here are some factors I take into consideration when deciding where to send my data.

Props:

• Hit expiry only
• 100 character limit
• can be turned into a list item (also limited to a total of 100 characters for the entire list

eVars:

• Can be set to expiry of choice (Visit is default, but I would say more than half of ours are set to Hit)
• 255 character limit
• Cannot be turned into a list item (however, there are three reserved "list" items which are technically eVars with selectable expiry, however, each item in the list can hold up to 255 characters instead of being limited to the entire string)
• Can be used as Merchandising values

Both of the above can be used with custom attribution in Workspace, allowing you to see "Visit" level data on a prop if needed... it's easier to "up" the attribution model, than to downgrade it (keep that in mind when deciding how to track your dimensions)

So, if the data I am tracking I know is short, and most of the time I will need it to be Hit, I will use a Prop.... If the data I want to store is long (replication page name to use with actions, urls, etc) I will use an eVar.

If I definitely need Visit level attribution, I will use an eVar, no matter how long or short the value is.... 

If I need merchandising values with my products, then I use eVars.

Let's look at a sample implementation and the flow

Prop1 = page type

eVar1 = page name (HIT level attribution)

eVar2 = campaign tracking (VISIT level attribution)

Visit 1 (campaign X):

• Social Media Post with Campaign X sending people to the site
• Page A
  • prop1 = "home"
  • eVar1 = "page a"
  • eVar2 = set to "x"
    
    • Instance of eVar2 is triggered
• Page B
  • prop1 = "product"
  • eVar1 = "page b"
  • eVar2 = not set
    • eVar2 will still record as "x" due to Visit Level attribution
    • Instance of eVar2 is not triggered
• Add to Cart Action
  • prop1 = "product" (set specifically because if not, this is hit and won't follow through)
  • eVar1 = "page b" (set specifically because if not, this is hit and won't follow through)
  • eVar2 = not set
    • eVar2 will still record as "x" due to Visit Level attribution
    • Instance of eVar2 is not triggered
• Page C
  • prop1 = "cart"
  • eVar1 = "page c"
  • eVar2 = not set
    • eVar2 will still record as "x" due to Visit Level attribution
    • Instance of eVar2 is not triggered
• Order
  • prop1 = "cart" (set specifically because if not, this is hit and won't follow through)
  • eVar1 = "page c" (set specifically because if not, this is hit and won't follow through)
  • eVar2 = not set
    • eVar2 will still record as "x" due to Visit Level attribution
    • Instance of eVar2 is not triggered

		Page View	Instance of eVar2	Add to Cart	Orders
Prop1		3	1	1	1
	home	1	1	0	0
	product	1	0	1	0
	cart	1	0	0	1

		Page View	Instance of eVar2	Add to Cart	Orders
eVar1		3	1	1	1
	page a	1	1	0	0
	page b	1	0	1	0
	page c	1	0	0	1

		Page View	Instance of eVar2	Add to Cart	Orders
eVar2		3	1	1	1
	x	3	1	1	1

Visit 2 (campaign X and Campaign Y):

• Social Media Post with Campaign X sending people to the site
• Page A
  • prop1 = "home"
  • eVar1 = "page a"
  • eVar2 = set to "x"
    
    • Instance of eVar2 is triggered
• Page B
  • prop1 = "product"
  • eVar1 = "page b"
  • eVar2 = not set
    • eVar2 will still record as "x" due to Visit Level attribution
    • Instance of eVar2 is not triggered
• User gets a Marketing Email promoting another product, campaign Y
• Page D
  • prop1 = "product"
  • eVar1 = "page d"
  • eVar2 = set to "y"
    
    • Instance of eVar2 is triggered
• Add to Cart Action
  • prop1 = "product" (set specifically because if not, this is hit and won't follow through)
  • eVar1 = "page d" (set specifically because if not, this is hit and won't follow through)
  • eVar2 = not set
    • eVar2 will still record as "y" due to Visit Level attribution
    • Instance of eVar2 is not triggered
• Page C
  • prop1 = "cart"
  • eVar1 = "page c"
  • eVar2 = not set
    • eVar2 will still record as "y" due to Visit Level attribution
    • Instance of eVar2 is not triggered
• Order
  • prop1 = "cart" (set specifically because if not, this is hit and won't follow through)
  • eVar1 = "page c" (set specifically because if not, this is hit and won't follow through)
  • eVar2 = not set
    • eVar2 will still record as "y" due to Visit Level attribution
    • Instance of eVar2 is not triggered

		Page View	Instance of eVar2	Add to Cart	Orders
Prop1		4	1	1	1
	home	1	1	0	0
	product	2	0	1	0
	cart	1	0	0	1

		Page View	Instance of eVar2	Add to Cart	Orders
eVar1		4	2	1	1
	page a	1	1	0	0
	page b	1	0	0	0
	page c	1	0	0	1
	page d	1	1	1	0

		Page View	Instance of eVar2	Add to Cart	Orders
eVar2		4	2	1	1
	x	2	1	0	0
	y	2	1	1	1

Visit 3 (campaign X and Campaign Y, multiple Orders):

• Social Media Post with Campaign X sending people to the site
• Page A
  • prop1 = "home"
  • eVar1 = "page a"
  • eVar2 = set to "x"
    
    • Instance of eVar2 is triggered
• Page B
  • prop1 = "product"
  • eVar1 = "page b"
  • eVar2 = not set
    • eVar2 will still record as "x" due to Visit Level attribution
    • Instance of eVar2 is not triggered
• Add to Cart Action
  • prop1 = "product" (set specifically because if not, this is hit and won't follow through)
  • eVar1 = "page b" (set specifically because if not, this is hit and won't follow through)
  • eVar2 = not set
    • eVar2 will still record as "x" due to Visit Level attribution
    • Instance of eVar2 is not triggered
• Page C
  • prop1 = "cart"
  • eVar1 = "page c"
  • eVar2 = not set
    • eVar2 will still record as "x" due to Visit Level attribution
    • Instance of eVar2 is not triggered
• Order
  • prop1 = "cart" (set specifically because if not, this is hit and won't follow through)
  • eVar1 = "page c" (set specifically because if not, this is hit and won't follow through)
  • eVar2 = not set
    • eVar2 will still record as "x" due to Visit Level attribution
    • Instance of eVar2 is not triggered
• User gets a Marketing Email promoting another product, campaign Y
• Page D
  • prop1 = "product"
  • eVar1 = "page d"
  • eVar2 = set to "y"
    
    • Instance of eVar2 is triggered
• Add to Cart Action
  • prop1 = "product" (set specifically because if not, this is hit and won't follow through)
  • eVar1 = "page d" (set specifically because if not, this is hit and won't follow through)
  • eVar2 = not set
    • eVar2 will still record as "y" due to Visit Level attribution
    • Instance of eVar2 is not triggered
• Page C
  • prop1 = "cart"
  • eVar1 = "page c"
  • eVar2 = not set
    • eVar2 will still record as "y" due to Visit Level attribution
    • Instance of eVar2 is not triggered
• Order
  • prop1 = "cart" (set specifically because if not, this is hit and won't follow through)
  • eVar1 = "page c" (set specifically because if not, this is hit and won't follow through)
  • eVar2 = not set
    • eVar2 will still record as "y" due to Visit Level attribution
    • Instance of eVar2 is not triggered

		Page View	Instance of eVar2	Add to Cart	Orders
Prop1		5	1	2	2
	home	1	1	0	0
	product	2	1	2	0
	cart	2	0	0	2

		Page View	Instance of eVar2	Add to Cart	Orders
eVar1		5	2	2	2
	page a	1	1	0	0
	page b	1	0	1	0
	page c	2	0	0	2
	page d	1	1	1	0

		Page View	Instance of eVar2	Add to Cart	Orders
eVar2		5	2	2	2
	x	3	1	1	1
	y	2	1	1	1

You can see that a HIT level eVar behaves the same as the Prop, the VISIT level eVar you can see the "Instances" (i.e. the hit where the value was set with the dedicated "Instance of eVar2" metric, but you can also see everywhere that the value existed using the Page View Metric). The Add to Cart and Orders pick up the whatever values are sent on the call, and the last set value within the visit for the campaign eVar.

The biggest challenge in the past between props and eVars was the ease of correlation.. the old Reports interface didn't allow these to correlate against one another, but you could in Data Warehouse exports.... 

In Workspace you can correlate everything, so duplicating your values isn't really helping you any longer..... So long as you understand the attribution models and what you need / how you want it to track, you can absolutely use eVars instead of props. If your colleagues have been doing this a long time, I can understand why they are "stuck" in the old-school way of thinking, particularly if they haven't been keeping up with modern tracking techniques.

What they say "used to be correct" (or at least standard practice), but not so any longer. And for the record, I came from that "old school" time... back when this was still Omniture SiteCatalyst (before Adobe acquired the technology).

[abhinavbalooni]

@Jennifer_Dungan Always amazed with the effort you put into all your responses !

One more thing that people still tend to think is that only props can be used for pathing whereas eVars can also be used in flow reports in the workspace.

So props definitely are on a deathbed !

Cheers,

Abhinav

[Jennifer_Dungan]

Honestly, I still miss the old pathing (I liked the simple list of page to page over the busy flow diagram), but there are ways to pull that out with a little effort... 

But you are right, "enabling pathing" was another feature that props had over eVars, but with Reports gone/going away (I think it will be like GA3, the old Reports will be turned off incrementally account by account), I felt it wasn't worth mentioning as its a deprecated feature

Also, thank you for the kind words 

[kr8tive]

thanks for your effort to take the time to answer my question.

just to be clear, let's say I made two segments like below

segment a 

hit bucket

page(prop) = A

segment b

hit bucket

page(evar) = A

when i look into the visit metric for a month, segment with evar had 1,070,297 visits and prop had 1,065,895 visits.

so the reason for the difference in # of visit metric for two segments are due to the conversion variable setting.

conversion variables are in default settings which means it expires after visit. 

so eventhough i use hit bucket for segments, there would be difference in the value of metrics unless i change the expiry to hit. 

decisions to use either prop or evar when making a segments depends on what metric i use, which attribution model i want, and the date range for the action.

am I on the right track?

[Jennifer_Dungan]

Correct!

My "page" level eVars I set to Hit to make sure they don't carry forward to places that I don't expect... if I want them on a "page view" and on "actions" (clicks, etc), then I send them specifically..

Even in your segments, you could pair with specific events, i.e.

HIT

    page (evar) = A

    AND

    Instance of page (evar) exists

That would limit the eVar to where it's specifically set, and exclude the "values set via the VISIT level attribution"... If the eVar is set in the same contexts as the prop, then the segments should match... however, I have seen some implementations where:

Page Views: prop and eVar set

Action: eVar set

If you have that, then you could try:

HIT

    page (evar) = A

    AND

    Instance of page (evar) exists

    AND

    Page View exists

Basically limiting the eVar to where it's set and just to Page Views....

Obviously it would be better / easier to have the eVar set to Hit expiry....

Changing your implementation is a large task, I had to do a similar one years ago. But with some creative segment creation you should be able to get more granular data from your eVars.