Hotjar, Clarity and Analogues: What You See When You Watch People Click on Your Website

You open Google Analytics, you see conversions on the pay page drop by a quarter in a week, and you sit with screenshots of the screen like an archaeologist. The numbers are there - and exactly what went wrong is unclear. People are walking away from step five. Why? Can you see the button? Is the field not filling? Are they even scrolling to her?

Here and appear Hotjar, Microsoft Clarity, PostHog Session Replay, FullStory, Smartlook and a dozen analogues. These are tools that record user sessions and show you a movie: here's a person coming in, here's a person driving, here's a three-click in an empty space, here's a swearing and closing the tab. Analytics answers the question “what happened”, session recording – “why”.

The main thing to understand from the start is that this is not an interview replacement, not an A/B test replacement, not a silver bullet. It's a microscope. Very useful if you know where to look, and completely useless if you look anywhere.

## What you can see through these tools

All these services do plus or minus four things. Understanding the set is more important than choosing between logos.

### Records of the sessions

Video recording of mouse movements, clicks, scrolls, input into fields (with masking sensitive data). You can view a specific user from entry to exit. This is the most expensive mechanic in time - an hour of real sessions looks like an hour.

### Heat maps

Aggregate for a bunch of users: where they clicked, where they scrolled, where the mouse moved. It shows the average picture well, it shows specific scenarios poorly.

### Click Cards and Rage Clicks

Separate category: places where people hit the element 3+ times in a row, click in the non-work area, or abruptly move the mouse back and forth. It’s almost always a “something is broken or unclear” signal.

### Events and funnels based on them

Modern tools (Clarity, PostHog) are able to collect custom events and immediately show records of those sessions where the event occurred or, conversely, did not occur. This is the most powerful application – a bundle of “metrics → specific video”.

## Why is it a designer, not just an analyst

The analyst looks for anomalies in numbers. A designer looks for reasons in behavior. We have different questions.

• Why don't people click on the main button when it's the only bright one?
• Does the user get to the block we drew for three weeks?
• What does a person do between “opening the form” and “sending” – thinking, making a mistake, copying from somewhere?
• What micro-frustrations (rage-clicks, scrolls back and forth) accumulate during the session?

Mixpanel and GA do not answer these questions. The session recording takes 30 seconds.

### Typical scenarios where it pays off

• Redesigned Flow. Metrics are not moving. You look at 15 records and you see that half the people don't understand the new toggle on top.
• Conversion falls in form. Hotjar shows people getting stuck in the phone field - the mask doesn't accept the format they're entering.
• Getting ready for a review of the product. ** Instead of "I think the block below the fold is superfluous" you bring a scrolling card: it reaches it well if half.
• **Support complains about the same problem.**Filter the session by URL and see the pattern in 20 minutes instead of a month of correspondence.

## What these tools don’t do (and why they are scolded)

If you expect too much from recording sessions, disappointment is guaranteed. A few honest restrictions.

• ** They don't tell you what the user thinks.** You see action, not motivation. Recording + interview = understanding. Recording separately = hypothesis.
• They shift the sample. Free rates don't write everyone; some are blocked by the adblock and CSP; mobile sessions are recorded worse. This is not representative sociology.
• ** They create the illusion of work.** You can watch the recordings for three hours and not draw a single conclusion. Without a hypothesis, this is a series, not a study.
• **They create privacy risks. ** If you do not configure the cloak, passwords, addresses, passports and correspondence get into the record. This is not a “potential problem,” it is a legal one.

Segment summary: Recording sessions is a tool to test specific hypotheses about behavior, not a way to “see how we’re doing.” Next, we will analyze what exactly Hotjar, Clarity and others differ, how to put them without harming privacy and how to watch records so as not to drown.

## Workflow: How to Watch to Understand Something

Recording a session without a hypothesis is YouTube with poor editing. For the tool to pay off, you need a repeatable cycle: question → filter → sampling → conclusions → action. Without either of the steps, you either watch random videos or collect "insights" that no one will apply.

### Step 1. Formulate the question before opening the dashboard

