It’s hard for me to write a post like this. It’s no secret: For the last years I spent in web analytics, I’ve become a huge fan of Adobe Analytics if it fits your company. I got to know all the intricate inner workings and the beautiful interface they call Analysis Workspace. But the recent October release introduced a seemingly innocent change that broke some of the basic principles Analytics is based on.
Analytics 101: props vs. eVars
Let me start by explaining one of the oldest principles in Adobe Analytics. Besides custom events, props (or custom traffic variables) and eVars (custom conversion variables) are two of the building blocks of your analytics implementation. Both are used to capture dimensions and offer a different feature set.
For example, props allow for pathing reports. With some simple configuration, we are able to capture the first and last value of a user session as dedicated dimensions, allowing us to quickly report on them. Those entry- and exit dimensions are valid for the whole visit, so we can answer questions like “how many pages does somebody look at who starts his visit on a certain page, compared to other entry pages?” with no hassle.
On the other side, we have eVars, which allow for expiration settings. This means that we are able to set them up in a way that they “remember” their value for some time or certain events. Imagine a website with a user login: If we capture the user’s ID when the login occurs in an eVar with a visit expiration, our reports would look as if we set that value on all subsequent hits in the same visit. That way we save some trouble and cookie dropping if we want to remember values.
But there is one important difference: They behave differently when we don’t set a value with an event. With eVars, that value would be reported as “Unspecified”. But with props, they would simply not show up in our report. So if a Page View happens, with an eVar and prop set to “Homepage” and then again without them, the sum of the report items for the eVar would be 2 (1 for “Homepage” and 1 as “Unspecified”) but only 1 for the prop (only showing 1 for “Homepage”).
This key difference also affects sequencing and calculations based on sequences. That principle comes into play once we look at metrics like the time a user spent with a specific dimension value. Because not-setting a prop basically leaves the value empty, the time spent with an item is calculated as the difference between two hits where we have a value for that variable. But for eVars, the time spent would always be based on the next hit: If that hit has the same value, it counts towards the sum of time spent, but towards Unspecified if there is no value set.
Because of this principle, the time spent with a certain page name (which is a prop) includes custom link events that happen on that page. If we would use an eVar with a hit expiration and set it together with the page name, time spent for that dimension would not include those custom link events. Extending the previous example, if we capture the page name in an hit-eVar as well, time spent for the page name and eVar would include all custom link events on the homepage for the page name report but only the time from the Page View up to the first custom link event on that page.
Broken by changes
Coming back to the October release of Adobe Analytics, those basic principles got turned on it’s head and broken completely if you use Analysis Workspace. It all started with an innocent sounding feature on the release notes:
Analysis Workspace: Option to remove Unspecified/Nonehttps://docs.adobe.com/content/help/en/release-notes/experience-cloud/previous/2019/10102019.html#analytics
The ability to easily remove ‘Unspecified (None)’ has been added as an option to report filters.
That sounds amazing! Finally we can exclude those nasty Unspecified values for eVars! And this is what it does for them just fine. But there is more… Because it also affects props. But how is that possible?
With this change, Unspecified became a valid value for props, just like with eVars. So if we filter those values from the report, things are working as we expect them to: They do not show up in the report and time spent is calculated from one hit, with the prop set, to the next one with it set. But once they are included in reporting, time spent is cut short for page names if there are custom link events, since those are always without a page name set (like eVars in the example above).
Just try it out: Look at the time spent metrics with a prop and activate and deactivate the filter. Time spent changes together with the filter. It’s lower with Unspecified! Now try the same with an eVar: The Unspecified value disappears from the report, but time spent stays the same for the other values, like it should.
But there is more: If we fix a value (just open a dimension on the left rail and drag an item to a table), we no longer have the option to remove Unspecified. It’s auto-included! The same happens with time dimensions, which don’t allow us to filter and exclude Unspecified. This leads to some awkward situations: The time spent changes for the same prop value if we trend it rather than looking at the aggregated value. And we can’t do anything about it!
And since we can’t get enough: Once we try to breakdown an Unspecified value, we get an empty breakdown by default, because Unspecified is included on the top level dimension but filtered out in the breakdown. Also, default values for the filter are different for props and eVars, which is annoying. That’s just to add insult to injury.
“It’s not a bug, it’s a… feature?”
So once we found this issue, we reached out to Adobe. Going through the usual Client Care and CSM process, it got escalated through several stages and teams. It took a lot of effort and detailed discussion to point out how this change breaks compatibility with the Reports & Analytics interface or Report Builder (everything based on the 1.4 API) and doesn’t make any sense.
But Adobe’s answer is as short as it is infuriating: It’s just how the product is now and not considered a bug. If we want correct data, we should use the old interfaces! This is just unacceptable: For the recent years, Workspace became equivalent to Analytics. We got urged to migrate all users to it and we, the Adobe Sheeples, followed. Breaking Workspace in such a severe way is just unacceptable.
Adobe even had a helpful advise: If I want a working product, I should just head to the forums to beg for something usable. Wow…
It’s not a feature, it’s FUBAR!
So, we have a broken tool at our hands. If you are affected by this (i.e., you use Analysis Workspace for anything) please reach out to Client Care and/or your Customer Success Manager (CSM) and chime in on Jira Bug-Ticket AN-196733, stating how you are hindered by this.
Analysis Workspace today is far more than one interface among many. It’s basically what Adobe Analytics is. Just look at their product pages and look for any other interface. So we need to get this fixed ASAP.