A/B testing o AI bandit? 30 giorni di CRO su una landing page

Sulla landing page con più traffico ho smesso di mettere in coda il successivo A/B testing e ho affidato l'ottimizzazione a un multi-armed bandit basato sull'AI. Trenta giorni dopo, le iscrizioni erano aumentate e il bandit aveva ridotto automaticamente il traffico destinato alla variante perdente. Ma non potevo attribuire il risultato con un dato statisticamente significativo, perché un bandit non produce quel tipo di prova. Tutto il punto è in questo compromesso.

A/B testing o AI bandit: il risultato e il limite

La pagina è un'offerta long-form che trasforma sia il traffico paid freddo sia i visitatori organici già interessati in iscrizioni alla prova. Nei 30 giorni precedenti l'attivazione del bandit, il tasso di conversione medio sulle iscrizioni era del 3.41%. Stessa pagina, stessa offerta, stesso mix di traffico: nei 30 giorni successivi, con l'allocazione affidata al bandit, il dato è salito al 4.62%. Sul principale evento di conversione, l'incremento relativo è del 35.5%.

Prima che qualcuno faccia uno screenshot del numero, però, va chiarito il limite: è un aumento del risultato cumulativo, non un effetto identificato causalmente. Un multi-armed bandit sposta il traffico verso la variante che sta vincendo in quel momento. Non mantiene una ripartizione pulita 50/50 abbastanza a lungo da calcolare un intervallo di confidenza per una singola variante. Non c'è un p-value. Non si può dire che «la variante B ha battuto la variante A con una confidenza del 95%». Si può soltanto affermare che, sull'intera popolazione dei visitatori, hanno convertito più persone rispetto al precedente periodo di controllo. Sono due affermazioni diverse, e un consiglio di amministrazione consapevole della distinzione chiederà quale delle due state sostenendo.

Per contestualizzare anche i costi: nei 30 giorni ho instradato ~84,000 visualizzazioni di pagina attraverso il bandit. La spesa per i tool è stata di $299 per un mese di Webflow Optimize nel piano da 100K visualizzazioni, più un progetto pilota con Coframe (prezzo su contatto commerciale, su cui torno tra poco). In tutto, meno di $500 di costi di piattaforma a fronte di un aumento reale su una pagina che genera un volume significativo di prove. I conti tornano. Il limite sull'attribuzione resta.

Perché ho abbandonato il test A/B previsto

La pagina si trova alla fine di due flussi di traffico: le campagne Meta paid gestite con la rotazione tra AdCreative.ai, Pencil Pro e controllo umano di cui ho già scritto, più il traffico organico e i referral dai motori AI ottenuti con il playbook GEO di 14 giorni. In totale, circa 2,800 sessioni al giorno, con una ripartizione paid/organico di 30/70 che cambia di settimana in settimana.

È esattamente il profilo di traffico meno adatto a un A/B testing pulito. Per rilevare un incremento relativo del 10% con una potenza dell'80% e un tasso di conversione di base del 3.4%, servivano circa 50,000 visitatori per braccio: all'incirca 35 giorni per un test a due bracci mantenuto al 50/50. Cinque settimane durante le quali una variante già riconosciuta come perdente avrebbe continuato a ricevere il 50% del traffico paid, solo per raggiungere la significatività. Con un CPL di $24 sul paid, ogni punto percentuale di sottoperformance di quella variante avrebbe significato bruciare denaro per scelta progettuale.

È il problema del regret. Un test A/B è esplorazione pura: la ripartizione resta fissa proprio per ottenere potenza statistica, e il prezzo da pagare è mostrare un'esperienza peggiore a metà dei visitatori per tutta la durata del test. Il bandit rinuncia a quell'inferenza pulita in cambio del risultato cumulativo: sfrutta la variante in testa e continua, allo stesso tempo, a esplorare le altre. I confronti empirici indicano che, nei problemi stazionari, riduce il regret cumulativo del 30–60% rispetto a un A/B con ripartizione uniforme.

Queste erano le mie regole decisionali prima di partire:

• Bandit quando il traffico è scarso rispetto all'effetto da rilevare, mostrare la variante perdente costa molto, la pagina resta attiva senza una finestra di campagna prestabilita e contano più le conversioni cumulative del trimestre che un dato causale difendibile.
• A/B testing quando devo sostenere l'incremento davanti a chi risponde del P&L, quando il cambiamento è ampio e poco frequente (prezzo, hero, posizionamento) oppure quando le varianti sono troppo diverse per apprendere in modo congiunto.

