How to investigate a signup conversion drop
On this page
Start by separating fewer visitors from a lower conversion rate. Then compare the same funnel definition across comparable periods, check collection health, and inspect errors or recordings from the affected journeys. SaaS Pro Max connects these views when the required events, identifiers and modules are available.
This guide uses an illustrative signup flow. The event names and numbers below are examples, not measured customer results.
1. Define the journey before comparing it#
Choose events that correspond to real application behavior, such as signup_started, email_verified and workspace_created. Send the completion event after the operation succeeds. A button click alone does not establish that an account was created.
Use the same application, environment, timezone and filters for both periods. Keep staging traffic out of a production comparison. Confirm that a deployment did not rename an event or change when it fires. The event catalog and analytics reference explains how to inspect event definitions and collection diagnostics.
2. Separate volume from conversion#
Suppose last week 1,000 visitors entered the funnel and 400 completed it. This week 600 entered and 240 completed it. Completions fell 40%, but both periods converted at 40%. Investigate acquisition and traffic mix before concluding that the signup form got worse.
If 1,000 entered and only 240 completed instead, conversion fell from 40% to 24%. Inspect the step where the loss appeared. Source, campaign, device and release context can help narrow the investigation, but a correlation is a lead rather than proof of a cause.
| Observation | Next check |
|---|---|
| Fewer entrants, stable conversion | Traffic sources, campaigns and missing page or entry events |
| Stable entrants, lower completion | Step-level drop-off, errors, latency and changed validation |
| Both change together | Traffic mix and implementation changes; keep the two effects separate |
| Event volume suddenly disappears | Key, allowed origin, environment, consent, quota and module settings |
3. Let the conversion window finish#
The saved funnel defaults to ordered steps with a renewed conversion window at each step. The detail view can instead use an entry-based window, consecutive events, or any-order matching after entry. Those definitions answer different questions; record which one you used.
A visitor who entered five minutes ago still has time to complete a 24-hour window. Funnel diagnostics separate open windows from expired ones and report time to the next step among converters. Compare periods with similar observation time and do not label every open window a permanent loss.
The selected dates define entry, and a scan can extend beyond the entry range to observe later steps, up to the current time. Only retained events can participate. Read the funnel rules before comparing with another analytics tool.
4. Inspect a failed journey#
With the required People permission and module, open funnel participant counts to investigate a journey. The participant list is capped; it is a diagnostic sample of accessible results, not an unlimited export of every visitor.
Check grouped errors and release health for a change near the drop. A new exception in the verification step is a concrete lead. Inspect its stack and release, then reproduce it using your own test account.
If replay was enabled, separately consented to, sampled and retained, inspect the masked recording. Replay covers captured DOM layout and interactions, not the original page's images or a video. Missing replay is not evidence that the visitor had no problem. Replay setup and limits explain the coverage and permissions.
5. Verify the change after a fix#
Use the same events, environment, filters and window settings after releasing a fix. Check that events still arrive, the issue stops recurring, and enough conversion windows have closed to make a fair comparison. Keep acquisition changes, experiments and other releases in view.
Record the observation, the evidence, the change and the remaining uncertainty. Avoid attributing an improvement to one release when several things changed together.
Questions to take into the console#
- Did entrants fall, conversion fall, or both?
- Which exact step changed, and is its observation window complete?
- Did collection, consent or event naming change at the same time?
- Is the effect concentrated in a source, device or release?
- Can an error, trace or retained recording explain a reproducible failure?
For the definitions behind overview and cohort counts, continue with understanding analytics counts. For SDK installation, start with getting started.