Skip to main content
An experiment answers “did this change help?”. A funnel answers “where are we losing people?” — which is usually the question you have first. A funnel is an ordered list of events. Trevo counts how many users reached each step, so the gaps between steps show you where to look.
Two things stand out immediately: most people never start signing up, and most who complete signup never upgrade. Those are your two candidate experiments, and you didn’t have to guess.

​
Building one

Funnels → New funnel in your workspace — or let Trevo draft funnels from your live events with Generate funnels. Give the funnel a name, then add each step from the event picker, in the order visitors reach them. Minimum two steps. Steps can be events your app already sends — or events that don’t exist yet. Type a new name like card_entered and it’s saved as a planned event. On its next pass over your repository, Trevo’s agent finds where that moment actually happens (the payment form, the signup submit, the upgrade button) and opens a single pull request wiring track() for every planned event the workspace is still missing — one tracking PR per repository at a time. You review it like any teammate’s PR; once it merges, the events start flowing and the funnel starts recording. AI-generated funnels name events the same way and rely on the same PR. Until that PR merges, a step whose event never fires shows zero — it isn’t an error, just an empty column, and it’s the most common reason a new funnel looks unfinished.

​
Ordering and attribution

Steps are ordered. A user counts toward step 3 only if they also reached steps 1 and 2 — that’s what makes the drop-off between steps meaningful rather than a set of unrelated counters. Steps are attributed within a fixed 14-day window: a later step counts only if the user reached it within 14 days of entering the funnel at step 1. (Configurable attribution windows exist on experiments, not funnels.)

​
Funnels and experiments together

This is where they earn their keep. A funnel tells you where to experiment; an experiment tells you whether your fix worked. Concretely: the funnel above says 58% of visitors never start signing up. So you run an experiment on the landing page CTA, with signup_started as the decision metric — the exact step the funnel identified as leaky. And the step after your target makes a natural guardrail. If the new CTA lifts signup_started but signup_completed falls, you didn’t win — you just attracted people who bounce one screen later. Without the funnel you’d have shipped it.

​
Choosing events

Good funnel steps are the moments that genuinely matter to your product, not every click you can capture:
  • Entry — landing_view, app_opened
  • Intent — signup_started, checkout_started
  • Completion — signup_completed, purchase_completed
  • Value — plan_upgraded, first_project_created
Four to six steps is usually right. Too few and the drop-offs are too coarse to act on; too many and every step looks fine because the losses are spread thin.

​
What Trevo funnels are not

This is a focused conversion view, not a full product-analytics suite. There is no autocapture, no session replay, no retention curves, no cohort explorer. Trevo collects what it needs to run and settle experiments. If you want to explore user behaviour broadly, keep a dedicated analytics tool and use Trevo for experimentation. The two answer different questions.