> For the complete documentation index, see [llms.txt](https://docs.fullsession.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.fullsession.io/5.-sessions.md).
# 5. Sessions
The Sessions area is the heart of FullSession. Every visit to your site becomes a session you can search, filter, tag, comment on, flag, and share. This chapter covers everything *around* the recording — finding the right sessions, organizing them with your team, and getting data out. The session **player** itself (controls, panels, timeline) gets its own deep dive in \[Chapter 6 — The Session Player].
***
### 5.1 Session List & Navigation
Open **Sessions** to see your recorded visits. Alongside the full, filterable list, FullSession gives you three **curated views** so you don't always have to build a filter to find something worth watching:
| View | What it shows |
| ------------------ | --------------------------------------------------------------------------------------------------------- |
| **Worth Watching** | Sessions ranked by **frustration score** (highest first) — the most problematic visits surface to the top |
| **Recent** | The newest sessions, in reverse-chronological order |
| **Flagged** | Sessions you (or teammates) have pinned for follow-up |
#### What each row tells you
The columns shown depend on the view, but a session row summarizes who the visitor was and what happened, so you can decide whether to watch it:
| Field | Meaning |
| --------------- | --------------------------------------------------------------------------------- |
| **Visitor** | Name/email if identified, otherwise a user ID, plus *"since"* the date first seen |
| **Location** | Country and city, derived from IP |
| **Device** | Device type, with OS and browser |
| **Duration** | How long the session lasted (and active time) |
| **Date & time** | When the session started — or **Live** if it's in progress |
| **Events** | Number of recorded events in the session |
| **Pages** | Number of pages visited |
| **Signals** | Frustration indicators — Rage, Dead, Error, Thrash (see section 5.4) |
#### The frustration score
In the **Worth Watching** view, each session carries a **frustration score from 0 to 100**, calculated by FullSession from the density of frustration signals in the session (rage clicks, dead clicks, errors, thrashing, and more). Higher scores mean a rougher experience. The score is color-tiered, so the worst sessions stand out at a glance — this is the fastest way to find the experiences most in need of attention.
#### Live sessions
Sessions that are happening **right now** are marked **Live**. You can watch active visitors as they browse, which is useful for real-time monitoring during a launch or a support call.
#### Watched vs. unwatched
FullSession tracks which sessions you've already played, so it's easy to keep your place as you work through a list — sessions you've opened are marked as watched. You can also filter by watched status (section 5.2) to focus on what you haven't reviewed yet.
#### Opening a session
Click any row to open it in the **player**. Use the browser **Back** button to return to the list. Because the list uses cursor-based paging, you can scroll through very large result sets smoothly.
***
### 5.2 Filtering Sessions
You'll rarely scroll the full list. The **filter builder** lets you narrow thousands of sessions down to exactly the ones you care about — *"mobile users from Germany who had a rage click on the checkout page."* Filters are organized into categories, and most fields offer autocomplete as you type.
#### Filter categories
| Category | Filter by… |
| ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **User identification** | Any User, Email, Name, Signed-up status, User ID |
| **Events** | Any Activity, Clicked on, Error Clicks, Rage Clicks, Dead Clicks, Thrashed Cursor, Abandoned Form, Input Changed, Error Log, Uncaught Exception, Network Error |
| **Engagement** | Visited URL, Query String, Page visits, Total Sessions, Landing page, Exit page, Total Time, Total/Avg Active Time, Avg Session Length, First Seen, Last Seen |
| **Technology** | Device Type, Browser, Operating System, Is Mobile App |
| **Location** | City, Country, IP Address |
| **Performance** | Page Load Time, Avg Page Load Time |
| **Others** | UUID, Number of clicks, Screen height/width, Referrer URL, Is Live Session, Has Answered Feedback |
If your account has the **Optimizely** integration enabled, you'll also get filters for Experiment ID/Name and Variation ID/Name.
#### Operators
The operator available depends on the field type. The full set includes:
| Operator | Use for |
| ------------------------------------------------- | ----------------------- |
| **is / is not** | Exact match or negation |
| **contains / starts with / ends with** | Text matching |
| **equals** | Equality |
| **greater than / at least / less than / at most** | Numeric comparisons |
| **between / not between** | Numeric or date ranges |
#### Combining conditions with AND / OR / NOT
Filters aren't limited to simple AND lists — the builder supports **nested groups** combined with **AND, OR, and NOT**. This lets you express complex audiences like *"on the checkout page **AND** (had a rage click **OR** abandoned a form)."*
> **Tip** — your custom attributes (\[Chapter 4 — Identifying Users]) and identity fields (name, email, user ID) are all filterable here, so the data you send through `FUS.identify`, `FUS.setSessionAttributes`, and `FUS.event` becomes searchable the moment it arrives.
***
### 5.3 Sorting & Saving Filter Definitions
#### Sorting the list
Beyond the curated views, you can sort sessions by:
| Sort by | Surfaces |
| --------------------- | ------------------------------------------------------------- |
| **Frustration score** | The most problematic sessions (the default in Worth Watching) |
| **Most recent** | The newest sessions (the default in Recent) |
| **Event count** | The busiest sessions — most activity first |
Each sort can run ascending or descending; clearing the sort restores the view's default order.
#### Saving a filter you'll reuse
The session list's curated views (Worth Watching, Recent, Flagged) are built in, and the filter builder lets you assemble any ad-hoc query. When you want to **save** a filter definition to reuse across the product — in dashboards, funnels, and alerts — build it as a **Segment**. Segments are FullSession's reusable, named audience definitions and are covered in \[Chapter 11 — Segments].
> **Rule of thumb** — use the **filter builder** for a one-off question on the session list; promote it to a **Segment** when you'll ask the same question repeatedly or want to power a dashboard or alert with it.
***
### 5.4 Signals & Tags
FullSession marks notable sessions in two complementary ways: **signals** it computes automatically, and **tags** you apply yourself.
#### Automatic signals
Signals are computed from the session's own data — you don't apply them, and they're always up to date. The core frustration signals are:
| Signal | Detected from |
| ---------- | -------------------------------------------------------------- |
| **Rage** | Rapid, repeated clicking in frustration (rage-click intervals) |
| **Dead** | Clicks that produced no response (dead clicks) |
| **Error** | Clicks associated with errors (error clicks) |
| **Thrash** | Erratic, "thrashing" cursor movement |
FullSession also surfaces developer-oriented signals — **error logs, uncaught exceptions, unhandled rejections, and response (network) errors** — as well as contextual markers like **inactive periods** and **custom events**. All of these feed the frustration score (section 5.1) and are filterable (section 5.2).
### 5.5 Flagging, Comments & Watched Status
Sessions in FullSession are a shared workspace. Three features help your team triage and collaborate.
#### Flagging (pinning) a session
When you find a session worth coming back to, **flag** it (pin it). Flagged sessions collect in the **Flagged** view, stamped with the date they were pinned, so your team has a running shortlist of sessions that matter. Unpin a session to remove it from the list.
Flagging is ideal for:
* **Triage** — pin sessions that need a closer look or a follow-up.
* **Curation** — collect strong examples to share with design, onboarding, or leadership.
* **Hand-offs** — flag a session so a teammate can find it in the shared Flagged list.
#### Commenting on a session
You can leave **comments** on a session to capture what you found — a note for a teammate, a description of a bug, or context for later. Comments are tied to you as the author and timestamped, so a session becomes a small thread of team discussion rather than a silent recording. Comments can be edited and deleted by their author.
#### Watched status
FullSession remembers which sessions you've **watched**, so as you and your team work through a list, it's clear what's already been reviewed and what hasn't. Combine this with the watched-status filter (section 5.2) to focus only on unreviewed sessions.
> **Tip** — a simple team workflow: sort by **frustration score**, **flag** the sessions that need action, **comment** with what you found, and let **watched status** track your progress through the backlog.
***
### 5.6 Sharing a Session
When you find a session worth showing someone, you can share it with a link.
#### Copying a share link
1. Open the session in the player.
2. Open the **Share** option.
3. Click **Copy Session Link**.
The link points to the specific session (and can include more than one session at once). Paste it into your ticketing tool, chat, or email so the recipient can open the exact recording you're referring to.
#### Good to know about share links
* **The link opens the session directly** — there's no need to describe where to click.
* **Links are accessible to people who have them.** Treat a session link like any sensitive link: anyone you give it to can view the recorded session, so share thoughtfully — especially if the session contains customer activity.
* **Links don't carry a timestamp.** A share link opens the session from the start; it doesn't jump to a specific moment. If you want a colleague to see a particular moment, tell them roughly where to scrub to (or add a **comment** at that point — section 5.5).
* **A link relies on the session still existing.** If a session is later removed (section 5.8), its link stops working — so for anything you must keep, capture findings in a comment or your ticketing tool as well.
***
### 5.7 Exporting Session Data
When you need session **data** outside FullSession — for a spreadsheet analysis or a report — you can export it as **CSV** from a **session card on a dashboard**.
#### How to export
1. Add or open a **session card** on a dashboard (\[Chapter 9 — Dashboards]), filtered to the sessions you want.
2. Use the card's **download / CSV** option.
3. FullSession builds the CSV and downloads it.
#### What's in the export
The CSV contains the session **metadata** — visitor, date, duration, location, device, event counts, and the like — for the sessions in that card's view.
> **Notes & limits**
>
> * **Export is available from dashboard session cards**, not as a button on the main Sessions list. Build a card scoped to the sessions you want, then export it.
> * Exports are capped at **10,000 rows** — narrow your filters or date range if you need a focused set.
> * The export contains session **data**, not the **recordings**. Replays can only be watched inside FullSession.
For programmatic access to session data, see \[Chapter 20 — API & Developer Tools].
***
### 5.8 Retention & Deletion
Recorded sessions don't necessarily live forever, and a few are removed automatically because they hold little value.
#### What gets removed automatically
FullSession may remove a session for reasons such as:
* It **ended with no events** (a visit with nothing meaningful recorded).
* It matched a **deletion rule** configured for the account.
* It **expired** under the account's retention window.
This keeps your data focused on sessions that are actually worth reviewing.
#### Preserving what matters
Because some sessions are pruned over time, capture the important ones while they're available:
* **Flag** key sessions (section 5.5) so they're easy to revisit.
* **Comment** on them to record what you found — the note persists as part of your team's discussion.
* **Export** the surrounding metadata from a dashboard card (section 5.7) for a permanent record.
* Document findings in your ticketing tool, since a **share link stops working** once a session is removed (section 5.6).
> **Quota vs. retention** — two different limits affect your data. **Quota** governs how many *new* sessions you can record in a cycle (managed via plan and recording controls — see \[Chapter 3] and \[Chapter 7]); **retention/deletion** governs how long *existing* sessions are kept. Neither is something most users adjust day to day.
***
> **Next up:** \[Chapter 6 — The Session Player] opens a single session in full detail — playback controls, the event timeline, and the console, network, and error panels that turn a replay into a debugging tool.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.fullsession.io/5.-sessions.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.