Sessions and replay

The Sessions page is where you stop looking at totals and start looking at single visits. The Overview page tells you how many people came. Sessions lets you look at one person at a time: how long they stayed, which pages they opened, what device they used, and where they came from. Then you can open any visit and watch a replay, a video like rebuild of what that visitor actually saw and did on your site.

Think of the Overview as a weather report for your whole site, and Sessions as stepping outside to watch one person walk down the street. Both are useful. When a number surprises you or someone reports a problem, watching a real visit is often the fastest way to understand what is really going on.

What you see

The page has two parts: the list of visits, and the replay you open from it.

The list of visits shows one row per session. A session is one visit. For each visit you see the key facts at a glance:

How long the visit lasted, shown as a time like “3m 42s”.
How many pages the visitor opened during the visit.
The device they used, such as desktop, tablet, or phone.
The country the visit came from.
The source, meaning where they came from, such as a search engine, a link on another site, or a direct visit (someone typing your address or using a bookmark).

When you open a single visit, you get the replay view. This is the heart of the page.

A player in the middle that looks and behaves like a video. You press play and watch the visit unfold: the pages loading, the mouse moving, clicks landing, the page scrolling up and down, and the visitor moving from one page to the next.
Anything the visitor typed is kept hidden. Text in form fields, search boxes, and password boxes is masked, so you see that they typed something and where, but never the actual characters. This is on by design to protect your visitors privacy. You get the behavior without the private content.
A side inspector next to the player. It shows two kinds of technical detail that happened during the visit, lined up with the replay as it plays:
- Console messages, which are the notes and errors your website prints behind the scenes. A red error here, at the moment a visitor clicked a button, is a strong clue about a bug.
- Network activity, which is the requests your site made to load data or send it, such as fetching products or submitting a form. A failed request lined up with a stuck moment in the replay often explains the problem.

A “replay” is not a real video recording of the person’s screen. It is a faithful rebuild from the small, privacy safe signals your site sends, played back so it looks like a video. That is why it stays light and never captures the actual text people type.

How to read it

Start with the list, narrow it to the visits you care about, then open one and watch.

Here is a worked example. Say a customer emails you: “I tried to buy and the page just froze after I clicked Pay.” You want to find and watch that exact visit.

Open Sessions and set the date range to the day they wrote in, say the last 24 hours.
Scan the list for a visit that matches. You might filter to their country, or look for a visit that opened the checkout page and lasted a while before ending. Say you find a visit from their country, 4 pages, 5m 10s, from a search source.
Open that visit and play the replay. You watch them browse, add an item, reach checkout, and click Pay. The replay then sits still.
Look at the side inspector at that moment. You see a red console error and a network request that failed right when they clicked Pay.

What does this tell you? The freeze was real, and it happened at the payment step because a request failed and the page threw an error. You now know which step broke and you have the technical detail to fix it, all from watching one real visit. Without the replay, you would only know that someone left the checkout page, not why.

Reading sessions is detective work. The list helps you find the right visit, and the replay plus the inspector show you what happened, second by second.

Customize it

You control which visits you see and how the replay plays. Here is each control and when to use it.

Filter by website. If you track more than one website, narrow the list to a single site so you only see its visits. Use this when a report or a problem is about one specific site and the others are just noise.
Set the date range. Use the calendar to pick the period, such as the last 24 hours, 7 days, or a custom start and end day. Use a short range when you are chasing something that just happened, like a bug reported this morning. Use a longer range when you are looking for a pattern across many visits.
Filter by a single visitor. Narrow the list to just one visitor so you can follow only their visits over time. Use this when one person reported an issue, or when you want to see everything a single visitor did across several visits instead of one.
Playback speed. Speed the replay up or slow it down. Speed it up to skim a long visit quickly and find the interesting moment. Slow it down to study a tricky few seconds closely, like the exact order of clicks right before something broke.
Skip inactivity. Turn on skip inactivity to jump over the quiet stretches where nothing happened, for example when the visitor paused to read or stepped away. Use this to get through a long visit fast without watching dead time. Turn it off when those pauses themselves are interesting, such as a visitor hesitating for a long time on one screen.

Use cases

Reproduce a reported bug. A visitor says something broke. Set the date range to when they wrote in, find their visit in the list, and open the replay. Watch up to the moment it failed and read the side inspector for a console error or a failed network request. Action: once you see the error lined up with the broken step, hand that detail to whoever maintains the site so they can fix the exact cause, not a guess.
Understand a rage click spot. You noticed people clicking the same thing over and over in annoyance. Find a few of those visits and watch the replays around that spot. Action: if people keep clicking something that looks like a button but is not a link, make it an actual link or change how it looks, then watch new visits to confirm the annoyance is gone.
Watch a confused first time visitor. Filter to visits from a new source, like a fresh ad, and open a few replays. Watch where first timers hesitate, scroll back and forth, or leave. Action: if new visitors keep missing your main call to action, move it higher or make it clearer, then watch the next batch of new visits to see if they find it faster.

Tips

Use the list to find, use the replay to understand. The list narrows you down to the right visit fast. The replay and the inspector tell you the why. Trying to understand a problem from the list alone usually is not enough.
The inspector is your best friend for bugs. A red console error or a failed network request lined up with the exact moment things went wrong is often the whole answer. Always glance at the inspector when a replay sits still or jumps.
Speed up and skip inactivity to save time. Most of a long visit is uneventful. Skim at high speed with quiet gaps skipped, then slow down only for the few seconds that matter.
Remember that typed text is always hidden, on purpose. You will never see what a visitor typed into a form or a search box, only that they typed. This protects your visitors and is working as intended, not a missing feature.
A brand new site has few or no visits to watch yet, and replays take a little time to be ready after a visit ends. If the list looks empty on a fresh site, give it some real traffic and a few minutes. An empty list on day one is expected, not a fault.