L'errore più frequente al checkout costava zero euro

Un e-commerce WooCommerce di circa 2.400 prodotti perdeva ordini al checkout e nessuno sapeva dire dove. Il titolare aveva un elenco di ipotesi raccolte dai clienti al telefono, il fornitore precedente un elenco diverso. Nessuno dei due era un dato.

Il primo passo è stato rendere il checkout osservabile senza farne un problema di privacy: un piccolo plugin che registra dove e perché un tentativo di checkout si ferma, con la sessione salvata come hash e gli indirizzi email oscurati. Niente nomi, niente dati di carte, niente che identifichi una persona. Ha girato qualche settimana e ha dato la prima fotografia reale di quello che succede fra «effettua l’ordine» e un ordine pagato.

Il secondo passo è stato leggerla per esito e non per frequenza. L’errore più frequente, il 35% dei fallimenti, era una casella di consenso non spuntata. Contato per quello che succedeva dopo, non costava niente: ogni cliente che lo incontrava spuntava la casella e completava l’ordine. Gli errori che finivano davvero in una vendita persa erano altri e molto meno frequenti. Partendo dalla tabella delle frequenze, le prime settimane sarebbero andate a lucidare una casella.

Cosa ha indicato l’analisi per esito

Pagamenti con carta e 3-D Secure falliti al primo tentativo. Circa un pagamento con carta su venti falliva la prima verifica 3DS e riusciva pochi minuti dopo; nel frattempo il cliente riceveva un’email di pagamento fallito e poi una di ordine in lavorazione, e qualcuno rinunciava. Riprodotto nella replica locale con un gateway finto, corretto con una pagina di attesa visibile e un’email di fallimento ritardata, senza toccare il modulo del gateway, collaudo ostile di circa 150 prove in quattro passate prima del rilascio. Sui 19 casi osservati, l’email ritardata avrebbe evitato 18 notifiche sbagliate.

Errori su mobile. Il messaggio di validazione e i campi a cui si riferiva erano a 3,3 schermate di distanza su un telefono. Dopo la correzione il cliente viene portato sul campo in errore.

Un percorso PayPal attraverso il gateway che non incassava. Quindici operazioni tutte rimaste in sospeso, circa 380 euro di ordini in cinque giorni. Trovato nei dati della sonda, fermato in giornata, segnalazione al gateway con le prove allegate.

Tempo di creazione dell’ordine. Due sistemi di numerazione giravano in parallelo; tolto il doppione, la mediana è passata da 97,3 a 34,2 ms.

Regole di spedizione lette dal database e non dal pannello, verificate su 348 ordini: con certi coupon restava solo il ritiro in negozio. Un plugin da 11 MB per cinque tariffe sostituito da poche righe di codice, con una matrice di 17 carrelli identica prima e dopo e una vera zona Europa di 26 paesi.

Perché conta

Il lavoro sul checkout di solito si vende come un restyling. Questo è stato una misura: una sonda, una lettura per esito, correzioni nell’ordine dettato dalle perdite. Il budget è andato dove i soldi uscivano, non dove le lamentele erano più forti.

Limiti

Il campione della sonda copre qualche settimana di un negozio di medie dimensioni: le percentuali sono quelle osservate, non proiettate. Nessun aumento del tasso di conversione è dichiarato, perché non è stato fatto un confronto controllato. La stima delle perdite al checkout in euro non è citata: i documenti del progetto la indicano come limite superiore su un campione piccolo.