User Behavior Analysis: Event Modeling and Path Analysis in Practice
Summary: The starting point of user behavior analysis is not the dashboard, but the event model — behavior is essentially a time-ordered sequence of events, not a set of aggregate counts. This article gives the field spec and naming anti-patterns for events, the applicable boundaries of four analytic views such as funnel and path, and the bottleneck-locating principle of "watch relative performance, not absolute drop-off" with an experimentation loop.
The same ten events, in a different order, can mean completely different users: browse → error → help → leave, versus browse → add-to-cart → order → repurchase. The aggregate counts are identical, but the business meaning is worlds apart. That is why behavior analysis must build the event model before talking about dashboards and metrics. This article proceeds in four segments: model, analyze, locate, validate.
Key Takeaways
- Behavior is an event sequence, not a static profile; the event is the smallest atomic unit of analysis.
- Events must carry five kinds of information — subject, action, time, object, context — and event time must be kept separate from ingestion time.
- Naming should carry business meaning; names like "button_click_7" are nearly unusable for analysis.
- Four views each have a role: funnel watches drop-off, path watches real flow, retention watches quality, state watches transition.
- To locate the bottleneck, watch the worst relative performer, not the step with the largest absolute drop-off.
- Loop paths and p95 duration are two signals most easily masked by averages and need dedicated monitoring.
I. Behavior Is an Event Sequence, Not a Set of Aggregated Numbers
Behavior analysis studies what users "did, in what order, and with what interval." It cares not about total clicks but about state and movement: where they came from, where they stayed, where they went next, and whether they looped back. Compressing ten events into one count throws away the most critical ordering information.
So the event is the atomic unit of analysis. A qualified event should answer five questions: who did it (user, account, or organization ID), what they did (action), when it happened (event time, in-session sequence number), on what (product, order, content, or feature), and the context at the time (channel, device, version, network). Among these, "event time" must be stored independently of "ingestion time" — when data arrives late, sorting by ingestion time rewrites the whole journey.
II. Event Field Spec and Naming Anti-Patterns
| Field category | Required content | Common mistake |
|---|---|---|
| Subject ID | user ID, account ID, session ID | cross-platform not unified, one person split into multiple IDs |
| Action | semantically stable action name | UI-specific click name, breaks on redesign |
| Time | event timestamp, session sequence, duration | using ingestion time instead of event time |
| Object | product, order, content, feature ID | recording only the page, not the business object, no drill-down |
| Context | channel, device, version, network | missing version field, can't locate release regression |
Naming is where landmines are most easily buried. The anti-pattern is "button_click_7" — it only describes a UI element, breaks on any redesign, and can't map to a business action. One notch better is "pricing_cta_click", which states position and intent; even better is "trial_started_from_pricing_page", which attaches the context directly to the action so analysis needs no extra field joins.
The naming convention recommends a unified "object + action" or "action + source" structure, and maintaining an event dictionary that records each event's trigger condition, owning page, carried attributes, and business meaning. Event count should also be restrained: first rebuild the main funnel with 3–6 core events, then expand after validating signal quality.
III. Four Analysis Views, Each with Its Role
| View | Question answered | Fit and limits |
|---|---|---|
| Funnel analysis | how much each step converts and drops | intuitive, easy to report; but assumes a linear path and misjudges users who skip or take alternate paths |
| Path analysis | how users actually move, where loops and dead ends are | reveals real flow; with large data volumes noise grows, needs a minimum share threshold |
| Retention and cohort | whether user quality from different sources/batches changes | distinguishes "calendar effect" from "cohort quality"; needs right-censoring handling |
| State transition | which relationship stage a user is in, where they may go next | fits long-term relationship management; state definitions need validation against business outcomes |
The correct funnel approach is "path-aware": allow step skipping, allow loops, allow multiple entries — not assume every user completes browse → add-to-cart → checkout → pay. Otherwise users who convert via search, favorites, repurchase, or offline channels get misjudged as dropped off.
Cohort analysis distinguishes "decline caused by time" from "decline caused by cohort quality": an overall retention slide could be lower quality of newly acquired batches, or a pricing change affecting everyone; only grouping by acquisition or activation batch reveals which. Watch the bias from different observation windows when comparing — a batch observed for a full 12 months can't be directly compared with one observed only to month 3.
IV. Locating the Bottleneck: Watch Relative Performance, Not Absolute Drop-off
The most common misjudgment is "fix the step with the largest absolute drop-off first." The earlier a funnel step is, the larger its base, so absolute drop-off is naturally larger there — but that's often not where the problem is, because some upstream drop-off is normal intent filtering.
The correct principle is to build a baseline first: use two to four weeks of data to compute each step's conversion rate, then segment by channel, device, and user type to find the worst relative performer (the step deviating most from baseline) and fix it first. Another high-value view is revenue weighting: if a high-value segment's conversion at some step is clearly below average, even if the absolute volume is small, fixing it can out-earn fixing a high-traffic, low-value step's drop-off.
Funnel granularity itself must be controlled, usually 3–7 steps representing real decisions. Too few steps hide problems; too many and every step's fluctuation is drowned by noise. After each change, validate with an A/B test or before/after comparison, and watch the whole funnel, not just the changed step — a local gain often comes at the next step's expense.
V. Loop Paths and Time Distribution: Median and p95
Loops are among the most valuable path signals. Users bouncing back and forth between the same group of pages usually means a flow blocker, validation failure, or state loss. A simple threshold sets priority: if it appears in at least 5% of sessions, or accounts for more than 10% of a step's drop-off, it's worth handling immediately.
On the time dimension, watch both median and p95. The median represents the typical experience; p95 represents the worst batch — the latter is often caused by network, rendering, or specific-device issues: few people affected, but severe drop-off. Averages alone mask both. Post-release regression detection also relies on these two: filter paths by version, compare Top paths before and after the release, and you can locate and roll back within 24–48 hours.
Sequence modeling (n-gram, Markov transition, sequence embedding) fits more complex scenarios, to discover high-frequency patterns and high-friction transitions. But before adopting it, ask: does the added complexity actually change a decision, or reveal a blocker the team can fix? If it only produces more charts, it's not worth it.
VI. Cadence: Tracking Validation, Weekly Review, and the Experimentation Loop
Tracking must be validated before going live, or every later analysis rests on wrong data. Run 50–200 test sessions covering major devices and systems, export the session trajectory, and verify line by line that the screen order and event timing match real-device behavior, and confirm the session ID stays stable across foreground/background switches and page jumps.
Then establish a fixed review cadence: each week, look at the largest drop-off point, the largest cohort difference, any newly found loop or dead end, last week's experiment results, and this week's planned changes. Many teams don't fail at hard analysis; they fail because after the dashboard is built, nobody actually owns the funnel. After a quarter or a major release, recalibrate the stage definitions and the model.
Finally, the validation loop: turn insights into concrete actions (change the flow, change the copy, change the default), quantify the gain with experiments, and write the conclusion back into the event dictionary and dashboard. Attribution tools show "who gets the credit"; experiments show "whether there was any gain at all" — the two must work together, and before any major investment, use experiments to confirm causation where possible.
FAQ
Q: What should be the first step in behavior analysis?
A: Build the event model, not the dashboard. Clarify the five kinds of information every event must carry (subject, action, time, object, context), unify naming and maintain an event dictionary, then rebuild the main funnel with 3–6 core events to validate signal quality.
Q: Why can't event time use ingestion time?
A: Because data can arrive late. Sorting by ingestion time places late events in the wrong position, rewriting the whole journey's order, and the funnel and path analysis become distorted.
Q: What's the trick to event naming?
A: It must carry business meaning. Avoid names like "button_click_7" that only describe a UI element — they break on redesign and can't map to a business action; prefer an "action + source" structure, such as "start trial from pricing page".
Q: Should I fix the step with the most drop-off first?
A: Not necessarily. First build a baseline for each step with two to four weeks of data, then segment by channel, device, and cohort to find the worst relative performer. Upstream bases are large, so absolute drop-off is naturally high there, but that's often just normal intent filtering.
Q: How many steps should a funnel have?
A: Usually 3–7 steps representing real decisions. Too few hides problems; too many drowns each step's fluctuation in noise. At the same time allow skipping, loops, and multiple entries, to avoid misjudging users who convert via other paths as dropped off.
Q: Are loop paths worth handling specifically?
A: Yes. Users bouncing between the same pages usually means a flow blocker or state loss. Use a threshold to prioritize: appears in at least 5% of sessions, or accounts for more than 10% of a step's drop-off.
Q: How do you validate tracking before going live?
A: Run 50–200 test sessions covering major devices and systems, export the session trajectory to verify screen order and event timing, and confirm the session ID stays stable across foreground/background switches and page jumps.
About Tengence
The event model and path analysis are the foundation that turns user behavior into growth decisions; their quality decides how far segmentation, recommendation, and conversion optimization can go. Tengence (TENGENCE) focuses on the growth technology of enterprise public-domain traffic acquisition and private-domain conversion, and the user data and methodology covered here are a direction it continuously follows.
Related Reading
- Funnel Analysis Methodology: How to Precisely Locate Drop-off Points
- User Tagging System Building Guide: How to Build a Tag System from 0 to 1
- How to Make Data-Driven Decisions Work: A 5-Step Enterprise Framework
Data Sources
- Trusted Data: Customer Behaviour Analytics & Intelligence: proposes behavior as an event sequence rather than a static profile; events should contain five kinds of information — subject, action, time, object, context — and event time must be stored separately from ingestion time; funnels should allow skipping, looping, and alternate paths; and lists six views — cohort, funnel, retention, path, state transition, and anomaly.
- Pedowitz Group: Best Way to Analyze Customer Journeys: proposes triangulating funnel, path, and timing, validating causation with experiments, gives a fit-and-limit comparison of five methods, and a case where after setting up a "demo fast lane" the median evaluation time dropped 28% and the close rate rose 12%.
- KISSmetrics: Building Your First Funnel: recommends 3–7 steps representing real decisions, accumulate at least two weeks of data before concluding, segment by channel, device, and user type, and emphasizes optimizing the worst relative performer rather than the largest absolute drop-off, watching the whole funnel after changes.
- Vexo: Analyzing User Paths: gives the tracking-validation method (50–200 test sessions, export trajectory to verify order, confirm stable session ID), recommends watching both median and p95 duration, and proposes handling thresholds for loop paths (appear in at least 5% of sessions or more than 10% of a step's drop-off).
- User Behavior Flow Analysis for Conversion Optimization: gives naming anti-patterns and good examples (from "button_click_7" to "start trial from pricing page"), and emphasizes first rebuilding the main funnel with a few core events, validating signal quality, then expanding.
