Conversão mobile 2026 no PrestaShop: sticky cart, preenchimento automático de morada e indicativo E.164, a trilogia que desbloqueia o checkout mobile

O mobile faz 70 % do tráfego e 45 % das vendas: a diferença está toda no checkout

Nas lojas PrestaShop de média dimensão que instrumentamos em 2026, o mobile representa em média 71 % do tráfego e 44 % da faturação. A diferença de 27 pontos explica-se quase inteiramente pela taxa de conversão mobile, metade da do desktop (1,2 % vs 2,6 % em média). E este diferencial não se explica pela intenção de compra, observam-se taxas de adição ao carrinho equivalentes, mas pela fricção do checkout.

Três fricções precisas matam a conversão mobile:

1. A adição ao carrinho que força um scroll para cima nas páginas de produto longas: o utilizador acabou de ler as características no fundo da página, mas o botão de adição está no topo, fora do viewport.
2. O preenchimento da morada no checkout: digitar « Rua Almirante Reis 47, 1150-012 Lisboa » num teclado mobile leva 45 segundos e gera 2 a 3 erros em média.
3. A introdução do número de telefone internacional: para os comerciantes multipaís, pedir « digite +351 912 345 678 » a um cliente espanhol que hesita entre « 0034 » e « +34 » faz cair 8 a 12 % dos carrinhos no abandono.

Estas três fricções são independentes mas cumulativas. Corrigi-las ao mesmo tempo duplica o efeito: já não é uma otimização de 2 ou 3 pontos, é tipicamente um ganho de 6 a 11 pontos de conversão mobile. Este artigo detalha a mecânica de cada alavanca e as armadilhas de implementação.

Alavanca 1: o botão de adição ao carrinho fixo em mobile

Porque é que o sticky cart funciona

Uma ficha de produto mobile bem feita mede 2 500 a 4 000 pixels de altura (título, preço, imagem principal, seletor de variação, descrição, FAQ, avaliações, produtos similares). O botão de adição ao carrinho está na parte alta, à volta dos 600-800 px. Quando o utilizador faz scroll para ler os detalhes, o botão desaparece do viewport. Para comprar, tem de voltar atrás, um gesto que interrompe a leitura e sinaliza fisicamente « não é suposto estares aqui ».

O sticky cart resolve o problema mostrando em permanência um botão de adição ao carrinho (ou de pagamento expresso) na zona baixa do ecrã mobile, ao alcance do polegar. É a barra que vê na Amazon, na ASOS, na Sephora, e em qualquer loja mobile-first séria.

Anatomia de um sticky cart bem concebido

Um sticky cart eficaz contém:

• Uma miniatura do produto (40×40 px): lembra o que se está a comprar.
• O preço unitário (e o preço riscado se em promoção).
• O seletor de quantidade (com controlos + / − acessíveis ao polegar).
• Um botão de adição ao carrinho com pelo menos 48 px de altura (alvo tátil recomendado Android/iOS).
• Opcional mas poderoso: um botão de pagamento expresso (Apple Pay / Google Pay) diretamente na barra, que salta o carrinho intermédio.

O botão de pagamento expresso no sticky é a alavanca que faz bascular a conversão: transforma um percurso de 4 ecrãs (ficha → carrinho → checkout → confirmação) em 2 ecrãs (ficha → confirmação). Ver o nosso artigo sobre o pagamento expresso em 2026.

As três armadilhas do sticky cart

1. Aparição precoce demais. O sticky que aparece logo no carregamento da página mobile esconde a foto principal e é percebido como intrusivo. A regra: aparição após 200-400 px de scroll, quando o botão de adição nativo sai do viewport. Animação de slide-up de 200 ms para a suavidade visual.

2. Acumulação com o menu hamburger fixo. Se a loja já tem um header fixo no topo, o sticky cart em baixo come viewport. Nos ecrãs iPhone SE/Mini (320×568 efetivo), restam 400 px de conteúdo visível, insuficiente para ler confortavelmente. A solução: header não fixo em mobile (o hamburger continua acessível por gesto), sticky cart só em baixo.

