Test A/B su un sito: definire un'ipotesi e una regola decisionale

8 lettura minima

Un test A/B su un sito web confronta le varianti di un dispositivo preparato, con un'ipotesi, una distribuzione dei visitatori e una regola di analisi definita prima del test. Non consiste nel cambiare pagina, attendere un incremento e poi assegnarla al nuovo testo. Inizia con un problema documentato, scegli una modifica interpretabile e verifica la misura del risultato. Preparare inoltre con una persona competente i criteri tecnici di arresto ed i limiti statistici. Se il traffico o la raccolta non consentono una conclusione affidabile, preferire un test qualitativo o una correzione ovvia piuttosto che un falso verdetto sperimentale.

Ricorda: una variante non è ancora un esperimento

Il risultato può variare in base al canale, all'ora o al profilo del visitatore. Il NIST spiega che i fattori secondari possono influenzare la misurazione e devono essere identificati, controllati o considerati nel disegno sperimentale.^[29] Il tuo confronto dovrebbe risolvere questo problema, non solo produrre due versioni visivamente diverse.

Formula l'ipotesi per il test A/B del tuo sito web

Descrivi il problema riscontrato: una condizione dell'offerta non trovata, un'azione ambigua o un modulo di difficile comprensione. Affidarsi alle osservazioni disponibili, senza inventare un punto di partenza. "Il pulsante non converte" è troppo vago se non sai quale passaggio non riesce.

Scrivere un'ipotesi che colleghi il cambiamento e il risultato: rendere più visibile la condizione del servizio potrebbe aiutare i visitatori interessati a inviare una richiesta valida. La parola “potrebbe” riflette l’incertezza che il test cerca di esaminare. Non trasformare questa ipotesi in una promessa di aumento.

Scegli una variazione il cui significato sia interpretabile. Se si modificano contemporaneamente titolo, prezzo, forma e grafica, una differenza nel risultato non consente di identificare l'elemento responsabile. Un insieme coerente di modifiche può essere testato come un'offerta completa, ma è necessario poi annunciare questa portata ed astenersi dall'attribuire il risultato a un dettaglio isolato.

Definire il risultato principale e i guardrail

Il risultato principale deve corrispondere ad un'azione convalidata: richiesta accettata, comando o altro evento precisamente definito. Una progressione come il clic principale può aiutare con la diagnosi, ma non dimostra automaticamente il completamento con successo del viaggio. Controlla l'evento nel sistema finale.

Aggiungere guardrail aziendali e tecnici. Una variazione non dovrebbe aumentare gli errori di modulo, ridurre l'accesso alle informazioni o produrre richieste fuori gara per migliorare una metrica superficiale. W3C consiglia istruzioni, convalide e notifiche per comprendere e correggere gli errori del modulo.^[33]

Il 4SYSTEM guida alla pagina di destinazione aiuta a verificare la coerenza tra promessa e azione. Questa coerenza deve rimanere vera in tutte le variazioni. Una versione che rimuove una condizione essenziale non è un'ottimizzazione accettabile, anche se fanno clic più visitatori.

Preparare il compito e i fattori di confusione

Il confronto deve distribuire le unità secondo una regola pensata per la domanda e mantenere un'esposizione coerente. Esamina la persistenza della variante per una persona o una sessione, a seconda del tuo dispositivo. L'alternanza involontaria tra le versioni può rendere il risultato difficile da interpretare.

Il NIST riassume il suo principio sperimentale controllando i fattori controllabili e randomizzandone altri; descrive anche il blocco di alcuni fattori parassiti.^[29] Questa guida non è un manuale di istruzioni già pronto per nessun sito. Fornisce una base per progettare un confronto che non confonda variante e composizione delle popolazioni.

Documentare le fonti di contaminazione: modifiche alla campagna, visitatori interni, ripresa della sessione, cache o integrazione esterna. Una versione mostrata principalmente su cellulare e l'altra principalmente su computer non crea un confronto pulito visualizzando semplicemente due tariffe. Fai controllare il dispositivo prima di esporre i visitatori reali.

Scrivi il protocollo prima del lancio

Definire l'unità, il risultato principale, le esclusioni, la modalità di assegnazione e la regola di analisi. Stima il fabbisogno di dati in base al livello osservato, all'effetto che stai cercando di rilevare e al metodo scelto. Qui non viene offerto un numero universale di visite o giorni.

Pianificare un risultato "inconcludente". L'assenza di prova della differenza non dimostra l'equivalenza delle versioni. Un campione insufficiente, una raccolta interrotta o un effetto troppo incerto devono restare descritti come tali. Questo risultato è un risultato onesto del dispositivo, non un fallimento nel nasconderlo.

Distinguere tra arresto di emergenza e fine analisi. Un errore funzionale o un'esposizione inappropriata possono giustificare l'arresto immediato a seconda dei criteri. D'altro canto, fermarsi non appena un grafico appare favorevole può rendere fuorviante l'interpretazione se il metodo non ha previsto questo esame. Scrivi la regola prima di vedere i risultati.

