Conversion fell. Meet the people behind the number.

The drop is the easy part

Any funnel shows where people leave. The expensive part is the next hour. You export the ids and paste them into another tool. You look through recordings for the second it went wrong. Then you guess how many other people it hit.

Every drop-off is a person you can open. The number, the people, their replays and the measurement come from one event stream, so each step is a click.

• Ask finds sessions. It judges your recent sessions against one line that you write. It lists the likely matches, strongest first, each with a Match percentage.
• Findings counts. It runs five fixed checks on your sessions: errors, failed requests, clicks that did nothing, angry repeated clicks and quick bounces back. It counts each problem exactly, in sessions and people.

How it works

1. 01

   Meet the people who left.

   Click the Dropped number of a step. The panel Why people dropped here lists who left, the latest first. Click a person: their page highlights the events of the step they reached last.

2. 02

   Watch the moment.

   In the panel, Sessions to watch lists the sessions where they left. ▶ Watch from m:ss opens the replay at the step they reached last. Copy link at m:ss shares that second.

3. 03

   Find others, then the count.

   The panel shows Findings on this step: the findings in the sessions where these people left, in the last 7 days. Describe what you saw in one line, and Ask finds more sessions where it happened.

One drop, start to finish

This example is illustrative. Northlight Outfitters is our fictional demo shop.

Last week about half of Northlight’s carts reached Payment. This week 43% did: 1,000 opened a cart, 720 reached Shipping, 430 reached Payment. Under Payment, the Dropped column says 290: the people who reached Shipping but not Payment. Click it: "290 people left".

Under Sessions to watch, you press ▶ Watch from m:ss on one of them. The replay opens at the shipping step. They type a postcode with a space. The form refuses it. They type it again, then close the tab.

In Ask, you type "typed a postcode, got an error, and left". Ask lists the likely matches. When it can point to the moment, a row shows Watch from here. Its footer says how far it looked: "Searched the 200 most relevant of 1,840 sessions".

Ask finds sessions. It does not count them. Findings counts. The panel already shows one finding under Findings on this step: F-12, Failed request, "POST northlight.example/api/address fails with 422 on /checkout/shipping", in 52 of the 214 sessions where they left (last 7 days). On the Findings page, F-12 counts 52 sessions and 38 users in the last 7 days.

The panel puts the finding next to the drop. It does not say that the finding is the cause. You decide that by watching. The two count different things: people who left, and sessions with the problem. So keep two sentences. For Monday: "290 people left at shipping. An address error, F-12, was in 52 of the sessions where they left."

Your team’s agent files it in Jira as WEB-231. Release 2026.10.09 names F-12. A week later, the finding says Improved: "After 2026.10.09, 10 of 82 sessions had it (7–21%); before, 123 of 300 (36–47%)." The brackets give the likely range of the true rate.

Measured after the release: 41% → 12% of sessions on the shipping page. That is what the rate did, not why.

Let your agent do the legwork

For your engineers: the same investigation runs from Claude Code, Cursor, Codex or Claude Desktop.

• You: Checkout conversion went down this week. Who left at shipping?
• Agent: I ran the funnel: 290 left at Shipping. I followed 100 of them to their replays, then checked Findings. F-12 looks like the same problem: a 422 on the shipping address. It counts sessions on that page, not your 290 people. Three replays from the moment are below. Do you want me to file it in Jira?

The agent gets ids, never IPs. Sequential removes the names, emails and phone numbers that your app sent, as far as it can. Ids come as your app sent them, so if your ids are email addresses, the agent sees those.

The agent files tickets in your own tools. Sequential never touches them. Only a person can let the agent link a fix or record a release.

Good to know

• It shows what happened, not why. You, or your agent, decide the cause.
• You spot the drop. Run the funnel on two date ranges and compare them. When you change the dates and press Apply, the funnel runs again.
• Retention. The hosted preview keeps 7 days of data by default, so a week-on-week funnel may not fit there yet.
• The release measurement is the finding’s rate. It counts sessions on the finding’s page, not your conversion rate. For your conversion rate, run the funnel again before and after the release.
• Ask finds sessions. It does not count them. Funnels and Findings do the counting.
• Findings counts five kinds of problem. A script error or a failed server request opens a finding from its first session. The other kinds need 3 sessions from 2 people in 7 days.

Questions you will ask