Handling “unspecified” hits in Adobe Analytics

[NorData]

Hi Community,

We have decent amount of “unspecified” hits in our report suites and would like to find out the real reason behind these unspecified hits. Im trying to answer below questions about the current unspecified hits we have in our reports:

1: Is it really because of the missing evars/ values ?

2: are there any issues in implementation which we need to fix?

Some of these unspecified hits may be reporting from missing values because i noticed we are sending “” strings for a-lot of different eVars within different events. However, im not 100% sure if thats the only cause.

so, to get started, I'm thinking of tracking all empty digital data objects as  “not defined” instead of “”, but i’m wondering if there will be any issues with capturing it as “not defined” . Will it over inflate our reports with “not defined” value if i start tracking all evars as “not defined” if there is no value? What are the best practices?

Appreciate any suggestions

reduce the number of unspecified hits we get. 

[manojs57813206]

Potential Cause	How to Check	Fix
Missing eVar values (i.e., no value captured at hit-level)	Use Hit Depth breakdown to see when eVars are assigned.	Ensure eVars are set before the tracking call (s.t() or s.tl()).
Empty strings ("") being sent instead of a value	Look at Network request (b/ss call) and check if eVarX= (empty).	Use NULL or avoid sending eVar instead of "".
eVars being set on one hit but expected in another (Persistence issue)	Use Visit-Level Breakdown to see where eVars drop off.	Ensure correct persistence settings in Admin Console.
Incorrect Processing Rules overwriting values	Check Processing Rules in Admin Console.	Remove any rule setting an empty value.
Data Layer issues (values not available when the call fires)	Open Console in DevTools: console.log(digitalData);	Ensure data is populated before the tracking call.

[Jennifer_Dungan · Accepted solution]

First off, there is nothing inherently wrong with "unspecified" in an eVar... this is normal behaviour.

Unlike Props that are only hit attribution, and therefore empty values are automatically ignored, eVars being conversion variables that support persistence (you can set to hit too), appear in your reports differently.. every hit that doesn't not have a value (set or persisted) will show up as "unspecified".

In some uses, this is very handy. For instance, I want to correlate an internal campaign tracking to my orders... Orders that did not interact with an internal campaign will be unspecified, showing me the exact percentage of my orders that were not impacted by an internal campaign.

However, sometimes those values are unhelpful... this is why Adobe has a setting specifically built into Workspace tables to include or not include unspecified.

Simply go into the dimension filter and uncheck "include unspecified" if this is getting in the way.

Now, there is still a chance that your tracking is incorrect and missing values, that is something only you can determine... but seeing "unspecified" is not an indication of a problem on its own.

[NorData]

Thank you for your response! Do you have any suggestions on best way to handle empty string values being sent via data layer? for example - On a page view event, some times sub section1 and subsection2 may not have values and dev team is currently sending them as “” (empty string). In this case, can we ask them to pass “undefined” or omit the entire key value pair ? Will there be any issues in terms of eVar attribution by doing so?

[Jennifer_Dungan]

To be perfectly honest, if there is no value, I send the empty string...  

In AppMeasurement, not sending a dimension, or setting a dimension to "" results in the same behavior (no value / undefined). WebSDK should work the same way, you cannot override a persisted value with an empty string.

This also means that I can use the exists or does not exist logic in my segments, and I can use the default filters to not include those unspecified values.

And IF you are trying to use persisted values, you won't accidentally overwrite that value with a placeholder "non-value" breaking that all important persistence / expiry logic.

It sounds like what you have is already the best way to handle your variables.