A/B test: come farlo bene (e gli strumenti dopo Google Optimize)

Due monitor affiancati su una scrivania che mostrano diverse versioni grafiche delle pagine di un sito web

Un a/b test risponde a una domanda che in riunione si risolve quasi sempre a sensazione: questa modifica fa aumentare le conversioni o no? Invece di scegliere il titolo che piace al cliente o il pulsante che convince il grafico, mostrate due versioni della stessa pagina a due gruppi di visitatori scelti a caso e lasciate decidere i numeri. Sembra semplice, ed è proprio per questo che molti test vengono impostati male: troppo pochi visitatori, test fermati al primo segnale positivo, metriche cambiate a metà strada.

In questa guida vediamo come fare un a/b test nel modo corretto, dall’ipotesi alla lettura dei risultati, quanti visitatori servono davvero e quali strumenti usare oggi che Google Optimize non esiste più: il servizio è stato chiuso il 30 settembre 2023. L’articolo fa parte della categoria CRO e completa la nostra guida pratica alla Conversion Rate Optimization.

 

Cos’è un A/B test e perché conviene farlo

Un A/B test (detto anche split test) è un esperimento controllato. Prendete una pagina esistente, la versione A o controllo, e create una versione B o variante in cui cambiate un elemento: il titolo, l’immagine principale, il testo del pulsante, la lunghezza di un modulo. Il traffico viene diviso in modo casuale, di solito al 50%, e per ogni gruppo misurate la stessa metrica, per esempio la percentuale di visitatori che completano un acquisto.

La parola chiave è casuale. Se confrontate le vendite di ottobre (pagina vecchia) con quelle di novembre (pagina nuova), state confrontando due mesi diversi, con campagne diverse, stagionalità diversa e magari un Black Friday in mezzo. Con l’a/b test, invece, i due gruppi vivono le stesse condizioni nello stesso momento: l’unica differenza sistematica è la modifica che state provando.

Pensate a due bancarelle identiche, una accanto all’altra, allo stesso mercato e alla stessa ora. Una ha un cartello con il prezzo scritto in grande, l’altra no. I passanti si distribuiscono a caso tra le due: se a fine giornata una ha venduto molto di più, potete ragionevolmente attribuire la differenza al cartello. È esattamente quello che fa un test sul vostro sito, con migliaia di “passanti” e un calcolo statistico al posto dell’intuito.

Esistono alcune varianti del metodo che è utile conoscere:

  • A/B/n test: più di una variante contro il controllo (A, B, C…). Serve più traffico, perché ogni gruppo è più piccolo.
  • Split URL test: le due versioni stanno su indirizzi diversi, utile quando la variante è una pagina completamente ridisegnata.
  • Test multivariato (MVT): si combinano più modifiche contemporaneamente (titolo × immagine × pulsante) per capire quale combinazione funziona meglio. Richiede volumi di traffico molto alti.
  • Multi-armed bandit: l’algoritmo sposta gradualmente più traffico verso la variante che sta andando meglio. Utile per promozioni brevi, meno adatto quando volete capire con certezza perché una versione vince.

Perché conviene? Perché aumentare il conversion rate della pagina che riceve già traffico costa quasi sempre meno che comprare nuovo traffico. E perché ogni test, anche quello che “perde”, vi insegna qualcosa sui vostri utenti. Tutti i nostri contenuti sull’argomento li trovate sotto il tag A/B test.

 

Come funziona un A/B test: ipotesi, varianti e metrica

Mano che usa uno smartphone appoggiato su fogli con wireframe e schizzi di schermate da progettare
Foto di Akshar Dave su Pexels

Un test ben fatto parte da tre elementi, sempre gli stessi: un’ipotesi, una variante che la mette alla prova e una metrica primaria decisa prima di partire. Se ne manca uno, state solo cambiando cose a caso con un grafico in più.

L’ipotesi: il “perché” prima del “cosa”

Un’ipotesi utile non è “proviamo il pulsante verde”. È una frase che collega un’osservazione, una modifica e un risultato atteso. Una formula che usiamo spesso:

Poiché abbiamo osservato [dato o comportamento], crediamo che [modifica] porterà a [risultato misurabile] per [segmento di utenti].

Un esempio concreto: “Poiché nelle registrazioni di Microsoft Clarity vediamo molti utenti mobile che tornano su e giù tra prezzo e spese di spedizione, crediamo che mostrare le spese di spedizione accanto al prezzo nella scheda prodotto aumenterà le aggiunte al carrello da smartphone”. L’osservazione può arrivare dai dati di GA4, dalle mappe di calore, dai sondaggi o dalle domande che arrivano all’assistenza clienti.

