L’A/B testing a supporto della user experience
Osserva, misura, testa, confronta (e ripeti): quello che abbiamo imparato sulla tecnica dell’A/B testing, in collaborazione con ACI Informatica.
di Roberta Grimaldi, Daniela Iozzo, Paolo Guadagnoli*, Ilenia Tamasi**
La tecnica dell’A/B testing può essere utilizzata per migliorare la user experience di un servizio digitale.
L’abbiamo sperimentata su Costi chilometrici, uno dei servizi di portata nazionale più utilizzati del sito aci.it. Il test A/B ha riguardato la fase di accesso autenticato al servizio, ipotizzando che questa — per quanto già performante — potesse essere migliorata analizzando come gli utenti usano il servizio.
L’A/B testing è un tecnica che consiste nel comparare due varianti di una pagina web (in un sito ma anche in una app) per individuare — in base agli indicatori di performance selezionati — quale delle due funziona meglio rispetto all’obiettivo della pagina.
Nell’ambito della user research (di tipo quantitativo) questo tipo di test ha come fine ottimizzare la fruibilità di un servizio digitale coinvolgendo gli utenti del servizio stesso, seppur in modo inconsapevole, nel momento stesso in cui lo utilizzano. Nel corso di un A/B test il traffico di un sito viene infatti suddiviso in due gruppi: a uno viene proposta la versione originale (detta anche A o variante di controllo), all’altro una versione modificata in base a una ipotesi di ottimizzazione (detta anche variante B dell’esperimento).
Il servizio Costi chilometrici di ACI
Automobile Club d’Italia mette a disposizione dei cittadini il calcolo dei costi chilometrici di esercizio dei veicoli circolanti.
Gli utenti del servizio sono dipendenti, professionisti, aziende e studi professionali: la quasi totalità degli utenti si serve del servizio per verificare i rimborsi spettanti per l’utilizzo di un’auto privata nel contesto di attività lavorative. Il tool consente, in pratica, di stimare online quanto costa un particolare modello di auto, furgone o moto, su percorrenze medie annue.
La versione digitale del servizio è disponibile dal 2008: è gratuita e dal 2017 accessibile anche tramite login SPID.
Costi chilometrici (in breve indicato come CK) è inoltre un riferimento per eventuali controversie legali o per conoscere gli ipotetici costi di gestione di un particolare modello di veicolo (nuovo o usato che sia) prima di un acquisto.
Il servizio si compone di:
- una pagina di ingresso al servizio;
- una pagina di ingresso al servizio post-login (che sarà, come vedremo in seguito, l’oggetto del nostro test);
- 2 schermate facenti parte del tool di calcolo vero e proprio (una per inserire i dati del veicolo, una per visualizzare il risultato dei costi chilometrici).
Osservare: la preparazione del test
Una volta individuato l’oggetto dell’esperimento, il primo passo di un A/B test consiste nel formulare un’ipotesi di ottimizzazione, per migliorare una prestazione o risolvere un problema.
In questa fase di preparazione del test diverse fonti, dai web analytics alla analisi qualitativa, possono darci indicazione di elementi migliorabili o critici su cui poter lavorare.
Nel nostro caso, abbiamo iniziato a osservare il servizio nella sua interezza per poi soffermarci sulla schermata di accesso al servizio (post-login): abbiamo provato a immaginare in che maniera potesse essere ottimizzata nell’ottica di rendere l’accesso al tool di calcolo ancora più fluido.
Abbiamo osservato che la schermata di ingresso al servizio forniva una serie di contenuti utili solo a parte dell’utenza (ad esempio gli allegati forniti in una tabella). Nonostante un’organizzazione adeguata in termini di contenuti, rischiava pertanto di rallentare l’immediatezza di accesso al tool di calcolo.
La schermata sembra infatti impropriamente unire in un’unica pagina web due obiettivi principali.
- Obiettivo 1 (transattivo): costituire la landing page di accesso al tool di calcolo CK, ospitando il pulsante “Effettua il calcolo”.
- Obiettivo 2 (informativo): fornire agli utenti dei link di approfondimento e dei documenti scaricabili sul tema.
Date queste osservazioni e con l’intento di dare priorità all’obiettivo transattivo della pagina — ovvero condurre gli utenti verso il completamento della procedura di calcolo — abbiamo formulato la seguente ipotesi di ottimizzazione:
spostare più in alto (near the fold) il pulsante di accesso al tool di calcolo influirà su l’immediatezza dell’accesso e di conseguenza, sull’esperienza d’uso del servizio stesso.
Per la variante B della pagina test abbiamo quindi previsto lo spostamento del pulsante “Effettua il calcolo” da fine pagina a una posizione più evidente e che soprattutto non obbliga l’utente a effettuare uno scroll per accedere al tool di calcolo CK. Una soluzione semplice, perché è bene partire dalle cose più semplici per poi progressivamente testare soluzioni meno scontate e più sofisticate.
Abbiamo utilizzato come indicatore chiave di analisi il tasso di conversione del servizio, cioè il rapporto fra numero di utenti che accede alla schermata di ingresso e il numero di utenti che completa gli step del tool di calcolo fino alla pagina finale.
Misurare: la validazione dell’ipotesi
Per avere un quadro (pre-test) di quale fosse il tasso di conversione del servizio abbiamo impostato un obiettivo (di tipologia destinazione) in Google Analytics: la pagina di destinazione dell’obiettivo è la schermata finale del tool di calcolo dei CK.
Abbiamo inoltre corredato l’obiettivo del monitoraggio degli step del percorso utente fino alla pagina obiettivo (funnel).
Gli step considerati per il funnel sono le url che compongono il flusso del servizio stesso (4 url), partendo dalla la schermata di ingresso al servizio pre autenticazione (quindi, di fatto, la home di sezione CK prima del login). Abbiamo inoltre introdotto, come step precedente (ma non obbligatorio per il calcolo), la home di aci.it.
Abbiamo chiamato il funnel “Visualizza modello CK”.
Il monitoraggio interdominio
Poiché il percorso — nonché la fruizione di tutto il servizio — prevede la navigazione in tre domini web differenti, si è reso necessario a monte il setting di un monitoraggio interdominio. Il monitoraggio interdominio consente a una piattaforma di web analytics di tracciare come una singola visita le sessioni di uno stesso utente su due o più domini separati.
Abbiamo quindi collegato i 3 domini che si navigano lungo il percorso del servizio CK. I 3 domini coinvolti sono:
- www.aci.it (sito ACI)
- https://login.aci.it/ (login per l’accesso ai servizi ACI mediante registrazione al sito o account SPID)
- https://iservizi.aci.it (dominio che ospita i servizi online)
Leggi di più sul monitoraggio interdominio in Google Analytics
Una volta inserito lo snippet di monitoraggio interdominio sui 3 siti, il funnel “Visualizza Modello CK” ha iniziato a fornirci una fotografia immediata del percorso utente. Abbiamo monitorato il comportamento degli utenti e raccolto i dati per 4 settimane.
Testare: creare un A/B test con Google Optimize
Per l’esecuzione dell’A/B test vero e proprio, abbiamo scelto di utilizzare Google Optimize (GO). GO ha il vantaggio di essere nativamente integrato in Google Analytics (il che ci ha permesso di osservare l’andamento del test anche all’interno dei rapporti di GA). È gratuito e consente l’esecuzione simultanea di più test. Abbiamo impostato GO con i seguenti passaggi:
- installazione dell’estensione di Chrome che permette di creare l’esperimento con il visual editor, per un’immediata percezione di quanto impostato e un impatto procedurale minimo;
- creazione di un account GO;
- creazione del “contenitore” “Pagina CK ACI.it” che ha ospitato l’esperimento;
- associazione della proprietà analytics oggetto dell’esperimento al contenitore GO.
Abbiamo poi prelevato da Optimize 2 codici di monitoraggio (funzione “visualizza snippet” delle impostazioni di configurazione del contenitore):
- una stringa obbligatoria, che abbiamo aggiunto al già presente snippet Analytics nell’HTML del sito;
- uno snippet facoltativo, finalizzato a limitare sfarfallii nella visualizzazione della pagina “modificata” (variante B) che va posto immediatamente prima della variabile da modificare.
Leggi anche: La guida ufficiale sull’implementazione di GO (con e senza tag manager)
Una volta inseriti gli snippet abbiamo creato l’esperimento di tipo A/B test “Tasto Centro Pagina” indicando come URL oggetto del test la pagina http://www.aci.it/area-riservata/costi-chilometrici.html che ospita appunto la schermata di ingresso al tool di calcolo dei costi chilometrici.
Mediante il visual editor abbiamo generato la variante B direttamente sul front-end della pagina spostando (drag&drop) l’elemento pulsante Effettua il calcolo dalla posizione originaria a fondo pagina a quella scelta nella variante:
Leggi anche la guida di GO all’uso dell’editor visivo
Scegliere gli indicatori chiave di prestazione del test
Quando si configura un esperimento in GO è possibile importare da Google Analytics metriche custom e non. Durante la fase di osservazione avevamo scelto come indicatore chiave di analisi del servizio il suo tasso di conversione, il cui calcolo era stato predisposto tramite l’obiettivo dedicato e il funnel.
Anche per l’A/B test abbiamo quindi importato come indicatore di performance il medesimo obiettivo e la sua canalizzazione.
Per approfondire: gli obiettivi di GO per la configurazione degli esperimenti
Scegliere il campione utenti e la durata del test
Altra variabile da definire per l’avvio del test in GO è il Targeting che riguarda il campione e la tipologia di utenti su cui verrà effettuato il test. Nello specifico Optimize permette di impostare diversi parametri relativi al target:
- la percentuale di utenti a cui sottoporre il test sul totale del traffico del sito;
- la ponderazione del target rispetto alle due varianti cioè a quale percentuale mostrare la variante;
- le condizioni e circostanze in cui deve essere eseguito il test e quindi mostrata la variante (ad esempio: agli utenti che si collegano da dispositivi mobili, agli utenti provenienti da determinati siti o che si collegano da determinate città, agli utenti che appartengono ai segmenti di pubblico creati in GA, etc, o a una combinazione di diverse condizioni).
Nel nostro esperimento abbiamo scelto di:
- utilizzare il 100% dei visitatori del sito come target;
- dividere il traffico equamente fra le due varianti (50% e 50%);
- non limitare condizionalmente il pubblico a cui mostrare le varianti.
Per definire la durata del test abbiamo testato il calcolatore online VWO : in base ai dati di traffico medi del sito ACI e altre variabili, sarebbero bastati pochissimi giorni per avere dei dati indicativi rispetto a quale potesse essere la variante leader dell’esperimento. Perché i dati raccolti fossero effettivamente consistenti e non influenzati dalle variazioni settimanali di traffico sul sito, abbiamo però scelto di far durare il test 2 settimane, come suggerito anche da Optimize.
Leggi anche: la durata di un esperimento in Google Optimize
Confrontare: la variante leader
Abbiamo seguito l’evoluzione del test in tempo reale, sia su Google Optimize sia all’interno dei rapporti Google Analytics.
In GO abbiamo visualizzato l’andamento del test per giorno, nell’area “Rapporti” del contenitore dell’esperimento. In questa sezione si ha una panoramica di come si evolve l’A/B test in termini di conversioni, oppure in termini di eventuali altre metriche di confronto settate a monte (rimbalzi, pageviews e così via).
Optimize presenta i risultati delle 2 varianti distribuendo i valori delle metriche in 3 gruppi diversi: ogni gruppo rappresenta la percentuale di occorrenze di un certo valore, nella misura in cui questo rientra in un certo range (mediana, media 50° e media 98°).
Approfondimento: l’indice di posizione
Abbiamo monitorato i “miglioramenti” della variante sperimentale rispetto alla base di riferimento (quella della variante di controllo), nonché l’andamento percentuale degli indicatori “probabilità di essere il migliore” e “probabilità di battere la base di riferimento”.
Leggi anche: probability to beat baseline
In Google Analytics abbiamo invece seguito l’andamento del test nella scheda Esperimenti dei rapporti relativi al comportamento degli utenti.
Anche qui si possono monitorare l’andamento giornaliero del test in base al tasso di conversione, altre metriche di uso del sito (pagine/sessione, durata di sessione media, % nuove sessioni) e gli eventuali altri obiettivi personalizzati. In analytics si può inoltre sfruttare la segmentazione per capire se e in che maniera l’andamento dell’esperimento è stato diverso per diversi segmenti di utenza, soprattutto se in fase di impostazione del target in GO non è stata applicata alcuna condizione limitante.
Per esempio possiamo comparare le differenze nei tassi di conversione di nuovi utenti rispetto agli utenti di ritorno, confrontare quelli di utenti desktop e utenti mobile e così via, come vedremo più avanti.
Per approfondire: lettura dei dati e discrepanze fra Optimize e Analytics
A conclusione delle due settimane di test, abbiamo visualizzato in Google Optimize i risultati dell’esperimento: la variante B sarebbe la variante leader dell A/B test, con:
- un range di miglioramento del tasso di conversione stimato fino al 10%;
- il 97% di probabilità di essere la variante migliore fra le 2 considerate;
- il 98% di probabilità di battere la base di riferimento.
Secondo i dati del test la variante B migliorerebbe la fruizione del servizio costi chilometrici, nel senso che gli utenti a cui è stata proposta la variante durante il test hanno convertito di più.
Tramite la segmentazione di Google Analytics sui dati dell’esperimento, abbiamo inoltre scoperto che per il segmento di utenza “nuovi utenti” lo scarto di conversioni fra le due varianti è ancora maggiore: in altre parole, il pulsante in posizione “near the fold” inciderebbe in maniera particolarmente positiva soprattutto sul tasso di conversione degli utenti che visitano il sito per la prima volta (per gli utenti che già conoscono il sito e il tool di calcolo lo scarto è inferiore).
Per approfondire: La segmentazione in web analytics nelle linee guida di Designers Italia
La significatività statistica del test
Abbiamo esaminato i risultati di Optimize/Analytics per un’ulteriore conferma della loro significatività statistica. Quando parliamo di significatività statistica di un test intendiamo la verifica in termini probabilistici della validità di un’ipotesi statistica, entro un dato intervallo di confidenza (o margine di errore).
Più semplicemente, vogliamo essere quanto più possibile certi che le differenze individuate fra le due varianti non siano frutto del caso.
Online è possibile reperire numerosi tool gratuiti che consentono di valutare il livello di certezza statistica dei risultati di un A/B test: questi risultano particolarmente utili se e quando non si utilizza per il test un software ad hoc.
I risultati di più calcolatori ci hanno confermato la “leadership statistica” della variante B individuata da Google Optimize.
Ecco alcuni tool gratuiti reperibili online per calcolare la significatività statistica:
- https://neilpatel.com/ab-testing-calculator/
- https://abtestguide.com/calc/
- https://vwo.com/ab-split-test-significance-calculator/
Per approfondire: il modello statistico alla base di Google Optimize e maggiori informazioni sul p-value
A/B, test, repeat!
L’idea di fondo che sta dietro la tecnica A/B testing è un’ottimizzazione che proceda per iterazioni successive. Si parte dall’osservazione dei comportamenti dell’utente (e quindi dall’analisi del sito/servizio) per proseguire con ipotesi di miglioramento che vengono man mano testate, e poi implementate o scartate in base al loro successo o insuccesso.
Non sono da sottovalutare anche i fallimenti dell’ipotesi ideata: anche questi contribuiscono a fornirci informazioni utili sul comportamento degli utenti e ci spingono a continuare a interrogarci sulle modalità migliori per rispondere ai loro bisogni.
L’A/B testing risulta dunque uno strumento realmente efficace se inserito in un approccio generale alla progettazione che sia human centered, iterativo e guidato dai dati.
Sul data-driven design, dal blog di Designers Italia: ecco come i dati possono aiutarci a capire i bisogni dei cittadini
**Ilenia Tamasi è Program Manager presso Aci Informatica SpA.
*Paolo Guadagnoli è Responsabile Digital Solutions della Direzione Sviluppo Software per Aci Informatica SpA.
Ilenia Tamasi e Paolo Guadagnoli hanno collaborato per realizzare l’A/B test oggetto di questo post, fornendo la possibilità di effettuarlo sul sito dell’ACI (www.aci.it) e contribuendo inoltre alla redazione di questo caso studio.
Thanks to Lorenzo Fabbri, Letizia Sechi, Michela Calanna, Danilo Spinelli
