prop vs eVar : Adobe Analytics | Permanently solved
prop vs eVar.
Hello, my dear reader! Hope this post finds you in super amazing spirits!
So, would you like to learn about my take on the mystery of props vs eVars? Well, you are at the right place *wink*. Also, this is not going to be a single blog post. To solve the mystery of prop vs eVar, yours truly, Sanmeet Singh Walia, will be writing not 1, not 2, not 5, but 10 blog posts elaborating the various cases with props and eVars.
Alright then, “What is the difference between props and eVars?” can perhaps be the most asked question during the interviews for the role of a Digital Analysts with Adobe Analytics tool stack.
To me personally, props are eVars are like Batman and SuperMan. Why, you ask? Well, Just like Batman and Superman they are supposed to be on the same team, but every once in a while, they are made to fight against each other. And, at the end of fights, we find that fight was not required and Bats and Sups are together.
People (Digital Analysts) know about them (superheroes), are aware of their existence and take their help. But also, very few know who Batman and Superman actually are. I think you got my point and this should be enough for an attempt for an “interesting” blog opening.
Now then getting to business, we are covering the following in the first post of this series:
Some History of props and eVars
Incomplete definitions 🙂
Back to basics – hits, persistence, variable size, pathing and breakdowns
Defining props and eVars through basics
Summing up
prop vs eVar – History
Alright, now lets take a trip down the memory lane. Adobe Analytics was formerly known as SiteCatalyst. SiteCatalyst was a product of Omniture. Omniture was found in 1996. Adobe bought Omniture in 2009 and gradually branded this product as Adobe Analytics from Omniture SiteCatalysts. Many analysts in their late 30s and early 40s still call it Omniture SiteCatalyst. The props and eVars have been part of SiteCatalyst since the very beginning. Even after nearly 2 decades, they are known by the same names, even though the names might not entirely be relevant today.
Props essentially stand for property variables. My assumption is props came before eVars, and since they are the dimensions telling about the various website properties, they were named props.
eVars, I could not find the exact full form, but I know that since “events”, which are custom metrics since SiteCatalyst days and which for quite some time could be broken down only by eVars, I am assuming eVars stand for event variables. Now, you can break down events with props as well, but the numbers are not always correct so please be careful.
For quite some time, it was also the case that you could break down the prop reports by other prop reports only and same was the case for eVars.
Edit : The lengendary Adobe Analytics Messiah, his holiness Adam Greco, read my blog and enlightened me that eVar actually stands for eCommerce variable. Thanks Adam!
prop vs eVar – Definitions
Now the definitions (I am hoping I can do some justice here)
A conventional definition of props mostly starts with “they are property variables, also called traffic variables, also called custom insights variable”. It’s my honest opinion that knowing what is property or traffic variable per say is irrelevant. People need to stop starting the definition of props as they are traffic variables or property variables! Many people would say they are counters. No, they are not counters.
Counter with its inherent nature can only be a metric. A prop is not a metric, it is a dimension, so its not a counter, but rather something that can help break down the counters.
So, what the heck is prop? Prop is Batman *kidding with wink*
I will not tell you that yet 😛 I will tell you few other things first:
prop vs eVar – Back to basics
- Hits
- Persistence
- Variable size
- Pathing
- Breakdown
Hits baby Hits!
You might be aware that information to Analytics server are sent via http requests from the digital asset. A visitor’s session is nothing but a collection of these hits within a certain time frame. Each of these hits contain some information about the user’s activity on the digital asset. If you want to see these hits, you can do that in the network tab of your browser by filtering for “/ss”. All the Adobe Analytics hits would contain “/ss” and then followed by all the information through the variables it is sending to Analytics server. Like in the image below, I have debugged the website for Adidas India. And we can see the hit, and the information that it has sent to the analytics server.
Now, if you look at the variables c1, c2, v1, v2 etc, then all the variables starting with “c” are your props. All the variables starting with “v” are your eVars. So, here c2 is picking up the value “DESKTOP” and feeding it to populate the report for prop2. I am assuming that in Adobe Analytics console, prop2 will be user device category. Similarly, v1, v2, c3 and v3 are generating page names report.
There are basically, 2 kinds of hits. Page loads and event hits.
Page load hits, as the name suggest will be sent to the Analytics server every time a user loads a page your site. Event hits are the hits that are used to send interaction level information to the Analytics server, such that these interactions don’t result in a fresh page load.
As I mentioned earlier, a session is a collection of hits. All these hits will have some common information that will help the Analytics server identify that these hits are from the same user within the same session. But, each hit can comprise of different set of variables and each variable can contain different information.
For example, each hit recorded with a page load, will contain the variables to record page level information. But the information on each page will obviously be different. Also, based on the type of page, you might include certain variables and exclude others. For example, if you have an eCommerce site, your product and checkout pages will contain product variables which will not be required for your marketing pages.
You can imagine a big table of your data at Adobe Analytics servers with nearly 1,500 columns. Each column representing a variable and each row representing entries from a SINGLE hit for the relevant variables. An oversimplified example can be like this:
The processing engine at the analytics server will work on this table incorporating the configuration logic for each variable and populate the reports for you in the console, like your pages report for example. The configuration logic also uses visitor id, time stamp, session id etc to generate metrics like visits, visitors, time stamps etc
Hits are clear?
Persistence
Persistence is actually a database concept. In not so simple language, “in the context of storing data in a computer system, persistence means that the data survives after the process with which it was created has ended. persistence refers to an object that is not deleted until a need emerges to delete it from memory.”
The computer system in our context is the Adobe Analytics server. The data is our Adobe Analytics data passed through hits to the Adobe Analytics servers.
Using the concept of persistence, we can find out how the data points collected across different hits affect each other. For example, we can find out how the data points for marketing channels collected in the first hit on the landing page relate with purchase data collected on the second last page.
In Adobe Analytics only eVars can be made to persist. We can persist the information for a session, we can persist it for certain days, we can persist the information till a particular event occurs for example a purchase or a lead, or we can even persist it for a cookie lifetime.
Now, extending the previous hit example by adding another hit which in turn will add another row.
In this hit, we are passing only the page name, no props, eVars or events.
As I mentioned above, props don’t persist, but eVars do. Hence, in the second row there are no values for prop, but the persisting value of eVar from previous hit has been mapped to the second hit for V1 and V2. And hence we need to be careful, as this will wrongly over report the data for homepage if you populate the eVar1 report.
I hope there are some dots in your head for persistence now.
Variable size
This one is pretty self explanatory, the amount of memory space a data point occupies in the server’s memory. The heavier the variable the more computing power is required to process it. The variable size for props and eVars are different. Props are of only 100 bytes, while eVars are of 255 bytes. Hence, your real time reports in Adobe Analytics are only prop reports as props are lighter to process. Also, if you request reports from Adobe Data Warehouse, your prop reports will be delivered much faster than your eVar reports.
The size of variable also governs the length of string it can hold. In general, eVars being heavier can hold much lengthier strings than props.
I think knowing this much is enough for variable sizes in case of Web Analytics.
Next, Pathing
The context of pathing was developed to discover the path the user takes to navigate across a site. It is used to discover the traffic flow patterns from any page. You can see the paths users take to arrive at a particular page and can also find out where are they going from a particular page.
Essentially, pathing enables you to analyze the sequential flow of information.
Now, Adobe Analytics has enabled pathing for all the prop variables. So, you can see the sequential flow of information for any variable, for example the search keyword report where you can see what users are search before and after a particular keyword.
Pathing is not available for eVars.
Pathing sorted?
Next, breakdown
Metrics as you know are units for measuring anything. Like pounds for weight, feet for height etc
Similarly, we have metrics in web analytics – sessions, visitors, page views, orders, revenue, amount spent etc
Dimensions are essentially used to refine the information being presented by metrics. For example sessions is a metric and day is a dimension. And breaking down sessions by day will give us daily sessions. Similarly your marketing channel is a dimension, breaking down sessions by marketing channel will tell you sessions by each marketing channel.
Adobe Analytics provides certain standard out of box metrics which are in general applicable for all websites like page views, visits, visitors, time spent, for eCommerce – product views, cart additions, checkouts, reviews, orders, revenue etc etc. Then there are certain custom metric slots which can be used for measuring events relevant for your website but are not available in out of box metric list, like lead submissions, or interaction with a CTA buttons. Adobe Analytics calls these custom metrics “custom events”
These custom events can only be broken down by eVars. These can not be broken down by props.
Bada Boom!
prop vs eVar – What is prop again?
Prop is still Batman!
Let’s sum up what I mentioned above:
Prop is a “custom dimension” which is used to store string values only. Even if you pass numbers, they will be stored as strings. These values passed in prop are non-persistent. So, if you break down metrics with prop, it will show only those values which were passed in the same hit, props will not be able to show cross hit data in a table (you can use segment though, at visit/visitor level). The size of prop is 100 bytes. For creating real time reports in Adobe Analytics only prop based reports are available. All props can generate path flow reports (if enabled).
If this is still not clear, do not worry. As I stated earlier, this is going to be a 10 blog series and you will definitely have more clarity at the end.
Lets define eVar as well:
Same stuff- it is a dimension and will store string values only (There is a concept of counter eVars, but even they are basically string values only.) The values passed in eVars can be made to persist. You can control the persistence of any eVar from your Admin console. Since eVars are persistent, they enable you to analyze data points that might have been sent across different hits. You can record custom metrics with events in Adobe Analytics and you can breakdown these events by eVars, for example you can breakdown lead submission event collected on the second last hit in a session with marketing information collected in an eVar in the first hit of a session. eVars are of 255 bytes, hence can store relatively longer strings than props. You can not generate real time reports with eVars.
That covers our Superman as well.
Again, if it is still not clear, do not worry. There are nine more blogs coming your way to feast upon!
prop vs eVar – props AND eVar instead – Summing up
I want you to understand, that it is not prop vs eVar. Many people are now saying that we should discard props all together, but you might agree after reading this post that props and eVars are both important. Like men and women, they are not equal, they are different, but must be treated with equal respect *so philosophical*
Adobe Analytics is a brilliant tool and the concept of props and eVars contributes tremendously in making the tool so brilliant. If you want to master this tool, you must master the concept of props and eVars.
In the coming blogs I will cover more on props and eVars (prop vs eVar). We will go through subtle nuances, checkout various case studies and just hack the entire concept of props and eVars.
Till then. Stay awesome!
Here are the links to more popular blogs on Evars and Props:
- Props vs eVars | Why is there unspecified in eVar reports? Adobe Analytics
- Props and eVars | What are pathing reports in Adobe Analytics?
- Props and eVars | Passing page URLs in both prop and eVar
- Props and eVars | Why you should pass page names in both props and eVars?
- Props and eVars | How to use metrics correctly
- Prop and eVar | What is merchandising eVar
