Page tree
Skip to end of metadata
Go to start of metadata

In several standard tabular reports you will notice color legends applied across multiple columns/fields. NocTel Insight makes use where sensible heat mapping on certain quantified columns/fields to help better illustrate and draw attention to conspicuous values and patterns.

This sections explains and hopes to answer some questions surrounding heat mapping's interpretation and use.

Where is Heat Mapping Applied?

Heat mapping only applies to tabular reports/visualizations and only on quantifiable data. This does not include time formats. In most cases time format column/fields also have corresponding integer based calculations, such as in seconds, minutes, etc.. Where applicable to do so, the integer based conversion calculations may be used for heat mapping.

What's the Logic Applied to Color Schemes Used?

In most cases only two color schemes are necessary to be effective. We generally try to avoid using a distinct color scheme for each column's heat map legend since this often creates a rather vivid and difficult to interpret resulting table and color mapping - the exact opposite result we want.

Tabular reports often provide a summary (typically totals) column followed by separate columns for the relevant subdivisions/groupings of metrics. There may also be columns that tabulate related data in different dimensions, such as a table which provides the total of calls along with a column for total minutes. Cohort columns like (count of) inbound and outbound calls may be present along with their corresponding minutes. In such cases it makes sense to use just two color schemes: one for count of calls (volume) and one for the calculation of the minutes. This results in being able to visually compare like measures in different contexts.

How is Heat Mapping Applied to Columns?

As noted above, we generally use only a handful of color schemes for heat mapping causing one or more columns to use the same color scheme in the same way. 

The color scheme and subsequent heat mapping is applied only to the column and not applied across each column using the same scheme. There is no mapping across all the present values across multiple columns. This is done intentionally since multiple columns may be related but not on the same scale causing the overall spectrum to apply the extremes of the color scheme in a misleading way. For example, using the same legend across a column that measures things in seconds and another in minutes both expressed as integers. Insight would only consider the numeric values and knows nothing about the difference in scale. Such an application would highlight a row with a value of 100 more heavily than one with a value of 2 without having the right context that the 100 valued row is in seconds and the 2 valued row is in minutes.

This is a similar problem if heat mapping across multiple columns that may be related but typically not directly compared again. For example, a column for Inbound Calls and a column for Outbound Calls. Let's presume there are much more inbound calls occurring than outbound calls. If we were to heat map over both columns together, outbound calls would be skewed much lower and inbound calls much higher. The more useful analysis would be to apply heat mapping to each column individually to call out highs and lows.

Why Can't Heat Mapping Be Applied to Dimensions?

Dimensions and their values are typically not measured along a discrete spectrum. Particularly because Dimension type data tends to be values that are strings, such as friendly labels for entities. Strings inherently have no way of knowing the underlying context even if the interpretation is strongly tied to something measurable along a spectrum or could be parsed/interpreted numerically, such as having values of "one" and "Seven".

Another logical pitfall to avoid is that unique identifier numbers - typically those used in relational databases for table primary keys - are not measurable. The meaning of the value is not to be interpreted in a measurable way beyond as an anchor to evaluate conditional counts on, which would be used in aggregate fields/functions but never directly by themselves.

  • No labels