Study guide
16.4 Session Segmentation, User Journeys & Funnel Drop-Off Analysis
Dynatrace Certified Associate Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Platform Overview, Deployment Models & Architecture
1.1 Dynatrace Platform Capabilities, Web UI Navigation & the Dynatrace Hub 1.2 SaaS vs. Dynatrace Managed Architecture & Security 1.3 Core Telemetry Components: OneAgent, ActiveGate & Grail Lakehouse 1.4 Licensing Models: Dynatrace Platform Subscription (DPS) & Davis Data Units (DDUs)
2 Chapter 2: ActiveGate Architecture & Network Topologies
2.1 ActiveGate Types: Environment vs. Cluster ActiveGates 2.2 ActiveGate Capabilities: Proxying, Private Synthetic, Cloud Integrations & Extensions 2.3 Network Zones, Multi-DC Routing & Firewall Traversal
3 Chapter 3: OneAgent Deployment, Configuration & Management
3.1 OneAgent Architecture, Components & Automatic Injection 3.2 Host Installation on Linux, Windows & Containerized Hosts 3.3 Cloud-Native Deployment: Dynatrace Operator on Kubernetes & OpenShift 3.4 Kubernetes Observability: Clusters, Nodes, Namespaces, Workloads & Events
4 Chapter 4: Monitoring Modes, Process Groups & Infrastructure Observability
4.1 Monitoring Modes: Full-Stack vs. Infrastructure-Only vs. Discovery 4.2 Process Groups, Process Instances & Custom Process Group Detection Rules 4.3 Host Groups, Host Naming Rules & Environmental Metadata Extraction 4.4 Infrastructure & Operations: Host Health, Disk, Network & Availability Analysis 4.5 Database Observability: The Databases App, Connection Pools & Storage Latency
5 Chapter 5: Smartscape Topology & Service Flow
5.1 The 5-Layer Smartscape Topology: Datacenter to Application 5.2 Service Detection: Web Services, Background Tasks & Custom Services 5.3 Service Flow, Backtrace Analysis & Horizontal/Vertical Dependency Mapping
6 Chapter 6: PurePath Distributed Tracing & Code-Level Diagnostics
6.1 PurePath Architecture, Distributed Tracing & Request Context Propagation 6.2 Method Hotspots, CPU Profiling & Memory Allocation Thread Analysis 6.3 Database Service Diagnostics, Slow Queries & Exception Analysis
7 Chapter 7: Davis AI Engine, Baselining & Causation
7.1 Davis Deterministic Causation Engine vs. Pure Correlation 7.2 Automated Dynamic Baselining, Percentiles & Traffic Seasonality 7.3 Event Ingestion, Event Types & Event Hierarchy in Problem Evolution
8 Chapter 8: Problem Lifecycle, Root Cause Analysis & Alerting
8.1 Problem Lifecycle, Severity Categories & Root Cause Cards 8.2 Alerting Profiles, Delay Filters & Management Zone Routing 8.3 Problem Notification Integrations: Webhooks, Slack, ServiceNow & ITSM
9 Chapter 9: Digital Experience Monitoring: Synthetic Monitoring
9.1 Synthetic Monitors: HTTP, Single-Step Browser & Multi-Step Clickpaths 9.2 Private Synthetic Locations, ActiveGate Engines & Credential Vault 9.3 Outage Detection, Performance Baselining & Maintenance Suppression
10 Chapter 10: Digital Experience Monitoring: Real User Monitoring (RUM)
10.1 RUM Architecture, OneAgent Script Injection & Mobile/OpenKit Telemetry 10.2 User Actions: Load vs. XHR/Fetch Actions, Visually Complete & Speed Index 10.3 Apdex Performance Ratings, User Sessions & Session Replay Masking
11 Chapter 11: Log Management and Analytics on Grail with DQL
11.1 Log Management on Grail: Storage, Ingestion Pipelines & Log Masking 11.2 Dynatrace Query Language (DQL): Fetch, Filter, Fields & String Operations 11.3 DQL Aggregations: Summarize, MakeTimeseries, Sorting & Visualizations
12 Chapter 12: Platform Governance, OpenTelemetry & Automation
12.1 Management Zones: Scoping Observability, Dashboards & Access Control 12.2 Tagging Strategies: Automated Rule-Based Tags, Manual Tags & AWS/K8s Metadata 12.3 OpenTelemetry Ingestion, OpenPipeline & Dynatrace Workflows Automation
13 Chapter 13: Cloud Integrations & Agentless Infrastructure Ingestion
13.1 AWS, Azure & Google Cloud Integrations 13.2 VMware vSphere, Extensions & Other Agentless Ingestion Paths
14 Chapter 14: Business Analytics & Business Events
14.1 Business Events: Capture, Ingestion & the bizevents Grail Table 14.2 Business Analytics: Connecting Performance to Revenue, Conversion & KPIs
15 Chapter 15: Notebooks, Dashboards & Data Visualization
15.1 Notebooks: Section-Based Investigation & Shareable Analysis 15.2 Dashboards: Tiles, Variables, Segments & Continuous Monitoring 15.3 Choosing Visualizations: Data Explorer, Chart Types & Metric Selection
16 Chapter 16: Reporting, Metrics & User Behavior Analysis
16.1 Metrics on Grail: Built-in Metrics, Granularity & Retention 16.2 Dashboard Reports, Subscriptions & Exporting Data via APIs 16.3 User Behavior Analysis: Bounce Rate, Landing & Exit Pages, Conversion Goals 16.4 Session Segmentation, User Journeys & Funnel Drop-Off Analysis
17 Chapter 17: Security, Vulnerability Analytics & Application Protection
17.1 Platform Security: Data Privacy, Encryption & Access Control 17.2 Third-Party Vulnerabilities, the Davis Security Score & Security Advisor 17.3 Code-Level Vulnerabilities, Attacks & Runtime Application Protection 17.4 Security Investigator, Notifications & the Remediation Workflow
16.4 Session Segmentation, User Journeys & Funnel Drop-Off Analysis
Key Takeaways Explain This Topic AI
Session segmentation breaks user interactions into smaller parts to reveal typical user paths, drop-off points, and high-engagement sessions.
A user session is also called a visit, journey, or clickpath, and each session contains at least one user action.
Sessions can be filtered by duration — longer than, shorter than, or within a range — as well as by satisfaction, device, location, and application version.
Funnel analysis exposes which specific journey step loses customers, which aggregate conversion rate alone cannot show.
DQL over RUM data answers behavioural questions beyond the built-in views, such as which UI elements drive engagement and how navigation flows actually run.
Last updated: September 2026
Section 16.3 analyzed individual actions — the one users landed on, the one they left from. This section analyzes the whole journey . Dynatrace's definition: session segmentation helps track and analyze a user's journey (also called session, visit, or click path) by breaking interactions into smaller parts, showing typical user paths, drop-off points, and high-engagement sessions.
Those three outputs — typical paths, drop-off points, high-engagement sessions — are worth memorizing as a set, because they map directly onto the three questions the exam asks about journeys.
What a Session Is
A user session — also called a visit , journey , or clickpath — is a sequence of user actions performed by the same user during a limited period. Each user session includes at least one user action. From Section 10.3, the boundaries are: 30 minutes of browser inactivity, a session duration reaching 6 hours, the browser closing, or an explicit dtrum.endSession() call, with a split after roughly 200 user actions.
Session-level analysis is done in Session Segmentation , which is where filtered session lists and journey views live.
Filtering and Segmenting
The filter dimensions are the analytical vocabulary, and the exam expects familiarity with the range:
Dimension Question it answers
Satisfaction (Apdex) Do frustrated sessions behave differently from satisfied ones?
Device / OS / browser Is this a platform-specific defect?
Geographic location Is a region, CDN edge, or ISP implicated?
Application version Did a release cause this?
Session duration Longer than, shorter than, or within a range
User tag How does a specific customer's experience look?
Entry / exit action Where did this cohort arrive and leave?
Errors encountered Do error-affected sessions convert worse?
Duration filtering is more useful than it first appears. Very short sessions are usually bounces or bots. Very long sessions are either highly engaged users or users stuck in a loop , repeating the same action because something is not working — and that second population is invisible in every aggregate metric because the session looks like enthusiastic engagement.
Typical Paths and Drop-Off Points
Journey analysis renders the routes users actually take, which is reliably different from the route the design assumed. Two findings recur:
Unexpected paths. Users reaching checkout through search rather than through category navigation, or repeatedly returning to a help page mid-journey — a strong signal that a step is confusing.
Drop-off concentration. Attrition is rarely evenly spread. It clusters at one step, and that step is the thing to fix.
Funnel Analysis
A funnel formalizes drop-off: define the ordered steps of an intended journey and count how many sessions reach each one. Product page 12,400 sessions ——
- Add to cart 6,820 sessions 55% (normal for retail)
- Delivery details 6,150 sessions 90%
- Payment details 5,900 sessions 96%
- Order confirmed 1,980 sessions 34% <-- the problem
Every ratio here is unremarkable except the last. Fifty-five percent attrition from browsing to cart is ordinary retail behaviour; 66% attrition between entering payment details and confirming the order is not — those users had already decided to buy. The funnel converts "conversion is down" into "the payment step is broken," which is an actionable statement.
The follow-up analysis chains everything in this guide together:
Segment the failing step by device, version, geography, and payment method.
Check Apdex and errors on the payment action specifically (16.3).
If the front end is healthy , pivot to the backend service and its PurePaths (Chapter 6).
Quantify the loss in currency using business events (Chapter 14).
The canonical exam scenario is the one where steps 2 and 3 both come back clean — page fast, no JavaScript errors, backend service returning HTTP 200 in 300 ms — and the answer is that the failure is functional or business-logic driven rather than a performance defect. Healthy technical telemetry does not mean a healthy journey.
High-Engagement Sessions
The third output of session segmentation is the positive one: identifying the sessions that went well . These are useful in two ways — as a control group for comparison against failing sessions, and as a description of what the successful path actually looks like, which is rarely what the design documentation claims.
Extending with DQL
The built-in views cover the common questions. RUM captures rich behavioural data — clicks, navigations, session flows, and custom properties — in user events and user sessions, and DQL gives direct access to this data so you can answer behavioural questions that go beyond what the built-in views show , such as identifying which UI elements drive the most engagement, mapping navigation flows, or measuring bounce rates with custom definitions. fetch dt.rum.user_events, from: now() - 7d
- | filter event.type == "action" and app.version == "4.2.0"
- | summarize sessions = countDistinct(session.id), by: { action.name }
- | sort sessions desc
- | limit 20
The exam does not require you to author advanced RUM DQL. It does expect you to know that behavioural data is queryable in the same language as logs, metrics, traces, and business events , which is the structural reason a single Notebook can hold the whole story — from the funnel step that leaked customers to the PurePath that explains why and the business event that prices it.