4-Analysis Dashboard

🔖 4 – Analysis Dashboard

🔬 Overview

The Analysis Dashboard is GermainUX's root-cause investigation interface.

It helps teams understand why a business, user-experience, workflow, or technology KPI is behaving the way it is by automatically bringing together the evidence needed for investigation:

  • Baselines and trends

  • KPI relationships

  • Related KPIs

  • Leading factors

  • Segmentation

  • Affected users, sessions, and instances

  • Technical traces

  • Session Replay

Instead of manually searching across dashboards, logs, traces, and user sessions, teams can move from symptom → impact → likely cause → supporting evidence within one analytical workflow.

The Analysis Dashboard helps answer:

  • Is this abnormal?

  • What changed with it?

  • What factors are contributing to it?

  • Where is the issue concentrated?

  • How many users, sessions, or transactions are affected?

  • What happened in a specific affected instance?

  • What is the likely root cause?


📊 Aggregate vs. Instance Analysis

One of the key benefits of the Analysis Dashboard is the ability to investigate an issue from two complementary perspectives: Aggregate and Instance Analysis.

Analysis

Purpose

Example

Aggregate Analysis

Understand what is driving a KPI across many users, sessions, transactions, or systems.

Why did conversion decrease across thousands of sessions?

Instance Analysis

Understand exactly what happened during one specific occurrence.

Why did this particular user fail to complete checkout?

🌎 Aggregate Analysis — Find What Matters at Scale

Aggregate Analysis looks across the entire selected population and time period to identify patterns that would be difficult or impossible to discover by investigating individual instances one at a time.

image-20260918-170033.png
Aggregate View for a Technology Freeze - GermainUX

It helps answer:

  • What are the largest factors associated with the issue?

  • Which users, sessions, workflows, applications, products, regions, devices, browsers, or versions are most affected?

  • Which related KPIs changed at the same time?

  • Is the problem widespread or concentrated within a specific segment?

  • How many users, sessions, or instances are affected?

  • Which issues should be investigated first?

For example, if conversion drops across 100,000 sessions, reviewing individual sessions would not efficiently reveal what is affecting the population.

Aggregate Analysis can identify that the decrease is concentrated among a particular checkout step, browser version, product, error, performance condition, or user segment, helping teams quickly focus on the factors with the greatest impact.

Benefit: Find the patterns, relationships, and leading factors affecting the population without manually investigating thousands of individual occurrences.


🔎 Instance Analysis — Explain a Specific Occurrence

Once Aggregate Analysis identifies an important pattern or affected population, users can drill into an individual instance to understand exactly what happened.

image-20260918-170531.png
Instance View of a Technology Freeze - GermainUX


image-20260823-214302.png
Instance View of a Slow User Click - GermainUX

GermainUX can compare the selected instance across:

INSTANCE → SESSION → USER → POPULATION → OVERALL

This helps determine whether the behavior is:

  • Isolated to one occurrence

  • Specific to one session

  • Specific to one user

  • Concentrated within a population

  • System-wide

Depending on the KPI and available data, the investigation can include:

  • Duration breakdown

  • Technical traces

  • HTTP activity

  • Errors

  • Related transactions

  • User activity

  • Events occurring before and after the issue

  • Session Replay

Benefit: Move from identifying what is affecting users at scale to understanding exactly why a representative occurrence happened.


🔄 From Population-Level Insight to Individual Evidence

Aggregate and Instance Analysis are designed to work together:

Detect a KPI change
Analyze the population
Identify leading factors
Find affected segments
Measure users/sessions/instances affected
Open a representative instance
Analyze its trace and surrounding activity
Replay the user session
Identify the likely root cause

This approach avoids two common investigation problems:

Looking only at aggregate data can reveal a pattern without showing exactly what happened to an individual user or transaction.

Looking only at individual instances can explain one occurrence without showing whether it represents the broader population.

GermainUX combines both views so teams can understand what matters at scale and then validate it with instance-level evidence.


📈 Summary

The Summary helps determine whether the selected KPI is behaving abnormally.

image-20260823-212431.png

Depending on the KPI and available history, GermainUX can compare:

  • Vs Recent

  • Vs Last Quarter

  • Trend

  • How Extreme