Foglio di protocollo da condividere

Un protocollo completato permette di distinguere l'esperienza reale da una dimostrazione grafica. Mantieni le versioni e le impostazioni della pagina corrispondenti al test: senza questi elementi il ​​risultato non può essere collegato a una modifica specifica.

Ricetta tecnica e quadro di raccolta

Testare le versioni sui dispositivi rilevanti, sulla tastiera e sui percorsi di errore. Controllare la distribuzione, il mantenimento della variante e l'attivazione del risultato. Una pagina visualizzata correttamente potrebbe comunque inviare un evento diverso a seconda della versione.

Tracker di revisione utilizzati per assegnare o misurare i visitatori. La CNIL ricorda il principio del consenso preventivo per alcuni depositi e letture di traccianti, con limitate eccezioni.^[31] Uno strumento presentato come “A/B testing” non esonera dall'analizzare il suo funzionamento e le sue finalità.

Prepararsi a rimuovere le modifiche. La sospensione del test dovrebbe lasciare un sito funzionante e non lasciare script non necessari. Accesso ai documenti, versione di restituzione e controllo post-spegnimento. Il protocollo sperimentale e la sicurezza del sito devono essere affrontati insieme.

Esempio fittizio: rendere visibile una condizione B2B

Un'azienda immaginaria riceve richieste al di fuori dell'area di intervento. Si presuppone che la condizione geografica sia difficile da individuare su una pagina di offerta. Prepara una variazione che presenta questa condizione vicino all'azione principale, senza modificare l'offerta o aggiungere una falsa promessa.

Nello scenario illustrativo, il team sceglie le richieste valide in base alla sua definizione come risultato principale e monitora le richieste fuori ambito e gli errori del modulo. Fa verificare il metodo di assegnazione e analisi prima del lancio. Il numero di clic rimane un segnale secondario.

Se la variante attira meno clic ma richieste più personalizzate, la decisione dovrebbe seguire i criteri pianificati, non un target di clic aggiunto a posteriori. Se i dati sono insufficienti, il test rimane inconcludente. Non vengono inventati numeri, livelli di fiducia o guadagni dei clienti; L'esempio mostra solo la logica del protocollo.

Leggi il risultato e decidi senza storie opportunistiche

Gestire volumi, esclusioni, incidenti e limiti dei metodi. Cerca le differenze di esposizione e le interruzioni di raccolta prima di scegliere una versione. Un risultato favorevole non autorizza a ignorare una tutela degradata.

Preparare tre possibili decisioni: adottare secondo i criteri, mantenere il sistema precedente o concludere che il test non consente di prendere una decisione. Se distribuisci una versione, verifica il funzionamento dopo aver interrotto il test. Impostazioni sperimentali, cache e script potrebbero differire dalla versione finale.

Su un sito poco trafficato, un'osservazione qualitativa, una ricetta sull'accessibilità o un chiarimento del contenuto possono essere più utili di un lungo test senza una potenza adeguata. Non trasformare un errore evidente in un esperimento per ritardare la sua correzione. Il test serve all’incertezza reale e ad una decisione fattibile.

Domande frequenti

Quanto dovrebbe durare un test?

La durata dipende dalle esigenze di dati, dal traffico, dalla variabilità e dal metodo di analisi. Avere questi definiti prima del lancio, con una regola finale esplicita. Nessun arco temporale universale dimostra l’affidabilità. Un periodo trascorso non cancella un'assegnazione errata o una raccolta incoerente tra varianti.

Possiamo testare un solo pulsante?

Sì, se hai un'ipotesi sulla sua comprensione o ruolo e un risultato misurato correttamente. Controlla comunque che le versioni rimangano coerenti con l'offerta e accessibili. Un cambiamento di colore senza un problema identificato può produrre un confronto difficile da interpretare e distrae da un ostacolo più concreto sul percorso.

Cosa fare se i risultati rimangono vicini?

Applicare il metodo e la regola forniti, quindi mantenere l'incertezza quando i dati non consentono una decisione. Non scegliere un altro parametro a posteriori per creare un vincitore. Si possono esaminare i limiti del dispositivo e preparare un test diverso, ma deve partire da una nuova ipotesi chiaramente annunciata.

Passaggio successivo: convalidare il protocollo

Preparare un'ipotesi, una scheda completa e varianti funzionali prima di ogni esposizione. Il 4SYSTEM servizi può aiutare a inquadrare il percorso e la misurazione. Avere l'analisi statistica qualificata in base alla tua domanda; nessun pulsante “esegui test” garantisce una conclusione praticabile.

Fonti

• 5.3.3.2. Randomized block designs (accesso 2026-10-08)
• Cookies et traceurs : que dit la loi ? | CNIL (accesso 2026-10-08)
• Forms Tutorial | Web Accessibility Initiative (WAI) | W3C (accesso 2026-10-08)