A heat map shows, in aggregate, how people interact with a page. They are extremely helpful for figuring out what to test, how a test affected customer behavior, and assessing how an interface is connecting your business’s goals to your customers’ goals.

Heat maps also usually come with scroll maps, which show what percentage of users scrolled to what portion of a page. Scroll maps are great for showing when people stopped reading something. Could there be something wrong with your pitch? Has the reader made a purchasing decision by this point? Scroll maps are great for answering these sorts of questions.

Heat maps

First, you need to make a heat map. Here’s how you do that:

1. Get a tool for creating heat maps. We use Hotjar at Draft.
2. The tool will provide you with some JavaScript tracking code, so it can detect where people are clicking and scrolling. Install that in the right place in your theme.
3. Wait a week or two.

You now have a heat map. It’s that easy. It’s highly unlikely you’ll encounter bugs in the process.

What a heat map looks like

Here’s what a heat map looks like:

Here’s another:

These are real-world heat maps from a Draft Revise client, KeySmart, who graciously offered them for us.

Every heat map is different, but the approach is similar. It’s broken into three steps:

1. Where are people interacting?
2. Where are people not interacting?
3. Where does there appear to be concentrated activity that we don’t expect?

Let’s take this process and see what we can figure out from these!

Analyzing these heat maps

There is bound to be noise like this in your heat map:

Pay attention to what’s lighting up – as well as what’s going ignored. You’re looking for broad-scale trends that show a clear path forward.

Avoid reading into the tea leaves of random fields of clicks that don’t make any sense:

Instead, focus on buttons that see zero activity, and try to figure out why:

Let’s take the first heat map, which is of a product page for a KeySmart.

Here are a few things to note:

• Lots of people are playing with the add-on pull-down. That seems like an opportunity to make all three add-ons more immediately legible and understandable – or to move them later in the checkout process, upselling people after they’ve selected a model of KeySmart.
• Not many people are customizing the color of their KeySmart. Either they don’t want to or they don’t know to. Future tests could rework the layout and behavior of the color selector.
• There’s very little activity outside of these two areas – including on the navigation. Future tests could enclose this page (removing the header & footer navigation), or remove any elements below the checkout button (depending on whether people are scrolling down a lot to get a sense of the page’s credibility).
• Towards the previous end, people are clicking very infrequently on the expanders for features, various FAQ items, etc. Either people don’t care (possible!), they don’t know to click on these, or they’ve already made a purchasing decision. Future surveying and testing would confirm their behavior in practice, allowing us to create a layout that better met their needs.

Now, let’s take the second heat map, which is of KeySmart’s home page. Here are my takeaways:

• Nobody seems to care about their social media links. Move them to the footer; they distract from generating revenue.
• The currency selector seems to be getting a lot of activity. Do what you can to geolocate the customer, so you don’t have to provide a pull-down for language and a currency selector. This should keep people more focused on the value that KeySmart is able to provide.
• The old primary call to action, “Get a KeySmart Extended”, is seeing very little activity. Same with the second video:
  
  
  Future tests could automatically play the video, provide a different video, or even remove the primary CTA in favor of “I Need a KeySmart” below. (My take: adding “I Need a KeySmart” & “I Have a KeySmart” was the result of a successful test, which probably diverted attention from the rest of the masthead. Time to clean up the page.)
• People are dropping off after they see the grid of products below the shipping callout. Nobody is clicking on the video or noticing the callout for “the compact solution to your bulky key ring.” A future test could even remove these products, and move the value- and benefits-focused text further up the page as a result.

How to compare control & variant on a heat map

If you’re running an experiment, try to get separate heat maps that are segmented to every single variation in a test. This allows you to compare your control & variant really elegantly.

Again, here you need to pay attention to big shifts. This was readily apparent in the test we ran that added two new CTA buttons below the masthead: people just zoomed in on those and proceeded to ignore the primary CTA. It generated more revenue for the business, which is great – so what now? Do we remove the old CTA? Do we pursue a bolder rework of the masthead?

The heat maps from this particular test showed the knock-on effects that a test can provide, especially when messing with such significant elements as the primary call to action. Always vet your control against your variations to see not only whether the test won, but how, and what ramifications it has on your customers’ real-world behavior.

Examples of design insights that inform future tests

Per usual, I’m not here to recommend any experiments that are guaranteed successes. Instead, what I want to provide is a playbook. What should you do when you notice something happening in your heat maps? Here are a few of the most common situations I see, some potential explanations for those, and a brief description of what to do next.

