Skip to main content
ServiceAnalytics
Availability2014.1 or later

Core Capabilities

Main transaction analysis features

Analyze Transactions at Scale

Aggregate by measures and pivots

Transaction Performance Analysis

Investigate a single transaction

Data Privacy and Security

Limit sensitive data collected

​
GermainUX Transaction Monitoring Overview

GermainUX provides real-time insight into the performance, behavior and outcome of monitored transactions.

​
What is a transaction?

A transaction can represent a user interaction, web-service call, REST API request, application method, database query, business-process step or other timed activity.
GermainUX helps teams understand not only that a transaction was slow or failed, but where time was spent, which component was responsible and which users or business processes were affected.

​
What Transaction Insights Help You Understand

Transaction analysis can answer questions such as:
  • How long did the transaction take?
  • Which layer consumed the most time?
  • Did the delay occur in the browser, network, application, integration or database?
  • Which code, method, query or external service caused the slowdown?
  • Why did the transaction fail?
  • Which users, sessions or workflows were affected?
  • Is the issue isolated or recurring at scale?
  • Did performance change after a release or configuration update?

​
Core Capabilities

​
End-to-End Transaction Analysis

Depending on the monitored application and enabled components, GermainUX can trace a transaction across layers such as:
User interactionBrowserNetworkWeb serverApplication codeIntegration or APIDatabase or backend service
This connected view helps teams move from:
“The transaction is slow.”
to:
“The transaction is slow because this application method is waiting on this API, which is delayed by this database query.”
Details on how to correlate transaction from various data sources.

​
Time Breakdown

GermainUX can break down transaction duration by layer, component and child activity. Common layers include: The exact layers depend on the monitored transaction and available telemetry.

​
User Click Transactions

GermainUX can analyze a user click as an end-to-end transaction rather than an isolated input event. For a monitored click, the platform can correlate:
  • The element selected by the user
  • Browser and page activity
  • Synchronous and asynchronous requests
  • Network latency
  • Application and integration activity
  • Errors and exceptions
  • Related database or backend activity
  • The next visible outcome experienced by the user
This makes it possible to determine whether a slow click was caused by the interface, browser, network, backend code, external integration or database. User Click analysis can also be connected with Session Replay to show what the user experienced before, during and after the transaction.

​
Web-Service Transactions

GermainUX can monitor stateful and stateless web-service calls, including SOAP-based integrations. Transaction insights can include:
  • Service and operation name
  • Endpoint
  • Start time and duration
  • Request and response status
  • Error or fault details
  • Correlation identifiers
  • Parent and child transactions
  • Calling and target systems
  • Available request or response metadata
When configured and permitted by the organization’s privacy policy, relevant SOAP request or response details can be retained for troubleshooting. Sensitive fields can be masked, excluded or otherwise protected according to the monitoring configuration.

​
REST API Transactions

GermainUX can monitor stateless REST API calls using standard HTTP methods, including:
  • GET
  • POST
  • PUT
  • PATCH
  • DELETE
REST transaction data can include:
  • Method and URI
  • Endpoint and target service
  • Status code
  • Duration
  • MIME or content type
  • Request and response size
  • Error details
  • Correlation identifiers
  • Available JSON, XML or other payload context
Payload capture is configurable. Sensitive data should be masked, excluded or omitted according to security, privacy and compliance requirements.

​
Code-Level Analysis

When Code Profiling is enabled, GermainUX can connect a transaction to the code that executed it. Depending on the monitored technology, analysis can include:
  • Slow methods
  • Method call hierarchy
  • Exclusive and cumulative duration
  • Exceptions and stack traces
  • CPU or memory impact
  • Database calls
  • External-service calls
  • Repeated or inefficient execution
This helps developers identify the specific code path responsible for a poor transaction rather than relying only on high-level response times.

​
Correlation and Distributed Tracing

GermainUX can correlate transactions using mechanisms such as identifiers, exact matching and streaming relationships. Common correlation fields include:
  • Session ID
  • Request or transaction ID
  • Correlation ID
  • Trace or span ID
  • User ID
  • Business-object ID
  • Order, case or service-request number
  • Timestamp and source-target relationship
Correlation can connect telemetry collected from different applications, technologies or monitoring components into one transaction timeline.

​
Transaction Errors and Failures

When a transaction fails, GermainUX can help determine:
  • What failed
  • Where the failure occurred
  • Which error or exception was generated
  • What happened immediately before the failure
  • Which parent and child transactions were involved
  • Which user, session or business process was affected
  • Whether the same failure affects other transactions
  • Whether the issue is new or previously known
Errors can be prioritized by frequency, user count, workflow impact and business outcome. More details on Error Analysis.

​
Analyze Transactions at Scale

Transaction data can be aggregated and segmented using measures and pivots. Common measures include:
  • Count
  • Error or failure count
  • Average duration
  • Minimum and maximum duration
  • Total duration
  • 50th, 90th, 95th, 99th and 99.9th-percentile duration
  • Throughput
  • Success and failure rate
