Ottimizzare un Processo di Conversione (Senza Split Test)

Ci sono alcuni casi in cui non è possibile ottimizzare un processo tramite Split Test (A/B test o multivariate).

Il principale motivo è la scarsità di risultati: se un processo non genera sufficienti conversioni sarà pressoché impossibile ottenere dei valori statisticamente attendibili (in un arco temporale accettabile) per capire se la variante testata è effettivamente migliore rispetto al controllo.

In questi casi è necessario seguire un approccio diverso ovvero quello della riduzione dell’attrito. Questo per un semplice motivo:

L’attrito genera resistenza alla conversione!

Ad esempio:

• gli utenti abbandoneranno un sito se impiega più di 3 secondi per caricarsi;
• il 79% dei consumatori non tornerà su un e-commerce che li fa aspettare troppo;
• secondo Radware, un secondo di ritardo nel caricamento della pagina equivale a una perdita del 7% nel tasso di conversione.

Messa più semplicemente: minore è l’attrito, migliori sono i risultati.

Oltre a ottimizzare la velocità di caricamento, ci sono molti aspetti su cui possiamo intervenire per migliorare le conversioni, prima fra tutti l’usabilità.

In questo articolo vedremo alcuni interventi che ho implementato su Marketing Academy per rendere il processo di acquisto più fluido e lineare e, si spera, migliorarne i risultati.

Premessa

Un paio di mesi fa ho cambiato gateway di pagamento. È una cosa che succede in media ogni 2 o 3 anni.

Nel 2002 ho iniziato usando un gateway tedesco (ShareIt). Era perfetto per le mie necessità dell’epoca: vendevo software online e offriva tutto ciò di cui avevo bisogno (generatore di licenze, template personalizzabili, email transazionali, etc.).

Nel 2011 lo stato italiano, tanto amico di noi imprenditori, cambiò le regole e per i clienti aziendali italiani passare per un gateway tedesco diventò più oneroso (dichiarazione Intrastat mensile / trimestrale, etc.). Per questo creai un semplice script per ricevere gli ordini online (nulla di speciale, ma faceva il suo dovere).

Un paio di anni dopo, decisi di passare a WHMCS, un software nato per i fornitori di hosting che riadattai e personalizzai per integrarlo con la nostra piattaforma di distribuzione dei contenuti.

Arrivati al 2016, insieme al nuovo sito Marketing Academy decisi di abbandonare WHMCS (pieno di bug e buchi di sicurezza) e mi misi a cercare un’alternativa.

La scelta ricadde su PayPro, un servizio canadese che offre un semplice backend per la gestione dei prodotti e vari template per il frontend abbastanza “carini”. Il mio problema (la mia maledizione se vogliamo) è che non mi accontento mai della soluzione standard.

Nei prossimi paragrafi affronteremo step by step i vari interventi fatti e, molto più importante, le motivazioni che mi hanno spinto in una specifica direzione. Spero che questi spunti ti siano utili per il tuo prossimo progetto di riduzione dell’attrito.

Perciò, facciamo un bel respiro, e vediamo cosa ne viene fuori.

L’Obiettivo

L’obiettivo che mi sono posto è eliminare il maggior numero possibile di punti di attrito, distrazioni e problemi in modo da rendere la conversione più semplice e fluida possibile.

Come sempre si comincia con quello che si ha già a disposizione.

Design Standard

Il gateway prescelto offre un flessibile sistema di template per creare il processo di conversione che si desidera.

Ci sono processi mono step e multi step, diverse tipologie di form di registrazione, sezioni di offerte / upsell / cross sell e così via.

Il design iniziale che si ottiene con le impostazioni di default non è male. Per iniziare ho scelto un processo su pagina singola suddiviso in vari step lato client tramite Javascript

Ogni passo appare semplice e facile da compiere, inoltre l’utilizzo di Javascript offre il beneficio di non richiedere un’ulteriore chiamata HTTP per poter procedere, riducendo i tempi di caricamento e aumentando la soddisfazione del cliente.

Cosa Non Mi Piace

Il primo passo quando faccio uno studio di ottimizzazione di questo tipo è quello di elencare gli elementi che non mi piacciono, tutto ciò che mi distrare e quello che mi annoia.

