How to Triage UX Problems at Scale With FullStory's Frustration Signals

FullStory's automatic frustration detection is genuinely useful for finding problem sessions without watching recordings at random - see our session replay and heatmap tools comparison if you're still deciding between FullStory and a lighter alternative. What it doesn't do automatically is tell you which of the flagged sessions actually matter, or why the frustration happened in the first place. This guide covers a triage workflow built around FullStory's Sentiment Signals, segments, and Ask StoryAI that turns a growing queue of alerts into a short list of problems actually worth fixing.

Step 1: Know the Four Signals FullStory Flags Automatically

FullStory's Sentiment Signals automatically detect four specific frustration patterns in session replay: rage clicks (clicking or tapping rapidly, multiple times, in the same area), dead clicks (a click that triggers no visible response), error clicks (a click that coincides with a JavaScript error), and thrashed cursor (rapid, erratic mouse movement often associated with confusion). Each points at a different kind of problem - rage and dead clicks suggest something didn't respond the way a visitor expected, error clicks point more directly at an actual code failure, and thrashed cursor often signals a visitor who's lost or hesitating rather than reacting to a specific broken element. Knowing which signal you're looking at before investigating narrows down what kind of cause to expect.

Step 2: Start From the Default "Rage Clicked Recently" Segment, Not an Individual Session

Rather than reviewing flagged sessions one at a time as they appear in a feed, start from FullStory's default "Rage clicked recently" segment in the sidebar, which groups every session containing a rage click over a recent time window. Reviewing the segment as a whole, rather than session by session, immediately shows you volume and gives you a starting point for spotting which specific elements are generating repeat flags versus which only triggered once.

Step 3: Build a Custom Segment Around a Specific Element Once a Pattern Emerges

When the default segment reveals multiple sessions flagging the same button, form field, or page, build a custom segment filtered to exactly that element and frustration type. This turns a vague "we're getting rage clicks somewhere" signal into a precise, answerable question: how many sessions, over what window, hit a rage click on this specific element, and is that count growing or flat. A segment with a climbing count over the past week is a materially different priority than one that spiked once and hasn't recurred since.

Step 4: Cross-Reference the Segment Against Where It Sits in the User Journey

Before prioritizing by raw session count, check where the flagged element actually sits in your funnel. A rage click with fifty flagged sessions on a rarely used settings page is a smaller problem than one with ten flagged sessions on a checkout or signup step, because the second is sitting directly in a path tied to revenue or conversion. Pull up funnel or path analysis alongside the segment to confirm whether the flagged element sits on a step most visitors pass through or a rarely visited corner of the product, and weight your triage priority by that context rather than by session count alone.

Step 5: Watch a Handful of Full Sessions Before Concluding Anything

Once a segment looks worth investigating, actually watch several of the sessions inside it end to end, not just the few seconds around the flagged click. Look at what the visitor did immediately before the frustrated clicks, whether the element visibly changed state in response, whether a network request was stalling in the background, and whether the same behavior repeats consistently across sessions or varies from one to the next. It's worth watching sessions from more than one device type and browser while doing this, too - a rage click that only shows up on a specific mobile browser points toward a rendering or touch-target issue that a desktop-only review would never surface, and conflating the two can lead to a fix that solves the problem on one platform while leaving it completely untouched on the other.

A consistent pattern across multiple sessions points toward a real, fixable cause; inconsistent behavior across sessions flagged under the same label suggests the automatic detection is catching several unrelated things under one signal name, and the fix (if there is one) will need to be scoped more narrowly than "fix the rage click on this button."

Step 6: Use Ask StoryAI to Speed Up the First Pass, Not to Replace It

FullStory's Ask StoryAI can summarize what happened in an individual session, including its frustration signals, and when run against a full segment it can summarize patterns across every session in that group at once. Use this to get oriented faster before manually reviewing sessions, especially when a segment contains more sessions than you can realistically watch individually. Treat the AI summary as a faster first pass rather than a finished diagnosis - it's describing the same symptom-level behavior a human reviewer would see, and the judgment call about the actual underlying cause still benefits from watching at least a few of the sessions directly rather than relying on the summary alone.

Step 7: Rule Out Known False Positives Before Treating a Signal as Reliable

Some UI patterns naturally produce rapid repeated clicks as part of normal use rather than genuine frustration - pagination controls, carousel navigation, and multi-step form steppers are common examples. Before investing time triaging a segment built around one of these elements, watch two or three sessions specifically to confirm the clicking pattern actually reflects frustration rather than a visitor simply moving through content quickly. Skipping this check on a high-traffic navigational element can waste a disproportionate amount of triage time chasing a signal that was never a real problem.

Step 8: Track Whether a Fix Actually Reduced the Segment, Not Just Whether It Shipped

After shipping a fix for whatever caused a segment's frustration, don't close the investigation there - return to that same custom segment a week or two later and check whether its session count has actually dropped. A fix that addressed a cosmetic symptom rather than the real cause will often show the segment's volume holding steady or barely moving, which is the clearest signal that the original diagnosis in Step 5 was incomplete and needs another pass before the issue can be considered resolved.

Step 9: Give the Triage Process an Owner, Not Just a Dashboard

A frustration-signal queue that anyone can glance at but nobody is explicitly responsible for working through tends to sit unreviewed until something external forces attention to it - a support ticket spike, a drop in conversion that gets noticed in a weekly report. Assign ownership of the segments and the review cadence to a specific person or team, with a defined expectation for how often new segments get checked and how quickly a climbing one gets escalated. This matters more as session volume grows, since the gap between "the data exists" and "someone looked at it" is exactly where automatic detection's value gets lost if nobody's job includes acting on it.

A Note on Privacy Settings Before Scaling This Across a Team

Before giving a wider team access to session replay and the segments built from it, confirm FullStory's privacy and masking settings are configured correctly for any sensitive fields - payment details, personal information entered into forms - since session replay captures what's visibly on screen by default. Role-based privacy controls exist specifically so that a broader team can review sessions and segments without exposing data that shouldn't be visible outside a smaller, more restricted group. Checking this once during setup is far simpler than discovering a gap in masking after a wider team has already been granted access to session data.

If you're still deciding whether FullStory's depth is worth the cost over a lighter session replay tool, our session replay and heatmap tools comparison and FullStory tool profile cover where that trade-off tends to land.