A client shares his GA4 screen with me, last three months. 71% of sessions come from a phone; 38% of revenue does too. He comments before I say anything: "we need more traffic." No. He needs to keep the traffic that already arrives and leaves. Those thirty points of gap are not some law of mobile: they are four checkout screens designed for a mouse, a wide display and a wired connection, then served to a thumb on a 4G network with a keyboard eating half the page.
This article looks at exactly where margin leaks in a mobile funnel, what the most solid public data actually says, and above all in which order to fix things when you have neither a redesign budget nor enough traffic to test forever.
On mobile you almost never lose a customer because they changed their mind. You lose them because you asked them to do, on six inches and with one hand, what you designed for a keyboard and a mouse.
The mobile/desktop gap is real, but it isn't an intent problem
Start with the number that frames the debate. Contentsquare's 2026 benchmark, built on 99 billion sessions across more than 6,500 sites, puts the average conversion rate at 3.4% on desktop against 2% on mobile, desktop converting roughly 75% better. In retail alone the gap holds: 3.7% versus 2%. This isn't an anomaly on your site; it's a market-wide gap.
The reflex explanation is familiar: "people browse on mobile and buy on desktop." It is partly true and entirely misleading, because it turns friction into fate. Baymard's m-commerce research offers a far less comfortable reading: 43.2% of smartphone and tablet users say they abandoned an order during checkout in the past two months, and 61% sometimes or always switch to a computer to finish a purchase started on mobile. That switch is not a usage preference. It's a workaround. And by definition not everyone bothers to work around: the rest simply leave.
The form is the first place margin leaks
This is the most measured and most ignored point of all. Baymard's checkout benchmark database finds that the average checkout displays 23.48 form elements by default (14.88 if you count only fillable fields), while their usability testing shows an ideal flow fits in 12 to 14 elements (7 to 8 actual fields). In other words, most sites ask for roughly twice what they need. On a desktop that's annoying. On a phone, every extra field means a keyboard sliding up, a page jumping, an accidental zoom, a field disappearing under your thumb.
Among the abandonment reasons Baymard records once you set aside "I was just browsing", 18% of shoppers leave because the site forces account creation and 17% because the checkout is too long or too complicated. The account should be offered after payment, on the confirmation page, with a password as the only remaining input, never before, never as a condition of buying.
The highest-return technical lever fits in one attribute. A properly marked-up funnel fills in with a single tap: web.dev's guide to payment and address form best practices spells out the values to use (autocomplete="given-name", "shipping postal-code", "cc-number"…), with name and id attributes that stay stable across deployments. That stability is what lets the browser recognise the form. Add a coherent inputmode to summon the right keyboard, billing defaulting to shipping, and you have just removed some thirty keystrokes on a touchscreen.
Costs that show up too late
Across all cart abandonment (for which Baymard maintains a documented average of 70.22%, computed from 50 studies), 42% is plain window shopping, and nothing can be done about it. But among the rest, the leading cause hasn't moved in a decade: 40% leave because extra costs (shipping, tax, fees) are too high or discovered too late, and 12% because they couldn't see the total before committing.
Mobile mechanically worsens this: the order summary is almost always below the fold, collapsed behind a "see details" nobody opens. The customer discovers €6.90 of shipping at step three, after typing their address. The fix doesn't require a redesign: show the free-shipping threshold on the product page and in the cart, estimate shipping before asking for an email address, and keep a persistent expandable summary at the top of the funnel. Same logic for timing, 20% of abandonments come down to delivery judged too slow: show a date, not a number of business days nobody converts mentally.
Interaction latency, not load time
We talk endlessly about load speed and almost never about response speed. They are different things: LCP measures rendering, while INP (Interaction to Next Paint) measures the delay between a tap and the moment the screen reacts. The recommended threshold is 200 ms at the 75th percentile, and Google's documentation is explicit on the point that matters here: INP problems show up mostly on mobile, and testing from a desktop machine always paints a flattering picture.
The symptom is easy to spot in a session recording: tap "Add to cart", nothing moves for 600 ms, the user taps again. Result: two items in the cart, or a flat exit. That's not a bug, it's a saturated main thread, usually third-party scripts (chat, testing tool, a tag manager that grew without an inventory) executing exactly when the user interacts. It lines up with another Baymard figure: 17% of abandonments are blamed on "errors or the site crashing". On mobile, latency that lasts long enough is a crash, from the point of view of the person holding the phone. This work overlaps directly with Core Web Vitals, which is therefore not only an SEO matter.
The six leak points, and the order to fix them in
| Leak point | What you observe | Fix | Effort |
|---|---|---|---|
| Forced account | Exit spike on the login screen | Guest checkout by default, account offered after payment | Low |
| Costs revealed late | Exits at the shipping step, high carts abandoned | Free-shipping threshold and estimate on the product page | Low |
| Invisible order summary | Repeated back-and-forth between cart and shipping | Persistent expandable summary at the top of the funnel | Low |
| Limited payment | Exits on the payment screen, declined cards | Wallet (Apple Pay / Google Pay) as first option | Low |
| Form too long | Completion rate drops between address and payment | Down to 7-8 fields, correct autocomplete and inputmode | Medium |
| Tap latency (INP) | Double add-to-cart, visible re-taps in session recordings | Trim third-party scripts, defer non-critical ones | Medium |
The order isn't decorative: it runs from low-effort, immediate-effect fixes to actual engineering projects. On a modest-traffic site, the first four rows can be handled in a week of development and measured without an A/B test, because a removed blocker reads directly in the step completion rate.
Payment: fewer steps rather than more options
Three of Baymard's abandonment reasons revolve around payment: 19% don't trust the site with their card number, 10% see their card declined, 9% can't find the payment method they wanted. The mobile wallet solves all three at once: no card entry, biometric authentication, shipping address already known, and trust transferred to Apple or Google rather than a site the buyer is discovering. In effect-to-effort terms it is the single best investment in a mobile funnel.
The opposite reflex, stacking five payment methods to cover everyone, moves the problem without solving it: the screen gets longer, choice paralyses, and you add length exactly where you meant to remove friction. A wallet first, card next, possibly instalments if the average basket justifies it. And, wherever possible, no redirect off-site: every domain hop on mobile is a chance to lose the session.
The most expensive mistake
Launching a mobile redesign before looking at where people actually drop off. Three months of work, a serious budget, and most often the same assumptions carried over in fresh clothing. The reverse order costs ten times less: instrument the funnel step by step segmented by device, watch twenty mobile session recordings that end in an exit, fix the two or three frictions they reveal, and only then ask whether a redesign is still needed. Corollary of the same flaw: don't test a button colour when your funnel shows twenty-three fields. At that stage it isn't an A/B test question, it's an engineering one.
Measure the mobile funnel separately, or you see nothing
An aggregate conversion rate tells you nothing actionable. If mobile is 70% of sessions and converts half as well, it drags the average down and you conclude there's a site-wide problem, while desktop is in fact doing fine. What you need is the step-by-step completion rate, segmented by device: cart → identification → shipping → payment → confirmation. The step where mobile falls away relative to desktop is your leak, and it is rarely where you assumed. Alongside the quantitative view, the qualitative one settles arguments fast: twenty well-chosen mobile session recordings beat three meetings of hypotheses.
One measurement caveat: since consent, part of the mobile journey is modelled rather than observed, and the gap between tools widens, all the more reason to reconcile against the back office, as I detail in what GA4 can no longer see. On the ground the stake is concrete: for an event ticketing campaign I ran on Meta Ads, the purchase journey came almost exclusively from a phone. At a cost per ticket around €2.66, every friction added between the ad and the payment is paid for immediately in acquisition cost. Funnel optimisation and media optimisation are the same subject seen from two ends.
In the crucible: turning mobile traffic into margin
Mobile isn't a browsing channel that converts poorly by nature. It has become the primary channel, served by journeys designed for another device, and the conversion gap mostly measures that inheritance. The lead, here, is the traffic you buy in volume to compensate for a leaking funnel; the gold is exactly the same traffic run through a journey that fits in one thumb. Baymard puts the average conversion gain still available on large sites through checkout quality alone at 35.26%, that is, without buying a single extra visit.
If your traffic is mobile and your revenue is desktop, the gap is measurable and, for the most part, repairable. I audit the funnel step by step, device by device, and rank the fixes by their effect on margin as part of my CRO expertise, working alongside analytics measurement and e-commerce architecture.
Traffic on mobile, sales on desktop?
I instrument your funnel step by step, compare mobile against desktop stair by stair, and hand you a list of fixes ranked by effect on margin, not a three-month redesign.