El móvil hace el 70 % del tráfico y el 45 % de las ventas — la diferencia está enteramente en el checkout
En las tiendas PrestaShop mid-market que instrumentamos en 2026, el móvil representa de media el 71 % del tráfico y el 44 % de la facturación. La diferencia de 27 puntos es casi enteramente explicable por la tasa de conversión móvil inferior en la mitad al escritorio (1,2 % vs 2,6 % de media). Y ese diferencial no se explica por la intención de compra — se observan tasas de adición al carrito equivalentes — sino por la fricción del checkout.
Tres fricciones precisas matan la conversión móvil:
- La adición al carrito que obliga a un scroll hacia arriba en las páginas de producto largas — el usuario ha terminado de leer las características al final de la página, pero el botón de añadir está arriba del todo, fuera del viewport.
- La introducción de la dirección en el checkout — teclear «Calle Mayor 47, 28013 Madrid» en un teclado móvil lleva 45 segundos y genera 2 o 3 errores de media.
- La introducción del número de teléfono internacional — para los comerciantes multi-país, pedir «teclee +33 6 12 34 56 78» a un cliente español que duda entre «0034» y «+34» hace bascular el 8-12 % de los carritos al abandono.
Estas tres fricciones son independientes pero acumulativas. Corregirlas a la vez duplica el efecto: ya no es una optimización de 2 o 3 puntos, es típicamente una ganancia de 6 a 11 puntos de conversión móvil. Este artículo detalla la mecánica de cada palanca y las trampas de implementación.
Palanca 1 — El botón de añadir al carrito sticky móvil
Por qué funciona el sticky cart
Una ficha de producto móvil bien hecha mide entre 2 500 y 4 000 píxeles de altura (título, precio, imagen principal, selector de variación, descripción, FAQ, reseñas, productos similares). El botón de añadir al carrito está en la parte alta, alrededor de 600-800 px. Cuando el usuario hace scroll para leer los detalles, el botón desaparece del viewport. Para comprar, debe hacer scroll hacia atrás — un gesto que interrumpe la lectura y señala físicamente «no se supone que estás aquí».
El sticky cart resuelve este problema mostrando permanentemente un botón de añadir al carrito (o de pago exprés) en la zona inferior de la pantalla móvil, al alcance del pulgar. Es la barra que vemos en Amazon, ASOS, Sephora y cualquier tienda móvil-first seria.
Anatomía de un sticky cart bien diseñado
Un sticky cart eficaz contiene:
- Una miniatura del producto (40×40 px) — recuerda lo que se está comprando.
- El precio unitario (y el precio tachado si está en promoción).
- El selector de cantidad (con controles + / − accesibles con el pulgar).
- Un botón de añadir al carrito de al menos 48 px de altura (target táctil recomendado Android/iOS).
- Opcional pero potente: un botón de pago exprés (Apple Pay / Google Pay) directamente en la barra, que se salta el carrito intermedio.
El botón de pago exprés en el sticky es la palanca que hace bascular la conversión: transforma un recorrido en 4 pantallas (ficha → carrito → checkout → confirmación) en 2 pantallas (ficha → confirmación). Véase nuestro artículo sobre el pago exprés en 2026.
Las tres trampas del sticky cart
1. Aparición demasiado temprana. El sticky que aparece desde la carga de la página móvil oculta la foto principal y se percibe como intrusivo. La regla: aparición tras 200-400 px de scroll, cuando el botón de añadir nativo sale del viewport. Animación de slide-up de 200 ms para la suavidad visual.
2. Acumulación con el menú hamburguesa fijo. Si la tienda ya tiene un header fijo arriba, el sticky cart abajo se come viewport. En las pantallas iPhone SE/Mini (320×568 efectivo), quedan 400 px de contenido visible — insuficiente para leer cómodamente. La solución: header no-sticky en móvil (la hamburguesa queda accesible vía gesto swipe), sticky cart solo abajo.
3. Conflicto con el teclado virtual. En el momento en que el usuario teclea la cantidad en un campo texto del sticky cart, el teclado iOS/Android sube y enmascara el botón. La solución: usar selectores + / − en lugar de campos texto, o detectar visualViewport.height y adaptar el sticky.
Implementación en PrestaShop
El módulo sticky add-to-cart para PrestaShop inyecta la barra vía el hook displayFooterProduct, con CSS position: fixed; bottom: 0 y un trigger de visibilidad en el scroll. La barra es nativamente responsive (oculta en escritorio ≥ 768 px), compatible con las variaciones (actualización del precio al cambio de variante) y desactivable por categoría de producto (útil para los productos config-heavy como cocina a medida).
Impacto medido: +12 a +18 % de conversión móvil en las fichas de producto largas (catálogo moda, electrónica, belleza), neutro o ligeramente negativo en las fichas cortas (libros, accesorios simples). A configurar por categoría según el perfil del producto.
Palanca 2 — El autocompletado de dirección en el checkout
El coste oculto de la introducción manual
En PrestaShop, el formulario de dirección estándar pide 5-7 campos: número, calle (3 líneas en opción), código postal, ciudad, país, complemento. En móvil, estos campos disparan cada uno una animación del teclado, errores de introducción (autocorrector que transforma «calle» en «calla»), y un riesgo elevado de typo en el código postal o la ciudad.
El resultado medible: del 14 al 22 % de abandono específicamente en el formulario de dirección, primer punto de caída del túnel tras la creación de cuenta. Y el 4-8 % de los pedidos terminados tienen una dirección errónea que genera un fallo de entrega, una devolución o un abono.
Cómo funciona el autocompletado Google Places
El usuario empieza a teclear su dirección. A partir de 3 caracteres, se envía una solicitud a la API Google Places Autocomplete que devuelve una lista de propuestas estructuradas. El usuario selecciona la correcta, y la API devuelve la dirección completa en componentes normalizados: número de calle, vía, código postal, ciudad, país. Estos componentes se mapean automáticamente sobre los campos del formulario.
Tres beneficios inmediatos:
- Introducción en 5 a 8 segundos en lugar de 45 a 60 segundos.
- Ningún typo posible (la dirección está validada por Google).
- Estandarización: «Calle Mayor» siempre se escribe igual, lo que facilita la logística (clústeres de rutas) y el reporting BI.
La aritmética del coste de la Google Places API
Google Places factura por pay-per-use desde 2018:
- Autocomplete (per session): 0,017 $ por sesión, unos 0,015 €.
- Place Details (per request): 0,017 $ por lookup.
- Cuota gratuita: 200 $/mes de crédito Google Maps Platform (desde 2024, atención: evoluciona).
En una tienda con 5 000 pedidos/mes, son unos 100 € de coste API. El ROI es inmediato: recuperar el 1 % de conversión sobre 5 000 pedidos a 80 € de carrito medio = +4 000 €/mes de facturación. Ratio: 1:40.
Para las tiendas con mucho volumen existen alternativas: Mapbox Search, HERE Maps, OpenStreetMap Photon (gratuito pero calidad variable según la zona). La regla práctica: Google Places en Europa para la calidad, Mapbox en EE. UU., Photon para las tiendas con presupuesto muy bajo que aceptan menor cobertura.
Las trampas de implementación
1. La trampa del campo «complemento de dirección». Google Places no devuelve el complemento (piso, edif. B, código del portero). Hay que mantener un campo texto libre después de la selección, pero sin hacerlo obligatorio (la mayoría de las direcciones no lo tienen).
2. Las zonas rurales mal indexadas. Google Places cubre bien las direcciones urbanas, peor las zonas rurales (paraje, carretera comarcal). Siempre ofrecer una opción «introducir manualmente» como fallback, con un enlace discreto.
3. El perímetro por país. Restringir el autocompletado al país seleccionado vía componentRestrictions: { country: 'es' } mejora drásticamente la relevancia. No olvidar cambiar el perímetro cuando el usuario cambia el país de entrega.
4. La gestión de sesiones. Google factura por sesión, no por solicitud. Una sesión empieza en la primera llamada Autocomplete y termina en una llamada Place Details, en un plazo máximo de unos minutos. Gestionar bien el session token divide el coste entre 10.
El módulo Address Lookup para PrestaShop gestiona estas cuatro trampas de forma nativa, con configuración por país, fallback manual y un session token correctamente gestionado para minimizar el coste API.
Palanca 3 — El prefijo telefónico internacional (E.164)
Por qué el número de teléfono hace huir a los visitantes internacionales
En una tienda española, el campo teléfono por defecto acepta «612 34 56 78». Es legible para un español. Es incomprensible para un cliente francés que no sabe si debe teclear su número local (06 12 34 56 78), con prefijo Francia (+33 6 12 34 56 78) o intentar «0033 6 12 34 56 78». La regla implícita es cultural: una tienda española espera del español.
Consecuencia medida en las tiendas PrestaShop multi-país: del 8 al 14 % de abandono específico en el campo teléfono para los visitantes extranjeros, y del 3 al 5 % de números introducidos incorrectos (sin prefijo, mal prefijados). Esos números incorrectos hacen descarrilar los SMS de notificación de entrega (Correos, SEUR, MRW envían SMS al número introducido — un número francés mal prefijado es inutilizable).
La solución: el estándar E.164
E.164 es el estándar ITU-T que define el formato universal de los números de teléfono internacionales: +{prefijo país}{número local}, sin espacios, máx. 15 dígitos. Para España: +34612345678. Para Francia: +33612345678. Para Estados Unidos: +12025550123.
Un selector de prefijo internacional muestra una bandera clicable + el prefijo, y el usuario introduce únicamente su número local. El formato E.164 se construye automáticamente. Es la experiencia que vemos en WhatsApp, Telegram y la mayoría de las aplicaciones móviles modernas.
Las cuatro exigencias de un selector E.164 profesional
1. Detección automática por defecto. La bandera inicial se deduce del país de entrega seleccionado, o de la IP geolocalizada si no hay país elegido. El usuario no tiene que hacer scroll en una lista de 240 países.
2. Validación en tiempo real por reglas nacionales. Un número español móvil empieza por 6 o 7. Un número francés móvil empieza por 06, 07. La validación por regex estricta por país bloquea los errores de introducción inmediatamente. La librería de referencia es libphonenumber de Google, que cubre todos los países con sus reglas.
3. Almacenamiento normalizado en base de datos. El número almacenado en ps_address.phone o ps_address.phone_mobile está siempre en formato E.164 +34612345678. La visualización puede reformatearlo en lectura («+34 612 34 56 78») pero el almacenamiento está normalizado. Esto facilita las exportaciones CSV, las integraciones CRM, los envíos SMS.
4. Compatible RGPD. El número de teléfono es un dato personal. El selector debe respetar los derechos de acceso, modificación y supresión al mismo título que los demás campos.
Beneficio secundario: la fiabilidad de los SMS
Para las tiendas que envían SMS (notificaciones de entrega, códigos 2FA, alertas promo), el E.164 garantiza la entregabilidad. Sin él, el número 612 34 56 78 almacenado tal cual debe normalizarse en el envío — operación que falla en el 3-8 % de los casos según el país. Con E.164 en base, el SMS sale siempre al número correcto.
Implementación en PrestaShop
El módulo prefijo telefónico internacional PrestaShop E.164 reemplaza los campos phone y phone_mobile del formulario de dirección por un componente con bandera + prefijo + número local, basado en libphonenumber.js. Se integra vía hook en los formularios de dirección front (creación, modificación) y back-office (introducción de pedido). Multilingüe, multishop, validación en el lado servidor además del lado cliente.
El efecto acumulado de las tres palancas
En una tienda PrestaShop con un 70 % de tráfico móvil y 12 000 sesiones/mes:
| Optimización | Ganancia conversión móvil | Ganancia facturación mensual (carrito 80 €) |
|---|---|---|
| Baseline | 1,2 % | — |
| + Sticky add-to-cart | 1,4 % | + 1 920 € |
| + Autocompletado de dirección | 1,55 % | + 3 360 € |
| + Prefijo E.164 (multi-país) | 1,65 % | + 4 320 € |
| Total acumulado | 1,65 % | + 4 320 €/mes |
La ganancia es acumulativa pero no lineal: cada palanca corrige un punto de fricción distinto, y el beneficio marginal de la tercera depende del perfil de tráfico (tienda 100 % España: E.164 tiene un impacto bajo; tienda 30 % UE: E.164 es tan rentable como las otras dos juntas).
Compatibilidad con el resto del stack móvil
Con el pago exprés
Sticky cart + pago exprés = combo ganador. El botón Apple Pay/Google Pay en el sticky permite un recorrido en 2 clics: tap en Apple Pay → biometría Face ID → confirmación. El autocompletado de dirección ni siquiera interviene, ya que la dirección viene del Wallet. Véase nuestro artículo sobre el pago exprés en 2026.
Con el magic link
Para los clientes identificados, el magic link elimina el login. La dirección de entrega ya está en base, así que el autocomplete es un bono. El combo magic link + pago exprés + sticky cart representa el checkout móvil más corto posible en 2026.
Con la barra de envío gratuito
La barra de envío gratuito puede integrarse en el sticky cart: «Solo 22 € más para el envío gratuito». Doble beneficio: visibilidad permanente del umbral + incentivo a añadir al carrito directamente desde el sticky.
FAQ
¿El sticky add-to-cart contamina la experiencia escritorio?
No, siempre que esté oculto en los viewports ≥ 768 px (tableta landscape y escritorio). En escritorio, el botón de añadir al carrito generalmente es visible en el viewport inicial sin scroll, el sticky no tiene utilidad.
¿El autocompletado de dirección es compatible con el DOM por checkout en una página de PrestaShop?
Sí. El módulo se adjunta a los campos del formulario tras su creación (evento DOMContentLoaded o MutationObserver para los formularios inyectados dinámicamente). Compatible con el checkout nativo PrestaShop 8/9 y con la mayoría de los módulos de checkout custom.
¿Qué hacer si Google Places rechaza una dirección que sin embargo es válida?
Ocurre en el 2-4 % de las direcciones (construcciones nuevas, direcciones recientes aún no indexadas). Siempre ofrecer un enlace «Introducir manualmente» que desbloquee los campos nativos de PrestaShop. La experiencia estándar es: el 95 % de los usuarios pasan por el autocomplete, el 5 % por el manual — es ampliamente suficiente para recuperar la ganancia de conversión.
¿El selector E.164 funciona para los teléfonos fijos?
Sí. libphonenumber distingue los números móviles y fijos por país, y valida ambos. En PrestaShop, el campo phone de la dirección acepta los dos; el campo phone_mobile puede restringirse a los números móviles vía la configuración.
¿Cuál es el ROI del autocompletado en una tienda 100 % España?
En una tienda mono-país España, el autocomplete de dirección aporta típicamente +2 a +4 puntos de conversión checkout (vs +3 a +6 en multi-país). El ROI es positivo desde unas pocas centenas de pedidos/mes, ya que el coste API (100 € por 5 000 pedidos) sigue siendo muy inferior a la ganancia.
En síntesis
La conversión móvil en 2026 no se gana con una sola palanca — se gana eliminando las fricciones una a una, allí donde hacen perder clientes. Sticky add-to-cart, autocompletado de dirección, prefijo telefónico E.164 son las tres más medibles, con un efecto acumulado típico del +35 al +50 % en la conversión móvil y un payback de 30 a 60 días sobre la inversión en módulos.
La pila móvil recomendada 2026 en PrestaShop combina tres módulos complementarios: el sticky add-to-cart, el autocompletado de dirección y el selector E.164. Los tres son nativamente responsive, multishop, multilingüe y compatibles con PrestaShop 8 y 9.
Para ir más lejos, la optimización Core Web Vitals sigue siendo la capa fundamental del móvil (LCP, INP, CLS), y el server-side tracking GA4 permite medir el delta de conversión con fiabilidad, ahí donde las cookies de terceros e iOS 17 borran una parte de las señales del lado navegador.