Bad wording: “we’ll see how users behave on the landing page”, “we’ll look at the records for a week”. It's a show, not a job.

Good wording:

• Why did conversions in the tariff choice step drop after release?
• What do users do when they open a calculator but don’t submit a request?
• Do mobile users reach the second block with prices?
• What field do people stay on for more than 30 seconds?

The more the question is, the faster the answer will be found. The filter asks the narrow question.

### Step 2. Segment before viewing, not during

If you open all sessions in a week, you will drown. Basic slices that save hours.

• Device: Mobile/Desktop separately – different behavior.
• Paid traffic and organics behave differently, and their problems are also different.
• Duration: Sessions shorter than 10 seconds are almost always trash (failure), 10-60 seconds are the most valuable for finding frustration.
• Event: reached step N, but did not make step N+1. This is the main working filter.
• Rage-clicks and u-turn scrolls: instantly show where the pain is.

The rule that saves the day is one view, one segment. Don't mix.

### Step 3. Watch your little batches

10-15 entries on a narrow filter give a pattern. After the fifth entry, you begin to see a repetition, after the tenth, you begin to confidently formulate a hypothesis. If there is no pattern after 15 entries, either the filter is too wide or there is no problem where you are looking for it.

Run records on 1.5x-2x, rewind boring areas, stop at moments of fluctuation: cursor delay, scroll back and forth, repeat click. That's where frustration lives.

### Step 4. Fix observations, not interpretations

The difference matters. The user clicked on the word Pro three times, then went to FAQ. Interpretation: “the user does not understand the Pro tariff”. The first is a fact, the second is a hypothesis that has yet to be tested on at least three other records.

Start a simple log: a link to the session, a time code, what happened, what you assume. In two weeks, this log will be the basis for a redesign much faster than memory.

## How to apply this to the layout

Recordings are useful not only in post-factor but also before you discovered Figma.

### Before the screen redesign

• Watch 10-15 sessions of the old version of the screen you are touching.
• Write down places where people slow down, click the wrong way, scroll back.
• Check this with your “what I want to improve” list. Half of the items will fall off as irrelevant, new ones will appear.

Without it, redesign comes from taste, not behavior. And when the product asks "why did you move the blocks," the answer "so cleaner" loses to the answer "here are 8 sessions where people missed this block.".

### While working on the layout

• Keep 2-3 typical records of problematic behavior on hand. Every time you add an item, ask: Does it specifically help the people I just saw?
• A scrolling map tells you where the horizon is. The content below it only works if the user has a reason to get there.
• The click map answers the question “what they take for clickable.” If people poke an icon next to a headline, it reads like a button, even if you draw it as a decor.

### After release

• Set yourself a calendar task: 3, 7 and 14 days after the release to watch 10 sessions of new flow.
• Compare the observations to the previous log. If the old problems are gone and there are no new ones, the release is successful. If the old ones left, others appeared – normally, we fix and iterate.

## Typical mistakes that you can see right away

A few patterns that are repeated in teams and in people who have just started watching records.

• ** Watch "everything" on Fridays.** Turns into a ritual, zero conclusions. Healed by reference to the hypothesis.
• Draw conclusions from one record. One user is a joke, not a pattern. At least three repetitions of one behavior in a row, otherwise the hypothesis is weak.
• Consider a rage click as proof of a bug. Sometimes it's just an impatient user on a slow Internet. Look at the context around the click, not just the click.
• • Ignore the ones who did. ** It is very useful to watch successful sessions: you can see which path works and it is worth defending in the following iterations.
• **Present the recording as proof, not illustration. ** On the review, "Here's the video, he's suffering here" convinces, but it's still n=1. Correct: "Here's a pattern over 12 sessions, here's one expository entry.".
• **Do not touch the masking settings. ** Defaults are different in different instruments, and some of them write the contents of the fields. You need to check this with your hands on your site before you turn on the record on the sale.

## Questions for self-examination before viewing

A short checklist that is useful to run before you click play.

