Rage clicks
This FAQ provides a clear overview of how our tool detects rage clicks, evaluates user frustration, and prioritizes the most critical data, making it easy for anyone to understand why and how to use it effectively.
What is rage clicking?
Rage clicking occurs when a user repeatedly clicks on an area of a webpage in frustration, often because the page isn’t responding as expected. This pattern can indicate that something on the page is broken, too slow, or confusing. It’s a sign of user frustration, which is critical for website owners to address to improve user experience and engagement.
Why should I measure rage clicks?
Rage clicks are one of the clearest indicators that users are having a bad experience on your website. If users continuously click an unresponsive button or an area of your page that isn’t functioning properly, they are likely leaving your site frustrated or confused. By measuring rage clicks, you can:
- Identify broken or confusing elements on your site.
- Find out if your page is responding too slowly to user interactions.
- Improve your website’s usability and keep users engaged.
- Gain insights into performance issues like slow page loads or delays in visual feedback (such as buttons or links not working as expected).
Ultimately, measuring rage clicks helps you understand where users are struggling and gives you the data you need to improve the experience, leading to higher user satisfaction and better business outcomes.
Tracking methodology
This section explains what is determined rage clicking, a rage group and how our JavaScript is deciding which group to report.
Rage groups
Our tool captures and analyzes all user clicks that occur on your website. Depending on the (im)patience of a visitor, a user could become frustrated multiple times within a single page life cycle.
In other words, there could be multiple instances where a user becomes frustrated and starts clicking multiple times in the same or nearby position. And maybe even within a short timespan too.
We consider each occurrence a rage group: a group of approximately similar events (currently, only clicks):
- each successive event is happening at or within 10 pixels of the previous click.
- and each successive event is happening within 1 second (or the INP value) of the previous event.
If one of these is not a match, a new rage group is started.
Technically, there could be a single event in a single group. However, any group with more than 1 event is considered rage clicking and thus an actual group.
Mapping rage clicks with INP
The INP (Interaction to Next Paint) metric is crucial for understanding how quickly your site responds to user interactions, such as clicking a button or link. If there’s a delay between a user’s click and the page visually responding, this can cause frustration, which often leads to rage clicking.
Data from this metric becomes more valuable when combining it with user frustration, as everyone is perceiving the web differently. Combining INP with rage clicking helps to determine if INP did lead to frustration. So, when a new rage group occurs with either more events than the previous group or, if the number of events is the same, happens during an INP period, we prioritize and collect that rage group.
Prioritizing and saving rage clicks
Our tool is designed to collect and save only the most significant group of rage clicks from each user session. This helps ensure that the data you receive is highly relevant and focused on the most important frustrations users are experiencing. Here’s how we prioritize and save rage clicks:
- Click count: The tool prioritizes groups with more clicks. A group with more clicks indicates higher frustration and overwrites any previously recorded rage click groups.
- INP correlation: If a group of clicks happens during the INP period (a slow interaction on the page), this group is given priority over others. Slow response times during user interaction often lead to rage clicking, so these groups are considered more important.
- Duration: If two groups have the same number of clicks, the group that occurred over a shorter time frame is prioritized. A quicker burst of clicks indicates a higher level of user frustration.
The tool intelligently evaluates these factors and saves the most important group of rage clicks from each session. This way, you get the most valuable insights without being overwhelmed by data.
Rage clicking dimensions
Once the tool detects a group of rage clicks, it reports key information of that group and rage clicking in general. This results in multiple filters related to rage clicking and to be used by RUMvision clients. These dimensions are described below.
These filters only work with the Interaction to Next Paint metric
Rage to INP relation
This dimensions describes the relation of a rage group to the INP on that page. It's important to note that:
- A rage group is a group of clicks within a close timespan and position.
- When talking about INP, we're referring to the highest INP during a page life cycle, as reported by the web-vitals library and collected by RUM tools.
Possible values for the Rage to INP relation dimension are as follows:
- before: The rage group happened before the highest INP happened
- during: The rage group happened during the highest INP
- after: The rage group happened after the highest INP
Rage click element
This dimension can be used to see what element in the DOM was clicked first within a group of clicks. Only the details of the target element are collected.
However, if the Rage to INP relation equals during, the element is not collected as it is already part of the metric element dimension
Rage load state
The rage load state is collecting the state of the document during which the rage group happened. We use the same values as the web-vitals library or overwrite it with "fcp" when the rage group happened even before First Contentful Paint (FCP) happened.
By also taking FCP into account, site owners are able to determine how many of the rage groups happened while the page was not visible yet. Users of RUMvision could then choose to exclude these or focusing on them during segmentations.
Events in rage group
This states the amount of events in the reported rage group. RUMvision currently only collects clicks, which means this dimension is showing the amount of clicks within a rage group.
Total rage groups
See the explanation of "Rage groups". This dimension will then show the amount of groups where there were more than 1 event.
With this dimension, site owners have a better idea of how frustrated visitors could be during a single page life cycle. This is an experimental dimension though.
Rage group number
We report to which group number the reported group is beloning.
This dimensions is helping us as a RUM tool to determine if we are tracking the right thing and how valuable other data is. As a result, this is an experimental dimension.
How a RUM tool comes in
Our tool offers a comprehensive solution to detect and understand rage clicking, linking user frustration to potential performance issues. By combining rage click detection with the INP metric, you gain valuable insights into both usability problems and page performance bottlenecks.
- Improve User Experience: By identifying where users are getting frustrated, you can quickly address problematic areas and improve site usability.
- Boost Performance: If slow page responses are causing frustration, our tool pinpoints exactly where these issues are happening, allowing you to improve your site’s speed and responsiveness.
- Data-Driven Improvements: Armed with data on rage clicks, you can prioritize the fixes that will have the biggest impact on user satisfaction.
With our tool, you’ll have the insights you need to optimize your site, reduce user frustration, and create a better overall experience for your audience.
Drawing conclusions
When there are no or only a few rage groups tied to the highest INP, site owners might conclude that despite any high INP values, users are not getting significantly frustrated, and the INP metric might not be a key performance indicator (KPI) for their business.
Obviously, we advice site owners to combine such research with other dimensions or even consulting a web performance specialist before drawing such conclusions. In the end, frustration could still happen within other segmentations while not being visible at higher level. An example is the checkout page, typically the last place where you want users to become frustrated while being so close to a conversion. When not diving into other dimenions, frustration and loss of revenue might remain a blind spot.
Shortcomings
At RUMvision we considered different rage click tracking strategies. And no strategy will be the perfect one. During these considerations and choosing a final implementation, we identified a few shortcomings which are described below.
- It's not only clicks
Users might express their frustration in different ways. Throwing away their device might be the most extreme example, others might just sigh from frustration. In other words, not everyone will express frustration within the screen of their devices. - Event types
Even if they do, frustration might not only result in rage clicking. It could also lead to actions like scrolling and swiping. However, we observe a weaker correlation between these gestures and user frustration. - Repeated keyboard strokes
The same applies to keyboard strokes or keydown and keyup events. We wanted to track this, but it is likely to produce more false positives while overwriting a more meaningful group of clicks. A user typing text into a search bar or login form is a good example. - Dead clicks
Next to rage clicking, dead click could be tracked as well. But just like keyboard strokes, this is likely to result in many false positives. A breadcrumb's last item is typically not clickable because of WCAG, but some users might end up clicking on them. That's a deadclick, but not always a serious problem. - Not all clicks are measured
Although configurable, the RUMvision JavaScript is not listening to all clicks from the very start. It's only able to hook into clicks once the JavaScript itself was executed. This means that any frustration caused by a long white screen is less likely to be reported.
Because we know we are missing such pre-FCP data and because of other shortcomings, we decided to move rage click tracking methodology closer to the INP.