A/B test interfacce

Introduzione

A/B test è un esperimento controllato in cui due (o più) versioni dell'interfaccia vengono confrontate su utenti reali per capire quale versione porta alle migliori metriche alimentari. L'obiettivo è ridurre l'incertezza decisionale e migliorare la UX attraverso cambiamenti verificabili e non le opinioni.

Test A/B appropriati

C'è un obiettivo misurabile (conversione, tempo prima dell'azione, ritenzione, NPS, velocità dell'attività).
L'effetto previsto non è chiaro o può variare in base ai segmenti.
Il rischio di cambiamento è abbastanza alto da giustificare l'esperimento.
Il traffico consente di raccogliere rapidamente un campione statisticamente significativo.

Quando è meglio non testare: microcopie su schermi poco utilizzati, fitch con una forte dipendenza da rete/social, modifiche che richiedono una lunga formazione degli utenti.

Formulazione ipotesi

• Se cambiiamo [X nell'interfaccia] per [segmento Y/tutti], [metrica Z] cambia in [direzione/valore] perché [causa comportamentale].

Esempio: se si sposta il CTA principale sopra la linea di piegatura e si riduce la forma da 6 a 3 campi, il CR di azione primaria aumenta del + 3-5% riducendo l'attrito.

Metriche: target e protezione

Primary (principale): una chiave, ad esempio il completamento dello script di destinazione/conversione.
Secondary: profondità dello scroll, CTR, tempo prima dell'azione, errori, velocità della pagina.
Guardrails: stabilità delle prestazioni (TTFB, LCP), rimborsi/guasti, reclami/rimborsi, rispetto dei limiti di notifica, disponibilità.

Si consiglia di fissare in anticipo MDE (effetto minimo rilevabile), la finestra di sorveglianza e i criteri di successo.

Progettazione esperimento

Randomizzazione e unità di analisi

Unità randomizzazione: utente (user _ id), talvolta sessione o organizzazione (cluster).
Strazione/blocco: per dispositivi/canali, se vi sono forti differenze.
Sovrascrivi (interference) - Evita che il comportamento di un gruppo influisca su un altro gruppo (ad esempio elenchi/nastri comuni). In questi casi, test di cluster.

Dimensioni campionamento e MDE (semplificata)

Approssimativamente, più bassa è la conversione di base e minore è l'effetto, maggiore è il campione.
Per CR, il 10% e MDE, il 5% dell'effetto relativo spesso richiedono decine di migliaia di osservazioni per opzione.

Durata

Concentrarsi su un ciclo di comportamento completo di una settimana + riserva (di solito 2-4 settimane) o fino al raggiungimento della potenza prevista. Non fermate il test prematuramente.

Rampe (output graduale)

1-5% del traffico (canary) → 10-25% → 50% → 100%, monitorato da guardrail.

Qualità dei dati e validità

SRM (Sample Ratio Mismatch)

Verificare che la distribuzione effettiva del traffico (A/B) corrisponda a quella pianificata (ad esempio 50/50). Deviazioni significative = problema di incorporazione/flag/bot.

Identità e cross-device

Usa user _ id stabile; prendete in considerazione i dispositivi cross, i cookie-decay, l'autorizzazione in seguito nel vortice.

Bot e anomalie

Filtrare pattern innaturali (click ad alta velocità, agenti user mancanti, referori non calidi).

Stagionalità ed eventi

Non eseguire test per periodi «anomali» (festività/svendita) se questo non è l'obiettivo del test.

Analisi statistiche

Approccio frequenza (classico)

Fissa alfa (di solito 0,05) e potenza (generalmente 80%).
Non guardate ogni ore senza aggiustamenti, il rischio è falso.
Per le metriche/varianti multiple, applicare le regolazioni (Bonferroni/Holm/Hochberg) o la gerarchia delle metriche.

Approccio Bayeso

Valuta la distribuzione delle probabilità di effetto e le probabilità di eccellenza.
Facile da monitorare in tempo reale e prendere decisioni «abbastanza bene».

CUPED/covariati

Diminuire la dispersione grazie ai covari precursori (ad esempio, l'attività della scorsa settimana) è più veloce per raggiungere la potenza.

Interruzioni seriali/di gruppo