Il 70% del traffico arrivava da mobile, ma il checkout era pensato per desktop e impiegava 6 secondi ad arrivare al pagamento. L'abbiamo riscritto mobile-first: -48% di abbandoni.
Il cliente è un e-commerce D2C con un catalogo consolidato e campagne social che funzionavano: il traffico cresceva trimestre su trimestre, soprattutto da Instagram e TikTok, quindi da mobile.
Ma la crescita del traffico non si traduceva in ordini. Il carrello si riempiva, il checkout lo svuotava. Il tasso di abbandono al pagamento era il doppio del benchmark di settore.
Ho instrumentato ogni step del checkout e registrato sessioni reali. Tre colli di bottiglia, tutti evitabili:
6 secondi per arrivare al form di pagamento. Il checkout caricava l'intero bundle del sito, più tre script di terze parti bloccanti, prima di mostrare qualsiasi cosa.
5 schermate, 23 campi, zero autofill. Su mobile significava minuti di digitazione. Ogni campo in più era una percentuale di utenti in meno.
Errori di rete = carrello perso. Su connessioni mobili instabili un timeout buttava via l'intero stato del checkout. L'utente ricominciava da capo. O più spesso, non ricominciava.
Dati da tracking lato client su 30 giorni. (Numeri placeholder, da sostituire con i dati reali.)
Invece di ottimizzare il checkout esistente, l'ho sostituito con un flusso nuovo e brutalmente ridotto: una sola pagina, progettata per il pollice, non per il mouse.
One-page checkout mobile-first. Un'unica schermata con i 7 campi davvero necessari, autofill nativo del browser e wallet (Apple Pay / Google Pay) come prima scelta: pagamento in 2 tap.
Stato persistente e offline-friendly. Ogni campo salvato localmente man mano: un timeout o un refresh non buttano via niente. Il carrello sopravvive alla metropolitana.
Payment element isolato dal resto del sito. Il checkout carica solo il codice che gli serve: 1.2 secondi al form di pagamento anche su rete 4G, misurati sul percentile 75.
Non puoi fermare la cassa di un negozio aperto. Il nuovo checkout è andato in produzione dietro feature flag, prima sul 10% del traffico mobile, con il vecchio flusso come fallback istantaneo. Nessun ordine perso durante la transizione.
Il secondo rischio era contabile: ogni modifica al checkout tocca pagamenti veri. Ogni release è stata accompagnata da riconciliazione automatica ordini-transazioni, così qualsiasi discrepanza sarebbe emersa in ore, non a fine mese.
Pensavamo servisse un redesign del sito. Omar ci ha mostrato che il problema era un imbuto rotto in fondo al funnel, e l'ha sistemato senza toccare il resto. Testimonial placeholder, da sostituire con quote reale.
Parliamone: 30 minuti per capire il problema e dirti onestamente se posso aiutarti.
Prenota una call di 30 min Altri casi studio