• Do I have a specific question that I am looking for an answer to?
• Did I choose one segment rather than all?
• Have I limited the period (the last 7 days are better than all the time)?
• Am I willing to stop after 15 records if the pattern doesn't add up?
• Do I know where I'm going to record my observations?
• I understand what action I will take if the hypothesis is confirmed?

The last point is the most important. If the answer is “don’t know” – it is better to postpone the viewing and first agree with the team what you will do with the result. This is a very expensive form of procrastination.

Intermediate summary: the work cycle is a question, a narrow segment, a small batch, recording observations, action. Everything else is background. Next, let’s see how Hotjar, Clarity, PostHog and FullStory differ, and how to choose a tool without overpaying for features you won’t use.

## Advanced scenarios: when conventional viewing is not enough

When the basic cycle “question → segment → batch → log → action” is already working, problems arise where simply scrolling through sessions is not enough. This isn’t about new buttons in Hotjar, it’s about other ways to ask questions about data.

### Segment by event, not by page

The standard error is to watch "all sessions on /checkout." “Sessions where a person clicked Apply promo but didn’t get to Pay.” Almost all tools can filter by sequence of events: you're not looking for a screen, you're looking for behavior. Then you pull 10-15 entries out of this sample, and it’s no longer “see what happens,” but a test of a particular hypothesis.

### Comparison of two segments in parallel

A useful technique: simultaneously hold two lists of records — those who converted and those who fell off at the same step. The difference is often not in the interface, but in context: new traffic vs returning, mobile vs desktop, slow connection vs fast. If you don't share that, you'll fix the design where the performance is broken.

### Bundle to funnel

The record responds to “how”, the funnel answers to “where and how much”. Individually, they lie. The funnel shows that 40% go away in step two, but doesn't explain why. The records show "he clicked into the inactive field three times," but don't say how massive it is. Working order: first, the funnel narrows the search location, then the records explain the reason, then again the funnel to check that the fix worked.

### Heatmap by segment, not by all

A click-through map of "all" is almost always useless - it averages beginners and experienced, and ends up showing "everyone clicks everywhere." The map for new users in the last 7 days is already a tool. If the filter by segment is not available on your tariff, this is a good reason to think about changing the tool, not changing the design.

## AI features: where they really help and where they interfere

Many of the tools included automatic sammari sessions and highlighting issues. Treat it like a draft of an intern: quick, sometimes useful, but check with your hands is a must.

### Where AI saves time

• Clustering of similar sessions: instead of 200 entries, you get 6 groups by type of behavior and watch 2-3 representatives from each.
• Transcript and voice search from microphone recordings (if you have moderated tests in the same tool).
• Rage-clicks, dead-clicks, U-turn-scrolls are normal as the first filter, bad as the final verdict.

### Where AI Lies and Where Not to Let It Go

• Sammari "the user did not understand the form" without specifying the timecode. This is not an observation, this is a retelling, you cannot make a decision on it.
• Autoconclusions about the "cause" of the dump. The reason you determine yourself, because only you know the context of the release, the marketing campaign and the fact that yesterday the API fell.
• Any numbers from the AI report without reference to the original sessions. If you can’t click and review, don’t quote the review.

Practical mode: AI selects candidates, the person looks and formulates the conclusion. On the contrary, it doesn't work.

## How to check that the conclusions are qualitative

Before you go with a find to the team, run yourself through a short filter.

• Have I seen the pattern in at least 3 different user sessions?
• Did I check it wasn't the same person in multiple sessions?
• I know on which device and in which browser this is played?
• Have I watched at least one successful session of the same flow for contrast?
• Can I describe an observation without the words “seems” and “as if”?
• Did I separate the observation ("scroll up and down 4 times") from the interpretation ("not find the price")?

The last point is the main source of bad decisions. Observation is verifiable, interpretation is a hypothesis and must be tested separately.

## How to explain the decision to the team

Recording a review is a powerful but dangerous tool. One video of a tormented user will sell any discussion, even if there is no data behind it.

### A format that works

1. Number one: “For 14 of the 30 sessions viewed, new users make X.”.
2. Then one short recording of 30-60 seconds as an illustration, not as proof.
3. Then the hypothesis and the proposed action - separately so that they can be discussed.
4. Then a metric to see if it helped.