• If nobody is using your navigation: First, go to Baymard Institute’s site and read everything they have about ecommerce navigation. Then, explore why this might be happening. Are people buying straight from the home page? What traffic sources are people coming in from – are they searching for your products with Google? If so, is there something amiss with your search? Look more deeply into how people are browsing using Google Analytics – what paths are they taking, and does that fit your business’s goals? Only then can you figure out what to modify for a test.
• If nobody is using your filters or categories: It could be that your filters or categories aren’t the right ones to fit actual customer use. I’d run a few usability tests that ask people to find and purchase the right thing, and see how they end up behaving.
• If too many people are clicking around, but too few people are buying: Have you done a good job selling your product? If it’s particularly high-involvement – like, say, a fancy artwork on 1stdibs – then it may be that people are more liable to window-shop. In KeySmart’s case, they’re selling a $20 keychain. You have $20. Most of KeySmart’s customers have $20. If nobody ended up buying KeySmarts, then you absolutely need to do a better job of selling the thing.
• If people are spending too many clicks on fiddly customization options: Simplify your customization – or run a test that defers it until later in the checkout. Do what you can to gradually engage the customer, so they don’t feel overwhelmed from the get-go.
• If people are clicking on your navigation from your product page: Are they entering your product page through other traffic sources, like social media or Google? If so, run a test that explains the product – and assumes that the customer knows nothing about it. Are people entering from the home page, and bouncing around? Perhaps they’re considering all of their options, which means you need to do a better job of clarifying your product line earlier. In that case, I’d run a home page test that lays out all of the product offerings, and suggests specific use cases for each one.

Scroll Maps

Here’s an example of a scroll map, from former Draft Revise client KeySmart:

Red areas correspond to 100% of customers viewing those elements; then it fades to yellow (for 75%), green (50%), blue (25%), and black (0%).

Let’s talk about when scroll maps are useful, and how to meaningfully act on them.

When are scroll maps useful?

Scroll maps matter in two main ways:

• When correlating engagement in corresponding heat maps. Usually, scroll maps are run at the same time as heat maps, acting on the same data. That allows you to understand whether there’s a high percentage of people engaging with elements that look dimmer on the heat map than they should.
• On long-form pages. Are you running a long-form that you want customers to read, not just skim? Scroll maps tell you when customers get bored and leave – which lets you isolate any elements that need to be reworked to reduce bounce rates.

How to analyze scroll maps

So, you have a scroll map. What do you look at?

First, take a look at the most conversion-focused elements on the page:

• Price
• Calls to action
• Risk-reducing text & objection busters

Audit each of these, isolate where they are on each platform, and figure out what percentage of your customers are scrolling to each element. Scroll mapping tools often provide the ability to hover the map to see exactly how many customers are scrolling to each element.

If your most important elements are hidden below the fold, 1) they probably shouldn’t be, and 2) it’s likely that your scroll maps will uncover some significant issues with the page’s ability to move customers to the next step.

Then, take a look at any significant drop-off points where over 10% of your customers are exiting the page in the duration of one element. If most of your customers are dropping off at a given point, that’s probably a sign that you need to rework the page in order to keep their attention – if that’s a clear goal of the page, of course.

Troubleshooting

Let’s go over some of the most common issues when running heat maps, and the things you can do to address each one of them.

When the screenshot doesn’t underlay

Heat maps are generally overlaid on top of a static screenshot of the page. Most heat mapping tools take this screenshot using their own scripts; some use a third-party API like BrowserStack to do it.

Sometimes, the screenshot doesn’t underlay at all.

For Hotjar, this is best solved by pinging their support and having them do it themselves. (As of press time, Hotjar doesn’t allow you to underlay your own screenshot.)

Excessive noise

Sometimes, heat maps yield excessive noise: either a bunch of taps uniformly across the heat map, or pockets of taps in places that make no sense.

Noise uniformly across the heat map

This is likely the result of aggressive sideloading of elements changing the DOM tree in the background of the customer’s session, such that their taps keep registering in unexpected places as they continue browsing and loading new elements.

This is especially unfortunate, since any background noise is likely supposed to be rendered as taps in places you would expect on the page. This reduces the quality of signal you’d get in the heat map, and it lengthens the time it takes to get any meaningful, actionable results.

In order to address this, you’ll either need to change the way that you side-load assets (which is non-negligibly difficult, and could severely harm the page’s load & render times), or you’ll want to cross-check your results with a new heat map provider.

Pockets of noise in unexpected places

This is usually the result of people tapping on an element that clearly exists on the page, but taps are registered by the heat map as existing elsewhere.

You might be able to look at the heat map – especially hovering the heat map within your heat mapping tool – and determine where the customer truly intended to tap. But even then, that doesn’t make the heat map very shareable, and it remains a little confusing for you.

The #1 issue that causes this is absolutely positioned elements. If you have any major elements that are absolutely positioned on the page, taps could register in unexpected places, depending on the customer’s viewport width.

This also happens quite often with sticky headers & footers. Taps could be registered in a column down the page, in line with the middle of the element you’re tracking.

In either situation, you’ll either need to figure out how to change the positioning of the element (some absolute positioning can be solved with margins or relative positioning, and absolute positioning should only be used when necessary in general), or you’ll need to find a heat mapping tool that can follow sticky elements more gracefully.

Elements are nudged in one direction

Sometimes, taps appear uniformly shifted a few pixels to the sides of their corresponding elements.

If shifted to the side, this is usually the result of a breakpoint issue; the heat map is rendering at a specific width, while most customers are accessing the page at a different width.