La variante: una modifica chiara

All’inizio conviene cambiare una cosa sola, o comunque un gruppo di modifiche che servono la stessa ipotesi. Se nella versione B cambiate titolo, foto, prezzo e colore del pulsante e la variante vince, non saprete quale delle quattro modifiche ha fatto la differenza. Questo non significa che i test debbano essere timidi: modifiche più coraggiose producono differenze più grandi, che si misurano con meno traffico.

La metrica primaria e le metriche di controllo

La metrica primaria è quella che decide chi vince: acquisti, lead inviati, iscrizioni. Va scelta prima di avviare il test e non si cambia dopo. Accanto ci sono le metriche di controllo (o guardrail), che servono a verificare di non aver rotto nulla: valore medio dell’ordine, resi, tasso di rimbalzo, tempi di caricamento. Un pulsante che aumenta i clic del 30% ma fa crollare gli ordini completati non è una vittoria.

Per scegliere le metriche giuste partite dagli obiettivi di business: nella guida ai KPI e-commerce trovate quelle che contano davvero per un negozio online, mentre se l’obiettivo sono i contatti il riferimento è il funnel di marketing e i suoi passaggi.

Elemento Domanda da porsi Esempio
Ipotesi Cosa abbiamo osservato e cosa ci aspettiamo? Spese di spedizione nascoste → più abbandoni su mobile
Variante Cosa cambiamo, esattamente? Spese mostrate sotto il prezzo nella scheda prodotto
Metrica primaria Quale numero decide il vincitore? Tasso di aggiunta al carrello da mobile
Guardrail Cosa non deve peggiorare? Ordini completati, valore medio dell’ordine
Pubblico Chi entra nel test? Visitatori da smartphone sulle schede prodotto

 

Quanti visitatori servono: campione, significatività e durata

Primo piano di uno schermo con un grafico a linee che oscilla nel tempo, con valori e orari sugli assi
Foto di Markus Winkler su Pexels

È il punto in cui si sbaglia di più. Un test con 300 visitatori per variante in cui B “vince” 12 conversioni a 8 non dimostra nulla: con numeri così piccoli una differenza del genere può uscire per puro caso, come quando lanciate una moneta dieci volte e ottenete sette teste.

I quattro numeri da conoscere

  • Tasso di conversione di partenza (baseline): quanto converte oggi la pagina. Lo trovate in GA4.
  • Effetto minimo rilevabile (MDE): il miglioramento più piccolo che vi interessa scoprire. Più è piccolo, più visitatori servono.
  • Livello di significatività: di solito il 95% (α = 0,05). In parole semplici, accettate un 5% di rischio di dichiarare vincitrice una variante che in realtà non è migliore.
  • Potenza statistica: di solito l’80%. È la probabilità di accorgervi del miglioramento, se esiste davvero.

La metafora del rumore aiuta: le conversioni giorno per giorno oscillano anche se non cambiate nulla. Il test deve raccogliere abbastanza dati perché il “segnale” della vostra modifica si senta sopra quel rumore di fondo. Un miglioramento grande si sente subito, uno piccolo richiede molto più ascolto.

Un calcolo di esempio

Esiste una formula approssimata, nota come regola di Lehr, che vale per significatività al 95% e potenza all’80%: visitatori per variante ≈ 16 × p × (1 − p) / δ², dove p è il tasso di partenza e δ la differenza assoluta che volete rilevare. Vediamo cosa significa con una pagina prodotto che converte al 3%:

Miglioramento relativo da rilevare Da 3% a… Visitatori per variante (circa) Totale con A e B
+30% 3,9% 5.750 11.500
+20% 3,6% 12.900 25.800
+10% 3,3% 51.700 103.400

Il messaggio è chiaro: dimezzare l’effetto che volete rilevare quadruplica i visitatori necessari. Per i calcoli reali usate un calcolatore dedicato, come quello gratuito di Evan Miller, o quello integrato nello strumento di test che sceglierete.

Quanto deve durare un test

Dividete i visitatori necessari per il traffico giornaliero della pagina. Se servono 25.800 visitatori in totale e la pagina ne riceve 2.000 al giorno, servono circa 13 giorni. A quel punto arrotondate a settimane intere: 14 giorni, non 13. Il comportamento del lunedì mattina è diverso da quello della domenica sera, e un test che copre solo alcuni giorni della settimana dà un’immagine distorta.

