Dead Clicks: How to Find and Fix Them

To find dead clicks, look for clicks that are followed by nothing: no navigation, no change on the page, no feedback. Automated detectors flag them with a heuristic; in a session recording you can spot them yourself by watching what happens in the second after a click on the elements you suspect.

This post explains how dead click detection works in general, how to find dead clicks with AnyReplay (which does not detect them automatically), what usually causes them and how to fix each cause.

What is a dead click?

A dead click is a click or tap after which nothing observable happens. The user expected a response, got none, and either tried something else, clicked again or left. The dead click glossary entry has the one-line definition.

What is the difference between a dead click and a rage click?

The two overlap. A dead click on an important button often turns into a rage click a moment later, when the user tries again. A dead click on something that merely looked interesting usually does not. That is why dead clicks are easier to miss: the quiet ones leave no burst behind. How to fix rage clicks covers the louder case.

How automated dead click detectors work

Tools that report dead clicks generally watch each click and wait a short window for a sign of response: a DOM mutation, a URL change, a network request, focus moving. If none arrives, the click is labelled dead.

The rule is simple and the noise is real. Plenty of legitimate clicks produce no change: clicking into empty space to dismiss focus, selecting text to copy it, clicking a label whose checkbox is already checked, tapping a page to stop a scroll. Meanwhile some genuinely broken clicks do produce a change, such as a hover style or an analytics request, and are not flagged. Every detector tunes the window and the ignore list, and every one accepts some false results in both directions. Treat a dead click count as a pointer to sessions, not a finding.

How do I find dead clicks on my site?

AnyReplay does not detect dead clicks automatically. It flags errors and rage clicks at record time, and records every click in the interaction list. That is enough to find dead clicks with a little intent. Three approaches work well together.

Start from errors

A click handler that throws is the most common source of a dead click that matters. Filter the session list to Errors, open a session, and look at the clicks just before the error. If a click on a button is immediately followed by an error and no change to the page, you have found a dead click and its cause at the same time.

Read the interaction list

Open a session on a page you suspect and go through the interaction list. For each click on an element that should do something, jump to it and watch the next second. A click followed by no page change, no navigation marker and no visible feedback, and then a different action from the user, is a dead click. Because the replay is rebuilt from the DOM, you can see exactly which element was under the cursor.

Prioritise pages where people are trying to get something done: product pages, pricing, sign-up, settings. Dead clicks on a blog post are rarely worth the time.

Put custom events around suspect elements

When you suspect a specific element, mark both halves of the interaction with custom events: one when the click arrives, one when the result shows up. Sessions that contain the first event but not the second are where to look.

document.querySelector('#apply-filters').addEventListener('click', () => {
  anyreplay('track', 'filters_apply_clicked');
});

// wherever the results actually render
function renderResults(results) {
  // ...
  anyreplay('track', 'filters_results_shown', { count: results.length });
}

Filter the session list with Has event set to filters_apply_clicked, open the sessions and check the event list for a matching filters_results_shown. Keep the properties to counts and identifiers of your own; they are not masked, so never put personal data in them.

What causes dead clicks?

• Elements that look interactive but are not. Images, headings styled like links, cards with hover effects, icons, table rows, breadcrumbs that are plain text.
• Handlers that fail silently. An error is caught and swallowed, or a request fails and nothing tells the user.
• Handlers that never attached. A script loaded late or not at all, or a component re-rendered and dropped its listener.
• Disabled controls without a disabled look. The button ignores clicks until a condition is met and does not say which.
• Changes that happen out of view. The click worked, but the result appeared below the fold, in a collapsed panel or in a toast the user did not notice.
• Covered targets. An invisible layer sits over the element and takes the click. If the user tries again, this one often becomes a rage click.

How do I fix dead clicks?

• Decide whether the element should be interactive. If users keep clicking it, consider making it work. A product image that opens the product is a reasonable expectation. If not, remove the cues: no pointer cursor, no hover shadow, no link colour.
• Never fail silently. When an action cannot complete, show a message next to the control that says what went wrong and what to do.
• Give immediate feedback. Change the button state on the same frame as the click, even if the result takes longer.
• Bring results into view. Scroll to the updated content or show the change near the control that caused it.
• Explain disabled states. Style them as unavailable and say why.
• Remove stray layers. Check the page at the viewport size the user had and take hidden overlays out of the click path.

To confirm a fix, repeat the search you used to find the problem: the error filter, the same page in the interaction list, or the pair of custom events. The dead click should be gone from new sessions.

Frequently asked questions