{"id":3846,"date":"2026-06-23T10:40:33","date_gmt":"2026-06-23T09:40:33","guid":{"rendered":"https:\/\/www.gironi.it\/blog\/?p=3846"},"modified":"2026-06-23T10:40:34","modified_gmt":"2026-06-23T09:40:34","slug":"peeking-problem","status":"publish","type":"post","link":"https:\/\/www.gironi.it\/blog\/peeking-problem\/","title":{"rendered":"Il peeking problem: perch\u00e9 sbirciare l’A\/B test gonfia i falsi positivi"},"content":{"rendered":"\n

Il 21 gennaio 2015 Optimizely \u2014 una delle piattaforme di A\/B testing pi\u00f9 usate al mondo \u2014 accese per tutti i suoi clienti un motore statistico completamente nuovo, il New Stats Engine<\/em>.
Non era un capriccio tecnico: il vecchio motore, costruito attorno a un classico t-test a orizzonte fisso (Fixed Horizon<\/em>) e sviluppato con statistici di Stanford, aveva un difetto che riguardava chiunque guardasse i risultati di un test prima della fine. E noi i risultati di un test li guardiamo sempre<\/em> prima della fine.<\/p>\n\n\n\n

Il problema lo avevano misurato loro stessi, simulando dei test A\/A \u2014 due varianti identiche, dove per costruzione nessuna \u00e8 migliore dell’altra, quindi qualunque “vincitore” dichiarato \u00e8 un falso allarme.
Stando ai dati pubblicati da Optimizely, su test da 5.000 visitatori chi controllava i numeri dopo ogni<\/em> visitatore vedeva il 57% dei test A\/A dichiarare un falso vincitore almeno una volta<\/strong>; controllando ogni 500 visitatori il numero scendeva al 26%, ogni 1.000 al 20%. Numeri da brivido per uno strumento che dovrebbe servire a decidere con rigore. La riscrittura \u2014 inferenza sequenziale pi\u00f9 controllo del false discovery rate, quella che chiamano always-valid \u2014 serviva proprio a riportare l’errore, come scrivevano loro, “da oltre il 30% al 5%”.<\/p>\n\n\n\n

\u00c8 lo stesso inganno che abbiamo incontrato chiudendo l’articolo sulla regressione verso la media<\/a>: l\u00ec selezionavamo le pagine messe peggio \u2014 un istante estremo nello spazio<\/em> dei dati \u2014 e ci facevamo ingannare dal loro rientro. Qui selezioniamo un istante estremo nel tempo<\/em>: ci fermiamo appena il test ci d\u00e0 ragione. Il meccanismo \u00e8 cugino, il rischio identico.<\/p>\n\n\n\n\n\n\n\n

Cos’\u00e8 il peeking<\/h2>\n\n\n\n

Chi gestisce un A\/B test<\/a> lo conosce bene: il test \u00e8 in corso, i dati arrivano giorno dopo giorno, e la tentazione di sbirciare la dashboard \u00e8 irresistibile.
Il peeking<\/em> \u2014 letteralmente “sbirciare” \u2014 non \u00e8 il semplice atto di guardare: \u00e8 guardare riservandosi di fermare il test<\/em> nel momento in cui il risultato diventa significativo. \u00c8 quel “ottimo, la variante B ha superato la soglia, chiudiamo qui e dichiariamo il vincitore” detto a met\u00e0 raccolta dati.<\/p>\n\n\n\n

Il punto delicato \u00e8 che ogni sguardo accompagnato dalla possibilit\u00e0 di fermarsi \u00e8 un test statistico in pi\u00f9<\/strong>.
Un singolo test con soglia al 5% accetta, per definizione, un 5% di probabilit\u00e0 di gridare al vincitore quando in realt\u00e0 non c’\u00e8 alcuna differenza. Ma se quello stesso test lo ripetiamo venti volte lungo la raccolta, e ci basta che una sola<\/em> di quelle venti volte superi la soglia per fermarci e cantare vittoria, allora le probabilit\u00e0 di inciampare in un falso positivo non sono pi\u00f9 il 5%: si accumulano<\/strong> a ogni sguardo.<\/p>\n\n\n\n

Non \u00e8 la solita molteplicit\u00e0 di chi confronta dieci varianti insieme. Qui la molteplicit\u00e0 \u00e8 nascosta nel tempo<\/em>: una sola variante, guardata tante volte. \u00c8 la stessa logica per cui se si lancia una moneta una volta sola un risultato strano \u00e8 raro, ma se ci si concede di guardare dopo ogni lancio e di fermarsi al primo momento favorevole, prima o poi quel momento arriva \u2014 e lo si scambia per un segnale.<\/p>\n\n\n\n

Quanto costa sbirciare: una simulazione<\/h2>\n\n\n\n

Le parole convincono fino a un certo punto; i numeri molto di pi\u00f9. Simulo in R un A\/A test, cio\u00e8 due varianti con esattamente lo stesso<\/strong> tasso di conversione vero (il 10%): qualunque differenza che emerge \u00e8 rumore, e qualunque “vittoria” dichiarata \u00e8 un falso positivo per costruzione.
Preparo il terreno fissando il seme del generatore casuale (cos\u00ec i numeri sono riproducibili), la funzione che calcola il p-value del confronto tra due proporzioni, e la funzione che simula un singolo esperimento e dice se a un certo punto ha dichiarato un (falso) vincitore:<\/p>\n\n\n\n

set.seed(2025)\n\np_vero  <- 0.10    # stesso conversion rate per A e B (H0 vera)\nn_arm   <- 2000    # visitatori per variante a fine test\nn_sim   <- 4000    # numero di esperimenti simulati\nalpha   <- 0.05\nsguardi <- 20      # quante volte \"sbirciamo\" durante la raccolta\nlook_at <- round(seq(n_arm \/ sguardi, n_arm, length.out = sguardi))\n\n# p-value z-test due proporzioni, due code\npval_ab <- function(xa, na, xb, nb) {\n  pp <- (xa + xb) \/ (na + nb)\n  se <- sqrt(pp * (1 - pp) * (1 \/ na + 1 \/ nb))\n  2 * pnorm(-abs((xa \/ na - xb \/ nb) \/ se))\n}\n\n# un esperimento A\/A: TRUE se dichiara un (falso) vincitore\nesperimento <- function(soglia, guarda) {\n  a <- cumsum(rbinom(n_arm, 1, p_vero))\n  b <- cumsum(rbinom(n_arm, 1, p_vero))\n  for (k in guarda) {\n    p <- pval_ab(a[k], k, b[k], k)\n    if (!is.na(p) && p < soglia) return(TRUE)\n  }\n  FALSE\n}<\/code><\/pre>\n\n\n\n
Cominciamo dal comportamento corretto: un solo test, alla fine, sui 2.000 visitatori per variante. Lo eseguo 4.000 volte e conto quante dichiarano un vincitore:<\/p>\n\n\n\n
# orizzonte fisso: un solo test, alla fine\nfisso <- mean(replicate(n_sim, esperimento(alpha, n_arm)))\ncat(sprintf(\"Orizzonte fisso: %.1f%% falsi positivi\\n\", 100 * fisso))\n# Orizzonte fisso: 5.0% falsi positivi<\/code><\/pre>\n\n\n\n
Esce 5,0%<\/strong>: esattamente il livello che avevamo dichiarato con la soglia al 5%. Il test, usato come si deve, mantiene la promessa. 
Ora cambio una cosa sola: invece di guardare una volta alla fine, guardo venti volte durante la raccolta e mi fermo al primo momento in cui il p-value scende sotto 0,05. Aggiungo gli sguardi intermedi e rieseguo:<\/p>\n\n\n\n
# peeking: test a ogni sguardo, stop al primo significativo\npeek <- mean(replicate(n_sim, esperimento(alpha, look_at)))\ncat(sprintf(\"Peeking (%d sguardi): %.1f%% falsi positivi\\n\", sguardi, 100 * peek))\n# Peeking (20 sguardi): 24.3% falsi positivi<\/code><\/pre>\n\n\n\n
Da 5,0%<\/strong> a 24,3%<\/strong>. 
Gli stessi dati, lo stesso test, la stessa soglia: l’unica cosa cambiata \u00e8 quando abbiamo deciso di guardare, e il tasso di falsi positivi \u00e8 quasi quintuplicato.<\/strong> Quasi un test A\/A su quattro, in cui le due varianti sono identiche per costruzione, ci convince di aver trovato un vincitore. Il 24,3% della nostra simulazione e il 30% riportato da Optimizely raccontano la stessa storia con dati diversi: sbirciare non \u00e8 un peccato veniale, \u00e8 il modo pi\u00f9 efficace per ingannarsi da soli.<\/p>\n\n\n\n
Soluzione 1: l’orizzonte fisso<\/h2>\n\n\n\n
La cura pi\u00f9 semplice \u00e8 anche la pi\u00f9 antipatica: decidere prima<\/em> quanti dati raccogliere, e poi avere la disciplina di aspettare fino alla fine senza fermarsi in anticipo, qualunque cosa dica la dashboard nel frattempo. 
\u00c8 quello che la simulazione ci ha appena mostrato: con un solo test alla fine, il falso positivo resta inchiodato al 5% promesso. Nessuna magia, solo l’aver eliminato gli sguardi opportunistici.<\/p>\n\n\n\n
“Quanti dati” non \u00e8 una cifra a caso: dipende da quanto \u00e8 piccola la differenza che vogliamo essere in grado di cogliere e da quanta certezza pretendiamo. \u00c8 il calcolo della dimensione campionaria, che si fa prima di lanciare il test con il nostro calcolatore di significativit\u00e0<\/a> e che poggia sui concetti di effect size e power analysis<\/a>. 
Fissato quel numero, l’orizzonte fisso \u00e8 la strada pi\u00f9 sicura: nessuna correzione statistica da applicare, nessuna soglia da ritoccare. Si paga per\u00f2 un prezzo in pazienza \u2014 bisogna resistere alla curiosit\u00e0 per giorni o settimane \u2014 e questo, nella realt\u00e0 operativa, \u00e8 esattamente ci\u00f2 che quasi nessuno riesce a fare.<\/p>\n\n\n\n
Soluzione 2: guardare senza barare<\/h2>\n\n\n\n
E se monitorare in corsa fosse davvero necessario \u2014 perch\u00e9 un test che sta andando malissimo va fermato, perch\u00e9 gli stakeholder vogliono aggiornamenti? 
Allora la strada non \u00e8 guardare di nascosto con la soglia di sempre, ma guardare apertamente<\/em> con una soglia pi\u00f9 severa. L’idea \u00e8 semplice: se a ogni sguardo alziamo l’asticella, rendendo pi\u00f9 difficile gridare al vincitore in ciascuna occasione, possiamo fare in modo che l’errore complessivo<\/strong> \u2014 sommato su tutti gli sguardi \u2014 resti il 5% che volevamo. Calibro in R la soglia per-sguardo, provando valori via via pi\u00f9 stringenti sugli stessi venti sguardi di prima:<\/p>\n\n\n\n
# soglia per-sguardo pi\u00f9 severa che riporta l'errore complessivo ~5%\nfor (sg in c(0.05, 0.02, 0.01, 0.005)) {\n  fp <- mean(replicate(n_sim, esperimento(sg, look_at)))\n  cat(sprintf(\"  soglia %.3f -> %.1f%% complessivo\\n\", sg, 100 * fp))\n}\n#   soglia 0.050 -> 25.1% complessivo\n#   soglia 0.020 -> 11.7% complessivo\n#   soglia 0.010 ->  6.6% complessivo\n#   soglia 0.005 ->  3.3% complessivo<\/code><\/pre>\n\n\n\n
Come si vede, la soglia abituale dello 0,05 produce un 25,1% di errore complessivo (di nuovo il disastro del peeking), ma man mano che la rendiamo pi\u00f9 severa l’errore rientra: intorno allo 0,01 \u2014 una soglia cinque volte pi\u00f9 stringente di quella standard \u2014 l’errore complessivo torna vicino al 5% nominale.<\/strong> \u00c8 il prezzo da pagare per il diritto di sbirciare: a ogni singolo sguardo si pretende molta pi\u00f9 evidenza, in cambio della libert\u00e0 di guardare spesso.<\/p>\n\n\n\n
Quella appena mostrata \u00e8 una versione artigianale e a soglia costante dell’idea. I confini “da manuale” \u2014 pi\u00f9 raffinati, con soglie che cambiano nel corso del test, come quelli di Pocock o O’Brien-Fleming \u2014 si ottengono in R con il pacchetto gsDesign<\/code>, e i tool commerciali come Optimizely usano una variante always-valid<\/em> (la cosiddetta mSPRT) della stessa idea di fondo. 
Cambia la matematica fine, non il principio: per guardare spesso senza barare bisogna chiedere, a ogni sguardo, pi\u00f9 evidenza di quanta ne chiederebbe un test singolo.<\/p>\n\n\n\n
Un avvertimento: un risultato visto durante il test, da solo, non prova niente: conta quando si \u00e8 deciso di guardarlo.<\/strong> 
Lo stesso p-value sotto 0,05 significa cose diverse a seconda che sia l’unico test a orizzonte fisso o il primo dei venti in cui ci si \u00e8 riservati di fermarsi. Senza dichiarare in anticipo come e quando si guarderanno i dati, qualunque “vincitore” emerso in corsa \u00e8 sospetto.<\/p>\n\n\n\n
Prova tu<\/h2>\n\n\n\n
Per sentire il meccanismo da vicino, si parte dallo script e si cambia un solo parametro: il numero di sguardi<\/code>. 
Si prova a passare da un monitoraggio settimanale (pochi sguardi) a uno giornaliero (molti sguardi) e si riesegue la simulazione del peeking. Cosa aspettarsi: pi\u00f9 di frequente si sbircia, pi\u00f9 sale il tasso di falsi positivi \u2014 la frequenza degli sguardi \u00e8 la benzina del problema. Poi si rif\u00e0 la calibrazione della soglia con quel nuovo numero di sguardi e si verifica che, scegliendo una soglia abbastanza severa, l’errore complessivo torna comunque sotto controllo. \u00c8 la dimostrazione, fatta in prima persona, che il peeking non \u00e8 una maledizione: \u00e8 solo un conto che va pagato.<\/p>\n\n\n\n
\n\n\n\n
C’\u00e8 un’ultima trappola di questa famiglia, forse la pi\u00f9 subdola, perch\u00e9 non si nasconde nei nostri dati ma in quelli che ci raccontano gli altri. Quando leggiamo il case study di un’agenzia \u2014 “abbiamo aumentato le conversioni del 300% con questa tattica” \u2014 stiamo guardando un sopravvissuto: i mille tentativi identici che sono falliti non li racconta nessuno. \u00c8 il survivorship bias<\/em>, il motivo per cui i case study mentono anche quando dicono il vero, ed \u00e8 il prossimo passo del nostro viaggio tra i tranelli dei dati di marketing.<\/p>\n\n\n\n
\n\n\n\n
Per approfondire<\/h3>\n\n\n\n
Su peeking, arresto anticipato e test sequenziali il riferimento \u2014 in inglese \u2014 resta Trustworthy Online Controlled Experiments<\/em><\/a> di Ron Kohavi, Diane Tang e Ya Xu: scritto da chi ha guidato le piattaforme di sperimentazione di Microsoft, Google e LinkedIn, dedica pagine esplicite a tutti i modi in cui un A\/B test in corsa pu\u00f2 ingannarci, e a come difendersi. \u00c8 il libro che tira fuori dal cassetto chiunque debba prendere sul serio gli esperimenti online.<\/p>\n","protected":false},"excerpt":{"rendered":"
Il 21 gennaio 2015 Optimizely \u2014 una delle piattaforme di A\/B testing pi\u00f9 usate al mondo \u2014 accese per tutti i suoi clienti un motore statistico completamente nuovo, il New Stats Engine. Non era un capriccio tecnico: il vecchio motore, costruito attorno a un classico t-test a orizzonte fisso (Fixed Horizon) e sviluppato con statistici … Leggi tutto “Il peeking problem: perch\u00e9 sbirciare l’A\/B test gonfia i falsi positivi”<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_uag_custom_page_level_css":"","footnotes":""},"categories":[629],"tags":[],"class_list":["post-3846","post","type-post","status-publish","format-standard","hentry","category-statistica-it"],"lang":"it","translations":{"it":3846,"en":3847},"uagb_featured_image_src":{"full":false,"thumbnail":false,"medium":false,"medium_large":false,"large":false,"1536x1536":false,"2048x2048":false,"post-thumbnail":false},"uagb_author_info":{"display_name":"Paolo Gironi","author_link":"https:\/\/www.gironi.it\/blog\/author\/autore-articoli\/"},"uagb_comment_info":0,"uagb_excerpt":"Il 21 gennaio 2015 Optimizely \u2014 una delle piattaforme di A\/B testing pi\u00f9 usate al mondo \u2014 accese per tutti i suoi clienti un motore statistico completamente nuovo, il New Stats Engine. Non era un capriccio tecnico: il vecchio motore, costruito attorno a un classico t-test a orizzonte fisso (Fixed Horizon) e sviluppato con statistici…","_links":{"self":[{"href":"https:\/\/www.gironi.it\/blog\/wp-json\/wp\/v2\/posts\/3846","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.gironi.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.gironi.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.gironi.it\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.gironi.it\/blog\/wp-json\/wp\/v2\/comments?post=3846"}],"version-history":[{"count":1,"href":"https:\/\/www.gironi.it\/blog\/wp-json\/wp\/v2\/posts\/3846\/revisions"}],"predecessor-version":[{"id":3853,"href":"https:\/\/www.gironi.it\/blog\/wp-json\/wp\/v2\/posts\/3846\/revisions\/3853"}],"wp:attachment":[{"href":"https:\/\/www.gironi.it\/blog\/wp-json\/wp\/v2\/media?parent=3846"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.gironi.it\/blog\/wp-json\/wp\/v2\/categories?post=3846"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.gironi.it\/blog\/wp-json\/wp\/v2\/tags?post=3846"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}