Due regole pratiche che seguiamo nei progetti dei clienti:

  1. Almeno due settimane complete, anche quando i numeri arrivano prima, per coprire due cicli settimanali.
  2. Non oltre quattro-sei settimane: più un test dura, più aumentano i disturbi (cookie cancellati, campagne che cambiano, utenti che vedono entrambe le versioni da dispositivi diversi).

E se il traffico non basta? Allora conviene testare modifiche più radicali, spostare il test su una pagina con più visite (per esempio la home o una categoria), oppure usare una metrica intermedia più frequente, come i clic su “aggiungi al carrello” invece degli acquisti. In alcuni casi la scelta più onesta è non fare un a/b test e lavorare con ricerca qualitativa, test di usabilità e buone pratiche.

 

Come fare un A/B test bene: il processo in 7 passaggi

Team di marketing in un ufficio open space: una collega attacca post-it su una lavagna mentre gli altri seguono con i laptop
Foto di Alena Darmel su Pexels

Un singolo test fortunato non cambia i risultati di un’azienda. Un processo ripetibile, sì. Questo è lo schema che usiamo, dalla raccolta dati all’archivio dei risultati.

  1. Raccogliete i dati. Partite dai numeri: in GA4 cercate le pagine con molto traffico e conversioni basse, e i passaggi del funnel con gli abbandoni più alti. Poi capite il perché con strumenti qualitativi come Hotjar o Clarity, sondaggi brevi e interviste.
  2. Scrivete le ipotesi. Ogni problema osservato diventa un’ipotesi nella forma “poiché… crediamo che… porterà a…”.
  3. Date una priorità. Non potete testare tutto. Assegnate a ogni ipotesi un punteggio da 1 a 10 per impatto atteso, fiducia nell’ipotesi e facilità di realizzazione (è il modello ICE) e partite dai punteggi più alti.
  4. Calcolate campione e durata. Prima di costruire la variante, verificate che la pagina abbia traffico sufficiente per l’effetto che sperate di vedere.
  5. Costruite e verificate la variante. Controllate la versione B su desktop, smartphone e browser diversi. Verificate che il tracciamento registri gli eventi in entrambe le versioni: un evento che si attiva solo nel controllo falsa tutto il test.
  6. Lanciate e non toccate. Una volta partito, il test non si modifica: niente cambi alla variante, alla divisione del traffico o alla metrica. Controllate solo che tutto funzioni nei primi giorni.
  7. Analizzate e documentate. A fine test leggete il risultato, i segmenti principali e le metriche di controllo. Poi scrivete tutto in un registro condiviso: ipotesi, screenshot, date, numeri, decisione presa.

L’ultimo passaggio è quello che quasi tutti saltano ed è quello che vale di più nel tempo. Un archivio dei test è come il quaderno di laboratorio di un ricercatore: dopo un anno vi dice quali leve funzionano con il vostro pubblico e vi evita di ripetere esperimenti già fatti.

Sul piano tecnico, la configurazione degli eventi di conversione è la base di tutto: se non l’avete ancora fatto, seguite la guida agli eventi e conversioni in GA4 e gestite i tag con Google Tag Manager, così potete verificare ogni evento in anteprima prima di lanciare il test.

 

Gli errori che rovinano un A/B test

Uomo con occhiali che si tiene la testa con le mani, sorpreso davanti al monitor del computer in ufficio
Foto di Gustavo Fring su Pexels

La maggior parte dei test “vincenti” che poi non portano risultati reali ha alle spalle uno di questi errori. Conoscerli vale più di qualunque strumento.

1. Guardare i risultati ogni giorno e fermarsi al primo verde

Si chiama peeking. Nei primi giorni i numeri oscillano molto: se controllate ogni mattina e fermate il test appena compare “significativo”, aumentate di molto la probabilità di un falso positivo. È come dichiarare il vincitore di una maratona al terzo chilometro. Decidete la durata prima e rispettatela, oppure usate uno strumento con metodi statistici pensati per il monitoraggio continuo (test sequenziali), che molte piattaforme moderne offrono.

2. Test con troppo poco traffico

Se la pagina riceve poche centinaia di visite al mese, nessun test darà una risposta affidabile in tempi ragionevoli. Meglio puntare su modifiche più grandi o su pagine più visitate.