3. Conflito com o teclado virtual. No momento em que o utilizador digita a quantidade num campo de texto do sticky cart, o teclado iOS/Android sobe e esconde o botão. A solução: usar seletores + / − em vez de campos de texto, ou detetar visualViewport.height e adaptar o sticky.

Implementação no PrestaShop

O módulo sticky add-to-cart para PrestaShop injeta a barra pelo hook displayFooterProduct, com CSS position: fixed; bottom: 0 e um trigger de visibilidade ao scroll. A barra é nativamente responsive (escondida em desktop ≥ 768 px), compatível com as variações (atualização do preço na mudança de variante), e desativável por categoria de produto (útil para os produtos muito configuráveis como cozinhas por medida).

O impacto medido: +12 a +18 % de conversão mobile nas fichas de produto longas (catálogo moda, eletrónica, beleza), neutro a ligeiramente negativo nas fichas curtas (livros, acessórios simples). A configurar por categoria consoante o perfil de produto.

Alavanca 2: o preenchimento automático de morada no checkout

O custo escondido do preenchimento manual

No PrestaShop, o formulário de morada standard pede 5 a 7 campos: número, rua (3 linhas em opção), código postal, cidade, país, complemento. Em mobile, cada um destes campos aciona uma animação do teclado, erros de digitação (o autocorretor que « arranja » os nomes de rua), e um risco elevado de gralha no código postal ou na cidade.

O resultado mensurável: 14 a 22 % de abandono especificamente no formulário de morada, o primeiro ponto de queda do funil depois da criação de conta. E 4 a 8 % das encomendas terminadas têm uma morada errada que gera uma falha de entrega, uma devolução, ou um crédito.

Como funciona o preenchimento automático Google Places

O utilizador começa a digitar a morada. A partir de 3 caracteres, um pedido é enviado à API Google Places Autocomplete que devolve uma lista de propostas estruturadas. O utilizador seleciona a boa, e a API devolve a morada completa em componentes normalizados: número, via, código postal, cidade, país. Estes componentes são automaticamente mapeados nos campos do formulário.

Três benefícios imediatos:

• Preenchimento em 5 a 8 segundos em vez de 45 a 60 segundos.
• Nenhuma gralha possível (a morada é validada pela Google).
• Padronização: « Rua da República » escreve-se sempre da mesma forma, o que facilita a logística (clusters de rotas) e o reporting BI.

A aritmética do custo da Google Places API

A Google Places fatura em pay-per-use desde 2018:

• Autocomplete (per session): 0,017 $ por sessão, cerca de 0,015 €.
• Place Details (per request): 0,017 $ por lookup.
• Quota gratuita: 200 $/mês de crédito Google Maps Platform (desde 2024, atenção que evolui).

Numa loja com 5 000 encomendas/mês, são cerca de 100 € de custo de API. O ROI é imediato: recuperar 1 % de conversão em 5 000 encomendas a 80 € de carrinho médio = +4 000 €/mês de faturação. Rácio: 1:40.

Para as lojas muito volumosas, existem alternativas: Mapbox Search, HERE Maps, OpenStreetMap Photon (gratuito mas qualidade variável consoante a zona). A regra prática: Google Places na UE pela qualidade, Mapbox nos EUA, Photon para as lojas de orçamento muito baixo que aceitam menor cobertura.

As armadilhas de implementação

1. A armadilha do campo « complemento de morada ». A Google Places não devolve o complemento (andar, bloco B, código do intercomunicador). Há que manter um campo de texto livre depois da seleção, mas sem o tornar obrigatório (a maioria das moradas não tem).

2. As zonas rurais mal indexadas. A Google Places cobre bem as moradas urbanas, menos bem as zonas rurais (lugares, estradas municipais). Oferecer sempre uma opção « introduzir manualmente » em recurso, com uma ligação discreta.

