props vs eVars | Why is there unspecified in eVar reports? Adobe Analytics
Unspecified in Adobe Analytics.
Hello there, my amazing reader. Hope you are doing sensational 🙂
This is my second blog in the 10-blog series on props vs eVars. You can read my handwritten lovely first post here
In the first post I have explained the fundamentals of props and eVars. In this one I will start with few advanced concepts. The first one is bloody “unspecified” in eVar reports.
The “unspecified” bacteria is not just in eVar reports, it is also found in the guts of classification reports, mobile reports and breakdown reports.
But do not fear my dear, yours truly, Sanmeet Singh Walia, has decided that he will kick the ass of these doubts in one shiny pedicured kick.
Beware “unspecified”! Here I come. *Pew Pew Pow*
You can spot the “unspecified” bacteria at following locations:
- In an eVar report
- In classification reports
- In breakdown reports (breaking one dimension with other)
- Non-browser hits in technology reports
First one, why unspecified shows up in an eVar report?
As soon as you enable an eVar report, it wants a value. It is one hungry variable and if you don’t feed it, then it will make sure that you feel guilty about it. It doesn’t end there, it is one hungry variable that also keeps grudges for the time it was not fed. So, even if you feed it later, it will make sure to make you feel guilty for the time you did not feed it. *Bloody drama queen*
The eVar wants a value in every hit and for the hits in which it does not get a value, it will record that event as “unspecified”.
But, eVar has some good habits as well. Once fed, it holds the value for the time you tell it to (i.e., setting the expiry time in admin console).
The eVar tantrums start from the very first hit sent to Adobe Analytics. If you have enabled 50 eVar reports and you are not feeding 30 of them in the first hit, those 30 will record unspecified as a value. The 20 which are fed will persist their data points and if they do not expire in the session ahead, they will not get the opportunity to crib about the missing values with “unspecified”.
Now, I said that eVar will make you feel guilty even after getting fed. Lets take eVar31 as an example, it did not receive any value in the first hit and it sulked. You passed a value in the 4th hit, it took the value but deep down still felt that you are fond of the other eVars more. So, next time when you need eVar31 with a visit metric, it will give you the value you fed in 4th hit, but it will also remind you of the first 3 hits where you did not care for it. So, you will see 2 entries – row 1 with “unspecified” and row 2 with value passed in hit #4.
The volume of “unspecified” is dependent on the metric that we are using in our eVar report. If the metric is incremented before any value was passed to the eVar, “unspecified” will get the credit. If the metric was incremented after the value was passed to the eVar, the value will get the credit. Since visit/visitor are metrics that co-exist with any value in the session, when you break down eVars with these metrics the share of unspecified is fairly high.
Is that clear sugar?
Liking this blog? Hit the Facebook logo to join our FB group for web analytics power rangers:
“Unspecified” in classification reports
Classification is one of the most “underrated” feature of Adobe Analytics. Classification lets us classify the values in any dimension into various groups based on business logic. Further, classification can also be done long after the data has been collected by Adobe Analytics. That is like real world, you can manipulate the perception about history after winning the war!
Example: there was some bug in your payment system which passed unusual discounts to a series of order IDs and this series is affecting your data reported for average order value and conversion rates(more people bought because of discounts). To filter out this series for better analysis, you can upload this series and classify them as “buggy orders”. Using this you can create a segment and exclude these orders for your analysis.
You can also use classification with regular expressions. For example, you can pass all your UTM parameters as delimiter concatenated values in your s.campaign variable. Later on you can classify each delimited value using regex into separate bucket like source, medium, source/medium, campaign, keyword, etc.
Now, to enable classification, you first need to create the buckets in the report suite settings. Once that is done, you need to set the logic for classifying the values either through classification rule builder or through classification importer.
When you will open your classification reports, those values which could not be classified into any bucket based on the logic you supplied will be declared bloody “unspecified” blah. But the good part is that you can break down this “unspecified” with the original non-classified report and quickly find out which values are not getting classified into any bucket.
Example, you classified your campaign reports through classification rule builder using regex classification into source, medium, campaign and keyword. You open the keyword classification and see plenty of howling “unspecified” values, you can break down the “unspecified” with campaign and see all the campaign values for which keyword is unspecified and figure out why.
Rock and Roll!
In the breakdown reports
Breakdown or correlation or sub relation reports?
When you break down a prop report with another prop report, it is called a correlation. When you break down an eVar report with another eVar report, it is called sub relation.
When you break down, essentially you want to see when a report had a particular value for a metric, what value the other report had for the same metric. For example, your prop55 can contain the product category and your prop32 can contain brand. You want to break down “Nike” in prop 32 with prop 55 to see which product category is most viewed for “Nike” – shoes, trunk tops, headbands or what?
Now, it can happen that when one prop had a particular value, the prop which you are using for break down did not have any value and this instance of missing value will come as? as? as? yes you got it, bloody “unspecified”
Non browser hits in technology reports
Out of the above cases that I have shared, mostly you will tussle with the “unspecified” in the eVar reports and you should now be able to explain the cause of its occurrence with confidence.
Alright my pumpkins, this should help you understand why you see “unspecified” in Adobe Analytics. But, But, But, if you are making the same mistake with “unspecified” that people make with Appendix (calling it useless), then you should think again.
Appendix is not a useless organ, it is a very rich repository of friendly bacteria which plays a critical role when hostile bacteria attempt to hack your system. We now know why it exists and should think on utilizing and supporting it effectively.
Same case for “unspecified”. It helps you a great deal in analyzing cases where you were expecting some data point, but don’t see it in Adobe Analytics. Further, in Adobe Workspace, you now get the option to exclude unspecified entries in the table. So, while sharing the reports with various stakeholders you can use your discretion and hide the unspecified entries.
With this I’m concluding my second blog in our series. The next blog will be about the metrics that should be used with props and eVars.