3. Cambiare la metrica a test finito

Il test non vince sugli acquisti, ma “guardate che bello il tempo sulla pagina”. Se controllate venti metriche, una sembrerà significativa quasi per caso. La metrica primaria si decide prima.

4. Ignorare il campione sbilanciato

Se avete impostato una divisione 50/50 e vi ritrovate con 10.000 visitatori in A e 9.200 in B, qualcosa non va: un redirect lento, un errore di caricamento, un filtro sui bot. Si chiama Sample Ratio Mismatch (SRM) e, quando c’è, i risultati non sono affidabili. Alcuni strumenti lo segnalano in automatico.

5. L’effetto flicker

Con gli strumenti lato client la pagina originale può comparire per un attimo prima della variante. Questo “lampo” (flicker) disturba l’utente e altera il risultato. Si riduce caricando lo script del test il prima possibile nella pagina e usando gli snippet anti-flicker forniti dagli strumenti, o passando ai test lato server.

6. Non segmentare (o segmentare troppo)

Una variante può vincere su desktop e perdere su mobile, con un risultato complessivo piatto. Controllate sempre i segmenti principali (dispositivo, nuovi e di ritorno, sorgente di traffico), ma ricordate che ogni segmento ha meno dati: trattate le differenze nei segmenti come nuove ipotesi da testare, non come conclusioni.

7. Dimenticare la novità e la stagionalità

Gli utenti di ritorno possono cliccare su un elemento solo perché è nuovo (effetto novità), e un test che cade durante saldi o festività misura un pubblico diverso dal solito. Settimane intere e un occhio al calendario delle campagne riducono il problema.

 

Strumenti per l’A/B test dopo Google Optimize

Sviluppatore al lavoro su due monitor, con il codice aperto su uno schermo e la documentazione di un progetto sull'altro
Foto di Zayed Hossain su Pexels

Per anni Google Optimize è stato il punto di partenza gratuito per chi voleva fare un a/b test. Google lo ha chiuso, insieme a Optimize 360, il 30 settembre 2023, e non lo ha sostituito con una funzione equivalente dentro GA4. Ha invece aperto le API di Google Analytics alle piattaforme di test e ha avviato integrazioni con AB Tasty, Optimizely e VWO. Chi cercava un sostituto ha dovuto scegliere tra strumenti molto diversi per prezzo e approccio.

Prima di confrontarli, una distinzione utile:

  • Strumenti lato client (con editor visuale): la variante viene applicata nel browser da uno script. Sono adatti ai team marketing, perché molte modifiche si fanno senza sviluppatori.
  • Strumenti lato server e feature flag: la variante viene decisa nel codice del sito o dell’app. Niente flicker e più controllo, ma serve un team di sviluppo.

Una novità importante del 2026: VWO e AB Tasty si sono uniti a gennaio sotto il marchio Wingify. Le due piattaforme continuano a esistere, ma vale la pena verificare con il fornitore come evolveranno piani e contratti.

Strumento Approccio Piano gratuito Prezzo pubblico (verificato il 12/11/2026) Per chi
VWO (Wingify) Lato client e server, editor visuale Prova gratuita Piani Growth, Pro ed Enterprise su richiesta (demo) Team marketing ed e-commerce
AB Tasty (Wingify) Lato client e server, personalizzazione No Preventivo su richiesta Aziende medio-grandi
Optimizely Web e feature experimentation No Preventivo personalizzato Enterprise
Kameleoon Web e feature experimentation No Preventivo su richiesta Aziende medio-grandi
Convert Lato client, editor visuale Prova di 15 giorni Growth da 299 $/mese (annuale) o 399 $/mese (mensile), 100.000 utenti testati al mese; Pro da 420 $/mese (annuale), IVA esclusa PMI e agenzie
GrowthBook Feature flag ed esperimenti, open source Sì: open source self-hosted; Cloud Starter fino a 3 utenti Pro 40 $/utente/mese Team con sviluppatori e data warehouse
Statsig Feature flag, esperimenti e analytics Sì: Developer, 2 milioni di eventi/mese Pro 150 $/mese con 5 milioni di eventi, poi 0,05 $ ogni 1.000 Prodotti digitali e app
PostHog Product analytics, feature flag ed esperimenti Sì: 1 milione di richieste feature flag/mese A consumo oltre la soglia gratuita (esperimenti fatturati con i feature flag) Startup e SaaS

