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. 

[manojsingh-tech]

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.

[jaishal]

@Jennifer_Dungan @NorData  @manojsingh-tech What about the issue of "unspecified" showing up on device name SDK as it is directly available from Mobile SDK itself. What explains this? It should technically show up on all scenarios right? Are there any scenarios which does not capture device name for the app?

[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.

[AnM_S]

Hi @Jennifer_Dungan ,

Is this applicable for ECID as well?

We use D=mid parameter and pass it in the page view rule.

We don't have a lot of page view with unspecified value but we do have a lot of visits with unspecified value.

[Jennifer_Dungan]

We also use D=mid to pass the ECID to a dimension... 

However, this can fail if you have cookie consent management blocking the ECID on the initial Page View, or something impacted the ECID from being set in a timely fashion (and therefore it wasn't sent on the call). Or maybe, you missed adding D=mid to all your actions... Or maybe the user's browser settings are rejecting cookies.. 

If you have a mobile app, then the Lifecycle metrics probably aren't being set with the value either... 

Since you only mentioned passing the value on your Page Views and not your actions, then every single action performed on your site won't have a value unless you have attribution set on your eVar, but if the first hit of your site is an action (and not a page view) then all visits in that scenario will count as a visit with "no ECID"

Remember, not having a value in a dimension at a visit level is not the same as excluding visits that have a value.

Example:

• Hit 1 - no value
• Hit 2 - "123"

Example 2:

• Hit 1 - "456"
• Hit 2 - "456"

Example 3:

• Hit 1 - no value
• Hit 2 - no value

Segment 1:

VISIT [

    ECID exists

]

(This will return Visits 1 and 2)

Segment 2:

VISIT [

    ECID does not exist

]

(This will return Visits 1 and 3 - because there is one hit on Visit 1 that doesn't have a value)

Segment 3:

VISIT EXCLUDE [

    ECID exists

]

(This will return only Visit 3 - because this is excluding Visits that have a value on any hit, it will only return the visits that never see any value)

I noticed in your screenshot that you may have low PVs, but you have high occurrences on HIT DEPTH 1 with no ECID... I would say you have a lot of actions triggering before your first page view with no ECID value.

I also noticed that almost half your occurrences don't even have a HIT DEPTH, I am not sure what scenario might be causing that... do you have any sort of data upload / ingestion that may not be setting that type of information?

[AnM_S]

Thank you for your response,

We do pass ECID with our actions (addtocart, checkout) as well which I forgot to mention. However, we don't have any actions triggering before the page view rule.

We also have a condition which will only trigger analytics calls when performance cookies are active. 

For the hit depth question, the screenshots shows the hit depth occurrences are 8852 of 8852, but the breakdown depth is set to 5 which is hiding them.

I can share the website URL in dm if possible.

Thanks in advance

[Jennifer_Dungan]

Do you have any other actions? It's also possible that someone triggered a checkout before the "page view" fired.. this can happen if the site is loading slowly, or the Analytics is deferred or broken by other things happening on the site.

I am not talking about only seeing the first 5 rows... that first column showing occurrences, the total "unspecified" shows a total of 15,645... only 8,852 of those have a hit depth...  that means almost 7K occurrences have no hit depth at all.... 

All occurrences should have a hit depth:

You can see that the "total", matches the All Visits Total, Matches the Hit Depth Total.

Or, if I replicate your setup, looking at Unspecified ECID, the total unspecified matches the total Hit Depth:

In my case, I can see that most of my unspecified are coming from my Mobile App Lifecycle (which is expected, since we can't modify the Lifecycle metric to include dimensions), and I know that there is a small possibility in our apps for the ECID to fail which accounts for the remainder:

However, you have so many hits with no hit depth is something I really think you need to investigate... as that is not normal behaviour.

But yes, please send a URL in a DM, and I will try to take a look into what might be happening.