Errori comuni nei test A/B

Il metodo per i test A/B è semplice da descrivere: dividere il traffico, confrontare i risultati e attendere una significatività statistica. Tuttavia, è facile applicarlo in modo errato e alcuni errori si ripresentano regolarmente, anche tra team esperti. Questo articolo esamina gli errori più frequenti nei test A/B, perché falsano i risultati e il modo più semplice per evitarli.

Errore n. 1: Eseguire test senza un'ipotesi chiara

Avviare un test perché un concorrente ha apportato una modifica simile, o perché una tendenza di design sta circolando online, raramente produce risultati concreti. Senza un'ipotesi chiara che colleghi un'osservazione, una modifica e una metrica attesa, interpretare il risultato diventa difficile: un test vincente non rivela nulla sul "perché", e un test perdente non insegna nulla di trasferibile al test successivo.

La correzione è semplice da applicare: prima di ogni test, formulare l'ipotesi nella forma "poiché [osservazione], riteniamo che [cambiamento] causerà [effetto], misurato da [metrica]". Se questa frase non può essere completata chiaramente, probabilmente il test non è ancora pronto per essere eseguito.

Errore n. 2: interrompere il test non appena un risultato appare significativo

Questo è probabilmente l'errore più comune, anche tra i team che hanno familiarità con la teoria statistica. La maggior parte degli strumenti visualizza un livello di confidenza in tempo reale, ricalcolato a ogni nuova visita. Controllare questo valore quotidianamente e interrompere il test non appena supera il 95% – a volte dopo solo due o tre giorni – aumenta la probabilità di imbattersi in una fluttuazione casuale che, in un dato momento, assomiglia a un effetto reale.

Questo fenomeno, documentato come "peeking" nella letteratura sui test controllati, può aumentare significativamente il tasso di falsi positivi rispetto al livello di confidenza dichiarato. La soluzione consiste nell'impostare una dimensione minima del campione e una durata prima di avviare il test (si veda l'articolo su questo blog dedicato al calcolo della dimensione del campione) e nel considerare il risultato definitivo solo quando entrambe le condizioni sono soddisfatte, mai prima, anche se il pannello di controllo appare già promettente.

Errore n. 3: Testare troppe modifiche contemporaneamente

Modificare simultaneamente titolo, immagine, pulsante e layout di una pagina in un'unica variante potrebbe sembrare efficiente: un solo test anziché quattro. Il problema è che un risultato positivo non rivela quale delle quattro modifiche abbia prodotto l'effetto, né se alcune di esse abbiano in realtà ostacolato un risultato che avrebbe potuto essere persino migliore senza di esse.

Isolare una variabile per ogni test consente di attribuire chiaramente il risultato a una specifica modifica e, di conseguenza, di sfruttare questo apprendimento per i test successivi. Ciò non significa che ci si debba limitare a micro-modifiche: una riprogettazione completa di una pagina può essere assolutamente testata come un'unica variante "riprogettata" rispetto al controllo, a condizione che l'obiettivo del test sia quello di validare la riprogettazione nel suo complesso piuttosto che isolare l'effetto di ciascun componente.

Errore n. 4: Ignorare la dimensione del campione richiesta

Avviare un test senza prima stimare il numero di visitatori necessari porta spesso a una di queste due situazioni problematiche: o il test viene interrotto troppo presto per mancanza di pazienza, un errore simile al cosiddetto "peeking error" (sbirciare di nascosto), oppure viene lasciato in esecuzione a tempo indeterminato senza che venga presa una decisione definitiva, bloccando così parte del traffico su una variante non validata per mesi.

Calcolare la dimensione del campione prima del lancio, in base al tasso di conversione attuale e all'effetto minimo che si intende rilevare, ci permette di sapere fin da subito se il test è fattibile entro un lasso di tempo ragionevole e di adeguare di conseguenza le nostre ambizioni, anziché scoprirlo a posteriori.

Errore n. 5: Ignorare le differenze tra i segmenti

Un risultato aggregato può nascondere comportamenti molto diversi tra i vari segmenti di traffico. Una modifica potrebbe migliorare la conversione da dispositivi mobili, peggiorandola leggermente su desktop, oppure risultare efficace per i nuovi visitatori senza influenzare quelli di ritorno. Concentrarsi esclusivamente sul dato complessivo rischia di generalizzare un risultato che, in realtà, avvantaggia solo una parte del pubblico, o addirittura di implementare una modifica il cui effetto positivo complessivo maschera un calo in un segmento strategico.

Non è necessario analizzare ogni possibile segmento per ogni test, ma verificare la coerenza del risultato sugli assi più rilevanti per la propria attività (tipo di dispositivo, nuovi visitatori rispetto a visitatori di ritorno, principali fonti di traffico) prima di generalizzare una conclusione rimane un semplice controllo che evita spiacevoli sorprese dopo l'implementazione.

Errore n. 6: Confondere correlazione, causalità ed effetto novità

Un test A/B ben condotto, con distribuzione casuale del traffico, in genere stabilisce un nesso causale abbastanza affidabile tra la modifica testata e l'effetto misurato. Tuttavia, rimane possibile un bias: l'effetto novità. Un nuovo layout può attirare maggiore attenzione semplicemente perché è diverso, un effetto che svanisce una volta che i visitatori abituali si sono abituati ad esso. Questo fenomeno è particolarmente importante da monitorare per le modifiche molto visibili testate su un pubblico con un'alta percentuale di visitatori abituali.

