Before we get into the technical creation of heatmaps, it’s worth bearing in mind two important points:
A heatmap depends on the data – You can only generate a meaningful heatmap if it’s based on enough data. For less busy sites, you may be able to get some good insights from just 1,000 user visits; on sites with high levels of traffic, you may need at least 10,000 sessions. To avoid any kind of bias, the heatmap software should select user sessions at random – on different devices, at particular times of day, etc.
A heatmap depends on your preferences – You may need to think carefully about the parameters you set for a heatmap. For example, if you ran a campaign during a particular time period, you might want to know about activity either during or outside of the campaign period, but it’s probably best not to mix them.
The 4 things needed to create a heatmap
A set of sessions for which you want to aggregate data. Typically, this involves visits to a page, filtered by a date range; the better software tools will also let you generate a heatmap for a group of filtered sessions within that period (for example, sessions on a high-resolution screen; sessions that used Chrome; or sessions performed on an iPad). A great tool will, of course, let you combine these filters.
The x and y co-ordinates showing precisely where users clicked, or showing which pixels were revealed during scrolling, etc. This data comes from the browser, and is mapped from the top-left-hand corner of the window.
Information about the browser size so that the x/y co-ordinates (for click, for example) make sense in their wider context.
The page over which the heatmap is displayed. Take care here, however; can you foresee situations where your page might change after you collected the data for a heatmap? In which case, will the heatmap be overlaid onto the page as the user saw it, or as the page exists today?
It is hardly necessary to explain how confusing – and pointless – it would be to try and interpret user activity that doesn’t relate to what sits on the page. More importantly, in some instances (such as financial services), it might be crucially important to capture exactly what a user saw, in order to prove what they understood or agreed to.
How the calculations are done
Let’s take the example of a ‘click’ heatmap. Once the pixel co-ordinates have been collected for a group of sessions, showing where users clicked, those coordinates are mapped pixel-by-pixel across the page. (As we said earlier, this should be the page as it was seen by the users at the time, not the page as it looks today.)
At this point, your heatmapping tool needs to do some calculations, which may vary slightly according to the tool – as might the final image, since some heatmaps use red for the hottest point while some use white. But here’s one typical approach:
Every pixel is given a ‘score’, showing how often it was clicked. The hottest point on the heatmap will, of course, be where most clicks occurred, and the coolest will be where there were few or no clicks.
Each of these scores is then converted to a percentage of the hottest point. Therefore, if your hottest pixel results from 1,000 clicks (or 100%), then a pixel that has been clicked 333 times will have a score of 33%.
Next, each percentage is converted to a number between 0 and 255. These numbers relate to a spectrum of color, where 0 is black, moving through blue to greens (with a central green at 128) and then through yellows and oranges to red at 255.
The colors within this range are then mapped, pixel by pixel, across the browser window, with the relevant page showing through so that you can see what the user activity relates to. The better heatmapping tools will enable you to adjust the opacity of your heatmap overlay, so that you can see the page beneath more or less clearly, and to adjust the temperatures within your heatmap.
What about different browser sizes?
Yes, size does matter. Earlier on, we said that it was important to have information about the browser size, so that the x/y co-ordinates made sense in their wider context. Let’s have a look at what this means in practice.
If we have an x co-ordinate of 600, showing that the user clicked at a point 600 pixels across the page, then the size of the browser window itself is going to make a big difference. (The y co-ordinate isn’t important here, because websites don’t generally expand and contract vertically.)
For example, the screengrab below on the left is of a browser window 900 pixels wide, and the one on the right is 1300 pixels wide. This makes all the difference to whether, in this instance, the user was clicking on the call-to-action button, or somewhere else:
Smarter heatmapping tools can cope with this, and will find a way to make the x co-ordinate, as reported by the browser, meaningful to you. One approach might be to work out where the horizontal centre of the browser is, by dividing the total pixel width of the browser in half. The x co-ordinate is then subtracted from this, providing a consistent x value (regardless of the size of the browser) because it will always be relative to the center point.
What about the other types of heatmap?
The example above was based on clicking. Your software tool will adapt the above approach according to the type of heatmap required:
A sample of the x and y co-ordinates may be taken every so often (for example, every 200 milliseconds), and these values are plotted into the browser’s grid of pixels.
The height of the browser window is added to the highest scroll offset that the user reached on the page in question.
Both the width and height of the user’s browser, and how far the user scrolled, are taken into account – enabling a square area to be plotted, showing the area of the webpage being viewed by the user. This might also take into account the amount of time a user spent looking at the area (dwell time)