### What to Avoid at a Review

• Show the record without the counter "how many such". This is manipulation, even if unintentional.
• To mount the "cutting of suffering." The team stops believing twice.
• Come only with a problem without a proposed step. Records without the next step accumulate in Notion and devalue the instrument itself.
• Argue with the developer in the spirit of “this is what you see”. You can see it because you looked at 50 grand. He didn't. Give context.

A good sign: after the review, the team does not discuss the record, it discusses which version of the fix is cheaper to check. So you did the surveillance, not the movie screening.

The intermediate result of the segment: advanced work with records is not more viewing, but narrower segments, a bundle with a funnel, careful use of AI as a draft and discipline when presenting findings. Next is the comparison of specific tools and what they make sense to pay for.

## What in the tools makes sense to pay, and what – not

When it comes to choosing a tariff or changing a tool, keep in mind that the price usually increases not for “functions”, but for the amount of traffic and shelf life. Then there are filters and integrations. Everything else is most often marketing.

### Pay for it

• The storage period of records is at least 30 days, preferably 90. Less - do not have time to associate the behavior with the release and response from support.
• Segmentation by user events and properties, not just by URL and device.
• Sampling that can be turned off or controlled. If a tool silently throws out 80% of sessions, your conclusions are built on a scrap.
• Normal Exports: Links to specific sessions that don’t die out after a week.

### Don't pay for it

• AI-insights as a separate module. If the underlying analytics is weak, the AI on top of it lies more beautifully, no more accurately.
• Endless hitmaps on every page. Got the funnel key screens.
• Questionnaires inside the product if you already have a separate tool for them. Duplication doesn't work here.

## Anti-patterns that break all work with records

These are things that seem obvious in words, and in teams they meet all the time.

• Watch the recordings "when there is time." Without a schedule, the tool becomes an expensive subscription that no one opens.
• One person looks, the rest believe the word. After a couple of months, it becomes the only carrier of knowledge about users, and its conclusions cease to be rechecked.
• Entries to the developer in person with the caption "Look how bad everything is". It's not data, it's emotional blackmail.
• Call for “just in case” sessions without question. A full inbox you'll never read.
• Draw conclusions in 2-3 sessions because they are “very revealing”. Demonstration sessions are an illustration of a pattern already found, not a source.
• Ignore recording consent and private fields. One scandal with leaked map data - and the tool is cut off entirely, along with all the benefits.

## Checklist before introducing the tool

• It is clear what specific issue we want to close in the next month.
• There is a person who is responsible for viewing and sharing finds, not “the team at all.”.
• In the markup are hidden fields with personal data, payment, passwords.
• Consent to recording is in accordance with local law and privacy policy.
• The funnel and key events are set up before the traffic accumulates, not after.
• Decided how long we store sessions and who has access to them.
• The calendar has a recurring slot to watch - at least 60 minutes a week.

## Questions for a quarterly review of the process

Once every three months, honestly answer yourself and the team:

• What decisions did we actually make for the quarter based on records? Name three.
• How many times have we opened the tool on average per week? If it's less than two, it doesn't work.
• How many problems were found before the release, and how many were stuck in the backlog?
• Which user segments have we never looked at? Why is there no data or no interest?
• Which of what we “knew” was confirmed by the records and which was not? The second is more important than the first.
• If we turn off the instrument tomorrow, what exactly do we lose? If the answer is vague, it is time to change the process, not the tariff.

## Short practical outcome

Recordings and hitmaps are neither magic nor a substitute for research. It’s a way to quickly see what a person is doing with their hands when no one is looking. The benefit comes only when there is a specific question, a narrow segment, a regular slot in the calendar, and a habit of separating observation from interpretation. Everything else is a background in which it's easy to drown and convince yourself that you're "data-driven," actually just looking at someone else's screen.

If there is one action left from the entire article, set up an hour next week to view ten sessions on one particular float and bring one observation to the team in the format of “number, record, hypothesis, metric”. Then the process will tell you what to do.