In questo caso:

• La sidebar laterale è un’enorme fonte di distrazione. Visto che tutti i clienti di Marketing Academy acquistano in Euro e parlano in italiano, la relativa sezione può essere tranquillamente rimossa.
• I loghi di sicurezza sono certamente un elemento da mantenere, ma nella posizione attuale sono un po’ sacrificati e hanno poca rilevanza con la conversione.
• Il totale del carrello (nel mio caso specifico) è un’informazione ridondante. Il 99% dei clienti acquista un solo prodotto per transazione per questo è inutile che il sito gli ricordi in ogni fase quanto andrà a spendere (dolore psicologico). Per cui ecco un altro elemento da eliminare.

Prime Modifiche

Dopo aver apportato queste prime modifiche già si possono vedere dei benefici. Il design è più sintetico e ci sono meno distrazioni che allontanano dall’azione di conversione. Ma siamo solo all’inizio

Cose Che Mi Annoiano

Proseguendo l’attività di ottimizzazione mi focalizzo sulle cose che mi annoiano, come il logo del gateway.

Non capisco per quale motivo moltissimi gestori di e-commerce non si prendano la briga di personalizzare la pagina di pagamento con il proprio logo, design e riferimenti aziendali. La maggior parte dei gateway offre questa funzionalità (in modo più o meno accentuato) e solitamente è un’attività una tantum che permette di sfruttare il potere della coerenza come leva persuasiva.

Un altro aspetto che mi annoia molto sono i testi dei bottoni. In alcuni casi sono un mezzo Camel Case (testo minuscolo e prime lettere maiuscole) in altri sono TUTTO MAIUSCOLO e poi c’è quell’orrendo “INVA ORDINE”.

In alcuni casi me la sfango con un semplice CSS (sia lodato !important), mentre per le modifiche più importanti (non potendo accedere al file delle traduzioni) mi tocca implementare una soluzione in Javascript.

Stranamente l’ultimo bottone INDIETRO presente nel processo ha un colore grigio leggermente più accentuato rispetto al bottone precedente. Dato che in questa fase non vogliamo assolutamente attirare l’attenzione su un tasto che fa rimandare l’acquisto, modifico il CSS per riportarlo alle impostazioni del precedente. È importanti ricordarsi che il cervello umano, a livello subconscio, è un potente identificatore di pattern. Qualsiasi cosa che esca da questi pattern (es. un pulsante nella stessa posizione, con la stessa forma e lo stesso testo ma colore diverso) attira molto l’attenzione.

Un elemento che elimino sempre è l’opzione per inserire il coupon di sconto. Quando una persona vede questo campo in un processo di conversione la prima cosa che pensa è:

Io non ho un coupon? Se avessi un coupon potrei risparmiare! Aspetta un attimo che vado online a cercare un coupon valido...

Questa la chiamo la conversazione del “Coupon Uccidi Conversioni”. Invece di avere questa funzione nel checkout è molto meglio creare una pagina ad-hoc sul proprio sito dove inviare gli utenti che ricevono un coupon. In alternativa, come nel mio caso, è preferibile implementare un sistema che includa il coupon all’interno di un URL dedicato.

Questa soluzione prende 3 piccioni con una fava:

• l’utente risparmia grazie allo sconto
• non viene fermato dalla richiesta del coupon
• non deve perdere tempo ad inserirlo manualmente perché lo passo direttamente al gateway tramite il parametro dedicato.

Ti è mai capitato di vedere un’offerta (online od offline) del tipo “19,00 Euro” che se la guardi da lontano sembra 190 o, peggio, 1900 Euro. Se un valore termina per 00, soprattutto quando si riferisce a un costo, è preferibile non mostrare i centesimi. Per questo, quando il totale è netto, un paio di righe Javascript si occupano di normalizzare il campo IVA e i due totali mostrati sulla pagina.

Campi Personalizzati

Per creare un account su Marketing Academy ho bisogno di 3 informazioni: nome, cognome e indirizzo email dello studente. Dato che molto spesso l’intestatario della fattura e/o chi si occupa dell’ordine non è la persona che effettivamente accederà ai contenuti, devo aggiungere al processo 3 campi personalizzati per raccogliere queste informazioni.

