# What are frustration signals?

Canonical: https://flusterduck.com/learn/frustration-signals

Frustration signals are measurable behavioral patterns, like rage clicks, dead clicks, cursor thrashing, and navigation loops, that indicate a user is struggling with an interface. They surface broken and confusing experiences without recording screens or capturing personal data.

Frustration signals are the measurable behaviors of a struggling user. [Rage clicks](/learn/rage-click) on an unresponsive element. [Dead clicks](/learn/dead-click) on things that look interactive and are not. [Cursor thrashing](/learn/cursor-thrashing) across a page that will not give up its answer. [Navigation loops](/learn/navigation-loop) between pages that each promise what neither delivers. Field-level [form abandonment](/learn/form-abandonment). Repeated retries. The stall before the exit.

Together they form a second error channel. The first channel is the runtime reporting broken code to your error tracker. The second is your audience reporting a broken product, in the only language available to them. Most of what costs conversions lives on the second channel, [where error trackers cannot see it](/blog/your-error-tracker-thinks-your-site-is-fine).

## Why signals beat recordings

The older approach to seeing user struggle is session replay: record the screen, watch the videos. The problems are scale and privacy. Nobody watches forty thousand recordings, so replay in practice means sampling a handful and generalizing, and the recordings themselves capture everything on screen, including what users type. [The full argument is here](/blog/session-replay-wont-tell-you-what-to-fix).

Signals invert the model. Instead of recording everything and hoping a human notices the struggle, detect the struggle itself in the browser and keep the signal: this element, this page, this behavior, this many sessions. No video or replay recording. Form values and user-typed text are never read. An interacted element can carry a short, PII-redacted label so the issue is readable. Signals aggregate cleanly because they are counts, so they rank by frequency and reach, and they attach to specific elements, so they arrive pre-diagnosed.

## From signals to decisions

Raw signals are still noise until three things happen:

1. **Clustering.** One rage click means nothing. The same element provoking the same behavior across many sessions is an issue.
2. **Scoring.** Pages carry a friction score against their own baseline, so "worse than normal" is measurable and a spike after a deploy points at the deploy.
3. **Verification.** After a fix ships, the same signals measured on the same element answer whether it worked, [in numbers rather than vibes](/blog/did-your-fix-actually-work).

That pipeline, signals to clusters to scores to verified fixes, is what Flusterduck automates end to end. A [free scan](/scan) runs the first pass on your site and shows what the signals say today.

Related terms: [Rage click](/learn/rage-click), [Dead click](/learn/dead-click), [Cursor thrashing](/learn/cursor-thrashing), [Navigation loop](/learn/navigation-loop)