What are heat maps? A 1980s Predator-vision mash-up with web analytics?

What are Web Heat Maps, Really?

What heat maps are, what they do, and what they don’t do well for visualizing user interactions on a web app.

One of the most popular feature requests we’ve had at FullStory has been aggregated user interaction information — our customers want to see what their users are clicking and interacting with. They need a visualization.

The de facto solution to visualize aggregated clicks and user interactions on a website has been “heat maps” — like the Predator’s infrared Heads-Up Display applied to web pages.

For web applications, heat maps are graphical overlays that indicate the areas of heightened user interest and interaction. There’s no standard to how these heat maps are built, but generally, red, orange, and yellow areas show higher user interaction and interest. Green and blue areas are for moderate interest. Dark areas are … forever alone.

Really, there’s a reasonable chance that if you painted a red, yellow, and green “F” on any given web page, you’d approximate the insights of a heat map for that page.

Areas of user interaction are determined through eye-tracking tools, session replay tools, or perhaps just aggregated clicks on links.

Heat maps have been the go-to graphic for showing user interactions on a web application — they’re hot and cool!

Except the more we learned about heat maps, the more we found problems.

What’s a heat map really, anyway?

The term “heat map” or “heatmap” was trademarked by Cormac Kinney in the 90s to refer to a 2D financial market visualization (Wikipedia; also Kinney’s lapsed Trademark). Today, what most of us think of as heat maps is entirely different.

Above are a few examples of different types of heat maps.

Google image search reveals all sorts of visuals are being categorized as heat maps.

According to Kenneth Field (a.k.a. Cartonerd) in his post When is a heat map not a heat map, most of the data visualizations referred to as “heat maps” are not actually heat maps: they are technically isarithmic density maps.

So what is an isarithmic density map? According to the Geographic Information Systems encyclopedia, an isarithmic map is:

A type of thematic map that represents a continuous field using isolines (lines of equal value) or isopleths (regions of similar value). They are sometimes referred to as a heat map, although a heat map is only one type of isarithmic map that represents density.

A popular form of isarithmic map is a contour line map. Think about topographic maps — each connected line in a topographic map represents the same elevation:

Isolines are so line-y! A classic isarithmic map is topographic!

Your run-of-the-mill topographic map uses bright line data points — elevation at specific, unique geographic locations — and interpolates (i.e. connects the dots) the missing information across the data points.

Web application isarithmic density maps (Okay let’s just call them “heat maps”), don’t have isolines. Instead heat maps use isopleths. Isopleths are regions of similar value — the blue, red, green, and yellow color splotches.

Moving off isolines and on to isopleths takes us from the bright lines to fuzzy areas. Above is an isarithmic density map that visualizes areas of interest on a web page. These visualizations are popularly known as a heat maps.

Those splotches of color represent aggregated user interactions on a web application.

As visualizations go, heat maps make for an easy-to-grok, pretty picture. We look at them and say “Ah, I see!” We feel like we understand something deep and meaningful.

But there’s a catch — or at least four catches — and if you’re hypnotized by the glowing hotness of heat maps, you might miss these problems completely.

The four problems with web heat maps.

1. Lies, damned lies, and [X, Y] positions

In a world of responsive design and device heterogeneity, using a visualization designed for a fixed unchanging aspect ratio is a recipe for failure. “100px down and 350px to the right” doesn’t mean the same thing across two different user visits to your site with each at different browser window sizes and/or screen resolutions.

Ignore these differences and you might find yourself at a confusing dead end. Responsive design and varying display PPIs also make converting between aspect ratios only possible with a pile of assumptions.

You change the device but does the heat map visualization change, too? Hint: it probably should.

It all adds up to web heat maps forcibly siloing the data they visualize. You only see heat maps with aggregate data for users with the exact same screen resolution configuration. 1024x768 users go here. 1366x768 go there. 1280x800 users go in the cupboard. These arbitrary silos mean you aren’t actually seeing the meaningful aggregate across your actual non-same-screen-resolution-using users. Kinda defeats the purpose of the “easy” visualization, right?

And this is just on desktop. There are thousands of different mobile browser resolutions in the market. Most heat map visualization solutions pretend these differences don’t matter.

Yet they matter a lot.

Averaged and aggregated mouse hovers and un-contextualized [X, Y] click positions cause well-intentioned product teams to make actual product changes based on shoddy information, wasting time and money, negatively affecting the business, and harming customer experience.

2. It’s 2017. Dynamic applications are the norm.

Today, a single web page is no longer a static fixed document. Modern webpages and applications are dynamic. Animations, slide out panels, expanding menus and modal dialogs are the norm. As you might guess, this poses a problem for heat maps.

