Props and eVars | Why you should pass page names in both props and eVars?
Hello sunshine. Thank you for blessing my post with your grace! You seem to be in a mood for some prop and eVar today, eh? You naughty digital analyst!
The link to the previous three posts are here:
#1 – prop vs eVar : Adobe Analytics | Permanently solved
#2 – props vs eVars | Why is there unspecified in eVar reports? Adobe Analytics
#3 – props and eVars | How to use metrics correctly | Blog #3
In this blog, yours truly, Sanmeet Singh Walia, will tell you why page names should be recorded in both props and eVars.
Rock and Roll!
Once upon a time prop and eVar were planning on going for a mud bath session when this happened
The e-com team wants to test a new chat bot, named Jojo. Jojo is a goldfish and will be shown on all product pages. Users need to click on Jojo to interact with her. Jojo plops on all pages wags her tail asking for attention.
The e-com team wants to know how many times people click on Jojo, how many times Jojo navigates users to the another page and what is the conversion rate of people interacting with Jojo and those who don’t interact with her at all.
They come to you, the alpha digital analyst with mojo. You have been bestowed upon the task to keep an eye on naughty Jojo.
You configure the direct call rule in Adobe Launch and you are all set to rock.
A week later, the e-com team checks on how Jojo is doing.
Liking this blog? Hit the Facebook logo to join our FB group for web analytics power rangers:
You create a shiny workspace report – showing total interactions with Jojo, number of times Jojo successfully helped in solving the visitors’ queries and you create a segment comparing the conversion rate of users who interacted with Jojo vs those who don’t.
You sent the report to the e-com team. They send back a heart emoji and ask for a breakdown by page!
You are a bit confused. You open the pages report and break it down by the events you used in the report you sent earlier.
But, the out of box pages report is actually a prop report and if you have been following my previous 3 blogs, you know that props don’t persist.
The name of the page is recorded at a page load level, while interactions with Jojo are recorded as an event in a separate hit. So page name is recorded in a separate hit and interactions with Jojo are a separate hit. How will you break down the data between 2 hits?
If only there was a variable that could persist across multiple hits 🙂
Papa eVar to the rescue.
Now, if you pass page name in an eVar, it will persist on all the event hits that are made on a page after the page load call.
So, if you record the page name in eVar, it’s not just Jojo whose tail you can pick, but there can be any interaction that you want to look at a page level, you can break it down by the page name report in the eVar.
You create a new rule in Launch to pass the page name in eVar as well. Meanwhile, you create a segment for visits where Jojo was interacted with and apply it to the pages report.
You inform the e-com team that this pages report with segment will present directionally correct data, but you have enabled data collection for them to analyze the performance by week. This report will be available in 2 days and there will be no historic data.
They are pleased with your proactive approach and send you 2 heart emojis on IM.
Another mission accomplished in the action packed life of a digital analyst with mojo.
Now,
There is another very useful dimension that you can set in eVar along with the page name.
Can you guess?
Please guess. I insist.
Please. Come on.
Yes, you are right. Since you already know, I will end the blog here then. *kidding*
If you record previous page name in an eVar, it will persist across all the events on the page load and you will be able to understand user actions on a page, based on the previous page that sent them to current page.
Example:
Once upon a time prop and eVar were planning on trying keto diet when this happened
You work for an enterprise software company. Your company sells multiple products. But, their website is not an e-commerce site. Its a lead generation site.
The site presents various benefits of taking the software packages and if any visitor is convinced, they submit a lead, post which the sales team starts its role.
Now, on every product page there is a CTA that leads to a common Contact Us page. There is no dedicated lead submission page for each product.
There is an option to select the product for which the visitors want to submit a lead, but its optional.
The product managers for one of the solutions want to test a new variant of their product details page. They have created an A/B test where 50% of the users are being served with the old variant and 50% with new variant. Sadly, they have not used any kind of optimization tool like Adobe Target, Monetate or Optimize, because getting a new tool approved from IT will take a lot of time and they want to speed things up.
They now want to check the performance of the new variant and they come to you – the alpha digital analyst with mojo!
You tell them to append a string “-new” to the URL every time the visitor is served with the new variant. Using this you create a rule in Adobe Launch to append “new” to the page name as well, when the new variant is served.
You have already been using the getPreviousValue plugin to store the name of previous page in an eVar.
From here it’s a cakewalk.
You create a report to get the data of total page views for the 2 variants in the regular pages report. You create a lead submission report for 2 variants in the previous page report. You do a simple lookup and combine them.
You can easily take out the raw numbers and conversion rates and declare the winner.
That’s all for this one! In the next post, I’ll cover Page URLs in the context of props and eVars. Till then, stay awesome!
PS : If you are wondering I did not mention anything about passing the name in Prop. Well, your pages report are actually a form of prop report only! Holy shit!
