NEW RELIC / DASHBOARDS ECOSYSTEM

Customizing Visualization Units and Formats for Data Clarity

Customizing visual elements like units, formatting, colors, and thresholds in data visualization is crucial for businesses. It ensures that data is presented in a way that's easy to understand and relevant to their goals. By tailoring visualizations, companies can make informed decisions and gain more in-depth insights aligned with their industry standards. That's why we're offering customization options in New Relic based on valuable user feedback. First, and due to high-volume accounts needs, we will be tackling units and formatting.

In this project, we will go through: Understanding current implementation, analyzing user feedback, and devise how we can make the goal scenarios happen.

Problem

As a user of New Relic, when I make a query and see the resulting numbers, sometimes the formatting is not right. 

Goal

Enhance the formatting of query results in New Relic to ensure that users consistently receive clear and properly formatted numerical data.

Current implementation

Initially, we examine the process occurring from when the user executes a query to when they finally see the resulting data.

As we see in the schema, when the user enters a query, New Relic guesses the unit by looking at the set of data, and decides what type of data it is. It adds, if there's any, custom formatting from Insights (old tool) and the user settings, and returns it to the frontend.

But our guessing system doesn't always work.

Sometimes we can't guess the units’ formatting properly because it's very difficult to predict the defaults the users would like to have. Sometimes the unit itself is incorrect, and nowadays, the users can't adjust or modify the unit or the formatting.

So, the reality nowadays is that:

  • Users can’t select how many decimals they see. Currently, we display only 3.

  • Users can’t "correct" if data is misinterpreted by New Relic.

  • Users can’t choose between human-readability or accuracy.

  • Users can’t configure the decimal marker — nor the numeric scale.

  • Sometimes untouchable values (like identifiers) get formatted

An overview of the customizations available in familiar dashboarding tools.

All platforms seem to disregard the traditional European scale (long scale, in which a billion = 1.000.000.000.000, not 1.000.000.000) so I couldn't find how to set the formatting options between the short and log numeric scale↗︎.

Datadog users can select the number of decimals to show for each widget, also if the units are human-readable (called "Autoscale", e.g. 1000000 → 1M) and they can use custom units

Grafana lets users override the units from a vast list. In the Options panel for each chart, (sometimes) users can toggle on or off the Formatted data overrides, so they see the raw number. They can define the formatting in the options tabs: The number of decimals, What to show when there's No Value, Units, Min, and Max... And add thresholds. There are also overrides for time. It's different for each panel, depending on the query.

User requirements derived from user feedback, agent interactions, and escalation tickets.

We received a significant amount of feedback from interviews, users, and customer agents, enabling us to pinpoint the most commonly occurring issues.

Select if human-readable or accurate.

The customer (…) wants to be able to tell the chart builder that results should show in full, with no rounding or shortening. Such as seeing: 14000000000 instead of 14B.

Billboard charts use the count unit, so New Relic makes it human-readable by default. But I might want to be able to display the full number rather than humanized so that I know the exact count, which is crucial for my company. So, depending on the goal of the chart, the user should be able to make the values more readable, like rounding them (1.567 vs. 1.5K) or showing the exact number. As a user, I should be able to select if the number is humanized or accurate.

Select how many decimals should be displayed.

(...) The customer would like more accuracy, IE why does it show 100% and not 99.9998%?
(…) Milliseconds should round decimals instead of showing them.

Some users don’t want to see any decimals for a specific attribute in a widget because it adds complexity they don’t need, as seen in other tickets. And the opposite can happen too: Some users need to show at least 5 decimals in their charts to match their company criteria. SLOs and SLIs decimals are critical to look at the metric, but the standard number of decimals may vary from company to company. As a user, I want to be able to select the number of decimals to get the accuracy I need, without adding more complexity than necessary or ignoring key data. And I also want to quickly see if the value it's being rounded so that I don't waste time double-checking if the results are correct.

Change the unit.

(...) Customers would like to configure the charts to show measurement units of their choice.

Users want to be able to specify the unit or use a custom unit alias so they can read the chart with the most appropriate unit in that context. Also, since sometimes the returned unit is not exactly the one the user needs, as we saw just a moment ago, some users hope to be able to pick a different one so at least they can fix the unit returned. As a user, I want to be able to specify the unit or use a custom unit alias override so that my team can read the chart with its appropriate unit.

