Anatomia di un test sbagliato

Ho scritto di recente un articolo su quello che considero un uso diffuso e problematico dell'A/B testing nell'eCommerce: test compulsivi su micro-variabili, decisioni prese su campioni insufficienti, e la confusione sistematica tra rumore e segnale.

Poco dopo aver pubblicato, mi è capitato di leggere un messaggio di un collega a un cliente. Un caso concreto, reale, che illustra quei problemi meglio di qualsiasi teoria. Vale la pena analizzarlo nel dettaglio, perché contiene almeno tre errori metodologici significativi impilati uno sull'altro, tutti mascherati da un linguaggio tecnico che suona rigoroso.

Il caso: un pop-up, tre varianti, zero domande

Il contesto: un pop-up di lead generation su una pagina prodotto di un eCommerce. Il pop-up ha più step - un gancio iniziale per catturare l'attenzione, poi un form di sottoscrizione. Tre varianti in test: A, B e C.

Il messaggio del collega al cliente, parafrasato e anonimizzato, diceva più o meno questo:

"Il gancio del primo step nella variante B è quello che funziona di più, ma il tasso di submit più alto allo step della sottoscrizione è nella variante C. Quindi dichiariamo C vincente, ma poi facciamo un nuovo A/B test creando una versione del pop-up C con il gancio di B. E così via."

A prima vista sembra un ragionamento solido. Ci sono dati, varianti con lettere, un piano d'azione iterativo. Il cliente legge e pensa: che metodo. Ma sotto la superficie ci sono almeno tre problemi gravi, e nessuno dei tre è visibile se non ti fermi a ragionare su cosa quei numeri stanno davvero misurando.

Errore #1: il survivorship bias nel funnel

Partiamo dal dato apparentemente più solido: "il tasso di submit più alto è nella variante C".

Il pop-up ha due step. Il primo è il gancio, quello che cattura l'attenzione e convince l'utente a interagire. Il secondo è il form di sottoscrizione, dove l'utente lascia i propri dati. Il collega ha osservato che B ha il gancio migliore (più persone interagiscono allo step 1), ma C ha il submit migliore (più persone completano allo step 2).

Il ragionamento implicito è: C converte meglio dove conta, cioè al submit. Quindi C vince.

Ma il dato racconta una storia diversa se guardi i denominatori. Se il gancio di B è più efficace, significa che B fa passare più persone allo step 2. Un pubblico più ampio, più eterogeneo, che include anche persone con un livello di interesse medio-basso. Il gancio di C, meno efficace (o magari meno click-bait), lascia passare meno persone. Ma quelle che passano sono le più motivate, le più intenzionate. Sono già auto-filtrate.

Risultato: il tasso di submit di C è più alto non perché lo step 2 di C sia migliore, ma perché il campione che ci arriva è già selezionato. Stai confrontando il 60% del pubblico di B con il 35% del pubblico di C, e concludendo che C è superiore. In realtà, C ha semplicemente perso più persone prima.

Questo meccanismo ha un nome: survivorship bias. Si analizzano solo i "sopravvissuti" di un processo, ignorando tutti quelli che sono stati eliminati lungo la strada. È lo stesso motivo per cui un eCommerce con un checkout pieno di frizioni può mostrare un tasso di completamento altissimo sull'ultimo step. Non perché quell'ultimo step sia ottimizzato, ma perché chi ci arriva ha già superato talmente tanti ostacoli che non si ferma più. Leggere quel dato come "il checkout funziona benissimo" sarebbe un errore grossolano. Ed è esattamente quello che sta succedendo con questo pop-up.

Il dato corretto da guardare non è il tasso di submit dello step 2 in isolamento. È il tasso di conversione end-to-end: quanti utenti esposti al pop-up completano la sottoscrizione. Se B porta il 10% degli utenti esposti a iscriversi, e C ne porta il 7% nonostante il submit rate più alto allo step 2, allora B è la variante migliore. E nessuno se n'è accorto perché si stava guardando la metrica sbagliata.

Errore #2: non era un A/B test

C'è un secondo problema, più fondamentale. Rileggendo il messaggio, le varianti A, B e C avevano ganci diversi allo step 1 e, con ogni probabilità, differenze anche allo step 2. Toni diversi, strutture diverse, forse copy e immagini diversi. Erano tre esperienze utente distinte.

Un A/B test, per definizione, cambia una sola variabile e tiene tutto il resto costante. Se cambi il gancio e contemporaneamente cambi il form, il tono, la struttura, non stai facendo un A/B test. Stai facendo un test multivariato - e per di più uno non strutturato, senza un design fattoriale che ti permetta di isolare il contributo di ciascuna variabile.