Il problema è che, di default, questi campi vengono inseriti nella sezione relativa ai dati di pagamento. Dal mio punto di vista questa scelta è completamente illogica così ho abilitato la funzione di modifica avanzata del template e spostato i campi personalizzati nella sezione dedicata alla fatturazione.

E qui incontro un piccolo problema: i campi non vengono validati dal gateway. In questo modo potrei ricevere degli ordini senza le informazioni necessarie, creando ritardi e disguidi nella consegna dei dati di accesso (pessima esperienza per il cliente).

Apro un ticket di supporto ma la cosa non viene risolta in modo soddisfacente così mi armo di una santa pazienza e riscrivo lo script di validazione (c’è voluto molto più tempo di quanto desiderassi).

Princing Table

Sul sito web, la prima pagina del processo di conversine è quella con la pricing table.

La struttura di questa pagina è molto semplice:

• Headline con Call To Action diretta (comando implicito)
• Sottotitolo con benefici chiave (accesso illimitato, intera libreria)
• 4 liveli di prezzo (mensile / annuale, singolo / team)
• Feedback degli studenti
• Sezione FAQ per gestione obiezioni

Uno dei primi elementi che ho implementato è stato un sistema per gestire i coupon di sconto (per approfondire questo argomento, ti suggerisco di leggere l’articolo One Time Offer su Facebook). Quando l’utente arriva sul sito tramite il link di una offerta viene mostrata una barra orizzontale con lo sconto applicato:

Per rendere la cosa più chiara ho dovuto trovare un modo per aggiornare anche i valori mostrati nella pricing table. Il problema tipico che si incontra quando si usa un tema WordPress sviluppato da terzi è quello di modificare il comportamento di blocchi di contenuti strutturati come questa tabella dei prezzi.

Nel mio caso il tema è stato creato in modo da supportare gli shortcode all’interno di tutti i campi.

In questo modo ho potuto creare una semplice funzione per riscrivere i valori nel caso in cui sia stato applicato uno sconto.

Problema Inaspettato

A questo punto mi sentivo tutto bello e soddisfatto. Il processo funzionava correttamente e le conversioni iniziavano ad arrivare. Poi un cliente mi contatta per chiedermi dove poteva inserire i dati di fatturazione (nello specifico azienda e partita IVA). Letta l’email sono rimasto sgomento: e io che pensavo che funzionasse tutto perfettamente…

Il problema dipendeva dal fatto che il cliente, in fase di ordine, non aveva selezionato il checkbox “Acquisto aziendale” e i due campi richiesti non erano stati mostrati. Ho scelto di usare un gateway di pagamento esterno (e pagare le relative fee) per evitare di dovermi preoccupare di queste cose e ora ero (quasi) punto a capo 🙁

La questione era semplice: come offrire la migliore esperienza di registrazione a clienti privati e aziendali senza rischiare che:

• i privati dovessero de-selezionare l’opzione “Acquisto aziendale”
• le aziende dovessero selezionare l’opzione “Acquisto aziendale”

Pagina Intermedia

La migliore idea che mi è venuta in mente è stata quella di creare una pagina intermedia tra il sito e il gateway di pagamento che mi permettesse di segmentare queste due tipologie di clienti.

La pagina in questione dovrebbe avere lo stesso design del gateway di pagamento in modo che il passaggio sia il meno traumatico possibile per l’utente (psicologicamente parlando).

Per prima cosa devo decidere come suddividere i due target. In questa fase ho valutato diverse domande:

• Sei un privato o una azienda?
  Cosa dovrebbe farebbe il libero professionista?
• Come vuoi registrarti?
  Una alternativa potrebbero essere tre bottoni: privato, professionista e azienda. Ma con tre scelte diverse la cosa si fa complicata. Magari solo due pulsanti: privato e professionista / azienda, ma il design risultante sarebbe terribile.

Alla fine opto per un semplice “Hai la partita IVA?” Si / No

Se l’utente clicca sul no (privato) viene indirizzato direttamente al gateway di pagamento per completare la sua iscrizione.

