user-journeys-funnels

name	user-journeys-funnels
description	Build funnel analytics and user-journey graphs on top of the mobile event taxonomy. Use when analyzing conversion, drop-off, or retention in Amplitude, Mixpanel, PostHog, or GA4.

User Journeys and Funnels

Instructions

Funnels and journey graphs turn events into decisions. Their quality depends entirely on the taxonomy and the session model; get both right before spending time in the BI tool.

1. Prerequisites

• Event taxonomy is stable and typed (see product-analytics, event-schemas).
• Consent gating is in place (see analytics-privacy).
• session_id and user_id_hash are attached consistently.

Without these, every funnel number is an approximation you cannot defend.

2. Define Funnels From Outcomes Backward

For each key outcome (activation, purchase, re-engagement), enumerate the stages:

Onboarding funnel:
  1. app_first_open        (install attribution event)
  2. onboarding_started    (user tapped Get Started)
  3. onboarding_step_completed (step_id in {profile, perms, interests})
  4. onboarding_completed
  5. first_session_started
  6. first_key_action_performed

Each stage is one event name. Do not use "any of these events" as a stage; it hides logic in the BI tool.

3. Session Model Decisions

• Session boundaries: 30 minutes of inactivity closes a session, or app is terminated. Align with GA4 default so cross-tool queries agree.
• Per-funnel windows: most onboarding funnels fit inside the first session; purchase funnels often span sessions up to 7 days.
• Exit criteria: a stage counts as completed if the event fires between the previous stage and the next stage, within the funnel window.

Document the window and inactivity rule per funnel in the registry.

4. Forward vs Reverse Funnels

• Forward: count how many users who did stage 1 reached stage N. Good for onboarding.
• Reverse: start from the outcome (stage N) and measure what fraction came through each stage. Good for revenue attribution.

Use both when analyzing a regression; they diagnose different kinds of change (top-of-funnel vs mid-funnel).

5. Journey Graphs

A journey graph is the set of all observed transitions between events, weighted by count.

• Nodes: event names (or screens).
• Edges: ordered pairs observed within one session.
• Weight: number of transitions in a time window.

Use this when you don't yet know the "happy path". Amplitude's Journeys, Mixpanel's Flows, GA4's Path Exploration, PostHog's Paths all compute this.

Rules:

• Collapse repeated self-transitions (scroll, load_more) into a single node.
• Limit depth to 5-7 steps; longer paths become noise.
• Filter by user cohort (e.g. new users only) before interpreting.

6. Drop-Off Analysis

For each stage in a funnel:

1. Compute the drop-off rate (users entering - users completing) / users entering.
2. Slice by release, platform, device class, acquisition source, experiment bucket.
3. Rank by impact = drop-off rate * number of users entering.

Do not chase a 60% drop-off on a stage that only 1% of users reach. Impact ranking beats rate ranking.

7. Examples

Purchase Funnel

-- Rough warehouse SQL after events land
WITH starts AS (
  SELECT user_id_hash, MIN(event_time) AS t0
  FROM events WHERE event = 'checkout_started'
    AND event_time > NOW() - INTERVAL '7 days'
  GROUP BY user_id_hash
),
payment AS (
  SELECT s.user_id_hash
  FROM starts s JOIN events e USING (user_id_hash)
  WHERE e.event = 'payment_submitted' AND e.event_time BETWEEN s.t0 AND s.t0 + INTERVAL '30 minutes'
),
success AS (
  SELECT p.user_id_hash
  FROM payment p JOIN events e USING (user_id_hash)
  WHERE e.event = 'order_confirmed' AND e.event_time < s.t0 + INTERVAL '30 minutes'
)
SELECT
  (SELECT COUNT(*) FROM starts)  AS started,
  (SELECT COUNT(*) FROM payment) AS paid,
  (SELECT COUNT(*) FROM success) AS confirmed;

Onboarding Drop-Off Regression

Compare release 4.12.0 to 4.11.0 at the onboarding_step_completed(step_id='perms') stage, sliced by platform and os_version. An OS-specific drop usually means a permission prompt text change or a new iOS/Android behavior.

8. Cohort and Time Slicing

• Define cohorts by install week or acquisition channel; never by "active today" (leaky, correlated with the outcome).
• Window all funnel queries to a trailing period with a fixed cutoff ([now - 30d, now - 1d]) to avoid data freshness artifacts.

9. Cross-Tool Sanity

If the same funnel is computed in Amplitude and the warehouse, numbers must match within 5%. Larger gaps mean:

• Client-side sampling is different per tool.
• Event ingestion is losing data in one pipeline.
• The session definition differs.

Investigate the gap before trusting either.

10. Operational Hooks

• Dashboards per funnel, versioned in code (dashboard-as-code via Grafana/Datadog/Lightdash).
• Alert when a top-of-funnel stage drops > 10% week-over-week on the current release.
• Tie each funnel to an owning team and a PM-level OKR.

Checklist

• Each key outcome has a named funnel with explicit stages (one event per stage).
• Session boundary and funnel window are documented per funnel.
• Forward and reverse funnels are both computed for key outcomes.
• Journey graphs are filtered by cohort, depth-limited, and self-transitions collapsed.
• Drop-offs are ranked by impact, not rate.
• Sliced by release, platform, device class, acquisition source, experiment bucket.
• Funnel dashboards are version-controlled and owned by a named team.
• Cross-tool sanity check runs monthly.