Session Explorer is the Motadata ObserveOps RUM workspace for sifting real browser sessions, and Saved Views stores the filters, search query, time range, and layout behind an investigation so it reopens exactly as you left it.
Session Explorer is the workspace in Motadata ObserveOps Real User Monitoring where teams sift through real browser sessions. Each session carries page views, user actions, JavaScript errors, long tasks, resource timing, and Core Web Vitals, so the volume of data to sift through grows quickly as traffic climbs.
The challenge is rarely finding data. It is returning to the exact slice of data you were looking at yesterday. Rebuilding the same filter combination, search query, and time range every morning wastes time and invites inconsistency across an investigation.
Saved Views, added in ObserveOps 8.2.5, records the full state of a Session Explorer query so it reopens in one step. Filters, queries, time ranges, and layout are preserved as a named view, which turns a recurring frontend investigation into a repeatable routine rather than a manual rebuild.
Session Explorer and Saved Views are scoped to what a real visitor experienced in the browser: page loads, interactions, errors, and vitals. When a session's activity continues into a backend service, that request-level tracing and code behavior belong to Application Performance Monitoring; RUM's role is the session itself and the correlation that connects it to that trace, never the backend trace as its own capability.
A set of filters applied across sessions can be captured as a named view, so the same segment of browser traffic reopens without rebuilding each condition by hand.
The search query that narrowed a session set is stored with the view, which keeps every reopening of the investigation aligned to the same criteria.
Each view remembers its time range, so a recurring look at the same window reloads exactly as it was defined rather than resetting to a default.
Layout choices in Session Explorer are kept with the view, so the arrangement you work in returns intact every time the view is opened.
Views are saved and named for later reuse, so a routine daily or weekly review of frontend sessions becomes a single click instead of a fresh setup.
Individual sessions can be recorded and replayed, so a saved segment leads not only to filtered data but to the recorded session itself, played back as the visitor experienced it.
Session Explorer surfaces the sequence of pages and actions a visitor took, so a saved view can be scoped to a specific journey rather than a single isolated page.
Each session's resource waterfall breaks page load performance down request by request, and that detail stays attached to whatever segment a saved view returns to.
Flame charts break down the rendering work behind a session, giving a saved investigation a way to look past the page-level number and into what the browser was actually doing.
Sessions can be examined against a conversion funnel, so a saved view scoped to a drop-off point reopens at the exact stage of the funnel under investigation.
Real User Monitoring instruments the browser to collect sessions, page views, user actions, JavaScript errors, long tasks, resource timing, and Core Web Vitals directly from each visitor across Vue.js, Angular, React, and Next.js applications. Session Explorer reads from this stream of real browser sessions.
Inside Session Explorer, filters, search queries, and time ranges narrow the session set to the segment under investigation, measured against Core Web Vitals thresholds (LCP at 2.5 seconds or less, FCP at 1.8 seconds or less, CLS at 0.1 or less, and INP at 200 milliseconds or less) and an Apdex satisfaction threshold of T=2s. When that state is worth keeping, it is captured as a Saved View that stores the filter combination, the query, the time range, and the layout together.
Opening a saved view restores Session Explorer to the exact arrangement it held when saved, so the chosen sessions, filters, and layout present themselves the same way on every return. A saved segment can also be read as a severity Flame Chart over LCP and FCP for a real-time, severity-based visual assessment with no additional telemetry configuration to set up. For sessions that trace to a backend service, RUM-APM trace correlation links the frontend session to its APM-owned trace, so investigation can continue into Application Performance Monitoring at /products/application-performance-monitoring.
Session Explorer draws its sessions from Vue.js, Angular, React, and Next.js applications, so the frontend framework behind a page does not change how a saved view behaves. A segment can be narrowed by geography, device, or network conditions, which keeps a recurring regional or device-specific investigation scoped to the audience it was built to examine.
Getting an application into that stream starts with registration, and the RUM application registration screen carries a revamped interface with settings navigation aligned to the Application Performance Monitoring registration experience, so bringing a new frontend application into Session Explorer follows a familiar path for a team already registering services in APM.
A saved view restores filters, queries, time ranges, and layout together, so picking up yesterday's analysis does not start from a blank Session Explorer.
Because the query state is stored rather than remembered, everyone reopening a view examines the same session slice, which removes drift between people and days.
Skipping the manual rebuild of filters and time ranges puts attention back on what the sessions show about the frontend experience.
Named views give a team a shared, repeatable way to check the same segments, so daily and weekly RUM reviews follow the same starting point.
A one-click return to a defined view shortens the path to the sessions that matter, so recurring frontend questions get answered sooner.
The same RUM session data behind Session Explorer feeds Custom Reports in Chart, Grid, Top-N, Counter, and Aggregation formats, and RUM policies share the same Unified Incident Declaration workflow as Log, Flow, Trap, and APM policies. A frontend finding can move from a saved segment to a recurring report or a declared incident without changing tools.
Session Explorer and Saved Views stay inside RUM's own lane: the browser session, its filters, and its recorded detail. Two adjacent capabilities extend that session outward without RUM claiming either as its own.
When a session's activity continues into a backend request, RUM-APM Trace Correlation uses W3C distributed trace context headers to link the frontend session to its APM-owned trace, so the two read as one connected timeline. The backend trace itself remains owned and monitored by Application Performance Monitoring; RUM contributes the session and the link to it.
RUM's Core Web Vitals and Apdex measurements can also be evaluated as a RUM Performance SLO with multi-metric support, but that evaluation is owned by the Service Level Objectives module, which consumes RUM's metrics rather than collecting frontend data of its own. A saved investigation in Session Explorer and a tracked SLO built on the same metrics are two views of the same session data, kept in their respective modules.
Saved Views turns Session Explorer from a tool you reconfigure each session into one you reopen. By preserving filters, search queries, time ranges, and layout as named views, and by surfacing session recording and replay, user journeys, resource waterfalls, flame charts, and conversion funnels within that same saved segment, Motadata ObserveOps lets teams return to a recurring RUM investigation instantly and keep it consistent. The effort goes into reading real browser sessions across every framework RUM supports, not rebuilding the query around them.
Discover how Motadata ObserveOps can help you monitor your infrastructure in real-time and respond to issues instantly.