Article · Updated August 2026

Session replays or funnels: which explains the drop-off?

Funnels and session replays answer different questions. A funnel measures how many eligible users moved between defined events and locates the largest trustworthy loss. A replay lets you observe what happened in selected recorded sessions.

Use them in sequence:

1. funnel to measure the pattern;
2. replay to observe affected cases;
3. instrumentation or an experiment to test the suspected explanation.

A replay is a case. The funnel tells you whether the case is a pattern.

The core comparison

Neither is a complete causal explanation. Together they form a practical diagnostic loop.

Start with a trustworthy funnel

Define:

• the eligible cohort;
• one entity across the path where possible;
• the start and end events;
• the maximum conversion window;
• event order rules;
• internal/test exclusions;
• identity behaviour before and after signup.

For example:

If the entity changes from device to account or customer, document the join. A 45% “drop” can be identity loss rather than behaviour.

Choose which sessions to replay

Do not open the replay list and watch random recordings. Build a diagnostic sample.

For a drop between source_connection_started and source_connected, create groups:

1. eligible sessions that started but did not complete;
2. sessions that completed successfully;
3. affected sessions from the relevant release, source type and platform;
4. sessions with a related error event;
5. sessions with no recording, recorded as missing rather than ignored.

Sample across devices, browsers, acquisition sources and account types when those dimensions are plausible. Decide the sample before watching so the most dramatic recording does not become the explanation by default.

Use a replay observation sheet

Record behaviour using a controlled list:

Describe what happened, not the user’s intention. “Clicked submit three times after a 401” is observable. “Did not trust the form” is an inference.

Convert observations into testable hypotheses

Suppose 12 of 20 sampled failed sessions show the same error message after connection. Do not publish “60% of users fail because of the error.” The sample is filtered, small and may exclude unrecorded sessions.

Write:

Among the reviewed recordings from accounts that started but did not complete source connection, repeated authorization errors were a recurring observed pattern. We will instrument the error code across all eligible attempts and compare completion by error state.

Then add or use an event such as:

source_connection_failed { source_type, error_category, attempt_number }

The aggregate event can test whether the observed pattern explains a meaningful share of the funnel loss.

A fictional example

Acme Reports has this weekly funnel:

The largest absolute loss and lowest step conversion occur at connection success. The team reviews a predetermined sample:

The recordings support two hypotheses: authorization errors and unclear input requirements. They do not establish their corpus-wide frequency. The team instruments failure categories and attempt count for the next full cohort.

One week later:

Now authorization failure is an aggregate pattern. The next step is to separate upstream credential validity from the product’s handling and guidance.

When funnels are enough

Use the funnel without replay when:

• the loss is already explained by a known technical event;
• the next action is a measurement fix;
• privacy or platform constraints make replay inappropriate;
• the workflow is server-side and has little visible interaction;
• the aggregate segment cleanly identifies the issue.

A retryable API error does not need a recording to prove that it happened 400 times.

When replay is worth adding

Replay earns its cost when:

• the funnel locates a visible interaction problem;
• multiple plausible behaviours share the same outcome event;
• users cannot explain the problem reliably;
• the session can be recorded with appropriate privacy controls;
• someone will review a defined sample and record observations.

PostHog currently lists session replay separately from product analytics, with a free allowance and per-recording usage pricing on its public product page (PostHog). Pricing can change; the operating cost also includes review time and privacy governance.

Privacy and recording boundaries

Before enabling replay:

• mask sensitive text and fields by default;
• block payment, password, health and private-content surfaces;
• review consent and notice requirements for the product’s jurisdictions;
• control access to recordings;
• define retention and deletion;
• avoid recording internal/admin or test sessions as customer evidence;
• verify masking after every material UI change.

Do not collect a richer recording merely because the SDK allows it. Collect only what the diagnostic job warrants.

Common mistakes

Watching only failures

Successful sessions provide the comparison. Without them, a behaviour can look suspicious even when it occurs everywhere.

Watching the most dramatic recordings

Choose a sampling rule before reviewing. Anecdotal intensity is not frequency.

Using replay instead of event repair

If the funnel event is missing or fires incorrectly, repair it. Replay should not become a manual counter.

Treating missing recordings as successful sessions

Replay coverage can vary by consent, platform, duration and technical failure. Report the number requested, available and complete.

Publishing inferred intent

State the observed action and the hypothesis separately.

A repeatable weekly workflow

1. Review the mature funnel and absolute losses.
2. Confirm event, identity and cohort quality.
3. Select one handoff.
4. Define failed and successful replay cohorts.
5. Review a fixed sample with an observation sheet.
6. Rank candidate explanations by observed evidence and decision impact.
7. Add an aggregate event or controlled experiment.
8. Re-read the funnel after the change.

Stop when the first actionable explanation is strong enough to test. Do not turn replay review into a daily film festival.

Frequently asked questions

Sources

• PostHog product analytics and session replay product overview
• Discussion about replay review being heavy and manual
• Discussion about a funnel finding a severe drop
• Discussion about replay revealing a product issue
• Founder replay-review workflow
• Discussion about recordings revealing feature non-use
• Reddit discussion comparing standard analytics and replay
• PostHog replay landing-page diagnosis