Skip to content

Product

Session Replay vs Analytics: When to Use Which

Funnels tell you where users drop, heatmaps show what a crowd does on a page, and replay shows why one person did what they did. When each wins.

Published · Updated · 6 min read

Product analytics, heatmaps and session replay all claim to explain user behaviour, and teams often buy one expecting the other. They answer different questions. This post lays out what each is good at, where replay is the wrong tool, and how the three fit together — so you spend your review time on the sessions that matter and your dashboard time on the numbers that do.

Three tools, three questions

ToolQuestion it answersUnit of analysisBlind spot
Product analytics (funnels, retention, events)How many? Where? Which segment?Thousands of usersWhy any one of them did it
HeatmapsWhat does a crowd do on this page?One page, many visitsOrder, context, individuals
Session replayWhat did this person see and do?One sessionWhether it generalises

The columns are the point. Analytics aggregates; replay does not. Neither can substitute for the other, and a team that tries to answer "how many" by watching sessions, or "why" by staring at a funnel, will be slow and wrong.

Where analytics wins

Anything you need to measure, trend or compare. Conversion rate after a redesign. Whether the new onboarding improved week-two retention. Which acquisition channel produces users who stay. Which step of checkout loses the most people. These are statistical questions with statistical answers, and a funnel with a few thousand users in it beats any number of individually watched sessions. Replay cannot tell you a conversion rate; it can only show you conversions.

Analytics is also cheap to keep on for everyone. An event is a few bytes; a recorded session is kilobytes to megabytes. If you can express the question as an event, express it as an event.

Where heatmaps win

Layout decisions on a single high-traffic page. Do people see the call to action below the fold? Is anyone using the secondary navigation? Where do clicks land that are not on links — which reveals things people think are clickable? A heatmap compresses hundreds of visits into one image, which is exactly right for a landing page or a pricing page and exactly wrong for a multi-step flow, where the interesting behaviour is the order of events, not their density.

Heatmaps get a post of their own: heatmap vs session replay covers click, move and scroll maps, what they hide on single-page apps, and how to use both.

Where replay wins

Replay is the only one of the three that shows a specific experience as it happened. That makes it the right tool for four kinds of question.

  • Why did the funnel drop here? Say your funnel shows a sharp drop on the address step. Replay can show the postcode validator rejecting valid Irish postcodes and users retyping them three times before giving up. A rage click flag on the session takes you straight to the moment.
  • What happened in this ticket? A user says the export "does nothing". Their session shows the button turning into a spinner and the spinner never stopping, on a page with a JavaScript error flagged in the chunk. Customer support teams use this daily.
  • Is this bug real, and how do I reproduce it? Intermittent bugs are the ones that never reproduce on a developer's machine. A replay is a reproduction script written by the user. QA and bug reproduction goes deeper.
  • What does the product feel like in a market I do not live in? Watching sessions from a new country is the closest thing to a usability study you can run for free — especially when the session is translated into a language you read.

Replay is also the right tool when you do not yet know what to measure. A new feature has no funnel until someone decides what its steps are; the first fifty sessions tell you what those steps should be.

Where replay does not win

Be honest about the limits, because a replay tool sold as an analytics tool disappoints everyone.

  • It does not scale to "everyone". A human watches sessions one at a time. You will never watch all of them; you need something — flags, filters, a ticket, a funnel — to pick which ones.
  • One session is an anecdote. Three users struggling with a button is a lead, not a finding. Confirm with a number before you redesign.
  • It is not a substitute for talking to users. Replay shows what they did, never what they wanted.
  • It costs more per user than events. Sampling (sampling rate below 1) and short retention keep it proportionate; AnyReplay keeps sessions for 14 days by default.
  • It carries privacy weight that events do not. A recording is personal data. Masking, consent and retention are not optional; see privacy.

How the three fit together

The workflow that works looks like this: analytics finds the where, replay finds the why, and the fix goes back into analytics to prove it worked.

  1. A funnel or a retention chart flags a step that is worse than expected.
  2. Filter sessions to that step — and, if your tool records them, to sessions with errors or rage clicks on it. AnyReplay flags both on the chunk at record time.
  3. Watch five to ten. Patterns show up fast; if they do not, the problem is not in the interface.
  4. Ship the fix. Watch the funnel move. Stop watching sessions for that step.

This is also why replay does not need to be attached to a full analytics suite to be useful. Your funnel can live in whatever product-analytics tool you already have; replay only has to be findable from a ticket, a user id or a flag. AnyReplay's identify call attaches a user id and email to sessions so support can find a session from a ticket (user identification); everything else is filtering.

What replay adds on mobile

Mobile analytics is mature; mobile replay mostly is not, because most tools capture screenshots and screenshots are expensive, unmaskable after the fact and unreadable by machines. AnyReplay records the committed React Native element tree instead — a wireframe with real text — which makes it cheap enough to leave on and translatable like a web session. For a team whose product is a React Native app, that is often the first time "why" has been answerable at all.

A rule of thumb

If the question has a number in it, use analytics. If the question has a page in it, consider a heatmap. If the question has a person in it — this user, this ticket, this bug — use replay. And if you are choosing a replay tool, choose it for how quickly it gets you from a number to the right session, how safely it handles what it records, and whether you can actually read what you are watching. What is session replay covers the mechanics; session replay for product managers covers the workflow. The Free plan — one project, 500 sessions a month — is a reasonable size for a first experiment; see pricing.

Frequently asked questions

Does session replay replace product analytics?

No. Analytics measures aggregates: how many, where, which segment. Replay shows one session in full. Most teams use analytics to find a problem step and replay to understand why.

Is a heatmap the same as session replay?

No. A heatmap aggregates clicks or scrolls from many visits to one page into an image. Replay shows an individual session in order, across pages.

How do I decide which sessions to watch?

Start from a signal: a funnel step, a support ticket, a user id, or flags such as errors and rage clicks. AnyReplay marks errors and rage clicks on the recording as it happens.

Do I need to record every user?

Usually not. A sampling rate below 1 records a fraction of visitors, decided once per visitor, and short retention keeps storage proportionate.

Start free — 1 project, 500 sessions a month

Install the snippet, record a session, and watch it back in your own language.