Questa pagina soddisfaceva tutte le condizioni per il bandit. Ho quindi cancellato l'A/B testing in programma e avviato il bandit.

Stack completo: tool e costi

Ho valutato quattro tool che offrono ottimizzazione continua guidata dall'AI, anziché i classici workflow di A/B testing. Ne ho portati due in produzione; gli altri due sono stati analizzati seriamente, ma esclusi da questa prova. Ecco la valutazione senza filtri.

Coframe. Un ottimizzatore basato su un multi-armed bandit modificato, capace di generare varianti di copy, elementi visivi e persino codice dei componenti, per poi distribuire il traffico tramite il proprio bandit. Si installa con uno script tag. L'azienda ha raccolto circa $9M. Il prezzo viene comunicato solo contattando il reparto vendite: non esiste una pagina pubblica, e questo è già un segnale utile per la pianificazione. Il budget è imprevedibile, prima di avviare qualsiasi attività serve un ciclo commerciale e l'impostazione enterprise si adatta poco a chi lavora da solo. Ho eseguito un progetto pilota. La qualità delle varianti generative era la migliore tra i quattro tool; l'attrito nell'acquisto, il peggiore.

Webflow Optimize. Si basa sul motore Intellimize acquisito da Webflow. Il piano Standard costa $299/month per 100K visualizzazioni di pagina; i livelli disponibili sono 25K, 50K, 100K, 250K e 500K. Consente fino a 5 test simultanei. Funziona solo con pagine ospitate su Webflow: per me non è un problema, ma diventa un ostacolo insuperabile per qualsiasi altro stack. È il tool usato per i 30 giorni in produzione, perché la pagina era già su Webflow e il calcolo del piano Webflow era già coperto.

Optimizely Opal. Una sperimentazione guidata da agenti costruita sopra la piattaforma Optimizely esistente. Secondo i dati pubblicati dalla stessa Optimizely, gli utenti di Opal eseguono il 78.7% di esperimenti in più, il 24.1% di campagne di personalizzazione in più e registrano un aumento del 9.3% nel tasso di successo. Sono numeri del fornitore, basati sulla sua metodologia: li riporto perché possiate ridimensionarli opportunamente. Prezzo enterprise. Ha senso per un team che possiede già un contratto Optimizely, non per una sola landing page.

VWO Copilot. Uno stack Testing + Insights + Personalize con un livello AI sovrapposto. È la piattaforma più consolidata e, dietro le funzioni AI, conserva l'impostazione mentale più vicina all'A/B testing classico. La sceglierei per un workflow A/B pulito con assistenza AI, non per un workflow centrato sul bandit in cui il test A/B è solo un'opzione.

In questa prova, Webflow Optimize è rimasto in produzione per tutti i 30 giorni; Coframe è stato eseguito in parallelo come progetto pilota su una pagina secondaria, per confrontare la qualità delle varianti.

Il playbook di 30 giorni, giorno per giorno

Giorni 0–3: configurare il tracciamento e congelare. Un solo evento di conversione: l'iscrizione alla prova, confermata dal server, non il clic su un pulsante. Qualsiasi evento conteggiato sul client gonfia allo stesso modo i risultati di tutte le varianti, dando l'illusione di vincere quando in realtà si sta scambiando rumore per segnale. Ho congelato il controllo: la pagina esistente è rimasta la variante A, senza modifiche, con una quota minima garantita del 20% per tutta la prova. In questo modo conservavo una coorte holdback con cui fare il confronto successivo. Senza quella soglia, una volta emersa una variante in testa il bandit avrebbe tolto traffico al controllo, lasciandomi senza un riferimento.

Giorni 4–10: generare e lasciare apprendere. Ho inserito quattro varianti che intervenivano sul titolo della hero, sul copy della CTA principale e sull'ordine del blocco di social proof. La prima settimana è la fase di esplorazione del bandit. L'allocazione appariva quasi uniforme: 22%, 19%, 21%, 18%, 20% tra controllo e quattro varianti al giorno 7. È qui che molti operatori si fanno prendere dal panico e provano ad «aiutare». Non fatelo. Modificare le varianti durante l'apprendimento azzera le distribuzioni a priori e fa perdere la settimana.

