askbowtie

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.

  1. 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.
  2. 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.
  3. 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_pages sorted by exit_rate.
  • "Why is the payment page leaking?" -> get_incidents scoped to the page, then get_incident_detail.
  • "Is that step slow, or broken, or both?" -> get_performance for the page + get_incidents.
  • "Is this a mobile problem?" -> get_traffic device split + incidents filtered to the page.
  • "Which landing pages actually produce buyers?" -> get_landing_pages with conversions.
  • "Did conversions move after Tuesday's deploy?" -> get_conversions compared across periods.
  • "How's the funnel overall this month?" -> get_summary for 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: