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:

Show all 11

• Comparison with what worked
• Technical traces
• Session Replay
• Ai-powered analysis
• Recommendations

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:

​

Aggregate View vs. Instance view

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

​

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: 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: This helps determine whether the behavior is: Depending on the KPI and available data, the investigation can include: 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: 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: This helps identify signals that changed at the same time as the KPI being investigated and provides direction for further analysis.

​

Filter KPI by Friction

The Relationships graph can be filtered by the type of friction relevant to the investigation:

• Conversion Frictions — conditions that may interfere with a visitor’s ability to convert or complete a desired business outcome.
• Adoption Frictions — conditions that may interfere with successful application, feature, or workflow adoption.
• Experience Frictions — conditions affecting the user’s experience, such as errors, failed interactions, or other detected user friction.
• Technology Frictions — application or technology conditions such as errors, failures, or performance issues that may affect users or business outcomes.

Select one or more friction categories to focus the Relationships graph on the signals most relevant to the investigation. For example: Conversion Rate Declines
→ Filter on Conversion Frictions
→ Identify frictions occurring around the decline
→ Determine which populations are affected
→ Investigate representative instances
→ Review Session Replay and related technical evidence And you can replay the session behind that negative user feedback to understand the contextaround the cart abandonment. Or: CRM Adoption Declines
→ Filter on Adoption Frictions
→ Identify relevant workflow or user frictions
→ Compare affected populations
→ Investigate individual sessions
→ Identify likely contributing factors Friction filtering helps reduce noise and focus the investigation on the type of outcome being analyzed.

​

Related KPIs

Configured KPI Relationships allow GermainUX to automatically surface related signals during an investigation. Related KPI information can include: These signals help identify where to investigate next. Relationships and correlation provide supporting evidence but do not, by themselves, prove causation.

And you can pivot to further understand an issue:

​

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:

Show all 11

• Workflow
• Region
• Device
• Browser
• Version

Segments can be identified as: 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: 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: For HTTP activity, available evidence can include connection timing, SSL, waiting time, download time, response size, caching, compression, URL, response information, and HAR export.

​

Comparison

GermainUX automatically compares a transaction or event with another matching instance to identify differences in performance, behavior, and outcomes. Select one of four comparison options:

• Worst — Compare with the worst-performing matching instance.
• Most Recent — Compare with the most recently recorded matching instance.
• First Seen — Compare with the first recorded matching instance.
• Last Seen — Compare with the last matching instance recorded before the selected event.

​

Identify What Changed

GermainUX highlights the differences between the two instances, including:

• Duration — Compare execution times and quantify performance differences.
• Processing breakdown — Identify which operations, such as DOM processing, JavaScript execution, network requests, or server processing, contributed to the difference.
• Missing or additional activity — Identify operations that occurred in one instance but not the other.
• Business outcomes — Compare results such as conversion, abandonment, or other recorded conditions.

Differences are ranked by their contribution, helping teams focus on the most significant changes first. Each instance can be opened for further investigation.

​

Example: Investigating a Slow Click

A user interaction that took 40.444 seconds is automatically compared with a matching instance that completed in 3.650 seconds. GermainUX identifies:

• 11.1× slower execution in the problematic instance.
• 38.445 seconds of DOM processing in the slow instance, compared with none in the faster instance.
• 8.869 seconds of imageryFetch processing, compared with 4.105 seconds in the faster instance.
• Differences in network activity, JavaScript execution, and recorded business outcomes.

Instead of manually reviewing two transactions, teams can immediately see what changed, where time was spent, and which differences warrant further investigation. The comparison provides direct access to the underlying events and the full investigation view to help determine the likely root cause.

​

Extended Context

Expand the Trace Timeline to investigate what occurred before and after the selected transaction. Available context can include: 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: 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: Configuration is available under: Germain Workspace > Settings > Analytics

​

Related Documentation

​

Get Help

The content of this document is proprietary to GERMAIN SOFTWARE LLC.