16.4 Session Segmentation, User Journeys & Funnel Drop-Off Analysis

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:

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:

1. 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.
2. 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:

1. Segment the failing step by device, version, geography, and payment method.
2. Check Apdex and errors on the payment action specifically (16.3).
3. If the front end is healthy, pivot to the backend service and its PurePaths (Chapter 6).
4. 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.