La conseguenza è che qualsiasi conclusione su singole componenti ("il gancio di B è migliore", "il submit di C è migliore") è infondata. Non puoi sapere se il gancio di B performa meglio perché il gancio in sé è più efficace, o perché funziona nel contesto specifico della variante B, con quel tono, quel visual, quella sequenza. E non puoi sapere se il submit di C è più alto per merito dello step 2 o per il filtro di selezione dello step 1 che abbiamo appena descritto.

È come confrontare tre piatti completi - ingredienti diversi, cotture diverse, impiattamenti diversi - e poi concludere che il sale del piatto 2 è migliore dello zucchero del piatto 3. Non ha senso, perché ogni ingrediente funziona nel contesto del piatto intero. Estrarlo e metterlo in un altro piatto non ti garantisce lo stesso risultato.

Errore #3: Frankenstein non è una strategia

Ed eccoci al piano d'azione proposto: prendere il gancio "vincente" di B, attaccarlo allo step 2 "vincente" di C, e creare un ibrido. Il mostro di Frankenstein dell'ottimizzazione.

Abbiamo già visto perché le singole componenti non sono isolabili. Ma aggiungiamo un altro strato: l'ibrido che si crea non è mai stato testato. Non esiste alcun dato sulla combinazione "gancio B + submit C". È un'ipotesi presentata come una deduzione logica, ma in realtà è una scommessa costruita su premesse fragili.

Potrebbe funzionare meglio di entrambe le varianti originali. Potrebbe funzionare peggio di entrambe. Potrebbe creare un'incoerenza nell'esperienza utente - un gancio con un tono e uno step 2 con un tono diverso - che confonde l'utente e abbassa la conversione complessiva. Non lo sai finché non lo testi. E quando lo testi, il risultato è influenzato da tutte le stesse variabili confondenti che rendevano inaffidabili i test precedenti.

E poi c'è quel "e così via". Il piano dichiarato è iterare: prendere i pezzi vincenti del test successivo, combinarli in un nuovo ibrido, testare ancora. Un loop infinito dove ogni iterazione eredita le premesse (fragili) di tutte quelle precedenti, il baseline si sposta ad ogni giro, e il campione - le poche centinaia di visualizzazioni giornaliere di un pop-up su una pagina prodotto - non è mai abbastanza grande per dare significatività statistica a nessuno dei risultati.

Non è ottimizzazione iterativa. È un palazzo costruito su fondamenta che si muovono.

La domanda che manca

Ma il problema più grave non è in nessuno dei tre errori tecnici. Il problema più grave è che in tutto quel ragionamento manca una sola, semplice domanda: perché stiamo testando il pop-up?

Qual è il problema di business? Il tasso di iscrizione alla lista è troppo basso? Se sì, di quanto? Rispetto a quale benchmark? E siamo sicuri che il problema sia il pop-up e non il timing, il targeting, la proposta di valore, o il semplice fatto che l'utente in quel momento sta guardando un prodotto e non vuole essere interrotto?

Nessuna di queste domande è stata posta. Si è partiti direttamente con il test. E quando parti dal test senza una domanda, il test diventa l'obiettivo. Ottimizzi il pop-up non perché hai identificato un problema, ma perché il pop-up è lì e puoi testarlo. È la versione marketing del detto "quando hai un martello, tutto sembra un chiodo".

Ho scritto in un altro articolo del bias di conferma nell'analisi dei dati: la tendenza a cercare nei numeri la conferma di quello che già crediamo, invece di farci una domanda e cercare onestamente la risposta. In questo caso il bias è ancora più a monte: non si è nemmeno arrivati alla fase dell'analisi. Si è saltati direttamente alla fase della soluzione, senza aver mai definito il problema.

Come si sarebbe dovuto procedere

Se quello stesso collega si fosse fermato cinque minuti prima di proporre il test, il percorso sarebbe stato diverso. Non necessariamente più lungo, ma strutturalmente più solido.

Primo: definire il problema. "Il pop-up della pagina prodotto ha un tasso di iscrizione dell'1,2%. Il benchmark per questo tipo di pop-up nel settore è intorno al 3%. Vogliamo capire perché siamo sotto e se possiamo migliorare." Questo è un problema definito, con un numero, un riferimento, e uno scopo chiaro.

Secondo: formulare un'ipotesi. Non tre varianti buttate in test. Un'ipotesi. "Crediamo che il gancio attuale non sia abbastanza rilevante per l'utente che sta guardando un prodotto. Vogliamo testare un gancio che faccia leva sul prodotto specifico che l'utente sta visualizzando, rispetto al gancio generico attuale." Una variabile. Un confronto. Una domanda.

