Our Signup Conversion Drop Left No Error, No 500, and No Event

The session opened at 5:37 PM with a request to check whether some unknown bug was killing conversions on our newest signups. The signup walk that answered it is logged at 2:18 PM the next afternoon, and it took 7 minutes.

Asking the data for a bug

The conversion drop was real. New signups on the platform had gone bad, and the tempting move was to ask for evidence first. So we told the agent to hunt for an unknown bug that would explain it. The plan was to look at what the funnel recorded, find the step where people fell off, and work backward.

That plan assumed the failure would show up as an event: an error, a 500, a step with a suspicious cliff. Two of the three things that turned out to be wrong are not events. A landing page that takes about 18 seconds to load on a phone throws no error. The visitor leaves before any of your instrumentation has a reason to fire. The question sat open for roughly 21 hours of wall clock, and the funnel data was the wrong instrument for what was broken. What ended the wait was giving up on the data and doing what a prospect does.

The walk

We had the agent walk the signup as a prospect, start to finish, on a phone-sized viewport and then on desktop. It logged three findings:

1. Mobile landing page load: about 18 seconds. Any check that starts after the page has loaded never sees this.
2. The email field truncates, then rejects. Paste a long address and the field cuts it off. Then validation rejects the cut version. The prospect gets an error on an address they typed correctly.
3. Existing customers get told their invite link is expired. A returning customer who follows a signup or invite link is shown an expiry message instead of being sent to log in. The link is fine. The state check has no branch for “this person already has an account.”

None of these leaves a clean trace. The truncated email produces a validation failure that looks like user error. The expired-invite message looks like a legitimate rejection. If you counted them, they would land in the same bucket as ordinary bad input.

Why the walk found them and the query wouldn’t

Each finding lived in the gap between what the system did and what a person experienced. The system did what it was told. The page loaded eventually, the field validated what it received, and the invite check returned expired for a link it did not recognize as belonging to a known account. Every component was correct against its own spec. A prospect meets the whole chain at once, and the chain was broken in three places.

Telemetry can tell you where people stopped. It cannot tell you what they saw when they stopped, and that second thing was what we needed. We still want the instrumentation, because after the fix it will confirm whether the numbers moved. But three concrete defects in hand beat a chart that points at a step and shrugs.

What went into the ticket

The findings went into one ticket with the fix plan attached, three items long. The load time is a front-end performance job. The email field has a length limit and a validation path that disagree with each other. The expired-invite message needs a branch that checks for an existing account and redirects to login.

The next step on our side is the boring one. After each fix lands, we walk the signup again, on a phone, as a stranger, before we trust any number that says it worked. Twenty-one hours of asking the data got us nothing, and the walk got us all three defects.

If signups drop

Walk the signup as a prospect, on a phone and on desktop, before you wait on analytics. Keep the instrumentation to confirm the fix, and re-walk after each one.

dxdev LESSON · paste into your AI coding agent
LESSON: Walk The Funnel As A Prospect Before Chasing Telemetry
SOURCE: dxdev.com/blog/walking-the-funnel-beats-telemetry
WHAT HAPPENED: New-signup conversion dropped, so the initial investigation asked an agent to find an unknown bug in funnel data. That approach assumed the cause would appear as an event or an obvious drop-off, but the key failures did not produce clean traces. Walking the signup end to end found that the mobile landing page took about 18 seconds to load, long email addresses were truncated before being rejected, and existing customers using an invite or signup link were incorrectly told it had expired. The findings became a single ticket with fixes for performance, email length and validation alignment, and redirecting existing accounts to login. The team plans to repeat the signup walk on a phone as a stranger after each fix lands.
THE RULE: When conversion falls, run the full journey in the conditions a prospect actually faces before relying on telemetry to explain the drop. Instrumentation can show where people stopped, but an end-to-end walk exposes what they experienced across the chain.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Measure the landing page on a phone-sized viewport and verify it becomes usable before funnel instrumentation would otherwise begin.
      2. Paste a long valid email address and verify the field does not silently truncate it before validation.
      3. Follow a signup or invite link while already signed in or using an existing account and verify the flow redirects to login rather than reporting an expired link.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.