Rage clicks

A rage click is rapid, repeated clicking on the same spot. It is the universal sign that something looks like it should work and does not. The visitor clicks once, gets no response, and clicks again, harder, before giving up.

Clickport catches that moment and tells you exactly which element fought your visitor, on which page.

How detection works

Clickport flags a rage click when a visitor lands three or more clicks on the same small area within about one second. Everything runs in the visitor's browser, inside the tracker. Only the resulting signal is sent. No raw click stream ever leaves the page.

• Three or more clicks in roughly one second, landing inside a small radius of each other.
• One signal per burst. A single tantrum is recorded as one event, not ten, so a frustrated visitor cannot flood your data.
• Capped per page. Rage clicks are limited to a handful per page visit.

What is captured

The capture is deliberately thin. For each rage click Clickport keeps a short element selector (its tag, plus an id, a class or two, and a role when present), the element's visible label when it has one, and how many times the visitor clicked in the burst. That is all.

There are no click coordinates, no screen recording, no mouse paths, no keystrokes, and nothing about who the visitor is. It is cookieless and carries no personal data. Selectors that look like they could carry personal data are dropped, and form fields never contribute a label.

The sub-items: which elements get hammered

In the Signals breakdown, expand the Rage clicks row to see the exact element selectors people are hammering, ranked by how many visitors hit each one. This is where you find the single broken button costing you the most.

How to act on rage clicks

A rage click almost always points at one of these:

• A broken or unwired button. The element looks like it should do something but the handler never fires. This is the highest-value find: a checkout button that silently fails is lost revenue.
• A slow handler. The click works, but nothing happens fast enough, so the visitor assumes it failed and clicks again. Add a loading state or disable the control while it works.
• A misleading affordance. Something looks clickable (a styled card, an icon) but was never meant to be. Either wire it up or make it look inert.

When a rage click sits on the same element as a script error, you have found a root cause: the handler threw, so the click did nothing, so the visitor rage-clicked. Cross-reference the two signals on the same page.

Where it shows up

Rage clicks carry a red R badge. They appear on the individual session page lines in the Sessions sub-tabs, and inside a session they sit in the timeline next to pageviews, scrolls, and clicks, so you can see exactly when the visitor got stuck.

Good to know

• Forward-only. Rage clicks exist for visits that happen after the feature is active on your site. Past sessions cannot be backfilled, because the raw clicks were never recorded.
• Single-page apps are covered. A frustrated tap is tied to the right route even after a client-side navigation.
• It does not use your pageview allowance. Rage clicks are events, like outbound clicks and form submissions, and do not count toward your monthly pageview limit.

For the deep dive on how rage and dead clicks compare, and the privacy reasoning behind both, see Frustration Signals and the article Rage clicks and dead clicks.