How the product fits together

Everything starts as one recording

The SDK in your app produces a single stream of facts about a visit, and everything else in the product is a different view of that stream.

There are four kinds of fact in it.

Sessions. A continuous stretch of activity in one browser tab, identified by a sessionId. The SDK also records the DOM with rrweb as the session runs, which is what makes a session watchable later. A session rotates after 15 minutes of inactivity, or after 24 hours no matter what.

Events. Named things that happened. The SDK autocaptures the common ones ($pageview, $click, $rageclick, $deadclick, $form_submitted) and you add the ones only your product knows about, like signed_up or checkout_completed.

Errors. Uncaught exceptions and unhandled rejections, captured with the stack and the session they happened in. Similar errors are hashed into a fingerprint so they collapse into one issue.

Identity. Every visitor gets an anonymous id stored in their browser the first time they arrive. When you call identifyUser, that anonymous person becomes a named person, and their past sessions come with them.

All four share the session, which is why the product can move sideways: from an error to the replay of the session that produced it, from a visitor to every session they have ever had.

Which page answers which question

The product sidebar groups pages by the kind of question you are asking, not by the kind of data they read.

Something is broken. Start at Issues. It groups errors by fingerprint, so you see "this crash hit 40 people" instead of forty identical stack traces. Each issue links to replays of sessions where it happened, which usually tells you what the person did to trigger it faster than reading the stack.

Something is confusing. Start at Replays and watch. This is the right move when a number looks wrong but nothing errored, or when support forwards you a complaint you cannot reproduce.

Something changed. Start at the Dashboard for traffic, pages, sources, and devices over a date range, then drill into Visitors for the people behind the numbers or Funnels for where an ordered flow leaks.

You do not know where to start. Ask Home in plain language, then verify the evidence (Guide). Home queries project data and links back into the pages above when you cannot phrase the question as a filter yet.

You want this to happen without you. Agents are saved instructions with tools attached. They can run on a schedule or a trigger and report into Slack or email, which is how a recurring investigation stops being something you remember to do.

Common misconceptions

"A replay is a video." It is a DOM recording, not a screen capture. That is why it is small, why text stays selectable, and why redaction can mask a field before it ever leaves the browser. It also means a replay reflects the DOM the SDK saw, so anything rendered inside a cross-origin iframe is not in it.

"A visitor is a person." A visitor is a browser until you identify them. The same human on a laptop and a phone is two visitors, and clearing cookies makes a third. Calling identifyUser after login is what turns browsers into people.

"The session ends when the tab closes." It ends after 15 minutes of inactivity, or at 24 hours. Closing the tab drops live presence, but a person who comes back two minutes later continues the same session.

"An issue is an error." An issue is a bucket of errors that share a fingerprint. Resolving an issue resolves the group, and a new occurrence can reopen it.

"No data yet means the install failed." For errors specifically, empty is often correct: nothing has crashed. Judge the install by sessions and events in Verify, not by whether Issues has rows.

Next

Create a project and get an API key, which is the container all of this data lands in.