A screenshot from a popular heat map product. Note how the heatmap is an overlay for the page at one single state; when the page moves, the overlay doesn’t. 🙁

Simply put, heat maps don’t work well with dynamic applications where the page changes. And that is an especially huge problem for JavaScript heavy single-page applications.

Though heat maps’ challenges aren’t constrained to JavaScript heavy applications. Even server rendered websites that have data-driven content have this problem. The location of the thing you click on varies by the whims of the cosmos, popular culture, your scroll position, and what article grandma happened to post on her social media wall that day.

You end up with aggregated positional spaghetti.

And this same issue affects everything from product inventory tables on an e-commerce site to data-driven menu options in your business enterprise app.

3. Mapping orange splotch “heat map insights” to meaningful actions.

Even when the stars align and they provide accurate and meaningful aggregations of user interactions, the heat map visualization itself doesn’t directly tell you what you want to know. Those aggregated splotches obscure the very thing that was interacted with. You have to read the heat map tea leaves and interpret the splotches to figure out what you think the users were interacting with. What button, link, or control does that blob correspond to?

You might call this effort “splotch to element mapping:”

How do you see beneath the splotches and map back from the “insight” to the underlying element or link? Heat maps as actionable visualizations make implementation difficult.

After seeing a heat map and completing your back-of-the-envelope “splotch mappings,” what do you do next? How do you further research the insight?

How do you close the loop and turn this nugget of info into an actionable insight?

4. Yikes! I have to configure all that to make heat maps work?

Most heat map solutions ask you to configure complicated URL patterns and regular expressions to tell the system how to interpret interactions on a page-by-page level.

Imagine asking someone (non-engineer or engineer) to configure the set of possible URL regular expressions for all the important pages in a modern JavaScript application, with complex histories and dynamic URLs with identifiers in them. It’s hard to get it right in the first place, and guaranteed to go sideways the moment something changes — and your application will change.

If heat maps are busted, is visualizing aggregated user interactions on your site impossible? No!

Having thoroughly examined heat maps as a possible solution to meet our customer’s requests for a visualization of user clicks on a web application or webpage, we decided to go our own way.

We built Page Insights, which includes both Click Maps and Inspect Mode to make it easy to see how your users are interacting with your website, in aggregate, while gracefully dodging the four major problems of heat maps.

Above is a screencap of Page Insights with Click Maps and Inspect Mode from FullStory.

Page Insights are resolution independent.

FullStory understands the structure of your site. FullStory can translate that into aggregations that make sense across screen resolution, device type, and even the most dynamic and varied data driven interfaces by focusing on Elements. Not just position.

Above you can see the same page (The Fullstory “Wall of Love”) through Page Insights Click Maps — as seen at different screen resolutions.

Page Insights take into account what’s on (or not on) the page.

If you watch a playback of a dynamic single page application on FullStory, you realize that many things pop in and out of existence.

Page Insights knows automatically that these are separate app states and will show you different aggregated user interactions for each state.

Page Insights are smart enough to account for these dynamics and show you what’s relevant to what you are seeing on the page now. Click statistics for a non-existent popup won’t be shown when the popup isn’t there.

Page Insights are actionable.

You can click and see your answers immediately. And if you have questions you want to drill into, you can search. No orange splotch mapping to your web app required.

Actionable Insights: Start by discovering your top error clicks. Next, “Add to search.” Finally, see what the errors are in the Console.

Page Insights require zero configuration.

FullStory uses machine learning to know what the pages are in your web site or web application. FullStory understands what pages are the same, and what pages are different. So your insights are appropriately relevant and contextualized. No need to do complicated configuration or setup brittle URL route regular expression voodoo. It just works out of the box.

Bonus! Some new tricks.

Page Insights give you aggregations that respect the searches you do in FullStory, too (If you’re not familiar, here’s an explanation of FullStory search). This helps you answer questions like “What do visitors from my reddit ad campaign click on first?” Or you can see how they compare to “visitors that came from Product Hunt.”

Page Insights make your existing FullStory segments even more useful.

See ya later, web app heat maps!

As for the default data visualization for web app interaction of yesteryear — that is, isarithmic density maps … er … heat maps — until the day comes when we can reasonably manage the problems they create, we’re leaving heat maps where they left us: out in the cold.

And if you want to try visualizing aggregate customer experience on your web application, check out FullStory Page Insights, see what you can discover and take action on, and let us know how we can make it even better.

FullStory is the Customer Experience platform that helps everyone in your company build the best online experience for your users. Capture every click, swipe and scroll and unlock pixel-perfect playback, funnel analytics, detailed search and segmenting, and more.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.