User Behavior Analytics: Spot Friction in the Browser

Last verified on Nov 8, 2026.

User behavior analytics, in a product context, means reading what people do in your interface to find friction: clicks that do nothing, flows people abandon, pages that loop, features that work for some segments and not others. Security teams use the same phrase for a different practice, spotting abnormal account activity. For that, see the security monitoring guide.

This guide covers the product side, and what you need to capture to do it with any stack.

Eight patterns worth detecting

Each one has a detailed guide where it exists:

• Repeated clicks on one element, a sign of frustration: rage clicks.
• Clicks that change nothing on screen or in the network: dead clicks.
• Actions that report success but have no effect on data, such as a save that does not stick. See lost writes.
• Funnel steps where completion falls after a release.
• Navigation loops, where users bounce between the same two pages.
• Dead ends, pages with no way forward.
• JavaScript exceptions and failed requests: client errors.
• Field performance regressions: web vitals regressions.

Add one more dimension to every one of them: segment. A bug that appears only on one browser, locale or plan tier hides inside healthy averages.

What to capture

You need a small, consistent event stream from the browser or app. At minimum: page views and route changes, clicks with a stable element identifier, form field engagement without values, network requests with status and duration, errors and a session ID. Include the release version and a coarse segment such as browser family and plan. Never capture keystrokes or field contents.

Example events for one session:

t=0.0s   route /checkout           release=web-2026.11.08.2 browser=Chrome plan=pro
t=6.2s   click button#apply-promo  target_changed=false
t=6.9s   click button#apply-promo  target_changed=false
t=7.4s   click button#apply-promo  target_changed=false
t=8.0s   fetch POST /api/promo     status=422 ms=210

Three clicks, no visible change, one 422. The promo button is broken for this input.

Detect it step by step

1. Rage clicks: count clicks on the same element by the same session within a short window. Three or more clicks within two seconds is a reasonable starting definition.

-- Example: elements with the most rage-click sessions today
SELECT route, element, count(DISTINCT session_id) AS sessions
FROM (
  SELECT route, element, session_id,
         count(*) OVER (PARTITION BY session_id, element
                        ORDER BY ts RANGE BETWEEN INTERVAL '2 seconds' PRECEDING AND CURRENT ROW) AS burst
  FROM click_events
  WHERE ts >= current_date
) c
WHERE burst >= 3
GROUP BY route, element
ORDER BY sessions DESC
LIMIT 20;

2. Dead clicks: a click followed by no DOM change, navigation or request within a short time. Record a flag when the click happens, since reconstructing it later is hard.
3. Funnels: compute step-to-step conversion per release and per segment. Alert when a step drops by a set number of points against the previous release.
4. Errors per session: the share of sessions with at least one error, by route and release.
5. Vitals: web.dev recommends measuring at the 75th percentile of page loads, segmented by mobile and desktop, and treats an Interaction to Next Paint of 200 milliseconds or less as good responsiveness.

Thresholds and pitfalls

• Compare release to release, and segment to segment. Absolute click counts mean little.
• Count sessions, not events, so one frustrated user does not look like a trend.
• Legitimate repeated clicks exist: increment buttons, games, pagination. Allowlist those elements.
• Funnels move with traffic mix. A campaign that brings in low-intent visitors lowers conversion without any bug. Split by acquisition source.
• Bots click in patterns no person does. Filter them out before you read behavior metrics. See bots and scraping.
• Small segments produce noisy ratios. Require a minimum number of sessions.

What to do when it fires

Reproduce it using the same browser, route and release. Replay the event stream to see what the user did. If the cause is a code change, roll it back or flag it off. If it is a design problem, such as a button that looks active but is disabled, file it with the evidence attached.

Where Sazabi fits

Of this group, Sazabi detects client errors today: JavaScript exceptions, failed fetches and hydration errors, for every production project with no setup. See the frontend breakage detection page. The frontend breakage guide covers the engineering side, and PostHog is one analytics source that can feed this data.