Common pivots include:
  • Application and component
  • Transaction or operation name
  • Endpoint and HTTP method
  • User, role, group and location
  • Browser, device and operating system
  • Server, environment and version
  • Error category
  • Calling and target system
  • Business object or workflow
Percentiles are particularly useful because an acceptable average can hide serious delays affecting a smaller population.

​
Analyze Transaction Performance in the Analysis Dashboard

The is the primary place to investigate the performance of a monitored transaction. It brings aggregate behavior, related signals, segmentation and instance-level evidence into one investigation. Open the Analysis Dashboard by drilling into the transaction KPI from an Aggregate, Pivot or Drill-through Dashboard. The selected KPI, time range, filters and analytical scope are carried into the investigation.

​
Determine Whether Performance Is Abnormal

The Analysis Dashboard compares the selected transaction measure with its historical or configured baseline. Use this view to determine:
  • Whether transaction performance is actually degraded
  • When the degradation started
  • How current performance compares with the baseline
  • Whether the issue affects the average, a percentile or only isolated instances
  • Whether the behavior represents a spike, sustained regression or outlier
For transaction performance, the 95th or 99th percentile is often more informative than the average because it exposes serious delays affecting a smaller population. The Related KPIs section surfaces configured signals that may help explain the transaction’s behavior. Examples include:
  • Browser or JavaScript activity
  • Outbound HTTP requests
  • API and integration calls
  • Application errors and exceptions
  • Database queries and waits
  • CPU, memory or infrastructure utilization
  • Deployment or configuration events
  • User and workflow activity
Related KPIs are evaluated for factors such as deviation, direction, relationship type, expected strength and co-movement with the transaction KPI. This helps investigators focus on the signals most relevant to the slowdown or failure. Select a related KPI to compare its full trend with the primary transaction. Related events configured as markers can appear directly on the transaction timeline. More details on Related KPIs.

​
Identify Leading Factors

The Segmentation Breakdown groups transaction performance by available pivots and highlights the segments most associated with the current behavior. Leading Factors can identify concentrations such as:
  • A specific endpoint or operation
  • An application page or component
  • A browser, device or operating system
  • A server, environment or application version
  • A user group, role or location
  • An error category
  • A calling or target system
Segments can be identified as Degraded, Better, Spike, Outlier or New relative to their baseline. This helps distinguish a widespread problem from one isolated to a particular endpoint, release, user population or technical component.

More details on Leading Factor.

​
Open an Individual Transaction

After identifying an affected segment, open a representative transaction instance for detailed analysis. Instance Analysis can provide:
  • Transaction duration and status
  • Duration breakdown by layer or child activity
  • Transaction attributes and identifiers
  • Parent, child and related transactions
  • Errors and exceptions
  • Request, response and endpoint context
  • Application-code execution when Code Profiling is enabled
  • Related KPIs within the selected instance
Use the identifiers and attributes to confirm that all displayed activity belongs to the same transaction, session or business process.

​
Follow the Trace Timeline

The Trace Timeline displays the ordered activity associated with an individual transaction. Depending on available telemetry, it can show:
User ClickBrowser ActivityHTTP RequestApplication MethodAPI or IntegrationDatabase Query
Use the Trace Timeline to determine:
  • Which activity occurred first
  • Which calls executed inside the transaction
  • Where the critical path spent the most time
  • Whether activities were sequential or overlapping
  • Which child transaction failed or became slow
  • Which component should be investigated or assigned for resolution
More details on .

​
Replay the User Experience

When the transaction originated from a monitored user session, open Session Replay to see what the user experienced before, during and after it. Session Replay can reveal:
  • What the user was trying to accomplish
  • The interaction that initiated the transaction
  • Whether the interface appeared frozen or unresponsive
  • Which error or message the user saw
  • Whether the user retried, abandoned or completed the task
This connects the technical trace with its actual user and business impact.

More details on Session Replay.

​
Move from Analysis to Action

The Analysis Dashboard helps teams move through one continuous workflow:

​
Typical Investigation Workflow

​
Data Privacy and Security

Transaction monitoring can contain sensitive technical or business data. Configure collection according to organizational requirements. GermainUX can be configured to:
Exclude selected headers, fields or payloads; Mask or anonymize sensitive values; Restrict access to transaction details; Apply retention policies; Avoid storing request or response bodies when they are unnecessary.
  • Exclude selected headers, fields or payloads
  • Mask or anonymize sensitive values
  • Restrict access to transaction details
  • Apply retention policies
  • Avoid storing request or response bodies when they are unnecessary
Collect only the data needed to diagnose and improve the monitored transaction. More details on Data Privacy and Security.

​
Get Help

Contact GermainUX Support

The Germain Team can help you set this up.

Can't find what you need?

Search all GermainUX docs with Ctrl + K, or use the feedback buttons at the bottom of this page to tell us what is missing.

The content of this document is proprietary to GERMAIN SOFTWARE.