3. O perímetro por país. Restringir o preenchimento automático ao país selecionado via componentRestrictions: { country: 'pt' } melhora drasticamente a relevância. Não esquecer de mudar o perímetro quando o utilizador muda o país de entrega.

4. A gestão das sessões. A Google fatura por sessão, não por pedido. Uma sessão começa ao primeiro Autocomplete e termina num Place Details, num prazo máximo de alguns minutos. Gerir bem o session token divide o custo por 10.

O módulo Address Lookup para PrestaShop gere estas quatro armadilhas nativamente, com configuração por país, recurso manual, e um session token corretamente gerido para minimizar o custo de API.

Alavanca 3: o indicativo telefónico internacional (E.164)

Porque é que o número de telefone faz fugir os visitantes internacionais

Numa loja portuguesa, o campo de telefone por defeito aceita « 912 345 678 ». É legível para um português. É incompreensível para um cliente espanhol que não sabe se deve digitar o seu número local (612 345 678), com prefixo Espanha (+34 612 345 678), ou tentar « 0034 612 345 678 ». A regra implícita é cultural: uma loja portuguesa espera um número português.

Consequência medida nas lojas PrestaShop multipaís: 8 a 14 % de abandono específico no campo de telefone para os visitantes estrangeiros, e 3 a 5 % de números introduzidos incorretos (sem prefixo, mal prefixados). Estes números incorretos fazem descarrilar os SMS de notificação de entrega (os CTT, a DPD e as outras transportadoras enviam SMS para o número introduzido; um número espanhol mal prefixado é inutilizável).

A solução: o standard E.164

O E.164 é o standard ITU-T que define o formato universal dos números de telefone internacionais: +{indicativo do país}{número local}, sem espaços, máximo 15 dígitos. Para Portugal: +351912345678. Para Espanha: +34612345678. Para os Estados Unidos: +12025550123.

Um seletor de indicativo internacional mostra uma bandeira clicável + o indicativo, e o utilizador introduz apenas o número local. O formato E.164 é construído automaticamente. É a experiência que se vê no WhatsApp, no Telegram, e na maioria das aplicações móveis modernas.

As quatro exigências de um seletor E.164 profissional

1. Autodeteção por defeito. A bandeira inicial é deduzida do país de entrega selecionado, ou do IP geolocalizado se nenhum país estiver escolhido. O utilizador não tem de percorrer uma lista de 240 países.

2. Validação em tempo real por regras nacionais. Um número móvel português começa por 9; um fixo por 2. Um móvel espanhol começa por 6 ou 7. A validação por regex estrita por país bloqueia imediatamente os erros de digitação. A biblioteca de referência é a libphonenumber da Google, que cobre todos os países com as suas regras.

3. Armazenamento normalizado em base. O número guardado em ps_address.phone ou ps_address.phone_mobile está sempre no formato E.164 +351912345678. A exibição pode reformatá-lo na leitura (« +351 912 345 678 ») mas o armazenamento é normalizado. Isso facilita as exportações CSV, as integrações CRM, os envios de SMS.

4. Compatível com o RGPD. O número de telefone é um dado pessoal. O seletor deve respeitar os direitos de acesso, retificação e apagamento como os outros campos.

Benefício secundário: a fiabilidade dos SMS

Para as lojas que enviam SMS (notificações de entrega, códigos 2FA, alertas promo), o E.164 garante a entregabilidade. Sem isso, o número 912 345 678 guardado tal e qual tem de ser normalizado no envio, operação que falha em 3 a 8 % dos casos consoante o país. Com E.164 em base, o SMS parte sempre para o número certo.

Implementação no PrestaShop

O módulo de indicativo telefónico internacional PrestaShop E.164 substitui os campos phone e phone_mobile do formulário de morada por um componente com bandeira + indicativo + número local, baseado em libphonenumber.js. Integra-se por hook nos formulários de morada do front (criação, alteração) e do back-office (introdução de encomenda). Multilingue, multiloja, validação do lado do servidor além do lado do cliente.

O efeito acumulado das três alavancas

