Expand my Community achievements bar.

Webinar: Adobe Customer Journey Analytics Product Innovations: A Quarterly Overview. Come learn for the Adobe Analytics Product team who will be covering AJO reporting, Graph-based Stitching, guided analysis for CJA, and more!
SOLVED

To get the correct traffic count/source 'previous page' variable to be prop or eVar?

Avatar

Level 1

Presently we are capturing 'previous page value' under eVar but with this we are getting irrelevant previous pages (after breaking down the previous page value) which also contains some pages which are not directly contributing as previous page for that instance. 

So should we use Prop insted of eVar for 'Previous Page' Variable?

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

agreeing with @MandyGeorge 

 

I would assume that the "previous page value" should only be used to break down the "Page" (s.pageName) dimension in your report.

Hence, the value can be discarded after that page view call you are sending it with.

 

So, basically you have two options

  • take a traffic variable / s.prop that automatically epires after the hit
  • keep using your conversion variable / eVar and set the expiration to "Hit", which then essentially mimicks the behavior of a traffic variable

 

One thing to consider is, should your pageName be crazy long e.g., when you are using parts of the URL and have a very deeply nested content hierarchy, you may run into length limitations when using a traffic variable (100 Bytes) whereas the conversion variable can take up tp 255 Bytes.

 

So my recommendation: keep your setup and just change the eVar epiration in your report suite 

 

Hope that helps,

Björn

Cheers from Switzerland!

View solution in original post

2 Replies

Avatar

Community Advisor and Adobe Champion

Props are typically referred to as "traffic variables" because they capture what the customer is currently seeing in whatever step of their journey they are in. eVars are referred to as "conversion variables" because their values can be persisted throughout the visit to different conversion/success events. 

When you set up an evar, you also set up an allocation and an expiry for it. The value that is seen in an evar is going to be remembered (given credit) until it expires. This means if you have your previous page set to be an evar, and it expires at the end of a visit, when you bring in previous page, it's going to show you all of the values for that visit until it expires. Meaning it might not be directly related to the page you're interested in. 

 

For something like previous page, prop is the better one to use. Because a prop's value doesn't persist, it expires directly after the hit where it was seen, so you know it is only related to that one instance where it fired.

Avatar

Correct answer by
Community Advisor

agreeing with @MandyGeorge 

 

I would assume that the "previous page value" should only be used to break down the "Page" (s.pageName) dimension in your report.

Hence, the value can be discarded after that page view call you are sending it with.

 

So, basically you have two options

  • take a traffic variable / s.prop that automatically epires after the hit
  • keep using your conversion variable / eVar and set the expiration to "Hit", which then essentially mimicks the behavior of a traffic variable

 

One thing to consider is, should your pageName be crazy long e.g., when you are using parts of the URL and have a very deeply nested content hierarchy, you may run into length limitations when using a traffic variable (100 Bytes) whereas the conversion variable can take up tp 255 Bytes.

 

So my recommendation: keep your setup and just change the eVar epiration in your report suite 

 

Hope that helps,

Björn

Cheers from Switzerland!