Mobile generates 70% of traffic and 45% of sales — the gap is entirely in checkout
On the mid-market PrestaShop stores we instrument in 2026, mobile represents an average 71% of traffic and 44% of revenue. The 27-point gap is almost entirely explained by mobile conversion rate being half desktop’s (1.2% vs 2.6% on average). And this differential isn’t explained by purchase intent — we observe equivalent add-to-cart rates — but by checkout friction.
Three precise frictions kill mobile conversion:
- Add-to-cart forcing a scroll up on long product pages — the user has finished reading specs at the bottom, but the add button is at the top, out of viewport.
- Address entry at checkout — typing “47 rue de la République 75011 Paris” on a mobile keyboard takes 45 seconds and generates 2-3 errors on average.
- International phone number entry — for multi-country merchants, asking “type +33 6 12 34 56 78” of a Spanish customer who hesitates between “0034” and “+34” tips 8-12% of carts into abandonment.
These three frictions are independent but cumulative. Fixing them simultaneously doubles the effect: it’s no longer a 2 or 3-point optimisation, it’s typically 6 to 11 points of mobile conversion gain. This article details the mechanics of each lever and the implementation pitfalls.
Lever 1 — Sticky mobile add-to-cart button
Why sticky cart works
A well-built mobile product page is 2,500 to 4,000 pixels tall (title, price, main image, variant selector, description, FAQ, reviews, similar products). The add-to-cart button is in the upper part, around 600-800 px. When the user scrolls to read details, the button disappears from viewport. To buy, they must scroll back — a gesture that interrupts reading and physically signals “you’re not supposed to be here”.
Sticky cart solves this by permanently displaying an add-to-cart button (or express payment) in the lower mobile screen zone, within thumb reach. It’s the bar you see on Amazon, ASOS, Sephora, and any serious mobile-first store.
Anatomy of a well-designed sticky cart
An effective sticky cart contains:
- A product thumbnail (40×40 px) — reminds what you’re buying.
- Unit price (and strikethrough price if on sale).
- Quantity selector (with thumb-accessible + / − controls).
- Add-to-cart button at least 48 px high (recommended Android/iOS tap target).
- Optional but powerful: an express payment button (Apple Pay / Google Pay) directly in the bar, bypassing the intermediate cart.
The express payment button in the sticky is the lever that tips conversion: it transforms a 4-screen journey (page → cart → checkout → confirmation) into 2 screens (page → confirmation). See our article on express payment in 2026.
The three sticky cart pitfalls
1. Premature appearance. A sticky appearing as soon as the mobile page loads hides the main photo and feels intrusive. The rule: appear after 200-400 px of scroll, when the native add button exits viewport. 200ms slide-up animation for visual smoothness.
2. Cumulative with fixed hamburger menu. If the store already has a fixed header at the top, a sticky cart at the bottom eats viewport. On iPhone SE/Mini screens (effective 320×568), 400 px of visible content remains — that’s insufficient to read comfortably. The solution: non-sticky header on mobile (hamburger remains accessible via swipe gesture), sticky cart at bottom only.
3. Conflict with virtual keyboard. When the user types quantity in a sticky cart text field, the iOS/Android keyboard rises and masks the button. The solution: use + / − selectors instead of text fields, or detect visualViewport.height and adapt the sticky.
PrestaShop implementation
The sticky add-to-cart module for PrestaShop injects the bar via the displayFooterProduct hook, with CSS position: fixed; bottom: 0 and a visibility trigger on scroll. The bar is natively responsive (hidden on desktop ≥ 768 px), compatible with variants (price update on variant change), and disable-able per product category (useful for config-heavy products like custom kitchens).
Measured impact: +12 to +18% mobile conversion on long product pages (fashion, electronics, beauty catalogues), neutral to slightly negative on short pages (books, simple accessories). To configure per category according to product profile.
Lever 2 — Checkout address autocompletion
The hidden cost of manual entry
On PrestaShop, the standard address form asks for 5 to 7 fields: number, street (3 optional lines), postcode, city, country, complement. On mobile, each field triggers a keyboard animation, entry errors (French autocorrect transforming “rue” into “ruse”), and high typo risk in postcode or city.
The measurable result: 14 to 22% specific abandonment on the address form, the first drop point in the funnel after account creation. And 4 to 8% of completed orders have an erroneous address generating a delivery failure, return, or credit note.
How Google Places autocompletion works
The user starts typing their address. From 3 characters, a request is sent to the Google Places Autocomplete API which returns a list of structured proposals. The user selects the right one, and the API returns the complete address in standardised components: street number, road, postcode, city, country. These components are automatically mapped to form fields.
Three immediate benefits:
- Entry in 5 to 8 seconds instead of 45 to 60 seconds.
- No typo possible (the address is validated by Google).
- Standardisation: “Rue de la République” is always written the same way, facilitating logistics (route clusters) and BI reporting.
The arithmetic of Google Places API cost
Google Places bills pay-per-use since 2018:
- Autocomplete (per session): $0.017 per session, i.e. ~€0.015.
- Place Details (per request): $0.017 per lookup.
- Free quota: $200/month Google Maps Platform credit (since 2024, watch for changes).
On a store with 5,000 orders/month, that’s about €100 of API cost. ROI is immediate: recovering 1% conversion on 5,000 orders at €80 average basket = +€4,000/month of revenue. Ratio: 1:40.
For very high-volume stores, alternatives exist: Mapbox Search, HERE Maps, OpenStreetMap Photon (free but variable quality per zone). Practical rule: Google Places in France and EU for quality, Mapbox in US, Photon for very low-budget stores accepting reduced coverage.
Implementation pitfalls
1. The “address complement” field pitfall. Google Places doesn’t return the complement (floor, building B, intercom code). Keep a free text field after selection, but don’t make it mandatory (most addresses don’t have one).
2. Poorly indexed rural areas. Google Places covers urban addresses well, less so rural areas (hamlet, country road). Always offer a “manual entry” option as fallback, with a discreet link.
3. Per-country scope. Restricting autocompletion to the selected country via componentRestrictions: { country: 'fr' } drastically improves relevance. Don’t forget to change the scope when the user changes shipping country.
4. Session management. Google bills per session, not per request. A session starts at the first Autocomplete call and ends at a Place Details call, within a few minutes max. Properly managing the session token divides cost by 10.
The Address Lookup module for PrestaShop natively handles these four pitfalls, with per-country configuration, manual fallback, and a correctly managed session token to minimise API cost.
Lever 3 — International phone indicator (E.164)
Why the phone number drives away international visitors
On a French store, the default phone field accepts “06 12 34 56 78”. Readable for a Frenchman. Incomprehensible for a Spanish customer who doesn’t know whether to type their local number (612 345 678), with Spain prefix (+34 612 345 678), or attempt “0034 612 345 678”. The implicit rule is cultural: a French store expects French.
Measured consequence on multi-country PrestaShop stores: 8 to 14% specific abandonment on the phone field for foreign visitors, and 3 to 5% incorrectly entered numbers (no prefix, mis-prefixed). These incorrect numbers derail delivery notification SMS (Chronopost, DPD, Mondial Relay send SMS to the entered number — a mis-prefixed Spanish number is unusable).
The solution: the E.164 standard
E.164 is the ITU-T standard defining the universal international phone number format: +{country code}{local number}, no spaces, max 15 digits. France: +33612345678. Spain: +34612345678. United States: +12025550123.
An international indicator selector displays a clickable flag + indicator, and the user only enters their local number. E.164 format is automatically built. It’s the experience seen on WhatsApp, Telegram, and most modern mobile apps.
The four requirements of a professional E.164 selector
1. Default auto-detection. The initial flag is deduced from selected shipping country, or from geolocated IP if no country chosen. The user doesn’t have to scroll through a list of 240 countries.
2. Real-time validation by national rules. A French mobile starts with 06, 07. Landline 01-05. A Spanish mobile starts with 6, 7. Strict per-country regex validation blocks entry errors immediately. The reference library is Google’s libphonenumber, covering all countries with their rules.
3. Normalised storage in database. The number stored in ps_address.phone or ps_address.phone_mobile is always in E.164 format +33612345678. Display can reformat at read time (“+33 6 12 34 56 78”) but storage is normalised. This facilitates CSV exports, CRM integrations, SMS sending.
4. GDPR-compatible. Phone number is personal data. The selector must respect access, modification and deletion rights at the same level as other fields.
Secondary benefit: SMS reliability
For stores sending SMS (delivery notifications, 2FA codes, promo alerts), E.164 guarantees deliverability. Without it, the number 06 12 34 56 78 stored as-is must be normalised at send — operation failing in 3 to 8% of cases depending on country. With E.164 in database, the SMS always goes to the right number.
PrestaShop implementation
The PrestaShop E.164 international phone indicator module replaces the phone and phone_mobile fields in the address form with a flag + indicator + local number component, based on libphonenumber.js. It integrates via hook on front address forms (creation, modification) and back-office (order entry). Multilingual, multishop, server-side validation in addition to client-side.
The cumulative effect of the three levers
On a PrestaShop store with 70% mobile traffic and 12,000 sessions/month:
| Optimisation | Mobile conversion gain | Monthly revenue gain (€80 basket) |
|---|---|---|
| Baseline | 1.2% | — |
| + Sticky add-to-cart | 1.4% | + €1,920 |
| + Address autocompletion | 1.55% | + €3,360 |
| + E.164 indicator (multi-country) | 1.65% | + €4,320 |
| Total cumulative | 1.65% | + €4,320/month |
The gain is cumulative but non-linear: each lever fixes a different friction point, and the marginal benefit of the third depends on traffic profile (100% France store: E.164 has low impact; 30% EU store: E.164 is as profitable as the other two combined).
Compatibility with the rest of the mobile stack
With express payment
Sticky cart + express payment = winning combo. The Apple Pay/Google Pay button in the sticky enables a 2-click journey: tap on Apple Pay → Face ID biometry → confirmation. Address autocompletion doesn’t even intervene, since the address comes from the Wallet. See our article on express payment in 2026.
With magic link
For identified customers, magic link eliminates login. The shipping address is already in the database, so autocomplete is bonus. The magic link + express payment + sticky cart combo represents the shortest possible mobile checkout in 2026.
With free shipping bar
The free shipping bar can integrate into the sticky cart: “€22 more for free shipping”. Double benefit: permanent threshold visibility + add-to-cart incentive directly from the sticky.
FAQ
Does sticky add-to-cart pollute the desktop experience?
No, provided it’s hidden on viewports ≥ 768 px (tablet landscape and desktop). On desktop, the add-to-cart button is generally visible in the initial viewport without scroll, sticky has no use.
Is address autocompletion compatible with PrestaShop one-page checkout DOM?
Yes. The module attaches to form fields after their creation (DOMContentLoaded event or MutationObserver for dynamically injected forms). Compatible with native PrestaShop 8/9 checkout and most custom checkout modules.
What to do if Google Places refuses an otherwise valid address?
This happens on 2 to 4% of addresses (new constructions, recent addresses not yet indexed). Always offer a “Enter manually” link unlocking native PrestaShop fields. The standard experience is: 95% of users go through autocomplete, 5% via manual — widely sufficient to capture the conversion gain.
Does the E.164 selector work for landline phones?
Yes. libphonenumber distinguishes mobile and landline numbers per country, and validates both. On PrestaShop, the phone address field accepts both; the phone_mobile field can be restricted to mobile numbers via configuration.
What’s the ROI of autocompletion on a 100% France store?
On a single-country France store, address autocomplete typically returns +2 to +4 points of checkout conversion (vs +3 to +6 on multi-country). ROI is positive from a few hundred orders/month, since API cost (€100 for 5,000 orders) remains far below the gain.
In summary
Mobile conversion in 2026 isn’t won with a single lever — it’s won by removing frictions one by one, where they lose customers. Sticky add-to-cart, address autocompletion, E.164 phone indicator are the three most measurable, with a typical cumulative effect of +35 to +50% on mobile conversion and a 30 to 60 day payback on the module investment.
The recommended 2026 mobile stack on PrestaShop combines three complementary modules: sticky add-to-cart, address autocompletion, and E.164 selector. All three are natively responsive, multishop, multilingual, and compatible with PrestaShop 8 and 9.
To go further, Core Web Vitals optimisation remains the foundational mobile layer (LCP, INP, CLS), and GA4 server-side tracking allows measuring conversion delta with reliability, where third-party cookies and iOS 17 erase part of browser-side signals.