Sales-oriented users should be able to override the G or T prefix with billion, million, trillion...

(…) Customer is Nike, and they are confused by our Billboard with a G instead of a B when representing a Billion numbers. Customer is asking to have an accurate representation of the data with the proper unit.

This is not really about numeric scale, but prefixes. Particularly in economy settings, one billion can also be written as b or bn for sums of money (publications on Economy and English 1, 2), and that's what some users are asking for. As a user, I want to modify the prefix for a billion, so the results don't get misinterpreted at my company.

Note: We may need to know what is what users call a billion, and if they would like to call it Bn instead of G or T. That's why we'll cover the possibility of selecting the Numeric Scale. The G prefix means Giga (γίγας, "giant"), which corresponds to the S.I. System and scientific notation. It represents a billion (US) or a milliard (EU), depending on which scale are we using, but G always means 10^9.

Units or data-types returned should be good enough.

A query returns us an entityId reported as UNKNOWN, while the JSON chart treats it as a number and rounds it.

When trying to display results in a different unit than usual, let's say rpm, New Relic doesn’t recognize the unit. Another query returns us an entityId reported as unknown, while the JSON chart treats it as a number and rounds it. I want New Relic to correctly identify the unit as an identification number so it never gets rounded accidentally.

Decimal marker selector (point or comma).

4.123 vs 4,123

As a French user, I use the decimal comma, like the majority of European countries. But New Relic uses the decimal point, like the rest of anglophone countries. I want to be able to set the decimal marker preferred by my company, so I don't misread the data.

Numeric scale.

There are two numeric scales in the world: The short-scale used by anglophone countries, in which 1 000 000 000 = 1 billion, and the long-scale, traditionally used in European countries, in which 1 000 000 000 000 = 1 billion (and 1 000 000 000 = 1 milliard). New Relic uses the Short Scale 1 000 000 000 = 1 billion, but a billion is not the same for all users. Our suffixes are related to the potencies of the numbers and are valid for both scales, like 10^9 = G(Giga). But if we were to allow users to select a non-scientific suffix, like billion, it would be helpful to know what is the exact meaning of billion for them. We need to evaluate if, as we do with decimal markers, we allow users to select their scale on their settings: A billion is 1,000 million or 1,000,000 million.

Solution

Because of their specifics, we need to modify and format units at different configuration levels.

We identified 3 levels at different parts of the process.

User-level: preferences on how all the data is styled. Users can configure the decimal marker or (numeric scale) they prefer, independently of the data. It's like picking a language or a theme.

Data level: Independently of the widget and user settings, New Relic must return the correct unit. Relying on widgets' overrides for accurate data types is frustrating.

Widget-level: Users should be able to override units and/or formatting depending on their specific needs: depending on where the unit is displayed, I might want it to be displayed differently. For example, in a widget, the number of sales is my company's KPI and I want the exact number, and I like the cash attribute rounded to get a general idea. However, in another widget, I need to know the revenue to the last cent because I need to compare it to the previous quarter. Same unit, same value, but different formattings on different widgets. The type of visualization is not relevant as it can change, so users should be able to configure overrides with an attribute-based approach.

This is a very simplified version of how the guessing actually works, but it’s useful for explaining our cases in a quick way.

Scope

For the scope of this project, we’re solving the last group of use cases, which happen on a widget level. We will start reaching out to other teams so we can solve the rest of the cases, but for now, that’s out of scope. So, after this project:

  • Users will be able to select how many decimals should be displayed.

  • Users will be able to choose if the value is humanized or accurate.

  • Users will be able to use a custom unit alias or change the unit.

Key Element: Query Builder Configuration Panel

The UI will be generated dynamically based on their internal configuration schema. To support this, our configuration options must be generic, agnostic and with clear repeating patterns for each section.

Simple customizations, like displaying the legend, impact all data, while others like Data Formatting need a previous selection of a specific attribute or series. By using this method, we're supporting various override types with the same pattern.

Example

  1. I select the attribute I want to format, in this case the Timestamp

  2. Depending on the type, it will let me modify specific customizations.

  3. I can see the input fields valid for this Data / Time type. Each type has its specific input possibilities. For the Data / Time type, the option valid is changing the formatting of the date.

  4. Now the Timestamp will be displayed as DD/MM/YYYY, as it’s customary in my company reports.