🔖 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.
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.
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.
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.
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.
⛓️ Related KPIs
Configured KPI Relationships allow GermainUX to automatically surface related signals during an investigation.
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.
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.
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
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
📚 Related Documentation
ℹ️ Get Help
The Germain Team can help you set this up. Contact GermainUX Support.
Feature Availability: 2014.1 or later