Session replays with AI assessment: watch the friction, then have it graded

What is recorded, and what never is

Recording uses rrweb with all inputs masked by default. On top of that, any element given the block class or selector is excluded from the recording entirely, and any element given the mask class has its text masked. Canvas recording and font collection are off.

The practical result is a replay you can show a client: the layout, the scrolling, the hesitation and the clicks, without the card number, the ID number or the password. Do-not-track is respected, admin and sign-in paths are skipped, and sampling rules control what proportion of traffic and which paths are captured at all.

• All form inputs masked as a default, not an option
• Element-level block and mask classes for sensitive regions
• Do-not-track respected; admin and authentication paths excluded
• Path, campaign and sample-rate rules decide what records

Meaningful events, not just mouse noise

Alongside raw rrweb events, the recorder emits custom markers: navigation, page view, form start, form submit, rage clicks and long dwell. Rage clicks are detected as three or more clicks within a second in the same small area, the strongest single signal that something on the page looks clickable and is not.

Server-side, each session is summarised into visited URLs, click count, rage-click count, input changes, scrolls, captured errors and duration. That summary is what makes both the AI assessment and the reporting cheap to run.

Efficient capture, sane storage

Events are buffered and flushed every five seconds or every 500 events, compressed in the browser where supported, and sent as chunks with a hard per-chunk size ceiling. On tab hide or page unload the remainder is sent by beacon, so the end of a session is not lost.

Event data lives as compressed chunks in object storage, while session metadata lives in Postgres: device, browser and operating system family, viewport, referrer, campaign parameters and click identifiers, entry and exit URL, duration, event and chunk counts, and a hashed visitor address rather than a raw one. Retention and per-session byte caps are settings, not code changes.

The AI assessment, and its guardrails

For a single session, the summary and metadata are sent to a model that returns schema-validated JSON: a headline, friction points, likely intent, suggested changes and a severity of low, medium or high. That result is stored on the session with a timestamp so it is generated once and read many times.

Across many sessions the design is stricter, and this is the part worth reading twice. The funnel, how many sessions reached each step, how many dropped from the previous step, and the percentages, is computed in SQL. The model is explicitly forbidden from producing any number at all. It clusters issues, picks which funnel step each issue belongs to and which computed metric applies, and the real number is then substituted into its output by code.

So the narrative is AI and the arithmetic is the database. You get prioritised, plain-language findings that are safe to forward to a client, because no figure in them was ever generated by a language model.

Playback and reporting around it

Sessions play back in the browser with a scrubbing controller, alongside a derived action timeline of clicks, filled fields and navigations where each entry seeks the player to that moment. Journeys are classified deterministically from URL patterns, so pricing exploration, checkout and support paths can be filtered without an AI call.

Reporting covers session volume, average duration and top paths over a rolling window, with comparison and diagnostic views for funnel work, plus per-admin watched flags and notes so a team can review a set of sessions without duplicating each other's work.