Hello my ravishing reader! Hope this post finds you in a super delightful state. This is the third post in our props and eVars series and this post will push forward our quest to ‘once and for all’ eliminate all doubts with props and eVars.
The links for the first 2 pies are below:
In this post, yours truly, Sanmeet Singh Walia, will teach which metrics should be broken down by props and which by eVars. So let’s get cracking!
Metrics for props and eVars
In the last two blogs I have covered the concept of persistence, which will play a critical role in the choice of our metrics.
It is now a standard lazy practice where analysts are passing the same values to props and eVars.
For every data point, there now exist 2 reports – one for prop and one for eVar.
In principle it is not bad. But who cares about the intentions, in principle Khalisi only wanted order in the world, we all know how screwed that plan was.*I digress*
The problem arises when multiple stakeholders start using those reports and not all of them have an effing clue on what a bloody eVar, prop or persistence is. And then they question why two reports of same name are showing different data. Then they start reporting one and not the other. And then those numbers reach the c-suite, and then the c-suite gets very exited and wants deeper analysis, and then the analysis request comes to you – the alpha digital analyst with mojo, and then you realize “holy cow! this was to be reported with a prop report, not an eVar report”! And you tell that the numbers are wrong and then you tell the c-suite and then they tell you they told the PR person and the data is right now in print, and then you tell the c-suite, “It was an eVar report, it was supposed to be a prop report” and then the c-suite looks at you like this:
Hence, this lazy practice of setting everything in prop and eVar is not right.
One fine day props and eVars were planning to adopt a dog while this happened:
The content team wants to know the numbers for blog pages only. They want to have a dedicated report that shows only the blog data. They don’t want to work with segments or filters or anything fancy.
To achieve this, you set a rule in Adobe Launch – when url contains ‘/blog/’ set eVar50 and prop50 as the title of the blog. You are so intelligent.
You tell the content team, “I have set “Blog titles” report for you. You can use the page view metric.” You are amazing.
The content person, opens the blog title report with the page view metric, she uses the prop report and checks the performance of the recent blog. She sees 500 page views.
Next day, she again opens the blog titles report, looks for her recent blog and finds 2500 page views and she is happy, no she is very happy, it seems her blog is getting viral. She starts celebrating, she tells her boss, who appreciates her mildly so that she does not think she is ready to replace him. She tells her team who are like yeah everyone gets one viral blog in a lifetime. But then, her boss tells her to confirm the numbers with you.
She comes to you, doe eyed, excited, and she tells you that she already knows you set the right report and the numbers are correct but her insecure boss is asking her to check with you.
You are intelligent. You check the report and tell her, there are only 650 page views and you hear a glass break.
She tells you she can see 2500+ page views in her system and you discover she is using an eVar report. How stupid?
You tell her she is using the wrong blog titles and she gets confused and there is a long explanation at the end of which whatever she may say, she actually wants to ask – “Motherfookar! why are there two reports of same title reporting different numbers?!”
Can you guess what happened?
Your eVar report for blog titles will persist its last value for all non-blog pages as well which were being viewed after the last blog page and hence all those page views will be attributed to that last blog.
Can we blame the blog team for this? No. Their core competency is not analysis.
Realize this, same data point when put in both prop and eVar can produce drastically different numbers. You need to imagine in your head, how persistence is happening and how the numbers are getting processed at the servers. Only then you will be a true data consultant.
Moreover, its not just the non-analysts that can make mistakes like these. Once in a while even analysts can make the mistakes. Hence there needs to be a proper system. Small red flags that reduce the chances avoid human errors.
If there is no success event that you want to attribute to a report, no need to use an eVar in most of the cases. Especially now since Adobe Analytics also allows you to break a prop report by eVar and vice versa.
In case any advanced cross hit analysis is required, you can use segmentation. With Workspace, you can use even segments as dimensions.
As an analytics consultant, you need to imagine the use cases for each report and take a proper call, whether eVar is required or prop. Don’t follow the dumb logic of using both the variables for every report just because it is available.
If you are using both prop and eVars, make sure that the stakeholders who will use them for just reporting and not heavy analysis are given access to relevant dimensions only.
Don’t use same names for props and eVars, even if they hold the same data point, append something like “conversion” or “persisting” at the end of eVar reports. So that at least the stakeholders question back which one to use – with “conversion” or without “conversion”?
The concept of props and eVars are one of the strongest attributes of Adobe Analytics, but when used unwisely it can make Adobe Analytics very confusing for stakeholders. As the owner of Adobe Analytics in the organization, its the responsibility of the Analyst to make sure that the tool is not used wrongly. Just like we make incremental improvements in the digital assets using the data, we should make incremental improvements in our Analytics process and systems as well.
Hope this blog helped you to further enhance your understanding for props and eVars.
In this blog I discussed how to use the metrics judiciously when you are using both props and eVars to record the same data points. In the next post I will discuss why you should record page names though, in both props and eVars.