Main: SessionSight

Updated

Main: SessionSight

Overview

Use this page to understand what SessionSight captures and what you can do with it. The SessionSight overview is the informational front door for the web analytics and session replay area, sitting in the Main section of the navigation menu alongside the other module overviews. It draws the moving parts as one diagram, sequences the work as a lifecycle, and links into the pages where each piece is configured.

SessionSight answers the question "how is it actually used and experienced?". Everything else in the platform is synthetic: you decide what a simulated user does. SessionSight is the opposite, capturing what real visitors do on your web application, from aggregate traffic down to a replay of one individual session. The business value is twofold. It closes the loop on user experience, letting you watch the session behind a complaint instead of reconstructing it. It also closes the loop on testing: the Journeys wizard mines real navigation paths and exports them as LoadGen scripts, so your load tests reproduce the journeys your visitors genuinely take rather than the ones you assumed.

SessionSight is an optional, web-only module. On the platform map it is drawn as an optional telemetry flow, because the rest of the platform works without it. This page changes nothing and requires no configuration to open, and the capability cards lead to pages that keep their own licence and role gates.

Main: SessionSight, full page

Key concepts

  • Tenant and container - The two levels of scope. A tenant owns the analytics configuration; a container is the tracked property within it. Every SessionSight page is read in the context of a selected tenant and container. (related: Configuration: SessionSight: SessionSight)
  • First-party tracking - SessionSight is first party by default, meaning the tracking is served from your own property rather than a third-party domain.
  • Masking posture - The setting that controls how much of a captured session is recorded versus obscured, so sensitive fields are not stored in a replay. (related: choose the posture before capture begins, since it governs what is written)
  • Session replay - A playback of one visitor's recorded interactions, used to see exactly how someone navigated a flow or hit an error. (related: SessionSight: Replay)
  • Journey - A common navigation sequence discovered from recorded page-view sessions, exportable to LoadGen Script (.lgs) format so it can be run as a load test. (related: SessionSight: Journeys)

When to use it

  • When you want to know how real visitors use your web application, not how you assume they do.
  • When a user reports something you cannot reproduce and you want to watch the actual session.
  • When you want your load tests to reflect real navigation paths and need to know how to get from captured sessions to a script.
  • When you are evaluating what SessionSight records and need to understand the masking postures before enabling capture.
  • When you want to see where funnels, heatmaps, attribution, and GA4 fit relative to raw session data.
  • When you want a launch point into the SessionSight dashboard, visitors, replay, heatmaps, funnels, journeys, attribution, or insights.

Before you begin

  • No prerequisites for opening this page. It is informational and ungated.
  • Using the module requires the SessionSight licence module (LG056). Without it, the SessionSight pages show an activation card instead of the feature. Check your entitlement on Infrastructure: Licensing.
  • SessionSight is web only. It does not capture Citrix, RDP, or Azure Virtual Desktop sessions; use end-to-end monitoring for those.
  • A tenant, a container, and a datasource must be configured on Configuration: SessionSight: SessionSight, and the tracking must be live on your application, before any page here shows data.
  • Decide the masking posture and retention before capture starts. The page names three postures, Strict, Balanced and Relaxed (inputs are masked at the source, in the tracker tag). These govern what is written, so they cannot be applied retroactively to sessions already recorded.

Steps

Step 1

Open SessionSight in the Main section of the left navigation menu.

Expected result: The overview page opens immediately, with the architecture hero at the top. It renders whether or not SessionSight is licensed or configured.

Step 2

Read the architecture hero.

The diagram shows tracking on your web application sending events to the platform, scoped by tenant and container, and the analysis surfaces that consume them: dashboards and visitor profiles, session replay, heatmaps, funnels, attribution, and the Journeys export back into load testing. Quantities drawn inside the diagram are illustrative and prefixed e.g.; they do not read your configuration.

Main: SessionSight, architecture hero

Main: SessionSight, lifecycle strip

Step 3

Follow the lifecycle strip.

The strip lays SessionSight out as six ordered steps. The underlying chain, as documented across the SessionSight pages, is:

  1. Create the tenant and container. Configure analytics scope, API keys, goals, funnels, retention, and scheduled tasks on Configuration: SessionSight: SessionSight.
  2. Set the capture posture. Choose masking and retention before enabling capture, so sensitive data is never written.
  3. Instrument the application. Put the first-party tracking in place so real sessions start arriving.
  4. Read the aggregate. Use SessionSight: Dashboard for KPIs, realtime visitors, and event distribution.
  5. Drill into behaviour. Move from Visitors to Replay, and from Heatmaps to Funnels to find where visitors drop off.
  6. Close the loop. Turn discovered paths into test scripts with SessionSight: Journeys, and read the weekly AI summaries on Insights.

The page's lifecycle strip, From tag to insight, in six steps, reads: 1 Install (one tag + allowed origin), 2 Verify (events arriving), 3 Watch (replays + heatmaps), 4 Build (funnels + journeys), 5 Attribute (campaigns + sources), 6 Act (fix what users hit). The numbered list above expands those labels (verified).

Step 4

Use the capability cards to enter the module.

Each card names one thing SessionSight does and links to the page where you do it. Selecting a card is read-only navigation; no capture is enabled and no configuration is changed from this page.

Main: SessionSight, capability cards

Step 5

Note that this page has no pulse chip row.

Unlike some of the other overview pages, SessionSight ships without live counters, deliberately, rather than showing numbers that could not be sourced reliably. Open SessionSight: Dashboard for real figures.

Next steps

Verify the result

The page is working correctly when the architecture hero renders as a diagram, the lifecycle strip shows its steps, and the capability cards navigate into the SessionSight pages. Nothing is saved here, so there is no state to confirm. The absence of a live counter row on this page is by design, not a fault.

Troubleshooting

  • Symptom: A capability card opens a page showing an activation card with Activate License and Learn More. Fix: SessionSight (LG056) is not licensed on this appliance. Check Infrastructure: Licensing. This overview page is ungated by design and describes the module regardless.
  • Symptom: The lifecycle mentions Configuration: SessionSight, which is not in your navigation menu. Fix: CONFIGURATION: SESSIONSIGHT is an Expert-mode section; switch the sidebar footer toggle to Expert.
  • Symptom: SessionSight pages load but every panel is empty. Fix: Confirm a tenant and container are selected in the breadcrumb scope, that the container is instrumented, and that sessions have been recorded in the selected date range.
  • Symptom: You expected SessionSight to cover a Citrix or virtual desktop application. Fix: SessionSight is web only. Use End-to-End Monitoring: Profiles for those technologies.
  • Symptom: A replay shows masked fields you wanted to see, or shows a field you wanted masked. Fix: Masking is applied at capture time and is not retroactive. Adjust the posture on Configuration: SessionSight: SessionSight; the change affects sessions recorded from then on.
  • Symptom: GA4 metrics do not appear. Fix: The active container must match the one the GA4 connection was configured for, and the Google service-account credential must be in place.
Was this article helpful?
0 out of 0 found this helpful