Percentiles can also help determine whether an issue affects the overall population or only a subset.

For example, a normal median combined with a high p95 or p99 may indicate that most users are unaffected while a smaller population is experiencing significant degradation.


🔗 Relationships

The Relationships view overlays the KPI being analyzed with related signals on a common timeline.

image-20260823-212739.png

It can include:

  • Selected KPI

  • Overall population

  • Related KPIs

  • Discrete events

  • Errors

  • Alerts

  • Dimensional pivots

This helps identify signals that changed at the same time as the KPI being investigated and provides direction for further analysis.


Configured KPI Relationships allow GermainUX to automatically surface related signals during an investigation.

image-20260823-212653.png

Related KPI information can include:

  • Spike or drop

  • Current value

  • Baseline

  • Variation

  • Trend

  • Co-movement

These signals help identify where to investigate next. Relationships and correlation provide supporting evidence but do not, by themselves, prove causation.


🧭 Leading Factors

Leading Factors analyze available KPI dimensions to identify the populations or conditions most strongly associated with the observed outcome.

image-20260823-212830.png

Depending on the KPI, dimensions can include:

  • User

  • Session

  • Page

  • Application

  • Product

  • Journey step

  • Workflow

  • Region

  • Device

  • Browser

  • Version

Segments can be identified as:

  • DEGRADED

  • BETTER

  • SPIKE

  • OUTLIER

  • NEW

Affected instance, session, and user counts help determine both the scale and concentration of the issue.


⏱️ Duration Breakdown

For supported duration-based KPIs, elapsed time can be separated into areas such as:

  • Service

  • Network

  • Rendering

  • Document Processing

  • Idle or Unmonitored

Duration can be analyzed using Exclusive or Cumulative time to identify where time is actually being spent.


🕰️ Trace Timeline

The Trace Timeline displays the selected transaction and related activity on a common timeline.

image-20260823-213028.png

Depending on the monitored data, it can include:

  • Child spans

  • Server timings

  • HTTP requests

  • Browser activity

  • Errors

  • Related transactions

  • User activity

For HTTP activity, available evidence can include connection timing, SSL, waiting time, download time, response size, caching, compression, URL, response information, and HAR export.


✨ Extended Context

Expand the Trace Timeline to investigate what occurred before and after the selected transaction.

Available context can include:

  • Console errors

  • User-facing errors

  • Rage clicks

  • Popups

  • Navigations

  • Related requests

  • Related transactions

This is particularly important when the event responsible for a symptom occurred before the symptom itself became visible.


🔁 Recursive Analysis

Analysis does not have to stop at the original KPI.

Select Analysis from a supported trace span to investigate that KPI independently.

For example:

Slow User Click → Slow HTTP Request → Slow Service Call → Slow Database Operation

image-20260918-164029.png

Each level can then be analyzed using its own baselines, relationships, segmentation, aggregate patterns, and instance evidence.


🎥 Session Replay

When Session Replay is available, open the affected user's session to see what the user was actually doing and experiencing around the issue.

This connects analytical and technical evidence with the actual user experience.

Learn more about Session Replay.


📋 Investigation Workflow

A typical GermainUX investigation becomes:

Symptom
→ Confirm abnormal behavior
Analyze impact across the population
→ Review Related KPIs
→ Identify Leading Factors
→ Identify affected segments
→ Measure users, sessions, and instances affected
Select a representative instance
→ Review duration and trace
→ Review surrounding activity
→ Open Session Replay
→ Identify likely root cause
→ Take action
→ Validate

The result is a continuous investigation path from population-level impact to instance-level evidence.


⚙️ Configure Analysis

Analysis behavior depends on KPI configuration, including:

  • Fact Type

  • Fact Category

  • Measures

  • SLAs

  • Statistical SLAs

  • Dimensions

  • KPI Relationships

  • Matching fields

Configuration is available under:

Germain Workspace > Settings > Analytics

ℹ️ Get Help

The Germain Team can help you set this up. Contact GermainUX Support.

Component: Enterprise-OnCloud , Enterprise-OnPremise

Feature Availability: 2014.1 or later