Se risponde di si, tramite Javascript mostro una semplice form composta da un solo campo per l’inserimento della partita IVA e il bottone “Continua >>” per portarlo sul gateway di pagamento.

Questa soluzione mi permette di usare due template diversi in funzione della tipologia dell’utente:

• per i privati la normale registrazione (senza il checkbox “Acquisto aziendale”)
• per i possessori di partita IVA un modello con i campi “Nome dell’azienda” e “Partita IVA”

E quest’ultimo campo risulta già precompilato con il valore inserito dall’utente nello step precedente.

Pre-compilazione

Ora le cose iniziano a farsi interessanti. La maggior parte dei miei clienti hanno la partita IVA per cui molti me la forniranno nella pagina intermedia. Non sarebbe una vera figata riuscire a usare questa informazione per precompilare altre informazioni come l’azienda, l’indirizzo, la città etc.?

Un paio di minuti di ricerca online e trovo vari servizi che offrono un’API per questo tipo di ricerche. Mi registro a vatlayer e scrivo una semplice funzione per estrarre i dati e passarli come parametri nella querystring al gateway di pagamento.

Per ottimizzare l’efficacia di questa API utilizzo anche MaxMind per identificare con una buona approssimazione il luogo di provenienza dell’utente. In questo modo, nel caso in cui il cliente non inserisca le due lettere del codice della nazione nella partita IVA posso tentare di scoprirle tramite GeoIP:

Caching API

Tutte queste chiamate API hanno un costo però, sia in termini di latenza che di risorse economiche (sono API Pay Per Call). A questo si aggiunge spesso il fatto che chi effettua l’ordine spesso non è chi utilizza il servizio (ufficio acquisti Vs responsabile marketing).

Per tutti questi motivi ho implementato anche un sistema di caching sia delle informazioni raccolte tramite MaxMind che vatlayer. In questo modo si riducono i tempi delle successive chiamate e i costi di utilizzo delle API (win-win insomma).

Validazione della Partita IVA

Provando il servizio offerto da vatlayer mi sono accorto che sull’home page offrivano un sistema per validare in tempo reale un codice di partita IVA. All’inizio pensavo si trattasse di un’API lato server con relativa chiamata tramite AJAX. Poi, usando l’estensione Live HTTP Headers, mi sono accorto che non veniva fatta alcuna chiamata aggiuntiva. Così mi metto a scartabellare nel codice sorgente della pagina e trovo il riferimento a una libreria Javascript scritta da John Gardner (e molti altri contributors).

A questo punto decido di implementare anche questa funzione e validare lato client la partita IVA inserita dall’utente. Un vantaggio aggiuntivo, oltre a offrire una migliore esperienza per l’utente, è quella di evitare di fare una chiamata all’API di vatlayer con un valore errato.

Per completare questa implementazione faccio una breve modifica al codice della libreria per impostare l’Italia come paese predefinito (in modo che un valore senza l’IT iniziale passi la validazione).

Prefetch & Prerender

Ci siamo quasi! Dopo aver fatto tutte queste modifiche, svuoto la cache del browser e simulo la visita di un nuovo potenziale cliente. Ed ecco fatto il danno…

Quando clicco sul pulsante accedi della pricing table e vengo portato sulla pagina intermedia devo aspettare un’eternità (si fa per dire), lo stesso vale per il passaggio al gateway di naviazione. Per caricare i file associati al nuovo design il browser ci mette davvero troppo tempo (soprattutto per una fase così delicata).

Come sempre, quando mi trovo di fronte a un problema, mi rivolgo a quell’oracolo di saggezza che è Google e in meno di 30 secondi trovo un interessantissimo articolo di Robin Rendle che parla delle direttive prefetch e prerender (insieme a molto altro).

Per dirla nel modo più semplice e meno accurato possibile (leggete l’articolo se volete approfondire):

• prefetch indica al browser quali risorse potrebbero servire da li a breve
• prerender istruisce il browser di pre-caricare una risorse all’interno di una finestra nascosta

Visto che 56% dei browser che hanno visitato Marketing Academy dal suo debutto supporta la direttiva prerender e il 76% prefetch, ho dato il via all’implementazione. È importante notare che la funzione prefetch NON funziona su risorse che non consentono il caching (come accade con le pagine del gateway) ma è ottima per tutte le risorse statiche (css, js, font, etc.).

