Indagare gli abbandoni al checkout con compiti e dati
Un caso svolto unisce un test dei compiti su mobile, dati del funnel ed eventi di pagamento prima di pianificare una modifica al checkout.
La differenza tra checkout avviati e completati indica dove iniziare un’indagine. Per una modifica concreta servono anche il percorso osservato e gli eventi tecnici pertinenti. Parta da una domanda circoscritta: dove si blocca un determinato compito d’acquisto sullo smartphone?
Definire prima che cosa si conta
Definisca periodo, tipo di dispositivo e passaggi del funnel. Confronti sessioni contate con le stesse regole; ordini e sessioni sono unità diverse. La documentazione Shopify distingue anche funnel aperti e chiusi. Il confronto è pertinente solo se accessi e sequenze dei passaggi vengono trattati allo stesso modo. Se cambia il sistema di misurazione, verifichi le definizioni prima di ipotizzare un cambiamento nel comportamento.
Un esempio d’indagine svolto
Un negozio fittizio di materiale da disegno vuole esaminare questo compito: scegliere una cartella da disegno, inserire un indirizzo di consegna come ospite, selezionare la spedizione e proseguire al pagamento. Tutti i numeri e le osservazioni della tabella sono inventati; mostrano come riunire riscontri diversi.
Fonte | Riscontro fittizio | Limite dell’interpretazione |
|---|---|---|
Funnel mobile chiuso | 100 sessioni raggiungono il checkout; 60 lo completano nello stesso periodo di osservazione. | La differenza è visibile, ma la causa resta aperta. |
Dopo un codice postale non valido, il testo d’errore si trova fuori dall’area visibile dello schermo. | È un ostacolo concreto in questo percorso. | |
Esame del pagamento | Non è disponibile una richiesta di pagamento collegata a questo compito. | Questo non dimostra un rifiuto della banca. |
Verifichi prima se i registri dei pagamenti rappresentano integralmente l’operazione esaminata. Le voci mancanti possono anche dipendere da un collegamento incompleto. Se risulta che il modulo si blocca prima dell’invio della richiesta di pagamento, aggiungere un metodo di pagamento non corregge quel problema del modulo.
Osservare il compito sul dispositivo reale
Faccia svolgere il compito in un ambiente di test adeguato. Annoti dispositivo, browser, stato della tastiera e ultimo passaggio comprensibile. La persona riconosce quale campo è errato? I dati già inseriti restano disponibili? È possibile correggere l’indirizzo e continuare con la spedizione scelta?
L’esame del pagamento completa l’osservazione. Shopify descrive, per esempio, errori dovuti a decisioni bancarie, al servizio di pagamento o alla configurazione del negozio. Un messaggio generico nell’interfaccia non chiarisce quale caso si presenti. Colleghi gli eventi disponibili alla specifica operazione di test invece di contare tutti gli acquisti incompleti come errori di pagamento.
Trasformare il riscontro in una modifica verificabile
Per l’esempio, la prossima versione del design rende raggiungibile il campo d’indirizzo interessato, descrive lì l’errore con un testo chiaro e conserva gli altri dati. W3C spiega che un errore di inserimento rilevato automaticamente deve essere identificato e descritto con un testo. La modifica proposta non è ancora una valutazione completa dell’accessibilità.
Dopo l’implementazione, ripeta lo stesso compito e poi esamini l’andamento nel funnel definito con le stesse regole. Documenti anche altri cambiamenti, per esempio dell’offerta o delle fonti di traffico. Una prova riuscita dimostra l’usabilità di quel percorso; non dimostra ancora un effetto generale sui ricavi.
Fonti
Continuate a leggere
Tutti gli articoli
E-commerce con ASES
Negozi online, marketplace e portali B2B