Giorni 11–21: la curva di riallocazione. Intorno al giorno 12, il bandit ha iniziato a spostare visibilmente l'allocazione. Al giorno 18, la variante in testa riceveva il 41% del traffico; il controllo manteneva la soglia del 20%, le due varianti intermedie si attestavano a ~15% ciascuna e la peggiore era stata ridotta a meno del 10%. È il bandit che svolge il proprio lavoro: ogni visitatore inviato alla variante perdente genera regret, e l'algoritmo lo minimizza in tempo reale.

Giorni 22–30: fissare e decidere. Ho fissato la direzione vincente, non la singola variante: hero più breve, CTA orientata al beneficio, social proof above the fold. Ho esportato le varianti. La domanda al giorno 30 era questa: promuovere la variante vincente a un A/B testing pulito contro il controllo, così da ottenere un dato causale per il consiglio di amministrazione, oppure lasciare in esecuzione il bandit con il ciclo successivo di varianti?

I vincoli di sicurezza applicati per tutta la prova erano: una soglia minima di traffico del 20% sul controllo; un kill switch se il limite inferiore dell'intervallo di confidenza di una variante avesse indicato un calo relativo del 50% rispetto al controllo per oltre 48 ore; una verifica settimanale delle variazioni nel mix di traffico. Se la quota paid/organico si fosse spostata di oltre 10 punti da una settimana all'altra, avrei congelato il bandit fino alla stabilizzazione. Il traffico non stazionario è il pericolo silenzioso.

Il problema dell'attribuzione: il punto fondamentale

È la parte che i listicle non raccontano, nonché l'unico motivo per cui questo post esiste.

Per sua natura, un multi-armed bandit non può produrre significatività statistica su una singola variante. Gli strumenti statistici dell'A/B testing — p-value, intervalli di confidenza, calcoli della potenza — presuppongono una regola di allocazione fissa. L'intera proposta di valore del bandit consiste invece nel fatto che la regola di allocazione non è fissa: si adatta a ciò che indicano i primi dati. Quando l'allocazione dipende dai risultati, l'inferenza classica non regge più. I campioni di ogni braccio sono distorti. È ancora possibile misurare le conversioni cumulative sull'intera popolazione, ma non attribuire in modo causale e pulito un risultato alla variante B rispetto alla variante A.

Non è un bug, ma una scelta progettuale. Il bandit ottimizza un obiettivo diverso: ridurre al minimo il regret cumulativo e massimizzare le conversioni cumulative. I confronti empirici mostrano con coerenza una riduzione del regret del 30–60% rispetto a un A/B con ripartizione uniforme nei problemi stazionari. La metrica è «meno regret», non «incremento causale dimostrato per la variante B».

Questo impone precisione nelle parole:

• Difendibile: «Dopo l'attivazione del bandit, la pagina ha convertito al 4.62% su 84,000 visitatori nell'arco di 30 giorni, contro il 3.41% registrato sulla stessa pagina nei 30 giorni precedenti».
• Indifendibile: «La variante B ha causato un aumento del 35% nel tasso di conversione».

La prima frase descrive un risultato cumulativo. La seconda avanza una tesi causale che un bandit non può dimostrare.

La mia soluzione parziale è stata la coorte di controllo al 20%. Avendo garantito alla pagina originale un'allocazione del 20% per tutti i 30 giorni, dispongo di una coorte di confronto piccola ma pulita. Durante la prova, la coorte di controllo ha convertito al 3.38%, un valore sostanzialmente invariato rispetto al baseline dei 30 giorni precedenti. La coorte assegnata alle altre varianti ha convertito al 4.93%. È un'indicazione direzionale: l'incremento è reale, non un effetto stagionale. Non è comunque un risultato A/B pulito, perché il gruppo fuori controllo è a sua volta un mix variabile di versioni. Basta però per dire a un consiglio di amministrazione: «La prova ha superato il proprio holdback interno; ecco la differenza, ecco cosa stiamo affermando e cosa no».

Se serve un dato causale difendibile, utilizzate il bandit per trovare la direzione più promettente, poi promuovete la variante in testa a un test A/B 50/50 contro il controllo. È il workflow che rispetta sia il budget di regret di chi gestisce l'operatività sia lo standard probatorio di chi analizza i dati.

