Il test A / B viene spesso indicato come un modo scientifico per convalidare le decisioni di progettazione. Occasionalmente denominato split test, il test A / B è un processo semplice che sulla superficie sembra promettere risultati concreti:
Crea due varianti su un elemento di design, scambale casualmente sul tuo sito e registra come reagiscono i tuoi utenti, confronta i risultati, implementa qualsiasi variazione eseguita al meglio. Ha senso.
L'esempio classico è: un pulsante rosso contro un pulsante verde, che verrà toccato di più? Tuttavia, la domanda più interessante è: un pulsante verde rispetto allo stesso pulsante verde, che verrà toccato di più?
Cosa succede quando testiamo due varianti identiche? Un test A / A, se vuoi.
Per testare la validità di qualsiasi test A / B, abbiamo bisogno di un test che abbia una risposta 'corretta'. Abbiamo bisogno di una risposta corretta perché vogliamo sapere, a parità di condizioni, quanto è probabile che il test A / B produrrà il risultato che dovrebbe, e per questo abbiamo bisogno di sapere quale risultato aspettarsi.
Se eseguiamo il test A / B di due pulsanti identici, il risultato dovrebbe essere un calore morto
Quindi, supponiamo che stiamo testando un pulsante verde rispetto allo stesso pulsante verde e che il pulsante sia così allettante che il 100% degli utenti lo tocchi.
(La percentuale in realtà non importa, potrebbe essere il 14,872%. Ciò che importa è che, poiché i pulsanti sono identici, anche la velocità di battitura dovrebbe essere identica.)
Se eseguiamo il test A / B di due pulsanti identici, il risultato dovrebbe essere un calore morto.
Lancia una moneta. Quale lato si presenterà, testa o croce? Sappiamo che ci sono due lati, entrambi identici, quindi è una possibilità del 50%.
Se lanciamo la nostra moneta due volte, sappiamo che ci sono tre possibili risultati: 2 teste, 2 code, o 1 testa e 1 croce. E così via…
Diciamo che il lancio della moneta è il nostro test A / A; le probabilità che il lato delle teste si avvicini sono identiche alle probabilità che il lato delle code emerga, proprio come le probabilità che uno dei nostri bottoni verdi sia toccato sono uguali.
Quindi scriviamo uno script veloce nel browser (perché la maggior parte dei test A / B avviene nel browser) per simulare gli utenti che toccano un pulsante o l'altro, a seconda di quale di essi viene presentato.
Ricorda: stiamo testando due varianti identiche di un pulsante e il modo in cui sappiamo che sono identici è che stiamo trattando la probabilità che vengano identificati come identici. Tutto ciò che stiamo cercando è un risultato coerente (e quindi corretto).
In primo luogo, abbiamo bisogno di una tabella HTML per registrare i nostri risultati, la tabella sarà simile a questa:
# Heads Tails Difference Margin of Error
Nella prima colonna registreremo il numero del test (tutti i buoni test A / B, vengono ripetuti per verificare i risultati, quindi ripeteremo il test alcune volte). Successivamente registreremo il numero di risultati di Heads , quindi il numero di risultati di Tails . La colonna successiva sarà la differenza tra i due risultati (che dovrebbe essere zero). Quindi registreremo il margine di errore (che di nuovo dovrebbe essere 0%). Sotto il tavolo stamperemo un riepilogo, la media di tutti i risultati e il risultato peggiore.
Ecco la sceneggiatura:
var bestOf = 12, // the number of times we want to run the testtestRepeat = 12, // the number of times we’d like to repeat the testtestCount = 0, // the number of the current testtestInterval = setInterval(performCoinToss, 100), // call the coin toss functiontotalDifference = 0, // used for calculating the average differenceworstDifference = 0; // the worst casefunction performCoinToss(){testCount++; // increment the current testvar testCounter = bestOf, // the current iteration of the testheadsCounter = 0, // the total number of times the script came up with "heads"tailsCounter = 0; // the total number of times the script came up with "tails"while(testCounter--) // loop 'testCounter' times{Math.round(Math.random()) ? headsCounter++ : tailsCounter++; // finds 0 or 1 randomly, if 1 increments headsCounter, otherwise increments tailsCounter}var difference = Math.abs(headsCounter - tailsCounter), // the difference between the twoerror = (difference / bestOf) * 100; // the error percentagedocument.getElementById("results").innerHTML += "" + testCount + " " + headsCounter + " " + tailsCounter + " " + difference + " " + error + "% Average difference: " + averageDifference + "
Average margin of error: " + averageError + "%
Worst Case: " + worstDifference + "
"; // write summary to pageclearInterval(testInterval); // if the test has been repeated enough times, clear the interval}}Il codice è commentato, quindi qui ci sono solo i punti salienti:
Innanzitutto impostiamo alcune variabili tra cui il numero di volte in cui vogliamo lanciare la moneta (bestOf) e il numero di volte in cui vogliamo ripetere il test (testRepeat).
Avviso spoiler: stiamo per entrare in loop piuttosto alti, quindi per evitare di rompere il browser di qualcuno stiamo facendo il test su un intervallo ogni 100ms.
All'interno della funzione performCoinToss eseguiamo il loop del numero richiesto di volte, ogni iterazione del loop utilizza la funzione casuale di JavaScript per generare un 1 o uno 0, che a sua volta incrementa il headsCounter o il tailsCounter .
Successivamente scriviamo il risultato di quel test sul tavolo.
Infine, se il test è stato ripetuto il numero di volte che vorremmo, troviamo le medie e il caso peggiore, scriverle nel riepilogo e cancellare l'intervallo.
Ecco il risultato . Come puoi vedere la differenza media è, beh, sarà diversa per te, ma mentre sto scrivendo la differenza media è 2.8333333333333335, l'errore medio è quindi 23.611111111111114%.
Oltre il 23% di errore non ispira fiducia, soprattutto perché sappiamo che la differenza dovrebbe essere dello 0%. Quel che è peggio è che il mio peggior risultato è 8, cioè 10-2 a favore delle teste.
Ok, quindi quel test non era giusto. Un vero test A / B non avrebbe mai preteso di trovare un risultato conclusivo da soli 12 utenti.
Il test A / B utilizza qualcosa chiamato "significatività statistica", il che significa che il test deve essere eseguito abbastanza volte per ottenere un risultato perseguibile.
Quindi, raddoppiamo la variabile bestOf e vediamo fino a che punto dobbiamo arrivare per raggiungere un margine di errore, inferiore all'1%: l'equivalente del 99% di confidenza.
Al massimo su 24 (al momento della scrittura) la differenza media è 3.1666666666666665, che è 13.194444444444445%. Un passo nella direzione giusta! Provalo tu stesso (i risultati possono variare).
Raddoppiamo di nuovo. Questa volta, la mia differenza media è 6.666666666666667, con un margine di errore di 13.88888888888889%. Peggio ancora, il caso peggiore è 16, questo è un errore di 33.33333333333333%! Puoi prova quello anche per te
In realtà, non ci sono premi per indovinare che possiamo andare avanti: meglio di 96 , meglio di 192 , meglio di 384 , meglio di 768 , meglio del 1536 , meglio del 3072 , meglio di 6144 , meglio di 12288 , meglio di 24576 , meglio di 49152 , meglio di 98304 .
Infine, ad un massimo di 98304, lo scenario peggiore scende sotto l'1%. In altre parole, possiamo essere sicuri al 99% che il test sia accurato.
Quindi, in un test A / A, il cui risultato era noto in anticipo, è stata necessaria una dimensione del campione di 98.304 per raggiungere un margine di errore accettabile.
Ogni volta che viene discusso il test A / B, qualcuno ricorda un amico di un amico, che A / B ha testato un singolo pulsante sul suo sito e ha prontamente realizzato un profitto improbabile (il valore effettivo del dollaro del pulsante aumenta ogni volta che sento il storia).
In questi racconti, i pulsanti vengono solitamente testati per la micro-copia, "Scarica il mio ebook" e "Scarica il mio ebook gratuito". Non dovrebbe essere una sorpresa che quest'ultimo vince. È un miglioramento che qualsiasi buon copywriter farebbe. Un test A / B più appropriato sarebbe "Scarica il mio ebook" e "Scarica l'ebook" (i miei soldi sono su quest'ultimo).
Se ti trovi con un risultato pesantemente appesantito verso una delle opzioni, suggerisce che qualcosa è molto sbagliato in una delle tue varianti. Più spesso, un buon risultato sarà un miglioramento inferiore al 5%, che presenta un problema se si sta testando con circa 1000 utenti (il margine di errore è di circa il 5%).
Più un test è utile, più stretto è il margine di vittoria per una variazione o l'altra. Tuttavia, più stretto è il margine di vittoria, maggiore è la dimensione del campione necessaria per darti un accettabile margine di errore.
Mark Twain, forse citando Disraeli, una volta usò la frase: bugie, maledette bugie e statistiche. Con ciò intendeva che qualcosa dimostrato dalle statistiche, non è necessariamente vero. Le statistiche possono essere utilizzate per dimostrare tutto ciò che desideri.
Il test A / B ti fornirà un risultato, ma è un risultato che dirà di più su di te e su ciò che ti aspettavi di trovare, piuttosto che sui tuoi clienti
La cosa più pericolosa dei test A / B è che può provare qualsiasi cosa tu voglia; può produrre falsi positivi e ci consente di distinguere modelli non adeguatamente supportati.
Inoltre, un test A / B può indicare che un pulsante verde ha prestazioni migliori rispetto a un pulsante rosso, ma che dire di un pulsante blu? Anche il successo del test A / B ci consente di convalidare le nostre decisioni di progettazione nel contesto del test stesso.
Affinché un test A / B funzioni come previsto, abbiamo bisogno di due condizioni opposte per essere vero:
Sfortunatamente la maggior parte dei siti non ha una dimensione del campione abbastanza grande da raggiungere un margine di errore sufficientemente piccolo. E poiché non siamo in grado di aumentare le dimensioni del nostro campione (lo faremmo se potessimo), la nostra unica scelta è aumentare la variazione delle opzioni al fine di produrre un risultato chiaro, distorcendo il test secondo le nostre preferenze.
Il test A / B ti fornirà un risultato, ma è un risultato che dirà di più su di te e su ciò che ti aspettavi di trovare, piuttosto che sui tuoi clienti. Quando si tratta di prendere decisioni di progettazione su qualsiasi sito diverso da quelli con volumi di traffico molto elevati, potremmo anche lanciare una moneta, come test A / B.
Immagine in evidenza, immagine di lancio della moneta via Shutterstock.