Remove unspecified permanently

[jane_12]

How do we remove unspecified completely from the reports?

Apart from unchecking 'include unspecified' in the report?

[yuhuisg · Accepted solution]

You "remove" it completely by ensuring that each and every hit has a value for that dimension, whether set in the beacon or persisted from previous beacons.

On the other hand, if you mean that you simply don't want to see it in your report, i.e. hide it, then in your Freeform table, click the filter icon for your dimension, and uncheck the "Show unspecified" checkbox.

[jane_12]

We have made sure that each and every hit has a value for that dimension, whether set in the beacon or persisted from previous beacons. But still we see unspecified and when we break it with custom link it shows the value ADBINTERNAL:Lifecycle

[Jennifer_Dungan]

What is your eVar tracking? Is it something that makes sense in the context of your Mobile App Lifecycle Metrics? You could in theory add a processing rule to add a value to your eVar on your lifecycle calls. But ONLY if this makes sense... Lifecycle is a special action that tracks information such as Launches, Upgrades, Crashes, Days Since Last Visits, Days Since Last Upgrade, etc.

ADBINTERNAL:Lifecycle should always correspond with "Launches" metrics (other metrics will also pair with this event, but launches should be completely 1 to 1 (you can confirm this by looking at ADBINTERNAL:Lifecycle with a column for Occurrences and Launches (they should match)

So IF adding an eVar value to your lifecycle is what you want... you can create a Processing rule with the condition:

a.launchevent is set

OR, you just do what @yuhuisg suggested, and uncheck the "Show unspecified" checkbox.

[jane_12]

So the evar just has the screen names and userId...

We have used processing rules completely but still face the issue.

uncheck the "Show unspecified" checkbox - Yes we are aware of this and use often but the requirement is to completely avoid it from implementation itself.

[Jennifer_Dungan]

Ok, you probably won't have either of those on the LifeCycle... that is the very first call upon opening the app, and most of that info is still processing...

Also, new app users wouldn't have that data at all... surely even IF your app requires login, you would have page views on a login screen without the screen name/user id....  it's impossible to have every single instance be populated.... (unless you are populating placeholder values like "not logged in")

[jane_12]

So we have only two success events and when we use those 2 metrics we don't see unspecified. Unspecified values only appears when visits and unique visitors metrics are used.

[yuhuisg]

Yes, that sounds correct. That would be because your eVar isn't being set with some hits (both set in the hit nor persisted), so AA reports "Unspecified" in those cases.

If you expect your eVar to have a value with every hit, then you should check your implementation for correctness.

[jane_12]

At report suite level all eVars are set to expire after visit.

Code level, developer has said it's set at every hit but still we find unspecified but still will verify again.

[Jennifer_Dungan]

Again, as mentioned before... unless your developers specifically added context variables to the Lifecycle metrics (which is unlikely, as this is an extra implementation that won't be done generally unless specifically requested - in fact, I've been trying to get general context variables added to our lifecycle metrics for years and am still waiting - the first attempt broke our lifecycle metrics entirely, but it should be possible according to documentation)... this is where your unspecifieds are coming from.

So you can either have your developers try to get this added, or create a generic lifecycle processing rule and set some value on your lifecycle calls.....

[yuhuisg]

Consider the following visit:

Visit A:

Hit 1 (page view): eVar - not set

Hit 2 (custom link): eVar - not set

Hit 3 (page view): eVar - set with "foobar"

Hit 4 (custom link): eVar - not set but persists

Hit 5 (page view): eVar - not set but persists

no more hits

With this journey, AA will report the following:

eVar	Visits
Unspecified	1
foobar	1
Total	1

where the "Unspecified" value comes from Hits 1 and 2, when no value had been set and there was no previous value to persist from.

In your case, it could be that the first hits of a visit correspond with the Lifecycle metrics measurements, which normally fire before the app has completely started up. So those hits would not have your eVar yet. Your developers will then have to be able to set your context variables for that eVar before the Lifecycle metrics have been measured, as what @Jennifer_Dungan suggested. Using Processing Rules might also be the way to go.