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

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

È 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:
- Almeno due settimane complete, anche quando i numeri arrivano prima, per coprire due cicli settimanali.
- 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

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.
- 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.
- Scrivete le ipotesi. Ogni problema osservato diventa un’ipotesi nella forma “poiché… crediamo che… porterà a…”.
- 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.
- Calcolate campione e durata. Prima di costruire la variante, verificate che la pagina abbia traffico sufficiente per l’effetto che sperate di vedere.
- 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.
- 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.
- 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

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

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

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.



