È lunedì. Il team discute una nuova idea: cambiare il colore della CTA, mostrare un badge “più venduto”, spostare il prezzo in alto. Ciascuno ha un parere. Nessuno ha una prova. Il tempo passa, la decisione slitta, il rischio cresce. Qui la sperimentazione aiuta: un metodo chiaro per trasformare ipotesi in dati e dati in decisioni. Nelle prossime sezioni andiamo al sodo: come progettare test solidi, quali errori evitare, come leggere i risultati e quando agire.
Un esperimento è un confronto controllato. Mostriamo due o più versioni (A, B, a volte C) a gruppi simili di utenti, in modo casuale. Misuriamo l’effetto su una metrica chiave. Se la differenza supera il rumore, decidiamo.
Tipi comuni: A/B test (una variazione), multivariato (più cambi insieme), holdout (un gruppo non tocca la novità per misurare l’effetto vero), feature flag (rilascio graduale), quasi-esperimenti (quando la randomizzazione non è possibile). Per una tassonomia chiara di eventi e metriche in analisi, vedi le linee guida di Google Analytics 4 sugli eventi e sulle metriche.
“Basta un test e abbiamo la verità.” No. Un test risponde a una domanda precisa, in un contesto preciso. Serve una serie di esperimenti nel tempo.
“La significatività statistica è tutto.” No. Conta anche la dimensione dell’effetto, il costo, il rischio, l’impatto su metriche guardrail (es. errori, reclami). Il design viene prima del p-value.
“I piccoli numeri sono inutili.” No. Con poco traffico si può ancora testare, ma su cambi più grandi, su step più lunghi o con tecniche di riduzione varianza. Per un quadro sull’affidabilità degli studi con utenti e sui limiti, leggi i principi di Nielsen Norman Group sulla ricerca e validità.
Questa tabella ti aiuta a scegliere metrica, tipo di test, soglia minima misurabile (MDE), durata, guardrail e rischi. I numeri sono esempi: rifai i calcoli sul tuo traffico.
| Aumentare click su CTA | CTR | A/B | +5–8% | 1–2 settimane | Tempo di caricamento, bounce | Stagionalità campagne |
| Migliorare conversione checkout | CR acquisto | A/B (server-side) | +3–5% | 2–4 settimane | Error rate, rimborsi | Spillover su carrello |
| Ridurre churn abbonati | Churn a 30 gg | Holdout / rollout graduale | -5–10% | 4–8 settimane | Ticket supporto, NPS | Effetto novità |
| Nuovo onboarding | Attivazione (AHA) | A/B + segmenti | +7–12% | 2–3 settimane | Crash, tempo task | Bias di canale |
| Test prezzo | ARPU / Margine | Test prezzi (server) | +3–7% | 2–6 settimane | Reclami, rimborsi | Compliance, SEO |
| Ricerca interna più utile | Click su risultati | A/B + CUPED | +4–6% | 2–3 settimane | Latency, errori 5xx | Query rare |
| iGaming/affiliazione: funnel registrazione | Registrazioni qualificate | Holdout + A/B | +6–10% | 3–4 settimane | Qualità traffico, reclami | Compliance, responsabilità |
| Nuovo layout mobile | CR mobile | A/B (client-side cauto) | +4–8% | 2–3 settimane | CLS, INP, crash | Performance SEO |
Vuoi una base semplice per i calcoli? Qui trovi una spiegazione intuitiva di p-value, potenza e campioni. In breve: definisci la metrica, scegli l’MDE minimo utile, fissa potenza (80–90%) e livello alfa (es. 5%), poi ottieni la dimensione campione e la durata.
Nota breve (MDE in pratica): se la tua base è 3% CR e vuoi misurare un +0,3 p.p. (10% relativo), verifica di avere abbastanza traffico per vedere tale salto. Se no, punta a cambi più ampi o usa riduzione varianza (CUPED).
Frequentista vs Bayesiano. Entrambi validi. Il frequentista è standard e ben noto. Il bayesiano offre probabilità dirette su “B è meglio di A” e supporta decisioni sequenziali. Una buona introduzione è la guida di Google Developers ai test A/B.
CUPED e riduzione varianza. Usa dati pre-test come covariate per ridurre il rumore. Spesso tagli il tempo del 10–30%. Approfondisci con Microsoft Research su CUPED.
Sequential testing e alpha-spending. Se devi guardare i dati in corso, pianifica soglie che si adattano nel tempo per non gonfiare i falsi positivi.
Server-side vs client-side. Per test su prezzo, checkout, SEO e performance, preferisci server-side. Il client-side è rapido per UI, ma può creare flicker e problemi di misura. Cura LCP, CLS, INP.
Ipotesi: rimuovere distrazioni nel passo pagamento alza il CR. Metrica primaria: acquisti completati. Guardrail: errori, rimborsi. Risultato: +4,2% CR dopo 3 settimane, nessun aumento di errori. Decisione: rollout al 100%, poi test su metodi di pagamento.
Ipotesi: mostrare “X articoli rimasti” prima del blocco aumenta i trial. Metrica primaria: start trial. Guardrail: cancellazioni entro 7 giorni. Risultato: +6,1% trial, ma +1,5% cancellazioni. Decisione: mantieni il messaggio, affina onboarding per ridurre cancellazioni.
Ipotesi: una pagina di confronto bonus più chiara aumenta registrazioni qualificate e ricavi per click, senza impatti su reclami. Disegno: holdout 10% + A/B su layout e copy. Guardrail: tasso di reclamo, tempo di caricamento, compliance. Nota etica: messaggi sulla responsabilità di gioco e link a risorse di aiuto.
Esempio reale: un portale che recensisce siti di casinò affidabili ha creato un holdout stabile e ha misurato l’effetto netto della nuova pagina di confronto. Risultato: +8–9% registrazioni qualificate su traffico organico, zero aumento nei reclami, LCP sotto 2,5s. Decisione: rollout graduale al 100%, poi test dei filtri (bonus, metodi di pagamento) e delle etichette di trasparenza.
Per ispirazione sul metodo e sulla cultura degli esperimenti, dai un’occhiata alla ricerca pubblica di Booking.com sugli esperimenti.
Raccogli solo i dati necessari, rispetta il consenso, evita dark pattern. Se testi prezzi o messaggi sensibili, definisci limiti chiari e una via rapida di roll-back. Consulta le indicazioni ufficiali del Garante: guida su cookie e tracciamento. Inserisci nel decision log i rischi etici e le mitigazioni.
Quanto deve durare un test? Almeno un ciclo completo dei tuoi pattern (tipico: 2 settimane). Serve coprire giorni feriali e weekend. Se la potenza non basta, allunga o riduci l’MDE atteso.
E se la metrica primaria non si muove ma le secondarie sì? Riporta al piano. La decisione si basa sulla primaria. Le secondarie offrono insight per il prossimo test, non per cambiare l’esito.
Posso testare prezzi? Sì, ma server-side, con segmenti ben randomizzati, e con forti guardrail su reclami e rimborsi. Valuta impatto su brand e SEO.
E mobile vs desktop? Se la UX è diversa, testa separando i segmenti o assicurati che l’effetto sia coerente sui due mondi. Occhio a performance e crash.
Per la progettazione a livello business, utile la lettura HBR: come disegnare esperimenti aziendali efficaci.
Passi rapidi: 1) prendi il numero di utenti in A e in B; 2) confronta con la quota attesa (es. 50/50); 3) applica un chi-quadro semplice o usa una libreria; 4) se p < 0,01 o lo scarto è grande, stoppa e indaga (bug nel routing, filtri, bot, adblock). Meglio perdere un giorno che lanciare un falso “vincitore”.
Ferma solo se: a) durata minima rispettata; b) credibilità 95% (o p < 0,05) sulla metrica primaria; c) nessuna violazione guardrail per 3 giorni di fila; d) effetto coerente su top 2 segmenti (es. mobile e desktop). In caso contrario, prosegui o chiudi come “inconclusivo” e riprogetta.
La sperimentazione non è un trucco. È disciplina. Con ipotesi chiare, design pulito e lettura onesta, il team smette di discutere a vuoto e inizia a imparare in fretta. Parti piccolo, scrivi tutto, proteggi gli utenti e il brand. I risultati arrivano.