Sperimentazione & CRO
CRO e sperimentazione: la guida completa agli A/B test
Nella maggior parte delle aziende con cui ho lavorato, "fare CRO" vuol dire lanciare un A/B test ogni tanto su un bottone o un titolo e sperare che succeda qualcosa. Non è sperimentazione, è un tentativo isolato travestito da metodo. Quando ho costruito il programma che ha portato l'e-commerce Whirlpool EMEA a +57% di conversione, la differenza non stava in un singolo test fortunato: stava in un processo che generava ipotesi giuste una dopo l'altra, con una disciplina statistica che impediva di illudersi sui risultati. Questa guida raccoglie quel metodo per intero, dal punto in cui nasce un'ipotesi fino al momento in cui si decide, con onestà, se un test ha davvero vinto.
Cos'è un programma di sperimentazione, e perché non è una lista di test
CRO, conversion rate optimization, viene spesso ridotta a una tattica: cambio un colore, sposto una call to action, misuro il click-through. Un programma di sperimentazione è un'altra cosa. È un ciclo che si ripete: osservazione del comportamento, ipotesi, test, lettura del risultato, apprendimento che alimenta l'ipotesi successiva. Il singolo test conta meno del ciclo che lo produce.
Nel mio lavoro su Whirlpool EMEA questo ciclo aveva una cadenza fissa: revisione settimanale del backlog, lancio di nuovi test quando lo slot di traffico si liberava, lettura dei risultati con soglie decise in anticipo, non a risultato ottenuto. Senza questa struttura, un'azienda finisce per testare ciò che è comodo testare, di solito piccoli dettagli visivi, invece di ciò che il comportamento reale degli utenti suggerisce di testare. La differenza tra un singolo test vincente isolato e un +57% cumulativo sta quasi sempre qui: nella cadenza, non nella genialità del singolo test.
Da dove nasce un'ipotesi che vale la pena testare
Un test vale quanto l'ipotesi che lo genera. Troppi backlog di CRO sono liste di "idee carine" senza una base comportamentale: si testano varianti perché un competitor le usa, non perché si è capito un attrito reale nel percorso dell'utente. Il mio approccio parte da un altro punto, e nasce da prima ancora di lavorare nel marketing: un MSc in Cyberpsychology, dove ho iniziato a chiedermi perché le persone si comportano come si comportano online molto prima di provare a risolverlo con un test.
Un'ipotesi solida segue una struttura semplice: cosa osservo nel comportamento reale (dati di sessione, heatmap, drop-off in un funnel), quale cambiamento credo lo affronti, e quale metrica mi aspetto che si muova, di quanto. Non "proviamo un pulsante verde", ma "gli utenti abbandonano il checkout al passaggio delle spese di spedizione perché il costo compare tardi: mostrandolo prima, riduciamo l'abbandono a quello step". Questa è la differenza tra un test che informa il prossimo e un test che finisce in un report dimenticato. Ho raccolto il formato completo in una guida dedicata a come scrivere un'ipotesi di A/B test efficace.
Prioritizzare il backlog: non tutti i test valgono lo stesso tempo
Con più idee di test di quante risorse per eseguirle (ed è la norma, non l'eccezione) la prioritizzazione decide cosa succede davvero. Esistono framework consolidati per farlo: alcuni pesano impatto atteso, fiducia nell'ipotesi e facilità di implementazione; altri pesano più la potenzialità intrinseca della pagina, l'importanza del traffico che ci passa e la facilità di test. Nessuno dei due è "quello giusto" in assoluto: dipende da quanto traffico hai, da quanto è costoso implementare una variante e da quanto la tua organizzazione tollera test che falliscono.
Quello che conta, indipendentemente dal framework scelto, è avere un criterio esplicito e condiviso, così che il backlog non si riempia dei test più facili da spiegare in una call invece di quelli più probabili a spostare i numeri. Su Whirlpool EMEA molte delle vittorie più grandi non venivano dalle pagine più visitate in assoluto, ma dagli step del funnel dove il traffico era qualificato e la frizione osservata era più forte.
Progettare l'esperimento: metriche, randomizzazione, segmenti
Un test ben progettato decide prima del lancio, non dopo, cosa conta come vittoria. Serve una metrica primaria unica, quella che decide se il test ha vinto o perso, e un piccolo set di metriche guardrail che verificano che non si stia ottimizzando una cosa a scapito di un'altra (più clic sul pulsante ma meno margine per ordine, per esempio). Se si guarda a dieci metriche sperando che una sia significativa, prima o poi lo sarà per puro caso: non è un risultato, è rumore statistico travestito da insight.
Anche la segmentazione va trattata con cautela. È tentante tagliare i risultati per dispositivo, canale di traffico o paese finché non si trova un segmento "vincente": ma più tagli si fanno, più aumenta la probabilità di trovarne uno significativo per caso. I segmenti vanno decisi prima del test, in numero limitato, e legati a un'ipotesi (per esempio se si crede che l'attrito colpisca diversamente mobile e desktop), non generati esplorando i dati dopo la fine del test.
Significatività statistica e l'errore che uccide più test di quanto sembri
Il peeking, controllare i risultati ogni giorno e fermare il test appena la variante sembra vincere, è probabilmente l'errore più comune e più costoso nella sperimentazione. Ogni volta che si guarda un risultato parziale e si decide se fermarsi, si aumenta la probabilità di dichiarare vincitore un test che, portato fino alla fine, sarebbe tornato alla parità. La significatività statistica calcolata su un campione ancora in crescita non significa quello che sembra significare.
La soluzione pratica non è smettere di guardare i dati (è normale farlo) ma decidere in anticipo la dimensione del campione o la durata minima del test, e usare, quando la piattaforma lo permette, metodi statistici pensati per la lettura sequenziale invece che per un singolo controllo a fine test. Nel mio lavoro come Optimizely Experimentation Certified Core Strategist questo è uno dei punti su cui più spesso correggo l'istinto di chi vorrebbe fermare un test "perché ormai sembra chiaro come va a finire".
Optimizely nella pratica: cosa cambia con la piattaforma giusta
Uso Optimizely ogni giorno come piattaforma di experimentation, ed è quella su cui ho costruito il programma per Whirlpool EMEA. La differenza che fa una piattaforma matura non è la possibilità di lanciare una variante (quello lo fanno anche strumenti gratuiti) ma la QA prima del lancio (verificare che la variante si comporti bene su tutti i browser e dispositivi prima di esporla al traffico reale), il motore statistico che gestisce correttamente il problema del peeking descritto sopra, e la possibilità di collegare feature flag e test A/B nello stesso strumento, così che un rilascio graduale di prodotto e un esperimento di conversione parlino la stessa lingua invece di vivere in sistemi separati.
Questo conta soprattutto in un contesto enterprise, dove un test mal implementato non costa solo il tempo perso: costa la fiducia degli stakeholder nel programma di sperimentazione nel suo complesso, ed è quella fiducia che permette di continuare a testare anche quando un test perde.
La cultura della sperimentazione conta più del singolo test vincente
Un programma di CRO che sopravvive a un anno, e non solo a un trimestre, ha bisogno di qualcosa che va oltre la piattaforma: una cadenza condivisa con gli stakeholder, un linguaggio comune su cosa significa "vincere" un test, e l'accettazione che la maggior parte dei test, anche quelli ben progettati, non produce un vincitore netto. Se ogni test perso viene letto come un fallimento del programma invece che come un apprendimento, l'organizzazione smette di testare proprio quando comincerebbe a imparare di più.
Le radici comportamentali di ogni buon test meritano un discorso a parte: se vuoi capire più a fondo perché gli utenti si comportano come si comportano online prima ancora di trasformarlo in un'ipotesi, ho scritto una guida dedicata alla psicologia del consumatore online, che è la base su cui costruisco ogni ipotesi di test che lancio.
Parliamo del tuo programma di sperimentazione
Da dove iniziare se il tuo primo programma parte oggi
Se stai costruendo un programma di sperimentazione da zero, l'ordine conta più degli strumenti. Prima si definisce come si scrivono le ipotesi e da dove nascono: dati di comportamento reale, non intuizioni isolate. Poi si stabilisce un criterio di prioritizzazione esplicito, anche semplice, purché condiviso e applicato con costanza. Solo a quel punto si sceglie la piattaforma, perché uno strumento potente usato senza disciplina statistica produce solo falsi vincitori più in fretta.
Il +57% di conversione su Whirlpool EMEA non è arrivato da un test geniale isolato, ma da mesi di questo ciclo ripetuto senza scorciatoie: ipotesi fondate, backlog prioritizzato, test letti fino alla fine prevista, non fino al punto in cui il numero piaceva di più. È un metodo replicabile, non un colpo di fortuna, ed è quello che porto in ogni programma di sperimentazione che gestisco per i clienti enterprise con cui lavoro. Se vuoi vedere come si applica al tuo e-commerce o al tuo prodotto digitale, trovi una panoramica dei servizi di CRO e sperimentazione che offro su questa pagina, oppure puoi scrivermi direttamente per parlarne.
Parliamo del tuo progetto
Ti è utile questo articolo? Vediamo come applicarlo al tuo contesto.
Articoli correlati
Ipotesi di A/B Test Che Portano Risultati
Come scrivere un'ipotesi di A/B test che porta risultati: dalla base comportamentale alla metrica attesa, il formato che uso per non sprecare traffico.
Il Test Ha Davvero Vinto? Significatività e Peeking
Come capire se un A/B test ha davvero vinto: significatività statistica, dimensione del campione e il peeking che fa dichiarare vincitori inesistenti.
+57% Conversione: Anatomia di un Programma CRO
Anatomia del programma di sperimentazione dietro il +57% di conversione su Whirlpool EMEA: com'è nato, cosa abbiamo testato e cosa ha funzionato.