Dopo una breve analisi della situazione decido di implementare queste direttive come segue:

• su tutte le pagine del sito: prefetch della pagina Accedi (quella con la pricing table) in modo che venga caricata il più velocemente possibile;
• sulla pagina Accedi: prefetch e prerender della pagina intermedia che più probabilmente verrà caricata (ne uso 4, una per ogni livello di prezzo)
• sulla pagina Accedi: ulteriore prefetch di tutte le risorse usate dalla pagina intermedia
• sulla pagina intermedia: prefetch di tutte le risorse della pagina del gateway che non ho ancora caricato.

Dopo aver implementato quest’ultima funzione decido di usare l’estensione Page load time per testare il miglioramento di velocità con e senza le varie direttive.

Ecco i risultati dei tempi di caricamento:

• la pagina Accedi si carica in media il 25% più velocemente
• la pagina intermedia impiega il 55% in meno del tempo
• ma la vera sorpresa è stato il gateway di pagamento: un miglioramento del 75% (solo 270 msec)

Non male per qualche tag HTML posizionato ad-hoc =)

Prossimi Step

WOW! È stato un vero tour de force. Il problema è che non è ancora finita…

Lavorando a questo processo di ottimizzazione mi sono venute in mente tutta una serie di attività da portare a termine per migliorare ancora l’esperienza dell’utente:

• Analizzare il comportamento degli utenti
  Usando un servizio come SmartLook nelle prossime settimane cercherò di studiare il comportamento reale dei potenziali clienti per individuare altri punti di attrito da limare.
• Migliorare la validazione della partita IVA
  Se un utente inserisce erroneamente per due volte di seguito la partita IVA nella pagina intermedia sarebbe opportuno farlo continuare comunque verso il gateway in modo da permettergli di completare l’acquisto.
• Precompilazione per futuri acquisti
  A breve inizierò a offrire altri servizi tramite questo sito (es. consulenze Skype, etc.) e perciò alcuni utenti potrebbero effettuare degli acquisti multipli nel tempo. Per ridurre ancor di più l’attrito potrei settare un cookie con la partita IVA inserita nella pagina intermedia e far trovare il campo precompilato allo successive visite (magari con il nome dell’azienda accanto).
• Precompilare nome ed email
  La maggior parte delle visite verso il sito derivano da attività di email marketing. Per questo, visto che dispongo già di nome e indirizzo email dei visitatori, potrei salvare in un cookie tale informazione per poi fornirla precompilata sul gateway di pagamento.
• Coupon di sconto con scadenza
  Al momento i coupon sono molto semplici: un codice e uno sconto (fisso o percentuale). In futuro vorrei aggiungere la capacità di impostare una scadenza temporale e mostrare un conto alla rovescia sopra la pricing table. Un po’ di scarsità non fa male 😉
• Template responsive più coerente
  Ultimo, ma non meno importante, vorrei rivedere completamente il template usato per il gateway di pagamento e la pagina intermedia in modo che sia molto più simile al sito ufficiale. In questo modo dovrei riuscire a ridurre la dissonanza cognitiva che rallenta l’utente nel proseguire lungo il processo (il suo livello di fiducia si resetta con ogni cambio di design).

E queste sono solo le idee che mi sono venuto scrivendo questo articolo…

Conclusione

Come abbiamo visto all’inizio di questa avventura alle volte non si può condurre uno split test per migliorare i propri risultati. In queste situazioni dovremmo mettere al lavoro la nostra intelligenza e il nostro intuito per creare processi più fluidi e facili da compiere focalizzando la nostra attenzione sulla riduzione dell’attrito. Servizi come UserTesting (test di usabilità) e SmartLook (registrazione delle sessioni) sono ottimi punti di partenza per comprendere dove mettere mano per creare pagine più performanti quando non ci si può basare su dei dati affidabili.

P.S.
È probabile che molti degli screenshot in questo articolo non rispecchino lo stato attuale del sito. Perché, ti starai chiedendo? Semplice, non smetto mai di fare aggiustamenti e sistemare le cose 😉