Data Dictionary in Analysis Workspace

Hey, guys. This is Ashok Gorrepati, from the Adobe Analytics product management team. We are really excited to unveil a new tool in analysis workspace called Data Dictionary. The data dictionary solves a couple of problems for our users and admins. For users, especially those that are new to the fold of Adobe Analytics. It is not unusual for them to wonder which components to use, or what each of the components listed for a specific report suite or data view mean or do. As for admins, it can be challenging to keep track of all those components that are approved, components that are duplicates, or those that have not been collecting any data. Since this is context and metadata that is sprinkled across various component managers, and admin sections, and analytics. The data dictionary is intended to help admins easily audit their component landscape and allow them to improve the quality and health of the data, that is being made available to their users, so they have the necessary context and can use the data with confidence. That said, let’s get into the dictionary. You can access the dictionary from workspace through the icon listed in the rail. Or you can launch the dictionary entry for a specific component from within the Info icon. You will find that the Info icon for every one of the components you have access to, has been embellished with a frequently used with, and a similar to section. The frequently used with section, lists the top five components across metrics, segments, dimensions, and date ranges that were typically part of the same freeform table that included this component. Like for instance, you can see here that the campaign dimension is most frequently combined with these metrics, and users across your org are usually analyzing campaign performance during the current month. None under similar to indicates that there aren’t any components that are similar to by way of label to the campaign dimension. These two sections are intended to help users discover other relevant components that they themselves may not have been aware of, but could prove useful as they get started on their analysis. For example, I could have started out wanting to analyze campaign performance, without knowing that AMO Cost, Impressions, and Click Throughs were metrics that were available to me or were popular among my colleagues. Now let’s get into the dictionary itself.

The first thing I’d highlight is the report suite selector or the data view picker. Note that this would default to whatever report suite or data view you selected in the underlying project. In fact, if the project included multiple panels, the dictionary would default to the data view or report suite, the panel you were on was set to when you accessed the data dictionary. Next, the dictionary includes two tabs, the dictionary health and quick filters. The dictionary health is exclusive to the admin. And that is what they will default to when they open the dictionary. Non-ad admins will not have the health tab and will instant default to the quick filters tab, that allows them to quickly filter the list of components they see in the left rail of the data dictionary. The left rail also lets you apply the user filters you’d find in workspace like Approved, Favorites, and Tags. Next tab is the dictionary health tab. Like I said earlier, this is exclusive to admins and lends them at a glance how many components across this particular report suite or data view are missing descriptions, have duplicate names or definitions, haven’t collected any data in the last 90 days. And finally, those components that haven’t been approved. Let’s look at each of these in turn. Applying the missing descriptions filter will let you list all those components that are the missing a description. While not every component needs a description, you can use this list to decide which ones can use one, and add it right within the dictionary. We will get to that when looking at dictionary entries. The next admin filter under dictionary health is a duplicate filter. If you’re loading the health tab for the very first time, this might take a few seconds to load. And that is because it is sifting through all your components and identifying those with the same. And by that, I mean identical name or definition. For instance, if two segments have been recorded different labels, but have the same underlying definition as in components that make up the segments and how they’ve been combined, they will show up as duplicates. This report suite apparently has 22 duplicate components. Applying this filter will not only list them, but group the ones that are duplicates of each other. Also worth noting is that on the first pass, this will only account for segments, calc metrics and date ranges that you have created or have been shared with you. But if you wanted instead to look at all duplicates, you will need to apply the show all filter, just like you would in any of your component managers. Now that I’ve applied the show all filter, you’d see that this one report suite has uploads of 1700 duplicate components. What’s even better? Components I have never thought were duplicates like these two here. AB testing model closed, and custom link filter closed, show up in the list of duplicates, so I can decide whether to delete one of them or maybe approve one of them, so the redundant duplicate falls out of favor and doesn’t confuse users. We had to constantly exclude a few things from V1 of the dictionary, but we are definitely envisioning a future edition that will allow admins to not only identify duplicates but also understand where the components may have been used, so they can either delete them right from within the dictionary or replace the duplicates with the one true component without necessarily breaking anything. Let me go back to the home screen of the dictionary, and then remove these two filters. After duplicates, is a filter that would let me list components that for some reason, haven’t been collecting any data over the last 90 days. This could be owing to implementation issues or maybe these components are no longer required, and hence, should figure in my plans to clean up, but I will be able to get to that list by applying this filter.

And finally, you can filter the left rail in the dictionary for components that haven’t been approved. Now, approval isn’t mandatory. And it’s not like unapproved components are not relevant or necessary, it’s just an additional vote of confidence that would allow users, especially those new to our analytics team or to the report suite or data view to consider using these components for their analysis. Admins and non-ad admins alike, can look up the entry for any component in the dictionary. Each entry will include a description, whether the component has been approved and potentially helpful contextual detail, including the frequently used with and similar to sections. As well as the definition in the case of calc metrics, segments and date ranges. We also include the name of the person that created these components, as well as the date when it was last modified. While this is what an admin and a typical user will see in the dictionary, admins will have the option to edit every component. Once in the edit mode, which they can get to where the pencil icon at the top. Admins can either approve or unapprove a component including metrics and dimensions. They can also add or edit the description if they wanted to. And any edits they make to the description will in turn trickle down to all the other places in analytics or CJA where that component has been referenced like the data view manager or each of the component managers.

While the frequently used with and similar to sections are auto-generated to begin with, admins will have the option to update those sections as well. Like for instance, if they wanted to draw attention to a complimentary component they think users should be aware of when using a specific component like asset id, in this case, they can search for an add that to the always include list. The new component will take the place of one of the components that’s auto-generated and already on the list. Likewise, if they wanted to exclude a component, like for instance occurrences, 'cause it’s not that valuable, the admin can decide to always exclude such components from the frequently used with list.

They can make changes to the similar to section as well. Like for instance, if they wanted users to be aware of a similar component that could potentially be better suited for their analysis, they can go ahead and include that in this section. For instance, if the admins are aware that users frequently are confused between an asset ID and a component called, say, a display campaign id, they can add the display campaign ID component under similar to. This would then appear in the info icon for the component in workspace, and users will hopefully make a more informed choice after looking at the dictionary entries for both and deciding that what they had in mind was not what they selected, but instead, one of the components listed under the similar to section.

They can save the component and have those changes reflect in the info icon in workspace, as well as the entry for that component in the data dictionary.

Also, a couple of actions we are exploring for a future edition of the dictionary, are the ability to rename components, as well as delete or modify them all without having to leave the dictionary.

So that is the data dictionary. This is only possible given all the feedback we get from users. So please keep that coming as always. Thank you so much.