Cos'è un test A/B?

Il test A/B è un esperimento controllato randomizzato applicato a una decisione aziendale: si divide una popolazione di utenti in due gruppi assegnati a caso, uno vede la versione attuale, il controllo, e l'altro la variante, il trattamento, e si confrontano su una metrica decisa prima di guardare un solo risultato. La randomizzazione è il cuore del metodo, perché è il meccanismo che rende l'attribuzione valida per costruzione, senza dover assumere nulla sui fattori nascosti che distinguono i due gruppi. Il riferimento sull'argomento è Kohavi e colleghi al KDD 2013: descrivono come Bing eseguisse oltre 200 esperimenti concorrenti al giorno, e raggruppano le difficoltà pratiche in tre aree: culturale e organizzativa, ingegneristica, e di affidabilità statistica dei risultati. Il metodo funziona solo quando c'è abbastanza traffico da rendere la randomizzazione significativa, ed è qui che la maggior parte delle PMI italiane esce dal suo campo di applicazione.

Cosa serve perché un test A/B conti davvero qualcosa

Un test A/B mal condotto è peggio di nessun test: produce una falsa certezza. Tre condizioni lo distinguono da un esperimento che sembra uno ma non lo è. Primo: la metrica di successo va fissata prima del lancio, con metriche di guardia che devono non peggiorare, o si finisce a scegliere a posteriori quale numero raccontare meglio. Secondo: il campione va calcolato prima, non a occhio; un test su poco traffico non regge l'effetto che si spera di misurare: quasi sempre non conclude, e quando conclude sovrastima l'effetto, come spiego alla voce significatività statistica. Terzo: la durata pianificata si rispetta, salvo un disegno sequenziale previsto prima o una metrica di guardia che peggiora; guardare i risultati in corsa e fermarsi appena sembrano buoni, e un effetto di novità che svanisce dopo la prima settimana, sono i due modi più comuni in cui un test A/B mente a chi lo legge. Il rilascio può passare da un feature flag, che però è solo l'infrastruttura.

Un esempio enterprise

Un e-commerce con milioni di visitatori mensili può testare in una settimana un nuovo checkout su metà del traffico: il volume rende possibile un campione ampio in poco tempo. Una PMI italiana di distribuzione B2B che vende macchinari industriali non ha questa possibilità: pochi visitatori al mese, un ciclo di vendita di settimane con più decisori, un sito che genera contatti, non transazioni. Testare lì due pagine prodotto in modo randomizzato non arriva a un campione sufficiente nei tempi in cui la decisione va presa, se non per effetti enormi. In un caso simile ho impostato un rilascio progressivo osservato invece del test: la nuova pagina è andata prima al 20% del traffico organico per un mese, monitorando richieste di preventivo e tempo in pagina, poi al 100% solo dopo un segnale stabile su più settimane. Non è un test A/B: è un confronto pre/post con i suoi limiti dichiarati, compresa la possibilità che stagionalità o campagne concorrenti si confondano con l'effetto della modifica.

Perché conta per chi decide

Chi decide deve prima chiedersi se il traffico o la popolazione disponibile reggono un esperimento randomizzato, prima di commissionarne uno già condannato a non concludere nulla. Per decisioni una tantum come la scelta di un fornitore o una migrazione di piattaforma non esiste un secondo gruppo a cui non applicare la scelta: l'alternativa onesta è un pilota su un segmento ristretto, misurato con attenzione, senza spacciarlo per un esperimento controllato che non può esistere in quel contesto. E quando un numero migliora ma un indicatore collaterale peggiora, vale la stessa cautela che riguarda ogni metrica isolata: vedi la legge di Goodhart. Il valore del test A/B non è la parola stessa, è la disciplina che impone: definire prima cosa conterebbe come prova, e accettare un risultato negativo tanto quanto uno positivo.