If shifted vertically, this could be the result of an injected header or footer banner, or a sticky header or footer, pushing the content in the wrong direction.

In either situation, you may need to ask the heat mapping provider to retake the underlying screenshot. If the issue is with injected elements affecting the page render, then you should probably change the timing of when those elements are injected, pushing them before the full page renders and document.ready fires to the browser.

Mobile heat maps don’t fire

If your desktop heat maps are showing new taps correctly, but your tablet & smartphone heat maps don’t show anything, then you could have some structural issues with your theme. Perhaps it’s rendering the whole experience as an AJAX-powered single-page app, or perhaps an overlay is preventing taps from registering.

In either case, this usually indicates a significant issue with the DOM that might require a re-theme. Sometimes, though, you can get off easy and discover that the heat mapping tool’s snippet simply doesn’t render on mobile. Try there first, and then look into the way that the page is being rendered for customers.

Remember that every addition of complexity in your theme is a conscious choice. The more complicated you’ve made things, the harder it will be to track customers’ behavior and make meaningful changes.

Time-scale analysis

You should run heat & scroll maps of every key page in your funnel at least once every month. That includes:

• Home page
• Category page
• 2-3 product detail pages
• Cart
• Checkout
• Thank you/order confirmation
• Any landing pages that you’re directing traffic to

You can get a lot of insights looking at just one heat map, of course. But heat maps gain a whole new layer of value when you are able to track how they change over time.

Let’s talk about how you can learn from many heat maps in aggregate, as you continue to make revenue-generating design decisions that change both your store and your customers’ behavior.

How to analyze time-scale changes

There are two main ways you can assess time-scale changes in heat maps: either through image diffs, or through overlaying.

In programming parlance, a diff is how you compare two blocks of text to determine what’s been added, removed, and changed. Diffs are commonly tracked per line, but you can always get more granular to assess changes between specific blocks of text.

And you can run diffs for images, too! There are a handful of great tools for the purpose, where you can look at two images at the same time and make comparisons. We use Kaleidoscope here at Draft.

Running heat maps per variant

Hotjar’s continuous heat mapping tools (probably rightly) strip any ids, hashbangs, and query parameters from URLs by default. But for the sake of this, we need to make it so that they treat those as separate pages.

1. In Hotjar, go to Settings at top right -> Sites & Organizations, and click the gear next to the site that you want to edit settings for.
2. Open the “Session targeting & tracking” accordion tab.
3. Under “Tracking URL Changes,” change the pull-down to “Track changes automatically, including fragments”.

In the future, this means you’ll want to search for pages using wildcarding in Hotjar’s continuous heat map tool, so that you can capture as much traffic as possible.

Setup step 2: configure Google Analytics to qualify out variant query parameters

Since you’ll be modifying the URL of the variant page, you’ll want control & variant to show up as one single page in GA, so that you can continue to have clean data.

1. In Google Analytics, go to Admin -> View -> View Settings.
2. In the box labelled “Exclude URL Query Parameters”, add the string var. This list is comma-delimited, so if other query parameters exist in there (e.g. foo), you’ll want to append them with a comma and no space (e.g. foo, var).

Note that this will only strip query parameters named var. If you update the query parameter’s variable name in the next step, you’ll want to strip that query parameter in GA as well.

Doing the thing: add global JavaScript to your experiment

Last, you’ll be configuring your experiment to add the query parameter. This should not present an appreciable performance hit for any experiment.

1. In Google Optimize’s editor, open the code editor pull-down, and select “Global JavaScript”.
2. Add the following code:

const url = new URL(window.location);
url.searchParams.set('var', 'var1');
window.history.pushState({}, '', url);

This will add ?var=var1 to your URL.

After launch, check Hotjar to confirm it’s working

Lastly, in Hotjar’s continuous heat map view, you’ll be pulling down a heat map to determine whether this worked.

1. After waiting a few hours for your heat map to gather data, go to your continuous heat map view in Hotjar.
2. Change the pull-down from “Single page” to “all pages containing”.
3. Type “var=var1” in the box, and hit “View Heatmap”.

You will now have a heat map for only the variant of the experiment that you ran.

Naming conventions

In order to keep GA happy, I would keep the variable name set as var no matter what. If you want, though, you can swap what it’s set as to reflect other experiments. That way, you can pull heat maps that reflect different experiments at different times – which will result in the right page background.

The naming convention we use at Draft is date_page_variant, such as 2021-08_home_var1, for example, for a home page test that was kicked off in August 2021.

Operational notes

Note also that the setup steps you just did in Hotjar & Google Analytics are a one-time thing. Going forward, all you need to do is add those lines of JavaScript into Google Optimize’s global JS, and it should be smooth sailing from there.

If you’re running into performance issues or bugs, the first thing to check is whether Google Optimize is being called first in <head>. Google Optimize should always be called first, and it’s doubly important here to make sure that it happens before Hotjar is called.

Wrapping Up

With this guide, you should get a sense of why heat maps are important, how to run & read one, and the different kinds of design insights that you can garner.

← Back to the Blog Check Out Draft’s Store →