> ## Documentation Index
> Fetch the complete documentation index at: https://docs.trevosdk.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Funnels

> An ordered chain of events that shows where users drop out.

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.

```
landing_view       1,000
signup_started       420   ← 58% drop
signup_completed     380
plan_upgraded         44   ← 88% drop
```

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](/concepts/reading-results). 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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.