Dove il bandit non ha funzionato

Ho applicato lo stesso playbook a due pagine in cui il bandit ha reso meno di un semplice test A/B. La prima era una pagina dei prezzi con poco traffico, meno di 400 sessioni al giorno. Il bandit ha impiegato troppo tempo per uscire dalla fase esplorativa e le indicazioni direzionali erano rumorose. Un semplice A/B 50/50 condotto per sei settimane mi ha dato una risposta più chiara, con meno complessità operativa. La seconda era un checkout in cui l'evento di conversione arrivava 3–5 giorni dopo l'esposizione alla variante. I bandit presuppongono un feedback ragionevolmente rapido: se tra esposizione e risultato passa troppo tempo, l'algoritmo rialloca il traffico usando dati obsoleti e insegue fantasmi.

Varianti generative scartate: circa il 40% di quelle prodotte da Coframe e una quota inferiore di quelle di Webflow Optimize. I segnali erano i soliti: trattini lunghi in punti innaturali, verbi d'azione da repertorio, liste parallele dal ritmo di un modello che cerca di sembrare un marketer. Tutto ciò che finiva nella uncanny valley della voce del brand veniva eliminato prima di ricevere traffico. Il tasso di scarto è il costo che nessuno indica nelle pagine dei prezzi.

La trappola della non stazionarietà ha rischiato di colpirmi nella terza settimana. La quota di traffico paid è passata dal 30% al 47% in quattro giorni, mentre una campagna Meta aumentava di scala. La variante in testa aveva vinto su un mix di traffico diverso da quello che stava arrivando e il suo tasso di conversione ha iniziato a scendere. Ho congelato il bandit per 48 ore, atteso che il mix si stabilizzasse e riavviato con una nuova esplorazione. Lasciandolo attivo, avrebbe tratto la lezione sbagliata da un pubblico temporaneamente diverso.

Il principio replicabile per la conversion rate optimization

Ecco la regola decisionale, generalizzata e separata dalle caratteristiche della mia pagina.

Usate un bandit quando il traffico è scarso rispetto all'incremento da rilevare, quando mostrare la variante perdente a metà dei visitatori ha un costo significativo, quando la pagina rimane sempre attiva senza una finestra di campagna e quando le conversioni cumulative del trimestre contano più di un dato causale difendibile per una singola variante. Usate un test A/B quando dovete sostenere il numero dell'incremento davanti a chi risponde del P&L, quando il cambiamento è abbastanza ampio e raro da richiedere una lettura pulita prima dell'adozione o quando intendete estendere la variante vincente ad altre superfici e dovete sapere se ha davvero funzionato.

La maggior parte degli operatori finirà per usare entrambi. Il bandit sulle superfici di conversione always-on: homepage, pagina principale dell'offerta, flusso di iscrizione. L'A/B sulle scommesse di direzione: prezzi, posizionamento, riscrittura della hero. L'errore è considerarli metodi concorrenti: ottimizzano obiettivi diversi. L'errore degli articoli-lista è presentare il bandit come un upgrade gratuito, senza compromessi statistici. Non lo è. Il prezzo è il p-value, e va pagato consapevolmente oppure non va pagato affatto.

Il costo per un'esecuzione continua, alla scala descritta, è di $299/month per Webflow Optimize nel livello da 100K visualizzazioni di pagina, con piani superiori al crescere del traffico. Va messa a budget anche mezza giornata aggiuntiva alla settimana per controllare le allocazioni, eliminare le varianti peggiori e monitorare le derive non stazionarie. È questo il costo reale. Se state integrando il workflow in un'agenzia o in una funzione growth interna e vi serve aiuto per collegare correttamente l'attribuzione delle conversioni al CRM e al data warehouse, è un'altra conversazione. Per implementare il bandit bastano invece un operatore, un pomeriggio e uno script tag.

Una sola CTA, perché il post è lungo e meritate un prossimo passo chiaro: la checklist per l'audit dei workflow aziendali con l'AI è quella che uso per stabilire quali superfici sono adatte al bandit e quali richiedono un A/B testing pulito. Applicatela al funnel prima di scegliere il tool. Quando si parte dal tool, i team growth finiscono per pagare funzionalità che non hanno abbastanza traffico per sfruttare.