The most useful fact about mobile conversion is this: when mobile lags desktop badly on the same flow, everything else was held constant. Same offer, same price, same copy, same traffic. The difference is the interface.
That's an unusually clean experiment, and it tells you the problem is physical rather than persuasive. People aren't less interested on a phone. They're being made to work harder.
Where the extra work comes from
The keyboard. It covers up to half the screen. An input positioned low on the page vanishes behind it, and the buyer types blind or gives up. Worse: a numeric field that opens an alphabetic keyboard forces a mode switch on every entry.
Autofill that doesn't fire. Inputs missing `autocomplete` attributes can't be filled by the browser or the password manager. On desktop that's a mild annoyance. On a phone it's the difference between one tap and forty.
Tap targets sized for a cursor. Links crowded together, checkboxes a few pixels across, a "remove" icon adjacent to "buy." Mis-taps aren't just errors; they're a loss of confidence in the page.
Validation rendered off-screen. The buyer submits, nothing appears to happen, and the error sits above the fold they've scrolled past.
Weight. A first screen assembled from large images and blocking scripts on a cellular connection gives doubt time to form.
Interstitials. A cookie banner, a newsletter modal, and a sticky header can consume an entire phone screen before a single word of the promise is visible.
Intent genuinely does differ — account for it before you panic
Some of the gap is real. Mobile traffic skews toward discovery and desktop toward transaction, particularly from social sources. Someone browsing on a phone at lunch may buy on a laptop that evening, and if you read those as two failed sessions you'll misdiagnose a healthy funnel.
So separate the two effects: compare the same step across devices, not overall conversion. If the drop concentrates at a form or a payment screen, that's interface. If it's spread evenly across the whole journey, some of it is intent mix.
A practical mobile audit
Do it on a real phone, on cellular, not a resized browser window.
Time how long until the promise is legible. Count how much of the first screen is banner and header. Tap every input and watch which keyboard appears. Try to complete the flow with autofill. Make a deliberate mistake and see where the error message lands. Try the whole thing one-handed.
Everything that annoyed you is costing you money at scale.
Fix order
Attributes first — `autocomplete`, `inputmode`, `type`. They're a few characters each and they recover the most work per change.
Then position: no critical input in the bottom third where the keyboard lives.
Then targets and spacing. Then first-screen weight. Then the banners.
Defrixa's free scan checks the structural mobile signals — whether the promise survives the first screen, whether one action dominates at phone width, whether the page's weight costs you before it's read.
Common questions
Not usually, because intent mix differs. But a step-level gap — the same form converting half as well — is interface, and it should close.
It doubles your surface area and your bugs. A responsive layout tested on real devices is nearly always the better investment.
Considerably. A modal that occupies a quarter of a desktop screen can occupy all of a phone's, and it arrives before the visitor has read anything.