Funnels overview
Funnels are multi-screen lead-capture flows. Each funnel is backed by a regular form (so notifications, webhooks, automations, autoresponders, anti-spam, and integrations work the same way) and adds: ordered screens, branching, A/B testing, conversion tracking, and tracking pixels.
A funnel lives at /u/{slug}. The first GET assigns a sticky visitor cookie and (if A/B testing is on) a deterministic variant. Each screen view, next/back, drop, CTA click, and submit is recorded as a funnel_event against a funnel_session.
When a form_collect screen is submitted, a real Submission is created on the underlying form. The submission's payload includes funnel_session_id, funnel_id, and funnel_variant_key so analytics can be joined.
When to use a funnel
Use a funnel when the respondent needs to move through a guided path before you collect their details:
- Lead qualification before a sales handoff.
- A quiz that routes visitors to different offers.
- A campaign-specific landing flow with conversion tracking.
- A multi-step form that should feel lighter than one long page.
Use a classic form when all fields can be shown together and there is no need for screen-by-screen analytics or branching.
Relationship to the underlying form
The form remains the system of record for submissions and downstream processing. The funnel adds the public path, session, screen flow, variant assignment, and event stream. That means existing form settings still matter: spam protection, notifications, autoresponder rules, webhooks, automations, file handling, retention, and exports all run through the same submission pipeline.
What analytics can answer
Because the funnel records events before the final submission, it can show where people abandon the flow. Use screen-level analytics to tune copy and question order, variant analytics to compare offers, and device analytics to catch mobile friction.