Conversion Funnels: Find Where Sessions End (and Why)
Bottom line
You don't need to build a funnel to find its leak. Every session already ends somewhere: sort your pages by exit rate and the leaking step surfaces itself. Then join that page against errors, rage clicks, and load times to learn why sessions die there, and use landing-page data to credit each conversion back to the entry page that earned it. askbowtie doesn't fix your funnel. It detects the failures other tools miss and lets your AI agent answer "where are we losing people, and why" with every number cited.
The problem
Funnel tools make you declare steps up front, then report drop-off percentages. That tells you WHERE the leak is in the abstract, never WHY. A 62% drop at payment could be price shock, a broken gateway, a mobile form that rejects valid cards, or a session timeout that empties the cart. The percentage looks identical in all four cases.
The metric most people reach for makes it worse. Bounce rate is useless mid-funnel: a bounce is a single-page session, and nobody lands directly on step 3 of your checkout. Bounce on /checkout/payment is ~0% by definition, so the page looks healthy while it quietly ends half your purchase intent.
The metric that matters is exit rate: of the sessions that reached this page, what share ended here? Every page has one, whether or not you ever defined a funnel.
The idea: the funnel is already in your data
Traditional funnel analysis is declare-then-measure. askbowtie flips it: measure first, then investigate.
- Find the leak: ask for top pages sorted by exit rate. The page where sessions end at an abnormal rate is your worst funnel step, no configuration required.
- Explain the leak: join that page against incidents (JS errors, dead buttons, rage clicks), performance (LCP, TTFB), and device split. Most "abandonment" that is actually "the button didn't work" shows up here.
- Credit the win: ask for landing pages with conversions. A conversion on /order/confirmed started somewhere; landing-page attribution tells you which entry pages actually produce buyers, so you fix the leak AND feed the pages that fill the funnel.
A real example (demo data)
An agent connected to a store's askbowtie MCP runs get_top_pages sorted by exit_rate over 30 days:
| Page | Sessions | Exit rate | Conversions |
|---|---|---|---|
| /checkout/payment | 780 | 62% | 296 |
| /cart | 1,100 | 34% | 0 |
| /product/anvil-pro | 2,400 | 31% | 0 |
| / | 6,300 | 28% | 0 |
| /checkout | 940 | 17% | 0 |
Site-wide average exit rate is 26% (demo data). One page is wildly out of line: 62% of sessions that reach the payment step end there. That page sees the highest purchase intent on the site, which makes it the highest-ROI page to investigate.
The agent's next question: is anything broken on that page? get_incidents returns an active TypeError: cannot read properties of undefined firing on /checkout/payment, mobile only, 214 sessions affected in the period (demo data). get_incident_detail names the failing selector: the card-number field's formatter. Mobile visitors typed a valid card and the form rejected it.
That is the through-line: a 62% "abandonment rate" was really a detected, fixable JavaScript error. No survey, no session-recording marathon, no guessing.
Then the credit side. get_landing_pages for the same period (demo data):
| Landing page | Sessions | Conversions | Conv. rate |
|---|---|---|---|
| /product/anvil-pro | 1,850 | 121 | 6.5% |
| / | 3,900 | 98 | 2.5% |
| /blog/anvil-buying-guide | 1,200 | 61 | 5.1% |
The blog guide out-converts the homepage 2:1 per session. Fixing the payment bug recovers revenue; feeding the buying guide grows it.
Why sessions end: the four silent failures
High exit rate is a symptom. These are the causes that never appear in a funnel report, because they don't announce themselves:
| Failure | What the visitor sees | Where it shows up in askbowtie |
|---|---|---|
| Payment gateway error | "Pay" does nothing, or a vague error | get_incidents (JS errors, failed clicks on checkout pages) |
| Form validation break | Valid input rejected, card won't format | get_incident_detail (failing selector + message), rage clicks |
| Mobile breakage | Buttons unreachable, form unusable on phones | device split in get_traffic, incidents filtered to the page |
| Slow step | Page hasn't rendered, visitor is gone | get_performance (LCP/TTFB per page vs baseline) |
Two behavioral notes. Rage clicks on a checkout element almost always mean "broken," not "impatient": see rage clicks. And a session timeout that empties the cart looks like a normal exit in analytics; it only surfaces when you notice returning sessions re-entering the funnel at step one.
Checkout deserves the most scrutiny because average cart abandonment runs around 70% industry-wide. Some of that is price shock and browsing. But the preventable share is concentrated in exactly these four failures, and they hit the visitors with the highest intent. The deep-dive is here: why customers abandon checkout.
Mobile vs desktop: segment before you conclude
Mobile usually converts lower. That alone proves nothing. Segment first (demo data):
| Metric | Desktop | Mobile |
|---|---|---|
| Sessions | 4,200 | 5,800 |
| Conversion rate | 4.8% | 1.9% |
| Payment-page exit rate | 31% | 74% |
A gap in conversion rate can be research behavior (browse on phone, buy on desktop). A gap in exit rate on one specific step is a defect until proven otherwise. In the example above, the mobile payment exit rate is the card-formatter bug from earlier, not "mobile users convert worse."
What the leak costs
Turn the exit rate into money before you argue about priorities:
weekly cost = sessions exiting the step per week
× completion rate you'd expect from that step
× average order value
With 300 weekly exits at payment, a 60% expected completion from that point, and an $85 average order (demo data):
300 × 0.60 × $85 = $15,300/week at stake
Numbers like that turn "we should look at checkout sometime" into a ticket with a deadline. Slow steps compound this: check Core Web Vitals on every high-intent page, because a slow checkout loses more than a slow blog post ever will.
Questions you can now answer
Ask Bowtie in plain language; each maps to one or two tool calls:
- "Where do sessions end on my site?" ->
get_top_pagessorted by exit_rate. - "Why is the payment page leaking?" ->
get_incidentsscoped to the page, thenget_incident_detail. - "Is that step slow, or broken, or both?" ->
get_performancefor the page +get_incidents. - "Is this a mobile problem?" ->
get_trafficdevice split + incidents filtered to the page. - "Which landing pages actually produce buyers?" ->
get_landing_pageswith conversions. - "Did conversions move after Tuesday's deploy?" ->
get_conversionscompared across periods. - "How's the funnel overall this month?" ->
get_summaryfor the joined health picture.
MCP reference (for agents)
Core loop for funnel-leak diagnosis:
get_top_pages { domain, period?, sort?, limit? }-> per-page sessions, exit_rate, conversions. Sort by exit_rate; a page far above the site average is the leaking step. Ignore bounce mid-funnel (it is ~0% by definition on pages nobody lands on).get_landing_pages { domain, period? }-> entry pages with sessions and conversions. Conversions are credited to the session's landing page, so this answers "which entry pages fill the funnel," the complement of "which step drains it."get_incidents { domain, period? }-> active issues ranked by business impact (JS errors, broken elements, rage-click clusters). Filter mentally to your leaking page.get_incident_detail { domain, incident }-> failing URLs, error messages, CSS selectors. This is where "abandonment" becomes "the card formatter throws on mobile."get_performance { domain, period?, page? }-> TTFB/LCP against baseline, per page. A leaking step that is also slow has two problems; fix the error first, the speed second.get_traffic { domain, period? }-> sessions with device split, for the mobile-vs-desktop cut.get_conversions { domain, period? }-> conversion counts and rates for before/after comparison once a fix ships.get_summary { domain }-> the joined briefing (traffic + conversions + errors) to open or close an investigation.
Recommended agent loop: get_top_pages sorted by exit_rate -> flag pages well above the site's average exit rate, weighted by sessions -> get_incidents + get_performance on the worst offender -> get_incident_detail for the failing selector -> quantify with the weekly-cost formula -> after the fix ships, get_conversions and get_top_pages again to verify the exit rate fell.
Gotchas (state these correctly):
- Exit rate on low-traffic pages is noise. Read sessions before ranking; do not flag a 70% exit rate on 12 sessions.
- Some pages SHOULD have high exit rates (order confirmation, contact-success). Judge exit rate against the page's job, not the site average alone.
- Landing-page conversion credit is entry attribution, not full multi-touch. Say "sessions that landed on X converted at Y%," never "X drove Y% of revenue."
- Correlation discipline: an error on a leaking page is a strong lead, not proof. Verify by shipping the fix and watching the exit rate move.
For a step-by-step guide on diagnosing conversion drops across all your metrics at once, see how I diagnose a conversion drop.
Related pages
Parent: Conversion Tracking covers what to track and how conversions are recorded.
Deep dive: Why Customers Abandon Checkout stays on the highest-ROI step: the 70% problem and the silent failures behind it.
Adjacent:
- Error Monitoring catches the technical failures that masquerade as abandonment.
- Prioritizing Errors by Revenue Impact is the framework for deciding what to fix first.
- Performance & Uptime covers the slow steps that end sessions before they render.