Session Replay

Numbers tell you where people dropped out and not what they were doing when they did. A record showing 100 people entering a screen and 60 continuing says one thing: forty disappeared. Which field their hands stopped on, what they clicked three times, none of that is in the log. Adding events for every possible interaction doesn't fix it either, because you have to guess in advance which interaction mattered.

Pagedeck's invite screen was one of those places. Forty percent of the people who reached it left without saving anything. Noa ran a usability test, and the participants completed an invitation without trouble. The people she recruited had arrived with a work email address ready, exactly as the instructions said, which made them different from the users who were getting stuck in a way the test could not surface.

The answer came after session replay was installed and ten real sessions were watched. Users were typing a colleague's name into the email field. The error message sat below the field in small grey text, and six of them scanned the screen three times without finding it. The log didn't even record a failed save, because nobody pressed the save button.

Start by not trying to watch everything. In a product where thousands of sessions accumulate daily, playing them back in order produces no conclusion. Five steps.

1. Write down what you want to know, in one sentence. Not "review the invite screen" but "why do users who start an invitation not reach the save." That sentence decides the filter in the next step.
2. Filter which sessions to watch. Four conditions usually do it: whether the session passed through that screen, whether an error fired, whether they left without finishing, and whether they clicked the same spot repeatedly in a short window. The last one is someone hammering an unresponsive screen, which tends to mark a problem.
3. Watch ten to twenty. Skim at speed and rewind only where the hand stopped. Watching one session properly takes three to ten minutes, so without a fixed count the day disappears. Most of a session is uneventful scrolling and typing, and the useful part is the pause before it.
4. Log what you saw in a table. Session number, timestamp, one line on what happened there. When the same scene repeats in three of ten, it goes onto the problem list. A scene that shows up once may just be that person's circumstances, so the table exists to keep you from arguing from the one session you happen to remember.
5. Follow up with something that explains why. Replay only shows what happened, so the reason gets asked in a customer interview or confirmed in a usability test that puts someone through the same task.

There's a decision to make when you install it. Whatever the user types is recorded as typed, so passwords, payment details and document content have to be masked. Settle how much personally identifiable information (PII) gets stripped and how long recordings are kept, and state the collection in the privacy policy.

It fits best when users already exist and a specific screen's numbers are bad for reasons nobody can name. It also earns its place on bug reports nobody can reproduce, because you can watch the screen of a customer who doesn't remember what they clicked. A report saying it broke when I saved becomes a sequence of three specific actions.

Three situations it doesn't fit. A product with no users yet has nothing to play. Questions that need a percentage are out of reach — six stuck sessions out of twenty does not mean 30 percent. And it can't validate a design before it's built, since there's nothing recorded yet.

Four limits are worth knowing.

1. It doesn't give reasons. You can see the cursor stop; what the person was looking for at that moment stays a guess.
2. The sample skews. Heavy users generate more sessions, so watching without a filter means watching the people who are doing fine. The sessions you most need are the short ones that ended early.
3. It costs time. Twenty sessions is half a day, and what that half day buys is scenes rather than proportions.
4. Some things don't record. Embedded third-party areas and canvas-style drawing surfaces come back blank or smeared.

Questions that need a numeric answer belong to quantitative research; this method is for finding where to point at the number that came back.

"Pull twenty drop-off sessions. Where they stop is something you have to watch."

The numbers are exhausted; look at the footage.

"Six of ten sessions show the same button being clicked three times."

It repeated across people, so it's the screen rather than one person's situation.

"Mask the payment field inputs before turning replay on."

Block what must not end up in a recording, first.

Noa now goes to replay first whenever a screen's numbers look bad. A usability test takes two weeks just to recruit and seat people, while real sessions from today can be watched today. The order matters because it also changes what the test is for — she arrives with a specific hypothesis instead of an open question.

She doesn't conclude from replay alone, though. On the invite screen she formed a hypothesis from the footage, then brought in five users matching the same conditions and gave them the same task. The hypothesis about the error message held up in the room, and after the message moved beside the field in larger type, the share reaching save went up.

The most common belief is that watching more produces the answer. Recordings are piling up, so more hours ought to mean more insight. Play a hundred in order, though, and most of them are people finishing the job without trouble. What decides the outcome is the filter, not the count. Start without one and half a day later there's nothing on the list to fix, which is usually what convinces a team the tool doesn't work.

The other reading is that this is surveillance. Hearing that the screen is recorded as-is makes that a fair worry. What actually gets watched is where hands stop rather than who did what, which is why masking inputs and setting a retention limit come with the setup. Skip that configuration and the worry becomes accurate: passwords and document contents sit in the recordings, and if those leak, the loss outweighs anything the study found.