Live Sessions

Audience: Sales · Support · QA · Engineering · Management · Where in app: Live Sessions (/live-sessions) · Plan availability: All plans (live-session view count is metered — see Plan & limits)

Live Sessions is the real-time view of everyone on a customer's website right now. Each row is one active visitor: the page they're on, how long they've been browsing, who they are (if we know), their lead score, and their location. An admin can watch the visitor's screen as it happens, start a chat, place a call, or just monitor. It's the surface sales and support teams live in when they want to catch a hot visitor mid-visit instead of chasing them afterwards.

What it does

• Lists every visitor with an active session, updating automatically as people arrive and leave.
• Shows, per visitor: current page URL + title, time on page, total time on site, pages visited, country/city, device + browser/OS, traffic source, IP, and the running lead score.
• Resolves identity inline: a verified visitor shows their name; an anonymous visitor whose network resolves to a known company (via B2B enrichment) shows the company name instead of "Guest User"; an unconfirmed match shows a Suspected badge.
• Lets an admin watch the screen in near-real-time (rrweb live mode), start a chat, start a call, or jump straight to an existing conversation.
• Flags bot traffic (Suspected Bot / Confirmed Bot) so teams don't waste time engaging crawlers.

How it works

The widget streams rrweb DOM events to ms-sessions over Socket.IO, keyed by company_id + user_session_id. While the visitor is browsing, the session's recording_status is active and they appear on the live list.

Recording lifecycle (session_files.recording_status):

Status	Meaning
active	Visitor is still on the site — appears in Live Sessions
finalized (a.k.a. stale)	Visitor left or went idle; queued for analysis
analyzing	The recording-analysis worker has the job
analyzed	Replay + analysis available in Recorded Sessions
failed	Analysis errored — see retry/error

Live replay. Clicking a row opens a player in rrweb "live" mode — the same DOM event stream that later becomes the recording, rendered as it arrives. The dashboard uses frontend/src/components/SessionPlayer/ with useLiveReplayer. There is no extra capture cost; live and recorded replay share one stream.

Presence. "Who is live" is answered from a cross-pod Redis registry (session_tabs:{user_session_id}, ~90s TTL, renewed every ~30s) so any ms-sessions pod can answer the question. This is the same presence layer ms-communication and Nox read. See ms-sessions › Presence and Session Recording.

Identity resolution on the list. Names come from the identity graph. If the visitor is verified, their name shows. Otherwise the row shows "Anonymous visitor" / "Guest User" with whatever signals exist (location, source, current page) — or a resolved company name if B2B enrichment matched their IP. See Lead Intelligence.

Multi-tab tracking. A visitor with several tabs open on the site shows all open tabs under one session entry — handled automatically via the presence registry.

Real-time per-session stats: current URL + page title, time on current page, total time on site, pages visited this session, country/city, device type, any active chat/call, and the running lead score.

Configuration & options

Setting / field	Where	Effect
SubscriptionModel.remaining_live_session_views	Subscription / plan	Meters how many distinct live sessions can be watched per period. Each unique session viewed counts once. Higher tiers are effectively unlimited. (verify exact per-tier numbers)
take_over_permissions	Company config	Gates whether an admin may call-in to a live visitor (verify exact key name)
Verified badge	Account-level toggle	Whether the Verified badge renders on rows. If not visible, it's off for the account
Bot detection	Automatic	No configuration; Suspected/Confirmed Bot badges appear automatically
iframe companion script	Customer site	Enables recording to span an embedded iframe the customer controls (see edge cases)

For QA/support: a visitor not appearing live almost always means the widget isn't streaming (script missing, blocked, or socket failing) — check that the widget is installed and the session shows recording_status: active.

Behaviors & edge cases

• Verified vs Suspected. A Suspected (amber) badge means the identity graph thinks it recognises the visitor by IP, device, or both, but they haven't confirmed it this visit. It is a hint, not a fact — do not greet the visitor by that name. A Verified badge means the AI is working with full cross-session history.
• Anonymous company resolution. "Acme Corp" appearing instead of "Guest User" comes from reverse-IP B2B enrichment (Snitcher, with Apollo for person-level) — it identifies the network/company, not necessarily the specific person. Naming tiers: self-provided → suspected → Apollo person → Snitcher company (business type) → Snitcher domain (⚠, non-business). See Lead Intelligence caveats.
• Consent gating. For tenants with consent gating enabled, the loader doesn't initialize rrweb/live-view (behaviour category) until the visitor consents — a non-consented visitor cannot be watched live; a mid-session grant starts capture forward-only.
• Location source. City/country comes from B2B company data when available, falling back to IP geolocation; the source is tagged so a confident company HQ can be told apart from a best-guess IP lookup.
• Privacy / masking. Password fields and inputs marked data-rrweb-block are masked. Cross-origin iframes are not captured unless the iframe companion script is installed. Recordings are tenant-isolated.
• Nox can now force an engage. Beyond reporting on live presence, Nox/admin can push an auto-engage message to a live visitor (server-pushed via ms-communication's nox-auto-engage-message socket); it bypasses the widget's heuristic auto-trigger suppressors, but hard blockers (tab hidden, user interacting, call in progress) still apply.
• Mobile. Mobile sessions render via live_session_for_mobile.js (touch events, orientation). A desktop admin can still watch them.
• Tab close detection is best-effort — a session may linger as active briefly after a visitor leaves until idle/finalization kicks in.

Plan & limits

• Live Sessions is available on all plans, but watching a live session draws down remaining_live_session_views for the billing period; higher tiers are unlimited. (verify per-tier view allotments)
• Call-in from a live session depends on call permissions/availability for the account.
• B2B company resolution on anonymous visitors requires Lead Intelligence enrichment, which has its own plan gating and budget — see Lead Intelligence › Plan & limits.

Technical implementation

• Service: ms-sessions — LiveSessionController, KnoxPresenceController (presence snapshot/visitor endpoints), SocketService (rrweb buffering).
• Collections: user_sessions (session lifetime, current URL, nested lead_score), session_files (recording_status, chunk metadata). SubscriptionModel holds remaining_live_session_views.
• Presence: Redis session_tabs:{user_session_id} registry; exposed via GET /internal/knox/presence/snapshot and /internal/knox/presence/visitor.
• Frontend: LiveSessionsView + frontend/src/components/SessionPlayer/ with useLiveReplayer.
• Nox tool: knox-presence returns a live snapshot (concurrency, top countries/pages, identified-vs-anonymous, score distribution); per-visitor entries now include person_id (verified preferred) and a resolved display_name (KnoxPresenceController).
• Subsystems: Session Recording, Identity Graph.

Related

• Recorded Sessions — replay and search past visits
• Per-Session Signals — what gets extracted from a recording
• Lead Scoring — the score shown on each row
• Lead Intelligence — anonymous → company resolution
• ms-sessions · Session Recording · Identity Graph