L'approccio più semplice consiste nell'estendere la durata del test oltre il minimo statistico necessario quando si sospetta un effetto novità e nel confrontare, se il volume lo consente, l'evoluzione del tasso di conversione della variante tra il primo e l'ultimo giorno del test: un effetto che si attenua chiaramente nel tempo è indice di un effetto novità piuttosto che di un miglioramento duraturo.

Errore n. 7: Non documentare i risultati

Un test i cui risultati non vengono registrati in modo strutturato (ipotesi, parametri monitorati, durata, dimensione del campione e risultato) perde gran parte del suo valore a lungo termine. Senza questa registrazione, la stessa idea viene talvolta riproposta un anno dopo a causa della mancanza di memoria collettiva, e le singole intuizioni non si traducono mai in una comprensione più approfondita e completa del comportamento dei visitatori.

Mantenere una cronologia strutturata dei test, anche in forma semplice, è uno degli investimenti meno costosi e più redditizi che un team possa fare nel suo programma di sperimentazione. Permette inoltre, nel tempo, di identificare temi ricorrenti (ad esempio, le modifiche che semplificano il percorso dell'utente funzionano quasi sempre meglio di quelle che lo arricchiscono) specifici per il pubblico di riferimento.

Errore n. 8: Generalizzare un risultato al di là del suo contesto

Un test condotto esclusivamente durante un periodo di vendite atipico (saldi, picco di traffico stagionale, campagna pubblicitaria una tantum) potrebbe produrre un risultato non replicabile nel resto dell'anno, poiché il profilo dei visitatori in quel periodo differisce dal profilo abituale. Allo stesso modo, un risultato ottenuto da una singola fonte di traffico (ad esempio, una specifica campagna pubblicitaria) non è necessariamente generalizzabile a tutto il traffico del sito web.

Prestare attenzione al contesto in cui è stato condotto un test (periodo, fonti di traffico predominanti, eventi eccezionali durante il periodo di test) consente una valutazione più accurata della reale portata di un risultato prima di implementarlo su larga scala, oppure di decidere di ripeterlo in un contesto più rappresentativo in caso di dubbi.

Errore n. 9: Il controllo tecnico prima dell'avvio viene saltato.

Un test può essere metodologicamente valido (ipotesi corretta, campione adeguato, una sola variabile testata) eppure produrre un risultato inutilizzabile se un problema tecnico passa inosservato al momento del lancio: un sistema di tracciamento delle conversioni configurato male che non conteggia determinati eventi, una variante che viene visualizzata male su un browser o una dimensione dello schermo specifici, oppure un elemento della variante che compromette il funzionamento di un altro componente della pagina senza che ciò sia immediatamente evidente.

Un controllo sistematico prima di avviare un test evita questi inconvenienti: visualizza la variante sui principali browser e dimensioni dello schermo utilizzati dal tuo pubblico, attiva manualmente l'evento di conversione tracciato per confermare che venga registrato e lascia che il test venga eseguito per alcune ore con un carico di traffico ridotto prima di passare al carico finale, per individuare eventuali anomalie evidenti prima che influenzino un campione più ampio. Questo controllo raramente richiede più di dieci minuti e impedisce di scoprire, dopo diversi giorni di raccolta dati, che parte del risultato è inutilizzabile.

Una breve lista di controllo prima di avviare un test

Per riassumere tutti questi errori in una forma direttamente fruibile, ecco i punti da verificare prima di avviare un test A/B:

• L'ipotesi è formulata in modo chiaro, con un'unica osservazione, un unico cambiamento e un unico indicatore di successo.
• Per ogni variante viene modificata una sola variabile, a meno che non si tratti di testare deliberatamente una riprogettazione globale come un insieme coerente.
• La dimensione del campione necessaria è stata calcolata in base al tasso di conversione attuale e all'effetto minimo desiderato.
• Viene stabilito in anticipo un periodo minimo (almeno una o due settimane), che verrà rispettato anche se il risultato dovesse apparire chiaro già dopo pochi giorni.
• Il monitoraggio delle conversioni è stato testato manualmente prima del lancio definitivo.
• La variante è stata verificata visivamente sui principali dispositivi e browser del pubblico.
• È stato predisposto un piano per documentare il risultato finale, qualunque esso sia.

Questa lista richiede solo pochi minuti per essere consultata prima di ogni lancio e copre la stragrande maggioranza degli errori che invalidano un test a posteriori: un tempo di verifica ampiamente compensato dall'affidabilità che si ottiene sulla decisione finale.

Punti chiave

Nessuno di questi errori richiede strumenti sofisticati per essere evitato: si corregge con metodo e disciplina: formulare un'ipotesi prima di ogni test, testare una sola variabile alla volta, calcolare in anticipo la dimensione del campione, rispettare la durata prevista, prestare attenzione alle differenze tra i segmenti e documentare sistematicamente i risultati. Sono queste abitudini, più che la scelta di uno strumento piuttosto che un altro, a determinare se un programma di test A/B produca risultati affidabili nel tempo.

BlastOptimize è stato progettato per eliminare gli ostacoli tecnici da questo processo – creazione di varianti senza codice, calcolo integrato della dimensione del campione, monitoraggio della significatività statistica in tempo reale – in modo che l'attenzione del team rimanga concentrata su ciò che conta davvero: la qualità dell'ipotesi e il rigore del metodo. Se riscontrate uno qualsiasi di questi errori nei vostri test precedenti, questa è una buona opportunità per rivedere l'argomento con un metodo più robusto nel vostro prossimo test.