Session and error overview
Session counts, error counts and error rate over any date range, with top pages by view count and a browser breakdown, in one view.
Session Analytics
See which sessions
See which sessions
went wrong, and why.
Aggregate session counts, error rates, top pages and frustration signals from real user sessions, with a one-click path from any aggregate view into the individual session behind it.
Free tier included
No credit card
2-minute setup
Aggregate first, then the exact session.
Session analytics turns the RUM stream into an overview you can act on: how many sessions, how many hit an error, which pages they spent their views on, and which of them show signs of a user fighting the interface. From any of those you open the session itself, with its full timeline and its replay.
Frustration signals
Three or more clicks on the same element inside one second are recorded as a rage click. Filter the session list to only the sessions that show one.
Find a specific person's session
Search the session list by the user id or email address you pass to setUser, so a support ticket turns into the actual session in a few seconds.
Full per-session timeline
Open a session and see its page views, actions, resource loads, long tasks and errors in order, with the linked replay in the same panel.
Segment on collected dimensions
Filter by browser, operating system, whether the session hit an error, whether it has a replay, and whether it shows frustration. Aggregate views also segment by device type and URL.
Attach your own context
Pass a context object to addError or addAction to record your own key-value pairs against an event. It is stored for 30 days, but no screen in the product renders it yet, so treat it as data you are keeping rather than data you can read back. Send labels, not personal data.
Sessions that hurt
Go straight to the ones
Go straight to the ones
that went wrong.
The session list is filterable down to exactly the sessions worth watching: the ones that threw an error, the ones where someone rage-clicked, the ones that have a replay to watch. Each row opens the full session timeline, and from there the recording.
- Filter to sessions with an error, with a replay, or with frustration signals
- Search by the user id or email you passed to setUser
- Every row opens the per-session timeline and its replay
Sessions: errors only 1,184 matchingLIVE
MATCHING1,184
WITH REPLAY307
RAGE CLICKS212
/cart241ms
/checkout218ms
/payment134ms
/confirm102ms
No extra instrumentation
All of it from
All of it from
the RUM script.
Session analytics is built from the same RUM event stream that powers Core Web Vitals and error tracking. No separate analytics script, no second pageview call. Page views and navigations are recorded automatically; the only calls you ever have to write are the optional ones that attach your own context.
- No second script tag and no manual page-view instrumentation
- Automatic page-view and navigation tracking from the RUM script
- Optional:
setUserto identify a session,addActionto record your own event
optional custom context// identify the session
SiteQwalityRUM.setUser({
id: 'u_123',
email: 'ada@example.com',
});
// record your own event, with context
SiteQwalityRUM.addAction('checkout_started', {
plan: 'pro',
currency: 'USD',
});
// page views are recorded automatically
SiteQwalityRUM.setUser({
id: 'u_123',
email: 'ada@example.com',
});
// record your own event, with context
SiteQwalityRUM.addAction('checkout_started', {
plan: 'pro',
currency: 'USD',
});
// page views are recorded automatically
0
extra scripts: analytics rides the RUM tag
100%
of sessions counted, with no statistical sampling
30d
per-session detail retention, on every plan
$0
free tier, no credit card required to start
FAQ
No. Session analytics is built from the same event stream as RUM. If the Site Qwality RUM script is already on your site, session analytics is already collecting. No additional script or configuration is required.
Session analytics surfaces aggregate patterns (session counts, error rates, top pages, frustration signals) across all sessions. Session replay lets you watch an individual session as a video-like recording. Both are powered by the same RUM data, and you can jump from an aggregate view into a specific session replay in one click.
Not today. There is no funnel builder, no scroll-depth tracking, no time-on-page metric and no return-rate metric: the SDK does not collect the underlying signals, so nothing computes them. An earlier version of this page advertised all four, which was wrong. What exists is the aggregate overview, the filterable session list, the per-session timeline and session replay.
Partly. setUser attaches a user id, email and name to the session and the session list is searchable by id or email. A context object passed to addError or addAction is stored against that event for 30 days, but nothing in the product renders it today: no dashboard screen and no API response returns it, and the session timeline shows the event without it. Do not treat that as a safeguard. The data is stored, it is readable by anyone with database access, and a future release may surface it. Filtering or grouping the aggregate views by your own attributes is not available today either.
Aggregate session measures are kept for 458 days, a little over 15 months, on every plan including the free tier. Per-session detail (individual actions, resources, errors) is kept for 30 days, and session replays for 30 days, again on every plan. Paying more does not extend any of the three. Two of the three can be shortened, and one cannot. A retention ceiling is set per RUM application through the API and caps the 458-day measures window (settings.retention.observe_days) and the 30-day per-session detail window (settings.retention.analyze_days), down to a floor of one day, and it applies to data already stored for that application as well as to new data. Session replay is the exception. Its window cannot be shortened, and a request that tries is refused with an error naming the reason rather than quietly ignored, because the recordings themselves are expired by a separate storage rule that cannot follow a per-application setting. None of this is in the dashboard yet: it is an API call today.
Related features
Start free. No credit card.
Uptime, cron, synthetic, logs, RUM, incidents, and status pages. Free tier on every product.