props and eVars | Passing page URLs in both prop and eVar
Welcome to my shiny blog. A blog dedicated to all the Digital Analytics ninjas and their beautiful mothers.
When I woke up on the morning of this blog, my mother told me go write a post on prop and eVar blog and make her proud. So here I am, writing the fifth blog of our 10-blog series of props and eVars on why we should pass page URLs in both props and eVars, making sure that never again a digital analyst questions what’s the difference between a prop and an eVar.
If you have followed the series so far, take a bow. If you are a “new visitor” (lol, DA jokes), then you can check out the other 4 here:
Once upon a time prop and eVar were watching Netflix and were about to chill when this happened
You have joined your new job with 40% hike as a Digital Analyst in a food delivery company.
You have set the expectations of the marketing and product teams very high after that ravishing interview you gave. On your first day your seat was already allotted, there was a balloon on your desk and a chocolate pastry near your laptop with a note, “Funnel is not reporting the data properly, finish the pastry and come to the product bay”.
You finish the pastry and get ready for your next mission. You, the alpha digital analyst with mojo.
You meet the product manager. Her name is Shanaya. Shanaya is beautiful and hence you must make sure the issue is resolved as soon as possible. (I am judging you.)
You are told that in the last two weeks, the reported conversion rate has plummeted. But the back-end does not show any issues. Moreover, if we look at the funnel which is based on page names, there is no issue at all.
Post exchanging some other pleasantries, you fly back to your seat and inspect the tag manager. You first want to know how the numbers are getting populated.
You locate the rule and figure out that the order is recorded every time the server returns an order ID. This rule is not based on loading of order confirmation page, but it fires any time Launch detects the presence of order ID. And that’s your clue 1.
Next, You check if they already have an eVar dedicated for page names and wow, they have.
Your heart beat raises as you open the eVar pages report and break it down with the order metric. You find that there is only one page that is presenting the orders.
But, it is not the case that orders are totally missing, it seems it is processing in some cases while ignoring in others.
You tell Shanaya, it seems that in last 2 weeks there are cases where order id is not getting passed on all the pages, and hence the order metric is not getting reported by Adobe Analytics.
You both rush to the development bay and tell about the issue.
You request for help but the dev starts crying, he has not slept for 48 hours and there is this urgent release coming up and he discovered he is lactose intolerant, but he loves butter.
You give him your handkerchief and come back to the product bay. You assure Shanaya that you’ll get this resolved. You are the alpha digital analyst with mojo.
You go to your site and order a raspberry flavored protein shake to debug the entire journey, and see if the order is going through or not. And for you, the order is recorded. Blah!
You are just staring at the thank you page and thinking of Shanaya and your protein shake. And, your sight catches the URL of the page. You see order ID as a part of the URL. You feel your mojo rising again.
Liking this blog? Hit the Facebook logo to join our FB group for web analytics power rangers:
You quickly open Adobe Launch, and set 1 eVar report and 1 prop report. You record the page URL in both prop as well as eVar. eVar to persist the value for all interactions and success events, and prop to enable pathing.
Your objective is to extract out order Ids from the URLs and check more information about those from CRM.
You just hope it works.
“Remember, Red, hope is a good thing, maybe the best of things, and no good thing ever dies” – Shawshank Redemption
You are very excited, you open the URL report with eVar and break it down by orders and it’s there in front of you! A list of over 1,000 URLs. Each order confirmation has its own URL with a different order ID in the URL. You drop a visit metric next to the orders in the same report and there it is, you now have a list of all the order confirmation URLs where visits are recorded but order did not fire.
You the alpha digital analyst with mojo export the entire data in a spreadsheet, use your superpowers to extract the order ID strings from the URL.
Next, you extract the report from back end for all the order IDs and using vlookup you keep those for which Adobe did not report the order metric.
Now, it’s time to find what is common between these order Ids with missing orders. Search….Search….Search…Search….SHANAYA….Search…Search…Found!
It’s Google Pay. All the orders that are having Google Pay as the payment medium are not passing any order Id. You cross check with the ones that are getting through and none of them are Google Pay.
You run towards the washroom first to groom yourself and then towards Shanaya.
You then update Shanaya about the finding and you both hug…awwww
You both run towards the dev with a margarine sandwich and assure him it tastes like butter. Dev starts crying, he is happy.
The dev makes the updates and order tracking is back in place.
Shanaya asks you for a date and you get married the next morning. While heading for your first night you both were stung by a radioactive spider. (Mah Blog Mah rules)
The case that I have provided above is very simple. But, there can be numerous benefits of recording URLs in custom dimensions. Adobe Analytics does not provide an out of box URL report by default, which I feel that should be provided, as it should be fairly simple to do, perhaps they feel this would reduce the reliance on pages report.
Two ways to pass URL in props and eVars
Implementing a report to record the URLs in custom reports is not a difficult task. But there can be further 2 versions of this report.
The first one can be the entire raw URL as it is inclusive of the query parameters. The second report will not contain the query parameters.
As you would have also understood, if we include the query parameters as part of the URL, then same URL with different parameters will be treated differently. This will prevent aggregated analysis of the URL and also affect pathing analysis. It can also confuse the stake holders and if there are pages where a query parameter always exists then analysis of such pages through URL will become difficult. For example, your search results page. Most of the search results page will contain the query parameter holding the value of the search query.
But, including the query parameter in URL has its benefits as well. This can greatly help in debugging the implementation of marketing parameters based on landing page URLs. Also like in the case study above there can be query parameters for orders IDs, payment status etc that can be picked from URL if these values are not getting tracked in a custom dimensions.
I hope this is clear.
Now, you might be wondering why should we pass the URL in prop report? The answer is pathing and I will elaborate more on the concept of pathing in the next blog.
Till then, stay healthy, stay happy and know your role.