Come orientarsi? Se avete un e-commerce o un sito di lead generation e nessuno sviluppatore dedicato, partite da uno strumento con editor visuale e prezzo leggibile, come Convert o VWO. Se avete un prodotto digitale e un team tecnico, GrowthBook, Statsig e PostHog permettono di iniziare gratis e di fare esperimenti lato server senza flicker. Optimizely, AB Tasty e Kameleoon hanno senso quando i volumi e i team giustificano un contratto enterprise.

Qualunque sia la scelta, verificate tre aspetti prima di firmare: come lo strumento gestisce il consenso ai cookie (deve partire solo dopo il consenso, se usa identificatori), se ha un’integrazione con GA4 e come conta il traffico ai fini del prezzo (utenti testati, eventi, richieste). Un prezzo basato sugli “utenti testati al mese” cresce in fretta su un sito con molto traffico.

 

Leggere i risultati con GA4, Clarity e Hotjar

Team riunito attorno a un tavolo che discute i dati di una dashboard con grafici e percentuali mostrata su un monitor verticale
Foto di Vitaly Gariev su Pexels

Lo strumento di test vi dice chi ha vinto. Per capire perché, e per decidere il prossimo test, servono gli strumenti di analisi che probabilmente usate già.

GA4: le varianti come segmenti

Le piattaforme integrate con Google Analytics inviano un evento chiamato experience_impression quando un utente viene assegnato a una versione, con il parametro exp_variant_string che identifica strumento, esperimento e variante. In GA4 potete così creare un segmento o un pubblico per ogni versione e confrontarli su tutto il resto: pagine viste, passaggi del funnel, ricavi, sorgenti di traffico. Se il vostro strumento non ha un’integrazione nativa, potete inviare lo stesso evento tramite Google Tag Manager.

Clarity e Hotjar: guardare come si comportano

Con Microsoft Clarity potete aggiungere un tag personalizzato con la variante (la funzione clarity(“set”, chiave, valore)) e poi filtrare registrazioni e mappe di calore per versione A o B. Con Hotjar il principio è lo stesso tramite eventi e attributi. Vedere due mappe di calore affiancate spiega spesso più di una tabella: magari la variante vince perché il nuovo pulsante è più visibile, oppure perde perché un banner copre il modulo su alcuni smartphone. Trovate altri approfondimenti sotto i tag Microsoft Clarity e Hotjar.

Come decidere

Risultato Cosa significa Cosa fare
B vince sulla metrica primaria, guardrail stabili La modifica funziona con buona probabilità Pubblicate la variante per tutti e misurate l’andamento nelle settimane successive
B perde in modo netto L’ipotesi era sbagliata o la realizzazione non funziona Tenete il controllo e analizzate registrazioni e mappe per capire perché
Nessuna differenza significativa L’effetto, se c’è, è più piccolo di quanto il test potesse rilevare Scegliete in base a costi e semplicità, poi provate una modifica più decisa
B vince ma un guardrail peggiora State spostando il problema altrove Non pubblicate: rivedete la variante

Prima di dichiarare un vincitore, una piccola checklist:

  • il test ha raggiunto il campione calcolato e ha coperto settimane intere;
  • la divisione del traffico è quella prevista (nessun SRM);
  • le conversioni nello strumento di test sono coerenti con quelle registrate in GA4;
  • i risultati per dispositivo non raccontano due storie opposte;
  • il registro dei test è aggiornato con numeri, screenshot e decisione.

Un buon a/b test, in sintesi, è meno una questione di strumento e più una questione di metodo: un’ipotesi chiara, abbastanza visitatori, la pazienza di aspettare e l’onestà di accettare anche un risultato che non vi piace. Per i negozi online, collegate sempre i test ai numeri che contano, come spiegato nella guida ai KPI e-commerce (tag E-commerce e KPI). Trovate altre guide nella categoria CRO e sotto il tag Google Optimize, dove raccogliamo anche le alternative allo strumento dismesso.

Condividi :

CRO

Trasforma il traffico in conversioni, migliora l'esperienza utente e ottimizza le performance del tuo sito.
Ultimi Articoli

Data Tracking

Guide su Google Tag Manager, GA4 e server-side tracking per monitorare le performance digitali.

Funnel

Progetta funnel di vendita efficaci, analizza il percorso degli utenti e individua le opportunità di conversione.

MarTech

Scopri software, piattaforme e soluzioni per integrare dati, automazioni e strumenti di marketing digitale.