Numa loja PrestaShop com 70 % de tráfego mobile e 12 000 sessões/mês:

O ganho é cumulativo mas não linear: cada alavanca corrige um ponto de fricção diferente, e o benefício marginal da terceira depende do perfil de tráfego (loja 100 % Portugal: o E.164 tem um impacto fraco; loja 30 % UE: o E.164 é tão rentável como as outras duas juntas).

Compatibilidade com o resto da stack mobile

Com o pagamento expresso

Sticky cart + pagamento expresso = combinação vencedora. O botão Apple Pay/Google Pay no sticky permite um percurso em 2 cliques: tap no Apple Pay → biometria Face ID → confirmação. O preenchimento automático de morada nem sequer intervem, já que a morada vem do Wallet. Ver o nosso artigo sobre o pagamento expresso em 2026.

Com o magic link

Para os clientes identificados, o magic link elimina o login. A morada de entrega já está em base, portanto o preenchimento automático é um bónus. A combinação magic link + pagamento expresso + sticky cart representa o checkout mobile mais curto possível em 2026.

Com a barra de portes grátis

A barra de portes grátis pode integrar-se no sticky cart: « Faltam 22 € para a entrega gratuita ». Duplo benefício: visibilidade permanente do limiar + incentivo à adição ao carrinho diretamente do sticky.

FAQ

O sticky add-to-cart polui a experiência desktop?

Não, desde que fique escondido nos viewports ≥ 768 px (tablet landscape e desktop). No desktop, o botão de adição ao carrinho está geralmente visível no viewport inicial sem scroll, o sticky não tem utilidade.

O preenchimento automático de morada é compatível com o checkout numa página?

Sim. O módulo liga-se aos campos do formulário depois da sua criação (evento DOMContentLoaded ou MutationObserver para os formulários injetados dinamicamente). Compatível com o checkout nativo do PrestaShop 8/9 e com a maioria dos módulos de checkout personalizados.

Que fazer se a Google Places recusa uma morada válida?

Acontece em 2 a 4 % das moradas (construções novas, moradas recentes ainda não indexadas). Oferecer sempre uma ligação « Introduzir manualmente » que desbloqueia os campos nativos do PrestaShop. A experiência standard: 95 % dos utilizadores passam pelo preenchimento automático, 5 % pelo manual, o que chega largamente para recuperar o ganho de conversão.

O seletor E.164 funciona para os telefones fixos?

Sim. A libphonenumber distingue os números móveis e fixos por país, e valida os dois. No PrestaShop, o campo phone da morada aceita ambos; o campo phone_mobile pode ser restringido aos números móveis via configuração.

Qual é o ROI do preenchimento automático numa loja 100 % nacional?

Numa loja de um só país, o preenchimento automático de morada rende tipicamente +2 a +4 pontos de conversão checkout (vs +3 a +6 em multipaís). O ROI é positivo a partir de algumas centenas de encomendas/mês, porque o custo de API (100 € para 5 000 encomendas) fica muito abaixo do ganho.

Em síntese

A conversão mobile em 2026 não se ganha com uma só alavanca: ganha-se suprimindo as fricções uma a uma, lá onde fazem perder clientes. Sticky add-to-cart, preenchimento automático de morada e indicativo telefónico E.164 são as três mais mensuráveis, com um efeito acumulado típico de +35 a +50 % na conversão mobile e um payback de 30 a 60 dias no investimento em módulos.

A stack mobile recomendada 2026 no PrestaShop combina três módulos complementares: o sticky add-to-cart, o preenchimento automático de morada, e o seletor E.164. Os três são nativamente responsive, multiloja, multilingues, e compatíveis com o PrestaShop 8 e 9.

Para ir mais longe, a otimização dos Core Web Vitals continua a ser a camada fundamental do mobile (LCP, INP, CLS), e o server-side tracking GA4 permite medir o delta de conversão com fiabilidade, lá onde os cookies de terceiros e o iOS 17 apagam parte dos sinais do lado do navegador.