Terzo: calcolare il campione necessario. Quante visualizzazioni giornaliere ha il pop-up? Quante ne servono per raggiungere la significatività statistica su un delta del 50% (da 1,2% a 1,8%)? Se il pop-up ha 300 visualizzazioni al giorno e ti servono 2.000 per variante, il test dura almeno due settimane. Se ne ha 100, dura più di un mese. Se non hai il traffico, non hai il test. E pretendere di avere un risultato affidabile dopo una settimana con 200 visualizzazioni per variante non è ottimismo. È finzione.

Quarto: misurare il dato giusto. Non il tasso di submit di un singolo step. Il tasso di conversione end-to-end: quanti utenti esposti al pop-up completano l'iscrizione. Se il pop-up ha due step, il dato che conta è il rapporto tra chi lo vede e chi arriva in fondo. Non il rapporto tra chi passa dallo step 1 e chi completa lo step 2, che è viziato dal survivorship bias che abbiamo descritto.

Quinto: accettare il risultato. Anche se non conferma la tua ipotesi. Anche se il gancio nuovo non migliora nulla. Quel "non miglioramento" è un'informazione preziosa: ti dice che il problema probabilmente non è il gancio, e che devi cercare altrove. È un dato che ti fa risparmiare tempo e risorse. Ma solo se lo accetti, invece di lanciarti nel prossimo test per cercare un risultato diverso.

Il framework: cinque domande prima di qualsiasi test

Da questa analisi si può estrarre un framework operativo. Prima di lanciare qualsiasi A/B test, su qualsiasi elemento del tuo eCommerce o della tua strategia email, rispondi a queste cinque domande. Per iscritto. Se non riesci a rispondere a tutte e cinque, non sei pronto per testare.

1. Qual è il problema di business che sto cercando di risolvere?
Non "voglio ottimizzare il pop-up". Ma "il tasso di iscrizione è sotto il benchmark e voglio capire perché". Il problema deve essere specifico, misurabile, e collegato a un impatto reale sul business.

2. Qual è la mia ipotesi?
Non "proviamo tre versioni diverse e vediamo quale va meglio". Ma "credo che il gancio non sia rilevante per l'utente in questo contesto, e che un gancio legato al prodotto specifico performerà meglio". Un'ipotesi è falsificabile. Se non può essere smentita, non è un'ipotesi.

3. Sto testando una sola variabile?
Se le varianti differiscono per più di un elemento, non è un A/B test. È un confronto tra esperienze diverse che non ti permetterà di attribuire il risultato a una causa specifica. Se vuoi testare più variabili contemporaneamente, serve un design fattoriale strutturato e un campione molto più grande.

4. Ho abbastanza traffico per un risultato significativo?
Un calcolatore di significatività statistica ti dice quante osservazioni ti servono in funzione della dimensione dell'effetto che vuoi misurare. Se il tuo pop-up ha 150 visualizzazioni al giorno e ti servono 3.000 per variante, il test dura tre settimane. Accettalo, oppure non testare. Dichiarare un vincitore dopo 400 visualizzazioni non è coraggio, è autoillusione.

5. Sto misurando la metrica giusta?
La metrica deve riflettere l'obiettivo di business, non lo step intermedio. Per un pop-up a due step, è il tasso di conversione end-to-end, non il submit rate dello step 2. Per un flusso email, è il revenue per recipient, non l'open rate. La metrica sbagliata ti dà la risposta giusta alla domanda sbagliata.

Il costo nascosto dell'ottimizzazione perpetua

C'è un ultimo punto che vale la pena fare. Tutto il tempo speso a iterare sui test del pop-up, a creare varianti ibride, a monitorare i risultati, a preparare il prossimo giro... è tempo che non viene speso su qualcos'altro.

Magari quel brand avrebbe beneficiato di più da un lavoro sulla proposta di valore complessiva. O da un'analisi seria delle ragioni per cui gli utenti abbandonano il sito. O dalla costruzione di un flusso di nurturing post-iscrizione che trasformi quegli iscritti in clienti. Ma quelle sono attività che richiedono pensiero strategico, non iterazione meccanica. E l'iterazione meccanica è seducente, perché dà la sensazione di fare qualcosa. Di ottimizzare. Di progredire.

La realtà è che a volte la cosa più produttiva che puoi fare è fermarti. Chiudere la dashboard. Spegnere il test. E chiederti: sto risolvendo il problema giusto?

Il buon lavoro richiede tempo. Ma richiede soprattutto che quel tempo sia investito sulla domanda giusta, non sulla risposta più veloce.

Vuoi un approccio strutturato al testing e all'ottimizzazione del tuo eCommerce, dove le domande vengono prima dei test? Parliamone.