Your Signup Funnel Ends in the Inbox: A Teardown of the Verification Drop-Off

Every signup teardown stops at the same place: the submit button. Submit gets treated as the finish line. It isn't. Submit is a handoff — you push the user out of your product and into their inbox, which is an interface you don't control, surrounded by a dozen unread emails and three calendar reminders.

Then they don't come back, and your dashboard calls it a win.

This is a teardown of that gap. One flow: email verification at signup. One goal: get the user from "account created" to "inside the product" without losing them somewhere you can't see.

Why your verification step hides from the funnel dashboard

Most signup funnels are instrumented on the client. The moment the tab closes, you stop hearing from the user. So the data looks like this:

• signup_submitted — fires normally.
• account_created — fires server-side, looks great, gets celebrated.
• ...silence...
• first_session_started — fires two days later for whoever made it.

Everything in between is a black box. Three reasons it stays that way:

• Delivery lives in a different tool. Your email provider knows whether the message was delivered, bounced, or reported as spam. That data never reaches your product analytics unless you deliberately pipe it there.
• The drop-off is silent by default. Someone who never receives the email doesn't file a ticket. They close the tab. You file them under "not a real user."
• Resend rates lie. The people who hit Resend are the persistent ones. Everyone who quietly leaves never touches that button, so the problem looks small.

If your "signup conversion rate" is measured at submit, you're measuring intent, not activation. The real number is further down the flow.

The events to fire before you touch any UI

You can't fix what you can't see, and the front end can't see this. Here's the minimum event set — roughly an afternoon of work if your transactional email provider has webhooks.

Client and server events:

• signup_submitted (client) — email address, plan, referrer, device.
• verification_email_sent (server) — store the provider's message ID on the user record.
• verification_email_delivered / bounced / complained (provider webhook) — the deliverability layer almost