How Rage Clicks Are Detected

Short answer: a rage click is detected by scanning a session's click events for a burst: several clicks, close together in time and in position. A typical rule is three or more clicks within about a second, inside a small radius or on the same element. The harder work is excluding legitimate repeated clicking, such as carousel arrows and quantity steppers, so the signal stays meaningful.

Exact thresholds differ between tools and are tuned over time. This article explains the logic, not one vendor's numbers.

Table of Contents

1. The Basic Rule
2. Three Thresholds
3. The False Positive Problem
4. Making the Signal Stronger
5. From Events to a Useful Report
6. Dead Clicks Are a Different Calculation
7. Key Takeaways

The Basic Rule

Every click is recorded with a timestamp, a position, and a target element. Detection walks through them in order.

function findRageClicks(clicks, minCount, windowMs, radiusPx) {
  const bursts = [];
  let group = [];

  for (const click of clicks) {
    const first = group[0];
    const near =
      first &&
      click.time - first.time <= windowMs &&
      Math.hypot(click.x - first.x, click.y - first.y) <= radiusPx;

    if (near) {
      group.push(click);
    } else {
      if (group.length >= minCount) bursts.push(group);
      group = [click];
    }
  }
  if (group.length >= minCount) bursts.push(group);
  return bursts;
}

This is a simplified illustration. Real implementations add the refinements below.

Three Thresholds

Count. A double-click is normal. Three is the usual minimum.

Time. Frustrated clicking is fast. A window of about a second for the first few clicks catches it, though on a slow device the gaps are longer.

Distance. People do not hit the same pixel twice. A small radius allows for that. Comparing the target element is often better than distance: five clicks on the same button are a burst wherever the cursor landed inside it.

On touch screens the same logic applies to taps, with a larger radius because fingers are less precise.

The False Positive Problem

A naive rule fires constantly on behavior that is not frustration.

Without filtering, a product gallery becomes the most "frustrating" element on the site.

Ways to reduce this:

• Ignore elements whose purpose is repetition, identified by role, type, or an explicit attribute.
• Check whether the click did something. If each click changed the page (the carousel advanced), the visitor got a response. Frustration is repeated clicking without a response.
• Treat text selection separately.
• Let site owners exclude elements.

The second is the most powerful. It turns the definition from "many fast clicks" into "many fast clicks that achieved nothing", which is much closer to what frustration means.

Making the Signal Stronger

A burst alone is a hint. Combined with other evidence it becomes reliable.

• Followed by a JavaScript error: almost certainly a real fault.
• On an element with no click handler: a dead element that looks interactive.
• During a pending network request: the page was slow to respond.
• Followed by leaving the page: the visitor gave up.
• On a conversion page: high cost.
• Repeated by many visitors on the same element: a pattern, not one impatient person.

This is why frustration is often summarised as a score per session, built from several signals, instead of a single flag.

From Events to a Useful Report

Detecting bursts is step one. Turning them into something a team can act on takes aggregation.

1. Group by element and page. "The Apply Coupon button on the cart page" is actionable. A list of timestamps is not.
2. Count sessions affected, not total clicks. One visitor clicking forty times is one visitor.
3. Express as a rate. Share of sessions on that page with a rage click.
4. Track over time. A rate that jumps after a release is a regression.
5. Link to recordings, so someone can watch what happened.

In DeepSync, each session row shows rage-click and dead-click counts and a frustration score, Highlights in the player jump to those moments, and Pulse's detectors on Business plans flag rage-click spikes with the sessions behind them (session filters, Pulse). Friction and rage-click detection is available on Pro and above.

Dead Clicks Are a Different Calculation

A dead click is a single click with no result, not a burst. Detecting it means watching what happens after a click.

• Did the DOM change?
• Did navigation start?
• Did a network request begin?
• Did anything scroll or focus?

If nothing happens within a short window, the click was dead. The challenge is the reverse of rage clicks: many legitimate clicks produce no visible change, such as clicking empty space or placing a cursor. Filtering to elements that look interactive keeps it useful (dead clicks explained).

Key Takeaways

• Detection uses thresholds for count, time, and distance or element.
• Excluding legitimate repeated clicking is most of the work.
• Clicks that produce no response are the real signal.
• Report by element, by sessions affected, with links to recordings.

Conclusion

Counting fast clicks is easy. Deciding which ones mean a person is stuck is the engineering. The closer the rule gets to "they asked and the page did not answer", the more useful it becomes.

Explore rage click detection.