Nell’articolo sul p-value abbiamo visto che anche i risultati «significativi» possono ingannarci. Qui l’inganno è ancora più semplice, e per questo più insidioso: guardiamo solo chi ce l’ha fatta. Si chiama survivorship bias, il bias del sopravvissuto.

In sintesi: il survivorship bias (in italiano bias del sopravvissuto o di sopravvivenza) è l’errore che commettiamo quando traiamo conclusioni guardando solo i casi che hanno superato una selezione, ignorando quelli che sono stati scartati lungo la strada. Se la selezione dipende proprio dal risultato che stiamo misurando (si pubblica il case study solo se è andata bene, resta online solo l’articolo che porta traffico) la media calcolata sui sopravvissuti è distorta, a volte di molto. Lo si combatte chiedendosi sempre chi manca dal dataset e perché, definendo il gruppo da studiare prima di conoscere l’esito e conservando i dati dei casi falliti.

Di cosa parleremo:

• Cos’è il survivorship bias?
• Un esempio: 1.000 siti e 55 case study
• Chi non torna non racconta
• Un secondo esempio: la potatura dei contenuti
• Dove si nasconde il survivorship bias nella SEO
• Come difendersi?
• Domande frequenti
• Prova tu
• Per approfondire

Cos’è il survivorship bias?

La storia più famosa arriva dalla Seconda guerra mondiale. A New York, alla Columbia University, lavorava lo Statistical Research Group, un gruppo di matematici al servizio delle forze armate americane; fra loro c’era Abraham Wald.
Il problema, nella versione che si racconta di solito, era questo: gli aerei che tornavano dalle missioni erano crivellati di colpi, ma non in modo uniforme. La fusoliera e le ali ne avevano molti, i motori pochissimi. Dove conveniva aggiungere la corazza, sapendo che non la si poteva mettere dappertutto senza appesantire troppo l’aereo?

La risposta istintiva è «dove ci sono più fori». Wald propose l’esatto contrario: la corazza va dove i fori mancano.
Gli aerei osservati erano quelli tornati. Se sui motori dei sopravvissuti i colpi erano rari, non era perché i motori venissero colpiti poco: era perché gli aerei colpiti ai motori non tornavano. I fori mancanti erano sugli aerei abbattuti, che nessuno poteva contare.

(La versione aneddotica semplifica parecchio: il lavoro di Wald fu un vero metodo matematico per stimare la vulnerabilità degli aerei a partire dai danni dei sopravvissuti. Ma il cuore del ragionamento è proprio quello.)

Dunque: il survivorship bias è l’errore di trarre conclusioni solo dai casi che hanno superato una selezione, come se rappresentassero tutti.
Non è un errore di calcolo: le medie sui sopravvissuti sono calcolate benissimo. È un errore su chi entra nel calcolo. E diventa grave quando la selezione dipende dall’esito che ci interessa: gli aerei tornano se non sono stati colpiti nei punti vitali, il case study si pubblica se la strategia ha funzionato.

Un esempio: 1.000 siti e 55 case study

Costruiamo l’esempio per simulazione, così conosciamo la verità. Mille siti fanno la stessa modifica, per esempio riscrivono i title delle pagine principali, e la modifica non serve a niente: la variazione di traffico nei tre mesi successivi è puro rumore, la normale oscillazione di un sito da un trimestre all’altro (la simuliamo con una deviazione standard del 15% circa).
Poi facciamo quello che succede nella realtà: scrive il case study solo chi ha visto almeno un +25%.

Genero i dati in R:

set.seed(42)
n_siti <- 1000
var_trim1 <- exp(rnorm(n_siti, 0, 0.15)) - 1   # variazione del traffico in tre mesi
pubblica  <- var_trim1 >= 0.25                  # chi racconta il successo

(Il rumore è generato sulla scala logaritmica e poi riportato in percentuale: così un sito può perdere al massimo il 100%, ma guadagnare anche più del 100%, come accade al traffico vero.)

Calcoliamo prima la verità, cioè la media su tutti i mille siti, e la quota di quelli che sono migliorati:

round(100 * mean(var_trim1), 1)       # variazione media, in %
# [1] 0.7
round(100 * mean(var_trim1 > 0), 1)   # % di siti migliorati
# [1] 48.5

Come ci si aspetta da una modifica inutile, la media è praticamente zero (+0,7%) e più della metà dei siti è peggiorata. Ora guardiamo il mondo come lo vediamo noi, cioè attraverso i case study pubblicati:

sum(pubblica)                              # quanti case study
# [1] 55
round(100 * mean(var_trim1[pubblica]), 1)  # variazione media raccontata
# [1] 34.9
round(100 * range(var_trim1[pubblica]), 1)
# [1] 25.1 68.9

Escono 55 case study, con una crescita media del +34,9% e punte fino al +68,9%. Il 100% dei case study racconta un successo, mentre fra tutti i siti i successi sono stati meno della metà.
Il lettore che li raccoglie tutti e ne fa la media, scrupolosamente, conclude che riscrivere i title vale un +35% di traffico. Ogni singolo numero è vero, e la conclusione è completamente falsa.

C’è un modo semplice per smascherare l’inganno: chiedere ai 55 vincitori come è andato il trimestre successivo. Se la ricetta funzionasse, dovrebbero continuare a crescere. Simulo un altro trimestre di rumore:

var_trim2 <- exp(rnorm(n_siti, 0, 0.15)) - 1   # il trimestre dopo
round(100 * mean(var_trim2[pubblica]), 1)      # i 55 vincitori, tre mesi dopo
# [1] 2.2
sum(var_trim2[pubblica] >= 0.25)               # quanti si ripetono
# [1] 4

I vincitori tornano sulla media di tutti (+2,2%), e solo 4 su 55 replicano il successo, più o meno quanti ci si aspetterebbe dal caso. È la regressione verso la media, che abbiamo già incontrato: chi è stato selezionato per un risultato estremo, alla misura successiva, tende a tornare nella norma. Survivorship bias e regressione verso la media sono due facce dello stesso problema: abbiamo scelto i casi guardando l’esito.

Chi non torna non racconta

L’idea è antichissima. Cicerone racconta che al filosofo Diagora di Melo, a Samotracia, mostrarono le tavolette votive dipinte da chi era sopravvissuto a un naufragio dopo aver pregato gli dèi: non era forse la prova che le preghiere funzionano? Diagora rispose chiedendo dove fossero i ritratti di quelli che avevano pregato ed erano annegati.
Nassim Taleb chiama questo insieme di dati invisibili il cimitero silenzioso: i casi che non ce l’hanno fatta non scrivono, non dipingono tavolette, non tornano alla base. E proprio perché sono silenziosi, ci dimentichiamo che esistono.

Il punto delicato è che il cimitero silenzioso non si vede per costruzione. Non è un dato mancante per distrazione, che con un po’ di cura si può recuperare: è il meccanismo stesso che produce i dati a escluderlo. Nessun case study ci dirà mai quanti altri hanno provato la stessa cosa.

Un secondo esempio: la potatura dei contenuti

Il survivorship bias non ha bisogno di LinkedIn: può nascere dentro i nostri stessi dati. Prendiamo un blog che pubblica 100 articoli all’anno dal 2020 al 2025. Ogni anno fa un audit dei contenuti, quella che in gergo si chiama content pruning: gli articoli che hanno almeno un anno e portano meno di 30 visite al mese vengono rimossi (o messi in noindex) con probabilità 1/2, perché qualcuno li giudica recuperabili e qualcun altro no.
Nella simulazione, e questo è il punto, il traffico di un articolo non dipende in alcun modo dall’anno in cui è stato scritto.

Costruisco il blog in R:

set.seed(2025)
anni <- 2020:2025
post <- data.frame(anno = rep(anni, each = 100))
post$visite <- round(rlnorm(nrow(post), log(40), 1.1))   # visite al mese
post$online <- TRUE
for (audit in 2021:2025) {
  candidati <- post$online & post$anno < audit & post$visite < 30
  post$online[candidati & runif(nrow(post)) < 0.5] <- FALSE
}

Il traffico segue una distribuzione log-normale, come accade di solito: molti articoli con poche visite, pochi articoli con moltissime. Proprio per questo come misura riassuntiva usiamo la mediana e non la media, che i pochi articoli di grande successo trascinerebbero verso l’alto.

Un anno dopo l’ultimo audit, qualcuno si chiede se convenga puntare sui contenuti evergreen. Estrae dal CMS gli articoli online e calcola le visite mediane per anno di pubblicazione:

online <- post[post$online, ]
tapply(online$visite, online$anno, median)
#  2020 2021 2022 2023 2024 2025
#  78.0 78.5 73.0 54.0 54.0 41.5

Il risultato sembra netto: gli articoli del 2020 portano quasi il doppio delle visite di quelli del 2025. «I contenuti invecchiano bene, il traffico si accumula col tempo». Ora guardiamo la stessa tabella su tutti gli articoli mai pubblicati, compresi quelli rimossi:

tapply(post$visite, post$anno, median)
#  2020 2021 2022 2023 2024 2025
#  38.0 38.0 43.0 38.0 40.5 41.5

La crescita sparisce: l’anno di pubblicazione non conta niente, come avevamo stabilito. L’effetto «età» era interamente prodotto dagli audit. Gli articoli del 2020 hanno subìto cinque potature e ne è rimasto il 62%, i più forti; quelli del 2025 non ne hanno subita nessuna e sono tutti lì, deboli compresi. Confrontando gruppi che hanno subìto selezioni diverse, abbiamo misurato la selezione, non i contenuti.

C’è un’ironia sottile: proprio chi lavora bene, e fa pulizia regolarmente, si costruisce un archivio che mente. E la menzogna è comoda, perché conferma che i contenuti vecchi sono preziosi e che la potatura ha funzionato.

Dove si nasconde il survivorship bias nella SEO

Una volta imparato a riconoscerlo, lo si trova dappertutto. Qualche esempio dalla pratica quotidiana:

• Gli studi sui fattori di ranking. Periodicamente esce lo studio che misura le pagine in prima posizione: tante parole in media, tante immagini, tanti backlink. Ma lo studio guarda solo le prime dieci posizioni: quante pagine con le stesse caratteristiche stanno in quarta pagina? Senza di loro non sappiamo se quelle caratteristiche distinguono i vincitori o sono semplicemente comuni a tutti. (È anche un problema di correlazione scambiata per causazione, ma il primo vizio è nel campione.)
• «Cosa hanno in comune i siti che hanno superato il core update». Senza guardare i siti con le stesse caratteristiche che invece sono crollati, l’elenco delle virtù dei sopravvissuti non dimostra niente.
• Search Console. Mostra le pagine e le query che hanno ottenuto impressioni: le pagine che Google non mostra mai non compaiono, e le query anonimizzate per privacy nemmeno. Le tabelle dell’interfaccia, inoltre, si fermano alle prime mille righe. Analizzare «le pagine del sito» partendo da lì significa analizzare le pagine che già funzionano.
• Le best practice degli A/B test. Le raccolte di «test vincenti» raccontano le varianti che hanno vinto, non le dieci identiche che hanno perso altrove. E i vincitori di un A/B test fermato al momento giusto, come abbiamo visto parlando di peeking, sono sopravvissuti doppiamente selezionati.
• I portfolio e le testimonianze. Un’agenzia mostra i clienti cresciuti, non quelli persi; un corso mostra gli studenti che hanno trovato lavoro. Non è disonestà: è il modo in cui funziona la vetrina. Ma la vetrina non è il magazzino.
• I dataset dei tool. I domini scaduti, i siti chiusi, le pagine eliminate escono silenziosamente dagli indici di backlink e di visibilità. Un trend storico calcolato sui siti attivi oggi è un trend dei sopravvissuti.

Come difendersi?

Non esiste una formula che corregga il survivorship bias dopo il fatto: se i casi scartati sono persi, nessun calcolo li restituisce. Esistono però abitudini che lo prevengono.

Definire il gruppo prima di conoscere l’esito. È la lezione del secondo esempio. Se vogliamo sapere come rendono gli articoli del 2020, il gruppo giusto è tutti gli articoli pubblicati nel 2020, non quelli ancora online. Gli epidemiologi lo chiamano studio di coorte: si segue tutto il gruppo dall’inizio, morti compresi. Nella simulazione, è esattamente la differenza fra la linea tratteggiata e quella continua.

Chiedere il denominatore. Davanti a un successo, la domanda è sempre «su quanti tentativi?». Cinquantacinque case study entusiasti su mille tentativi raccontano una storia molto diversa da cinquantacinque su sessanta. Se il denominatore non è noto, la conclusione onesta è che non sappiamo.

Conservare i morti. Nel nostro lavoro il cimitero silenzioso si può, in parte, conservare: le vecchie sitemap, l’elenco degli URL rimossi o reindirizzati con la data, gli export completi di Search Console scaricati regolarmente, i risultati di tutti gli A/B test, non solo dei vincenti. Costa poco, e trasforma un archivio che mente in uno che si può interrogare.

Confrontare con chi non ha fatto niente. Il modo migliore per sapere se una modifica funziona è confrontare le pagine modificate con pagine simili lasciate com’erano, scelte prima di guardare i risultati: è l’idea dello split test SEO. Il gruppo di controllo è, in un certo senso, il cimitero che ci costruiamo apposta.

Diffidare degli effetti grandi selezionati per successo. Quando un risultato ci arriva perché è stato eccezionale, aspettiamoci che alla prova successiva sia meno eccezionale. Non è pessimismo: è quello che abbiamo visto accadere ai 55 vincitori.

Domande frequenti

Qual è l’esempio più famoso di survivorship bias?

Quello degli aerei della Seconda guerra mondiale analizzati dal matematico Abraham Wald. Gli aerei che tornavano avevano pochi colpi sui motori, e la tentazione era corazzare le parti più colpite. Wald capì che i colpi sui motori mancavano perché gli aerei colpiti lì non tornavano: la corazza andava messa proprio dove, sui sopravvissuti, i fori non c’erano.

Survivorship bias e bias di selezione sono la stessa cosa?

Il survivorship bias è un caso particolare del bias di selezione. Il bias di selezione si ha ogni volta che il campione analizzato non rappresenta la popolazione di interesse; nel survivorship bias il campione è formato da chi ha superato una selezione, e la selezione dipende di solito dall’esito stesso, come il successo o la permanenza nel tempo.

Come si dice survivorship bias in italiano?

Si usano bias del sopravvissuto, bias di sopravvivenza o distorsione da sopravvivenza. Il termine inglese resta il più diffuso, anche nei testi italiani.

Perché i case study di successo sono poco affidabili?

Non perché siano falsi, ma perché sono selezionati: si pubblicano quando la strategia ha funzionato, e restano nel cassetto quando non ha funzionato. Una raccolta di case study mostra quindi solo la coda fortunata dei risultati, e la media dei successi raccontati può essere molto lontana dall’effetto reale, che può anche essere nullo.

Si può correggere il survivorship bias dopo aver raccolto i dati?

Solo se si recuperano le informazioni sui casi esclusi, o se si conosce con precisione il meccanismo che li ha esclusi e lo si può modellare. Se gli esclusi sono semplicemente spariti, nessuna tecnica statistica li restituisce: per questo conviene prevenirlo, definendo il gruppo da studiare prima di conoscere l’esito e conservando i dati dei casi falliti.

Prova tu

Il codice dell’articolo si presta a qualche esperimento.

• Si abbassa la soglia di pubblicazione dal +25% al +10% (pubblica <- var_trim1 >= 0.10): quanti case study escono ora, e quanto vale la loro media? La distorsione si riduce, ma sparisce?
• Si dà alla modifica un effetto vero ma piccolo, del +3%, aggiungendo log(1.03) alla media di rnorm(). Di quante volte i case study pubblicati esagerano l’effetto reale?
• Nella potatura si porta la probabilità di rimozione da 1/2 a 1 (runif(nrow(post)) < 1): come cambia la tabella degli articoli online? E se la soglia passa da 30 a 60 visite?

L’ultimo esperimento è il più istruttivo: più la potatura è severa, più l’archivio «dimostra» che i contenuti vecchi sono migliori, senza che sia cambiato niente nei contenuti.

Abbiamo visto che guardare solo chi è sopravvissuto alla selezione distorce le medie, anche quando ogni dato è vero. C’è una trappola parente, che ci aspetta ogni volta che una notizia ci sembra molto più probabile di quanto sia: dimenticare quanto è raro, in partenza, l’evento che stiamo cercando. Un test accurato al 99%, se l’evento che cerca è abbastanza raro, può sbagliare la maggior parte delle volte che dà l’allarme. È la base rate fallacy, e sarà la prossima tappa del nostro viaggio tra le trappole dei dati.

Per approfondire

Sul ruolo del caso nel successo e sui sopravvissuti che scambiamo per vincitori, consiglio Giocati dal caso di Nassim Nicholas Taleb: un libro brillante e polemico, nato nel mondo della finanza ma perfetto per chi deve giudicare strategie, case study e consulenti a partire dai loro risultati.

Su questo blog il p-value compare in decine di articoli, dal test delle ipotesi all’A/B testing, dalla regressione ai confronti multipli. È il numero più usato della statistica applicata, e probabilmente il più frainteso. Vale la pena fermarsi una volta su che cosa dice, e soprattutto su che cosa non dice.

In sintesi: il p-value è la probabilità di osservare dati almeno così estremi come quelli ottenuti, supponendo che l’ipotesi nulla sia vera (cioè che l’effetto non esista). Non è la probabilità che l’ipotesi nulla sia vera, né la probabilità che il risultato sia dovuto al caso. Un p-value piccolo non dice che l’effetto è grande, e un p-value sopra 0,05 non dice che l’effetto non c’è. La soglia di 0,05 è una convenzione, non un confine naturale. Per decidere servono anche la dimensione dell’effetto, l’intervallo di confidenza e una stima di quante delle idee che testiamo funzionano davvero.

Di cosa parleremo:

• Cos’è il p-value, in una frase
• Malinteso 1: «c’è il 97% di probabilità che funzioni»
• Malinteso 2: «un p piccolo vuol dire un effetto grande»
• Malinteso 3: «p sopra 0,05, quindi non c’è nessun effetto»
• Malinteso 4: «0,05 è il confine fra vero e falso»
• Cosa riportare, allora?
• Domande frequenti
• Prova tu
• Per approfondire

Cos’è il p-value, in una frase

Partiamo da un A/B test su due titoli di annuncio: 4.000 impressioni ciascuno, 200 clic per il titolo A (CTR 5,0%) e 240 per il titolo B (CTR 6,0%). Il test sulle due proporzioni restituisce p = 0,0498.

Per leggere quel numero bisogna fare un piccolo esercizio di immaginazione. Supponiamo che i due titoli siano identici, che la differenza di CTR non esista e tutto dipenda dal caso dei clic. È l’ipotesi nulla. In quel mondo immaginario, con quale probabilità vedremmo una differenza grande almeno quanto quella osservata, 40 clic su 4.000? La risposta è il p-value: circa il 5%.

In formula, con H₀ l’ipotesi nulla:

\(p = P(\text{dati almeno così estremi} \mid H_0 \text{ vera})\)

La barra verticale si legge «supponendo che»: tutto il calcolo avviene dentro l’ipotesi nulla. Il p-value misura quanto i dati sono sorprendenti se l’effetto non esiste. Non dice niente, direttamente, su quanto sia probabile che l’effetto esista. Ed è proprio da qui che nascono quasi tutti i malintesi.

Una conseguenza che pochi conoscono, ma che aiuta a capire tutto il resto: quando l’ipotesi nulla è vera, il p-value è un numero a caso fra 0 e 1, con distribuzione uniforme. Un p di 0,03 è raro esattamente quanto un p di 0,73. Lo verifichiamo simulando 10.000 A/B test in cui B non cambia niente, e altri 10.000 in cui B porta il CTR dal 5% al 6%:

un_test <- function(ctr_b, n = 4000, ctr_a = 0.05) {
  clic_a <- rbinom(1, n, ctr_a)
  clic_b <- rbinom(1, n, ctr_b)
  prop.test(c(clic_a, clic_b), c(n, n), correct = FALSE)$p.value
}

set.seed(1)
p_nulla <- replicate(10000, un_test(0.05))     # B non cambia niente
p_effetto <- replicate(10000, un_test(0.06))   # B funziona davvero (+20%)

mean(p_nulla < 0.05)
# [1] 0.0481
quantile(p_nulla, c(0.25, 0.50, 0.75))
#       25%       50%       75%
# 0.2483948 0.4970851 0.7524771
mean(p_effetto < 0.05)
# [1] 0.501

Senza effetto, il 4,8% dei test scende sotto 0,05 (il 5% promesso, a meno del caso) e i quartili cadono a 0,25, 0,50 e 0,75: la distribuzione è piatta. Con l’effetto vero, i p-value si ammassano vicino a zero, ma solo la metà scende sotto 0,05: con 4.000 impressioni per variante, la potenza del test è del 50%.

Malinteso 1: «c’è il 97% di probabilità che funzioni»

È il malinteso più diffuso, e il più costoso. Un p di 0,03 non vuol dire che c’è il 3% di probabilità che l’ipotesi nulla sia vera, né il 97% che l’effetto esista. Il p-value è la probabilità dei dati supponendo H₀, non la probabilità di H₀ dati i dati. Sembra un gioco di parole, ma le due probabilità possono essere lontanissime.

Un esempio fuori dalla statistica. La probabilità che una persona sia italiana, sapendo che è il Presidente della Repubblica, è altissima. La probabilità che sia il Presidente della Repubblica, sapendo che è italiana, è di circa una su sessanta milioni. Invertire il «sapendo che» cambia tutto.

Per passare dal p-value alla domanda che ci interessa davvero (questa idea funziona?) manca un ingrediente: quante delle idee che mettiamo alla prova funzionano in partenza. Facciamo un esempio realistico. Testiamo 1.000 idee (titoli, meta description, call to action) e solo una su dieci funziona davvero; le altre nove sono neutre. Lo simulo in R con gli stessi test di prima:

set.seed(5)
funziona <- seq_len(1000) <= 100        # le idee buone sono 100 su 1.000
p_idee <- sapply(funziona, function(f) un_test(ifelse(f, 0.06, 0.05)))

table(significativo = p_idee < 0.05, funziona)

#              funziona
# significativo FALSE TRUE
#         FALSE   853   50
#         TRUE     47   50

Su 1.000 test, 97 risultano «significativi». Cinquanta sono idee che funzionano davvero; 47 sono idee neutre che hanno superato la soglia per caso. Fra i nostri «vincitori», quasi uno su due è un falso allarme, eppure ciascuno di loro aveva un p-value sotto 0,05.

Il conto si può fare anche senza simulazione. Se π è la quota di idee che funzionano, α la soglia e la potenza la probabilità di accorgersi di un’idea buona, la quota di falsi allarmi fra i risultati significativi è:

\(\text{quota di falsi allarmi} = \frac{\alpha \, (1 – \pi)}{\alpha \, (1 – \pi) + \text{potenza} \cdot \pi}\)

Il numeratore sono le idee neutre che passano per caso (il 5% delle 900); al denominatore si aggiungono le idee buone che il test riconosce (il 50% delle 100). Con i nostri numeri: 45 / (45 + 50) = 47%. La tabella mostra come cambia la quota al variare delle due incognite:

La stessa soglia del 5% produce un 6% di falsi allarmi o quasi la metà, a seconda di quanto sono buone le idee che testiamo e di quanti dati abbiamo. È lo stesso meccanismo della base rate fallacy nei test medici: un test accurato su una malattia rara produce comunque una valanga di falsi positivi.

Malinteso 2: «un p piccolo vuol dire un effetto grande»

Il p-value mescola due cose: quanto è grande l’effetto e quanti dati abbiamo. Con dati abbondanti, anche un effetto minuscolo produce un p-value minuscolo.

Search Console ce ne offre l’occasione tutti i giorni. Due sezioni del sito, 10 milioni di impressioni ciascuna, CTR del 5,00% contro il 5,05%: una differenza di cinque centesimi di punto, l’1% in termini relativi. Lo calcolo in R:

n <- 1e7
prop.test(c(n * 0.05, n * 0.0505), c(n, n), correct = FALSE)$p.value
# [1] 3.091392e-07

Un p-value di 0,0000003: «altamente significativo». Ma l’effetto vale cinque clic ogni diecimila impressioni, e quasi certamente non giustifica nessuna decisione. Significativo, in statistica, vuol dire «difficilmente dovuto al caso», non «importante». Per l’importanza serve guardare la dimensione dell’effetto, il tema dell’articolo su effect size e power analysis.

Malinteso 3: «p sopra 0,05, quindi non c’è nessun effetto»

È il malinteso speculare, e altrettanto pericoloso. Torniamo alla figura con le due distribuzioni: quando B funziona davvero, con 4.000 impressioni per variante, metà dei test resta sopra 0,05. Un p-value «non significativo» vuol dire che i dati non bastano a escludere il caso, non che l’effetto è stato escluso.

Facciamo un esempio. Titolo A: 200 clic su 4.000. Titolo B: 222 clic su 4.000, un CTR più alto dell’11%. Lo verifico in R, guardando anche l’intervallo di confidenza:

t <- prop.test(c(222, 200), c(4000, 4000), correct = FALSE)
t$p.value
# [1] 0.271176
t$conf.int     # differenza di CTR, B meno A
# [1] -0.004295887  0.015295887

Il p-value è 0,27, ben sopra la soglia. Ma l’intervallo di confidenza della differenza va da −0,43 a +1,53 punti di CTR: in termini relativi, da un calo dell’8,6% a un aumento del 30,6%. I dati sono compatibili con un titolo leggermente peggiore e con uno nettamente migliore. Concludere «il titolo B non serve» sarebbe come dire che una partita non ancora giocata è finita in pareggio.

L’assenza di prove non è la prova di un’assenza. Il test ci sta dicendo che servono più dati, non che l’idea è da buttare.

Malinteso 4: «0,05 è il confine fra vero e falso»

La soglia di 0,05 non viene dalla natura: viene da Ronald Fisher, che negli anni Venti la propose come riferimento comodo, uno su venti, per segnalare i risultati che meritavano un’occhiata più attenta. Nel tempo è diventata un confine burocratico, con un effetto curioso: un risultato con p = 0,049 viene pubblicato, comunicato, applicato; uno con p = 0,051 finisce nel cassetto.

Quanto sono diversi, nei dati, quei due risultati? Nel nostro A/B test con 200 clic per il titolo A, se il titolo B ne prende 239 il p-value è 0,0555; se ne prende 240 è 0,0498. Un clic su ottomila separa il «non significativo» dal «significativo». Nessuna persona ragionevole cambierebbe idea per un clic, eppure la soglia ci chiede di farlo.

Nel 2016 l’American Statistical Association ha pubblicato una dichiarazione ufficiale sul p-value, la prima volta in 177 anni di storia in cui prendeva posizione su un singolo aspetto della pratica statistica. Contiene sei principi. Tre dicono esattamente quello che abbiamo visto: il p-value non misura la probabilità che l’ipotesi sia vera; non misura la dimensione di un effetto; le conclusioni non dovrebbero basarsi soltanto sul superamento di una soglia.

C’è poi un quarto modo di sbagliare, il più subdolo, perché non riguarda la lettura del p-value ma il modo in cui ci si arriva. Il p-value vale per un test deciso prima di guardare i dati. Se proviamo tante metriche, tanti segmenti, tanti momenti di stop, e teniamo il risultato che passa la soglia, il 5% non vale più. È quello che abbiamo visto parlando di confronti multipli e di peeking, e ha anche un nome poco lusinghiero: p-hacking.

Cosa riportare, allora?

Il p-value non va buttato: risponde onestamente alla sua domanda, quella sul caso. Va solo smesso di fargli rispondere alle domande che non gli competono. Nella pratica quotidiana, un risultato ben riportato ha tre parti.

La dimensione dell’effetto, nell’unità che conta per il business: punti di CTR, clic al mese, euro. Non «significativo», ma «+0,8 punti di CTR, circa 1.200 clic in più al mese».

L’intervallo di confidenza, che dice quanto siamo incerti su quella dimensione: «fra +0,1 e +1,5 punti». Contiene tutto ciò che c’è nel p-value (se esclude lo zero, il test è significativo) e molto di più.

Il contesto del test: era l’unico test previsto, o uno dei venti? La potenza era sufficiente? Quanto erano promettenti le idee in partenza?

Chi vuole rispondere direttamente alla domanda «con quale probabilità B è migliore di A?» deve cambiare approccio: è il terreno dell’A/B test bayesiano, che a quella domanda risponde, a patto di dichiarare le proprie ipotesi di partenza.

Domande frequenti

Cosa significa un p-value di 0,05?

Significa che, se l’effetto non esistesse, osserveremmo dati almeno così estremi in circa 5 casi su 100. Non significa che c’è il 95% di probabilità che l’effetto esista, né il 5% di probabilità che il risultato sia dovuto al caso.

Il p-value è la probabilità che l’ipotesi nulla sia vera?

No. È la probabilità dei dati supponendo vera l’ipotesi nulla, non la probabilità dell’ipotesi nulla dati i dati. Per ottenere la seconda serve sapere anche quanto era plausibile l’ipotesi prima del test: con idee poco promettenti, anche fra i risultati con p sotto 0,05 i falsi allarmi possono essere quasi la metà.

Un p-value molto piccolo indica un effetto importante?

No. Il p-value dipende sia dalla dimensione dell’effetto sia dalla quantità di dati: con milioni di impressioni, anche una differenza di CTR irrilevante produce un p-value minuscolo. L’importanza si giudica dalla dimensione dell’effetto e dal suo intervallo di confidenza.

Se il p-value è maggiore di 0,05 l’effetto non esiste?

Non necessariamente. Vuol dire che i dati non bastano a escludere il caso. Se il test aveva poca potenza, un effetto reale può facilmente produrre un p-value alto: l’intervallo di confidenza mostra quali effetti sono ancora compatibili con i dati.

Perché proprio 0,05?

È una convenzione proposta da Ronald Fisher negli anni Venti come riferimento comodo, una probabilità su venti. Non ha nessun fondamento naturale: un risultato con p = 0,049 e uno con p = 0,051 portano praticamente la stessa evidenza.

Prova tu

Il codice dell’articolo si presta a qualche esperimento rivelatore.

• Si porta la quota di idee buone da 100 a 500 su 1.000 (funziona <- seq_len(1000) <= 500) e si ricalcola la tabella: quanti dei «vincitori» sono ora falsi allarmi? Il risultato dovrebbe avvicinarsi al 9% della tabella.
• Si aumentano le impressioni per variante da 4.000 a 16.000 nella funzione un_test(): cosa succede alla potenza, e alla quota di falsi allarmi fra le idee significative?
• Si ripete la simulazione p_nulla e si contano i test con p fra 0,04 e 0,05, e quelli fra 0,94 e 0,95. Perché sono circa lo stesso numero?

L’ultimo esercizio è il più breve, e forse il più istruttivo: quando l’effetto non c’è, un p-value «quasi significativo» non è più vicino alla verità di un p-value altissimo.

Abbiamo visto che, fra i risultati significativi, la quota di falsi allarmi dipende da quanto sono buone le idee che testiamo. Ma c’è un modo ancora più insidioso di farsi ingannare dai successi: guardare solo quelli che ce l’hanno fatta. I case study che leggiamo raccontano le strategie che hanno funzionato, mai le cento identiche che sono fallite. È il survivorship bias, ed è il prossimo passo del nostro viaggio tra le trappole dei dati.

Per approfondire

Sul p-value, sui suoi usi e sui suoi abusi, consiglio L’arte della statistica di David Spiegelhalter: spiega cosa dice davvero un test di significatività, perché tanti risultati «significativi» non si replicano e come ragionare sull’incertezza senza farsi abbagliare da una soglia.

Nel nostro lavoro il salmone morto ha un nome familiare: Search Console. Confrontiamo il CTR di questo mese con quello del mese scorso su 200 query, troviamo una dozzina di variazioni “significative” e scriviamo nel report quali query sono migliorate. Ma quante di quelle dodici sono cambiate davvero? È il problema dei confronti multipli, e abbiamo già visto spuntarne il profilo parlando di split test SEO e di peeking.

In sintesi: quando si eseguono molti test statistici insieme, la soglia del 5% non vale più per l’insieme: con 10 test indipendenti la probabilità di almeno un falso positivo sale al 40%, con 100 al 99%. I confronti multipli si correggono in due modi. La correzione di Bonferroni (o la sua versione migliorata, il metodo di Holm) controlla la probabilità di commettere anche un solo falso positivo, dividendo la soglia per il numero di test: è prudente, ma perde molti effetti veri. Il metodo di Benjamini-Hochberg controlla invece la quota di falsi positivi fra le scoperte (false discovery rate): è meno severo e più adatto quando si scandagliano molte pagine o query. In R si usa p.adjust().

Di cosa parleremo:

• Perché più test fanno più falsi allarmi?
• Un esempio: 200 query in Search Console
• La correzione di Bonferroni (e quella di Holm)
• Errore sulla famiglia o quota di scoperte false?
• Il metodo di Benjamini-Hochberg
• Quale correzione scegliere?
• Dove si nascondono i confronti multipli nella SEO
• Domande frequenti
• Prova tu
• Per approfondire

Perché più test fanno più falsi allarmi?

Ricordiamo cosa promette la soglia del 5% in un test delle ipotesi: se non c’è nessun effetto, il test ci darà un falso allarme in 5 casi su 100. È una promessa che vale per un test. Il guaio comincia quando di test ne facciamo molti, e ci basta che uno qualsiasi risulti significativo per alzare la mano.

Facciamo un esempio al volo. Lanciando un dado una volta, la probabilità di fare 6 è un sesto; lanciandolo dieci volte, la probabilità di fare almeno un 6 sale all’84%. Con i test funziona allo stesso modo. Se un test da solo ha il 95% di probabilità di non dare un falso allarme, due test indipendenti ne hanno il 95% del 95%, e così via. La probabilità di almeno un falso positivo su m test indipendenti, che gli statistici chiamano family-wise error rate (FWER), è dunque:

\(FWER = 1 – (1 – \alpha)^m\)

dove α è la soglia del singolo test (0,05) e m il numero di test. Con 10 test vale 1 − 0,95¹⁰ = 40%; con 14 supera il 50%; con 100 arriva al 99,4%.

C’è un altro modo di vederla, ancora più diretto: su m test senza alcun effetto reale, il numero atteso di falsi positivi è m × α. Su 200 query che non sono cambiate affatto, dobbiamo aspettarci una decina di variazioni “significative” (200 × 0,05 = 10). Non sono un’anomalia: sono esattamente ciò che la soglia del 5% promette.

Un esempio: 200 query in Search Console

Costruiamo l’esempio per simulazione, così conosciamo la verità. Prendiamo 200 query, con qualche migliaio di impressioni al mese ciascuna e un CTR fra l’1% e il 6%. Per 180 di esse non cambia niente fra un mese e l’altro; per le prime 20 il CTR sale davvero, del 50%. Per ogni query confrontiamo i due mesi con un test sulle proporzioni, come faremmo in un report.

Genero i dati in R:

set.seed(7)
n_query <- 200
impressioni <- round(300 + rlnorm(n_query, log(5000), 0.8))   # impressioni al mese
ctr <- runif(n_query, 0.01, 0.06)                              # CTR fra l'1% e il 6%
vera <- seq_len(n_query) <= 20                                 # le 20 che cambiano davvero
clic_prima <- rbinom(n_query, impressioni, ctr)
clic_dopo  <- rbinom(n_query, impressioni, ifelse(vera, ctr * 1.5, ctr))

# un test per query: il CTR del mese scorso contro quello di questo mese
p <- mapply(function(a, b, n) prop.test(c(a, b), c(n, n))$p.value,
            clic_prima, clic_dopo, impressioni)

Ora facciamo quello che si fa di solito: segniamo come “cambiate” le query con p-value sotto 0,05, e confrontiamo con la verità.

table(scoperta = p < 0.05, vera)

#         vera
# scoperta FALSE TRUE
#    FALSE   171    2
#    TRUE      9   18

Il test ha segnalato 27 query. Diciotto sono cambiate davvero, ma nove no: sono falsi allarmi, esattamente il 5% delle 180 query immobili. In termini più chiari e diretti: un terzo delle “scoperte” del nostro report è rumore, e niente nei numeri ci dice quale terzo. Se a ciascuna di quelle nove query dedicassimo un’analisi, un intervento, una riga di commento al cliente, staremmo lavorando su un fantasma.

La correzione di Bonferroni (e quella di Holm)

La soluzione più antica, e la più intuitiva, è rendere ogni singolo test più severo. Se vogliamo che la probabilità di almeno un falso positivo sull’intera famiglia di test resti al 5%, basta dividere la soglia per il numero di test. È la correzione di Bonferroni:

\(\alpha_{Bonferroni} = \frac{\alpha}{m} = \frac{0{,}05}{200} = 0{,}00025\)

Una query è “cambiata” solo se il suo p-value scende sotto 0,00025. In R non serve fare la divisione a mano: p.adjust() restituisce i p-value corretti, da confrontare con la soglia abituale. Lo verifico in R:

table(scoperta = p.adjust(p, method = "bonferroni") < 0.05, vera)

#         vera
# scoperta FALSE TRUE
#    FALSE   180    6
#    TRUE      0   14

Nessun falso allarme: le 14 query segnalate sono tutte vere. Il prezzo, però, si vede nell’angolo in alto a destra. Sei query cambiate davvero sono sparite dal radar, perché un aumento del 50% su poche centinaia di clic non basta a scendere sotto una soglia così bassa. Bonferroni compra la certezza di non sbagliare con la cecità su una parte degli effetti reali.

C’è un perfezionamento che non costa nulla, il metodo di Holm. Si ordinano i p-value dal più piccolo al più grande; il primo si confronta con α/m, il secondo con α/(m − 1), il terzo con α/(m − 2), e ci si ferma al primo che non supera la sua soglia. Garantisce lo stesso controllo di Bonferroni ed è sempre almeno altrettanto potente, spesso di più. Nel nostro esempio dà lo stesso risultato (14 scoperte, nessuna falsa); con p.adjust(p, method = "holm") non c’è motivo di preferirgli Bonferroni.

Errore sulla famiglia o quota di scoperte false?

Prima di andare oltre, conviene fermarsi su una domanda che sembra filosofica ed è invece pratica: che cosa vogliamo controllare?

Bonferroni e Holm controllano la probabilità di commettere anche un solo falso positivo. È la richiesta giusta quando ogni errore costa caro: decidiamo di rifare il template di tutte le schede prodotto sulla base di un test, e un falso positivo vuol dire settimane di lavoro buttate.

Ma in molte analisi SEO la situazione è diversa. Scandagliamo 200 query o 500 pagine per capire quali meritano un approfondimento. Qui un falso positivo non è una catastrofe: è un’occhiata in più a una pagina che non ne aveva bisogno. Quello che non vogliamo è che le scoperte siano per lo più falsi allarmi. La grandezza da controllare diventa allora la quota di falsi positivi fra le scoperte, che gli statistici chiamano false discovery rate (FDR). Un FDR del 5% vuol dire: delle query che segnaliamo, in media il 5% sarà rumore.

Sono due promesse diverse, e la seconda è molto meno esigente della prima: per questo, a parità di dati, lascia passare più effetti veri.

Il metodo di Benjamini-Hochberg

Il metodo che controlla il FDR, proposto da Yoav Benjamini e Yosef Hochberg nel 1995, è sorprendentemente semplice. A parole: ordiniamo i p-value dal più piccolo al più grande, e invece di una soglia fissa usiamo una soglia che cresce con la posizione in classifica. Il p-value al primo posto deve stare sotto 1/m × 0,05, quello al secondo sotto 2/m × 0,05, e così via:

\(p_{(i)} \le \frac{i}{m} \cdot q\)

dove p₍ᵢ₎ è il p-value in posizione i, m il numero di test e q il FDR che accettiamo (qui 0,05). Si cerca la posizione più bassa in classifica (il p-value più grande) che rispetta la disuguaglianza: quella query e tutte quelle che la precedono sono le scoperte.

Vediamo i p-value del nostro esempio dalla posizione 14 alla 20, con la soglia di ciascuno:

L’ultima posizione che sta sotto la sua soglia è la 17: le prime 17 query sono le scoperte. Bonferroni, con la sua soglia fissa di 0,00025, si sarebbe fermato alla 14. Lo verifico in R:

table(scoperta = p.adjust(p, method = "BH") < 0.05, vera)

#         vera
# scoperta FALSE TRUE
#    FALSE   179    4
#    TRUE      1   16

Diciassette scoperte, sedici vere e una falsa: un falso allarme su diciassette, il 5,9%, in linea con il 5% promesso. Rispetto a Bonferroni abbiamo recuperato due query cambiate davvero, al prezzo di un solo errore. E rispetto al report senza correzioni siamo passati da nove falsi allarmi su 27 a uno su 17.

Il grafico mostra bene la logica. In cima alla classifica ci sono gli effetti grandi, con p-value minuscoli: li trova qualunque metodo. Il problema è la zona di mezzo, dove effetti veri ma modesti si mescolano al rumore. Bonferroni la scarta in blocco; la soglia piatta la accoglie in blocco; Benjamini-Hochberg la attraversa con una soglia che si allarga quanto basta.

(n.b. il metodo garantisce un FDR medio del 5%: in un singolo report la quota effettiva può essere più alta o più bassa. Ripetendo la simulazione 300 volte, Benjamini-Hochberg produce in media 0,6 scoperte false per report, una quota del 3,7%: sotto il 5% promesso.)

Quale correzione scegliere?

Non esiste una correzione giusta in assoluto: esiste quella adatta alla domanda. In sintesi:

Il caso più comune nella pratica quotidiana, però, è un altro: non avevamo deciso niente prima. Abbiamo aperto Search Console, filtrato, segmentato, confrontato, e ci siamo fermati sui numeri che ci sembravano interessanti. In questo scenario nessuna correzione è possibile, perché non sappiamo nemmeno quanti test abbiamo fatto davvero.

Dove si nascondono i confronti multipli nella SEO

Il report mese su mese delle query è il caso più evidente, ma la molteplicità ha molti travestimenti.

I segmenti. “Il CTR non è cambiato, ma da mobile in Lombardia sì”: a forza di affettare i dati per dispositivo, paese, categoria e tipo di pagina, qualche fetta significativa salta fuori sempre. È la stessa trappola del paradosso di Simpson, vista dal lato opposto.

Le metriche. In uno split test SEO guardare clic, impressioni, CTR, posizione e conversioni vuol dire fare cinque test. Per questo la metrica principale si sceglie in anticipo.

Le varianti. Un A/B test con cinque varianti contro il controllo sono cinque confronti; se poi confrontiamo anche le varianti fra loro diventano quindici. Per i confronti fra tutte le coppie di medie l’ANOVA ha un suo strumento dedicato, il test di Tukey.

Il tempo. Guardare un test ogni giorno riservandosi di fermarlo è una molteplicità nascosta nel calendario: è il peeking problem.

Le correlazioni. Una matrice di correlazione fra 20 metriche contiene 190 coppie: una decina risulterà “significativa” anche se le metriche fossero tutte indipendenti.

(n.b. nella realtà le cose vanno anche peggio che nella nostra simulazione. Il CTR di una query non oscilla solo per il caso binomiale dei clic: cambia con la posizione, con le funzioni della SERP, con il mix di dispositivi. prop.test() ignora queste fonti di variabilità e sottostima l’incertezza, quindi sui dati veri i falsi allarmi sono più del 5%. Le correzioni per confronti multipli non rimediano a un modello sbagliato: lo presuppongono giusto.)

Domande frequenti

Cosa sono i confronti multipli in statistica?

Sono le situazioni in cui si eseguono molti test statistici sugli stessi dati o sulla stessa domanda: confrontare molte query, molti segmenti, molte metriche o molte varianti. Ogni test ha la sua probabilità di falso positivo, e insieme le probabilità si accumulano: con abbastanza test, qualche risultato “significativo” arriva per puro caso.

Come si applica la correzione di Bonferroni?

Si divide la soglia di significatività per il numero di test: con 20 test e una soglia del 5%, ogni test deve avere un p-value sotto 0,05 / 20 = 0,0025. In modo equivalente si moltiplica ogni p-value per il numero di test e lo si confronta con 0,05. In R lo fa p.adjust(p, method = "bonferroni").

Che differenza c’è tra FWER e FDR?

Il FWER (family-wise error rate) è la probabilità di commettere almeno un falso positivo nell’insieme dei test; il FDR (false discovery rate) è la quota media di falsi positivi fra i risultati dichiarati significativi. Controllare il FWER è più severo e adatto a poche decisioni costose; controllare il FDR è adatto all’esplorazione di molte ipotesi.

Quando usare Benjamini-Hochberg invece di Bonferroni?

Quando i test sono molti e lo scopo è selezionare cosa approfondire, accettando che una piccola quota delle scoperte sia falsa: analisi di centinaia di query o pagine, screening di segmenti, ricerca di anomalie. Bonferroni, in questi casi, è così severo da perdere buona parte degli effetti veri.

La correzione serve anche con pochi test?

Con due o tre test il rischio complessivo cresce di poco (dal 5% a circa il 10-14%), ma cresce. Se i confronti sono stati decisi in anticipo e sono pochi, il metodo di Holm costa pochissimo in potenza e mette al riparo. Se invece è stato deciso in anticipo un solo confronto principale, la correzione non serve.

Prova tu

Il codice dell’esempio è completo, e si presta a qualche esperimento.

• Si mette a 0 il numero di query che cambiano davvero (vera <- rep(FALSE, n_query)) e si contano le scoperte con e senza correzione. Senza correzione dovrebbero essere una decina; con Bonferroni e con Benjamini-Hochberg quasi sempre zero. È il caso del salmone morto.
• Si porta l’aumento del CTR da 1,5 a 1,2: un effetto più piccolo, più realistico per un title riscritto. Quante delle 20 query vere ritrova ciascun metodo?
• Si ripete la simulazione con 2.000 query invece di 200, sempre con 20 vere. Cosa succede alla soglia di Bonferroni, e quante query vere sopravvivono?

L’ultimo esercizio, in particolare, mostra perché i grandi siti hanno bisogno del FDR: più test facciamo, più Bonferroni ci rende ciechi.

Abbiamo parlato di p-value per tutto l’articolo: da correggere, da ordinare, da confrontare con soglie diverse. Ma che cosa dice, esattamente, un p-value di 0,03? Che c’è il 97% di probabilità che l’effetto sia reale? Che l’ipotesi nulla ha il 3% di probabilità di essere vera? Nessuna delle due, ed è forse il numero più frainteso di tutta la statistica applicata. Sarà il tema del prossimo passo: il p-value e i suoi malintesi.

Per approfondire

Per capire perché tanti risultati «significativi» non reggono alla prova dei fatti, e quanto conti il numero di domande che abbiamo posto ai dati, consiglio L’arte della statistica di David Spiegelhalter: un libro che spiega l’incertezza senza formule inutili e senza scorciatoie. Per i confronti multipli negli esperimenti online, dalle metriche alle varianti, il riferimento in inglese resta Trustworthy Online Controlled Experiments di Ron Kohavi, Diane Tang e Ya Xu.

Nel marketing la risposta classica a questo problema è l’A/B test: due versioni, utenti divisi a caso, si confrontano i risultati. Con la SEO però c’è un ostacolo insormontabile, perché Google vede una sola versione della pagina. Non possiamo dividere gli utenti: possiamo dividere le pagine. È l’idea dello split test SEO, e lo strumento statistico che lo rende affidabile ha un nome che sembra uno scioglilingua: la differenza delle differenze.

In sintesi: uno split test SEO misura l’effetto di una modifica (title, template, dati strutturati) dividendo a caso un gruppo di pagine simili in pagine test, che ricevono la modifica, e pagine di controllo, lasciate intatte. Il confronto prima/dopo da solo inganna, perché stagionalità e core update colpiscono tutte le pagine; la differenza delle differenze (difference-in-differences, DiD) sottrae alla variazione delle pagine test quella delle pagine di controllo, e ciò che resta è l’effetto della modifica. Con un t-test sulle variazioni pagina per pagina si stabilisce se l’effetto è distinguibile dal caso. Servono pagine numerose e omogenee: per accorgersi di un +8% ne servono, di norma, alcune centinaia.

Di cosa parleremo:

• Perché l’A/B test classico non funziona per la SEO
• Perché il confronto prima/dopo inganna
• Come si costruisce uno split test SEO?
• Un esempio: 200 schede prodotto e un core update
• Cos’è la differenza delle differenze?
• Come verifichiamo che il controllo sia un buon controllo?
• Quante pagine servono, e per quanto tempo?
• Le insidie dello split test
• E quando non si può sorteggiare?
• Domande frequenti
• Prova tu
• Per approfondire

Perché l’A/B test classico non funziona per la SEO

In un A/B test sulla conversione di una landing page, ogni visitatore vede la versione A o la versione B, assegnata a caso. Siccome il sorteggio rende i due gruppi di utenti simili in tutto il resto, una differenza nei risultati si può attribuire alla versione. Il caso fa da garante.

Con il ranking il meccanismo si inceppa subito. L’utente che conta, nella SEO, è uno solo: Googlebot. Se gli mostriamo due versioni della stessa pagina a seconda della visita, nel migliore dei casi non capisce quale indicizzare, nel peggiore si chiama cloaking. E il risultato che vogliamo misurare (posizioni, impressioni, clic organici) dipende da come Google valuta la pagina, non da come la vive il singolo visitatore.

La via d’uscita è spostare il sorteggio un livello più su. Al posto degli utenti si sorteggiano le pagine: su un gruppo la modifica, sull’altro niente. Funziona quando il sito ha molte pagine costruite con lo stesso template, che rispondono allo stesso tipo di ricerca: le schede prodotto di un e-commerce, le schede di un sito di annunci, le pagine di categoria, le pagine città di un portale. Un sito con dieci pagine tutte diverse, va detto subito, non può fare uno split test: non ha abbastanza unità da sorteggiare.

Perché il confronto prima/dopo inganna

Se non abbiamo un gruppo di controllo, l’unico confronto possibile è con il passato. Il guaio è che il passato differisce dal presente in mille modi che non c’entrano con la nostra modifica:

• la stagionalità: a dicembre si cercano regali, ad agosto molto meno di tutto il resto;
• gli aggiornamenti dell’algoritmo, che spostano il traffico di interi settori nel giro di pochi giorni;
• la concorrenza, che nel frattempo pubblica, migliora, sparisce;
• la regressione verso la media: se abbiamo scelto di intervenire proprio sulle pagine andate peggio, una parte del miglioramento sarebbe arrivata comunque.

Ognuno di questi fattori può essere più grande dell’effetto che cerchiamo. Un title migliore vale magari un 5-10% di clic in più; un core update può toglierne il 20% in una settimana. Confrontando solo il prima con il dopo, misuriamo la somma di tutto ciò che è cambiato, e la nostra modifica ne è solo un pezzo, spesso il più piccolo.

Il gruppo di controllo risolve il problema alla radice: le pagine di controllo vivono la stessa stagione, lo stesso core update, la stessa concorrenza delle pagine test. L’unica cosa che le distingue è la modifica.

Come si costruisce uno split test SEO?

Le regole sono poche, ma vanno rispettate tutte.

Pagine omogenee. Test e controllo devono essere pagine dello stesso tipo, con lo stesso template e lo stesso intento di ricerca. Mescolare schede prodotto e articoli del blog vuol dire confrontare mele con pere.

Assegnazione casuale. Non scegliamo noi quali pagine modificare: le sorteggiamo. Se scegliessimo “le più promettenti”, introdurremmo esattamente la differenza di partenza che il test deve evitare. Un accorgimento utile è la randomizzazione a coppie: si ordinano le pagine per traffico, si formano coppie di pagine vicine e dentro ogni coppia si tira a sorte quale va nel test. I due gruppi nascono così bilanciati anche sul traffico, che è il fattore più ingombrante.

Un periodo “prima” abbastanza lungo. Ci serve per sapere come si comportano le pagine quando nessuno le tocca, e per verificare che test e controllo si muovano insieme (ci torneremo). Sei-otto settimane sono un buon punto di partenza.

Decidere prima quando guardare. Durata del test e metrica si fissano in anticipo. Guardare i dati ogni mattina e fermarsi al primo segnale favorevole è il peeking problem, e gonfia i falsi positivi esattamente come in un A/B test.

Un esempio: 200 schede prodotto e un core update

Come sempre, un esempio è utile a chiarire il tutto. Lo costruiamo per simulazione, così conosciamo la verità e possiamo vedere quali metodi la ritrovano.

Immaginiamo un e-commerce con 200 schede prodotto dello stesso template. Decidiamo di riscrivere i title di metà di esse, sorteggiate a coppie. Nel nostro mondo simulato la modifica funziona: porta l’8% di clic in più. Ma una settimana dopo la messa online arriva un core update che toglie il 15% dei clic a tutte le pagine del sito, test e controllo. E ogni pagina, come accade sempre, oscilla anche per conto suo, salendo o scendendo di qualche posizione.

Costruisco le pagine in R, con il sorteggio a coppie:

set.seed(2020)
n_pagine <- 200
base <- rlnorm(n_pagine, meanlog = log(30), sdlog = 1)   # clic medi al giorno

# randomizzazione a coppie: ordino per traffico e sorteggio dentro ogni coppia
ordine <- order(base)
gruppo <- character(n_pagine)
for (k in seq(1, n_pagine, by = 2)) {
  gruppo[ordine[k:(k + 1)]] <- sample(c("test", "controllo"))
}
pagine <- data.frame(pagina = 1:n_pagine, base = base, gruppo = gruppo,
                     deriva = rlnorm(n_pagine, -0.25^2 / 2, 0.25))

tapply(pagine$base, pagine$gruppo, median)
# controllo      test
#    32.36      31.96

Il sorteggio a coppie ha fatto il suo lavoro: la pagina “tipica” dei due gruppi fa circa 32 clic al giorno in entrambi.

Genero poi 14 settimane di clic giornalieri: 8 prima della modifica e 6 dopo. Il giorno 57 arrivano i nuovi title (solo sulle pagine test), il giorno 64 il core update (su tutte); nel weekend il traffico cala del 30%.

simula_clic <- function(pagine, effetto = 1.08, modifica = 57, core_update = 64) {
  d <- expand.grid(pagina = pagine$pagina, giorno = 1:98)
  d$gruppo <- pagine$gruppo[d$pagina]
  lambda <- pagine$base[d$pagina] *
    ifelse(d$giorno %% 7 %in% c(6, 0), 0.7, 1) *                    # weekend
    ifelse(d$giorno >= core_update, 0.85, 1) *                      # core update
    ifelse(d$giorno >= modifica, pagine$deriva[d$pagina], 1) *      # deriva
    ifelse(d$gruppo == "test" & d$giorno >= modifica, effetto, 1) * # la modifica
    rlnorm(nrow(d), 0, 0.15)                                        # rumore
  d$clic <- rpois(nrow(d), lambda)
  d$periodo <- ifelse(d$giorno >= modifica, "dopo", "prima")
  d
}
clic <- simula_clic(pagine)

(n.b. la deriva è l’oscillazione propria di ogni pagina dopo la modifica: concorrenti nuovi, link guadagnati o persi, piccoli spostamenti di posizione. Vale in media 1, ma la singola pagina può guadagnare o perdere anche il 30-40%.)

Ora mettiamoci nei panni di chi ha fatto la modifica e non ha un gruppo di controllo. Per ogni pagina calcolo i clic medi al giorno prima e dopo, e la loro variazione:

variazioni <- function(d) {
  m <- aggregate(clic ~ pagina + gruppo + periodo, data = d, FUN = mean)
  w <- reshape(m, idvar = c("pagina", "gruppo"), timevar = "periodo",
               direction = "wide")
  w$delta <- log(w$clic.dopo / w$clic.prima)
  w
}
w <- variazioni(clic)

# variazione media delle pagine test, in percentuale
exp(mean(w$delta[w$gruppo == "test"])) - 1
# [1] -0.101

Le pagine con i title nuovi hanno perso, in media, il 10% dei clic. Senza un controllo, la conclusione sarebbe immediata: la modifica ha fatto danni, torniamo indietro. E sarebbe sbagliata, perché sappiamo (l’abbiamo deciso noi) che la modifica funziona.

(n.b. lavoriamo sul logaritmo del rapporto dopo/prima per due ragioni. Le pagine hanno volumi diversissimi, da un clic al giorno a qualche centinaio, e un effetto come “+8%” è proporzionale, non un numero fisso di clic: sulla scala logaritmica le variazioni percentuali diventano differenze, che si possono sommare e mediare. E la media dei logaritmi, riportata indietro con exp(), è la media geometrica: non si fa trascinare da una pagina che passa da 2 a 9 clic.)

Cos’è la differenza delle differenze?

Guardiamo ora anche le pagine di controllo:

tapply(w$delta, w$gruppo, function(x) exp(mean(x)) - 1)
# controllo      test
#    -0.166    -0.101

Le pagine di controllo, che nessuno ha toccato, hanno perso il 16,6%. È il core update, più le oscillazioni di periodo: è ciò che sarebbe successo anche alle pagine test, se non le avessimo modificate. Gli economisti lo chiamano controfattuale, la storia che non è andata in scena.

L’idea della differenza delle differenze è tutta qui. Calcoliamo prima la variazione di ciascun gruppo (prima differenza), poi la differenza fra le due variazioni (seconda differenza). A parole: l’effetto della modifica è quanto le pagine test sono andate meglio, o peggio, rispetto alle pagine di controllo. In formula, con la variazione media sulla scala logaritmica indicata con Δ:

\(DiD = \bar{\Delta}_{test} – \bar{\Delta}_{controllo} = (\log T_{dopo} – \log T_{prima}) – (\log C_{dopo} – \log C_{prima})\)

dove T e C sono i clic delle pagine test e di controllo. Tutto ciò che ha colpito entrambi i gruppi allo stesso modo (stagionalità, core update, il weekend) compare in tutte e due le parentesi e si cancella nella sottrazione. Resta solo ciò che distingue i gruppi: la modifica.

Il grafico racconta la storia meglio di qualunque tabella. Nella prima settimana dopo la modifica le pagine test salgono davvero, e chi guardasse solo quei giorni griderebbe al successo; poi arriva il core update e tutto precipita. Ma il controllo precipita di più. Lo scarto fra le due linee, che si mantiene fino alla fine, è il nostro effetto.

Resta da capire se quello scarto è abbastanza grande da non essere un caso. Le pagine sono poche e rumorose: magari il sorteggio ha messo nel gruppo test, per pura sfortuna del controllo, qualche pagina che sarebbe salita comunque. È una domanda da test statistico, e siccome abbiamo una variazione per pagina e due gruppi da confrontare, lo strumento è il familiare t-test per due campioni. Lo calcolo in R:

t.test(delta ~ gruppo, data = w)

# t = -2.1086, df = 197.34, p-value = 0.03624
# 95 percent confidence interval:
#  -0.144123939 -0.004821942
# mean in group controllo      mean in group test
#              -0.1809326              -0.1064596

La differenza fra le due medie è 0,0745 sulla scala logaritmica, cioè exp(0,0745) − 1 = +7,7% di clic: molto vicino all’8% vero. Il p-value di 0,036 ci dice che una differenza così grande, se la modifica fosse stata inutile, uscirebbe per caso meno di 4 volte su 100.

L’intervallo di confidenza è però l’informazione più onesta. R lo riporta per la differenza controllo − test; girato nel verso che ci interessa e riportato in percentuale va da +0,5% a +15,5%. In termini più chiari e diretti: la modifica ha quasi certamente funzionato, ma i dati sono compatibili sia con un effetto trascurabile sia con un effetto doppio di quello stimato.

Questa seconda figura spiega perché nessuno dovrebbe giudicare una modifica guardando una pagina sola, o anche dieci. Le oscillazioni di una singola pagina sono molto più grandi dell’effetto che cerchiamo: decine di pagine con i title nuovi hanno perso più di pagine di controllo intatte. Solo la media su molte pagine, confrontata con la media del controllo, fa emergere il segnale.

(n.b. lo stesso risultato si ottiene con una regressione, lm(delta ~ gruppo, data = w): il coefficiente di gruppotest vale 0,0745, con lo stesso p-value. È la forma che conviene quando vogliamo aggiungere altre variabili, per esempio il tipo di pagina, e il motivo per cui nei manuali la DiD compare quasi sempre come un modello di regressione.)

Come verifichiamo che il controllo sia un buon controllo?

Tutto il ragionamento si regge su un’ipotesi: che, senza la modifica, test e controllo si sarebbero mossi allo stesso modo. Si chiama ipotesi delle tendenze parallele (parallel trends), ed è il punto in cui uno split test sta in piedi o crolla.

Non possiamo verificarla nel periodo “dopo”, perché lì il controfattuale non lo vediamo. Ma possiamo controllarla nel periodo “prima”, dove nessuno ha toccato niente. Due strumenti, entrambi di estrema utilità.

Il primo è il grafico che abbiamo già visto: prima della modifica le linee devono sovrapporsi. Se nel periodo “prima” le pagine test crescevano già più del controllo, il sorteggio è andato storto, o le pagine non sono davvero omogenee, e qualunque differenza successiva è sospetta.

Il secondo è un test placebo: si finge che la modifica sia avvenuta a metà del periodo “prima” e si ripete l’analisi. Siccome in quel momento non è successo niente, la DiD deve risultare nulla. Lo verifico in R, spostando la finta modifica al giorno 29:

pre <- subset(clic, giorno < 57)
pre$periodo <- ifelse(pre$giorno >= 29, "dopo", "prima")
t.test(delta ~ gruppo, data = variazioni(pre))

# t = 0.071079, df = 197.57, p-value = 0.9434

Differenza praticamente zero (−0,09%), p-value 0,94: il controllo si comportava come il test quando nessuno li distingueva. È esattamente quello che vogliamo vedere. Un test placebo “significativo”, al contrario, sarebbe un campanello d’allarme da non ignorare.

Quante pagine servono, e per quanto tempo?

Nel nostro esempio è andata bene: p-value 0,036, effetto ritrovato. Ma ci è andata bene quanto? Lo scopriamo con la power analysis: la probabilità che il test si accorga di un effetto che c’è davvero.

Per calcolarla servono tre ingredienti: l’effetto che vogliamo scoprire (+8%, cioè log(1,08) = 0,077 sulla scala logaritmica), il numero di pagine e la variabilità delle variazioni pagina per pagina dentro ciascun gruppo. Quest’ultima la stimiamo dai dati del test: vale circa 0,25. Calcolo in R:

s <- sqrt(mean(tapply(w$delta, w$gruppo, var)))   # dev. standard dentro i gruppi
s
# [1] 0.2497

power.t.test(n = 100, delta = log(1.08), sd = s)$power
# [1] 0.583

power.t.test(power = 0.8, delta = log(1.08), sd = s)$n
# [1] 166.3

Con 100 pagine per gruppo, la potenza è del 58%: poco più di una moneta lanciata. Se ripetessimo lo stesso identico esperimento molte volte, in quattro casi su dieci concluderemmo che la modifica non serve, pur sapendo che funziona. Per arrivare all’80%, la soglia abituale, servono circa 166 pagine per gruppo, oltre 330 in tutto.

La figura dà la misura del problema. Gli effetti tipici delle modifiche SEO sono piccoli, e gli effetti piccoli richiedono molte pagine. Un +15% si vede anche su un centinaio di schede; un +5%, che su un grande e-commerce vale comunque parecchio denaro, ne richiede più di 800.

Prima di partire, dunque, conviene fare il conto all’incontrario: quante pagine abbiamo? Con quel numero, quale effetto minimo possiamo sperare di vedere? La variabilità si stima dalle stesse pagine, confrontando due periodi passati lunghi quanto il test. Se l’effetto minimo rilevabile è più grande di quello che ragionevolmente ci aspettiamo, il test è sottodimensionato. In quel caso o si allarga a più pagine, o si accetta che dirà soltanto “non lo so”.

Quanto al tempo, due considerazioni. Google deve prima scansionare e rielaborare le pagine modificate, e su siti grandi può volerci più di una settimana: i primi giorni dopo la modifica vanno spesso esclusi dal confronto. Poi, un periodo “dopo” più lungo riduce il rumore giornaliero, ma non quello pagina per pagina, che è il grosso. Allungare il test aiuta meno che allargarlo: quattro-sei settimane sono di solito un buon compromesso.

Le insidie dello split test

Il metodo è solido, ma nella pratica quotidiana le occasioni per farsi ingannare non mancano.

La contaminazione. Le pagine test e controllo non vivono isolate: si linkano fra loro, condividono menu e pagine di categoria. Se la modifica cambia i link interni, per esempio aggiungendo un blocco di prodotti correlati, l’effetto si travasa anche sul controllo, e la DiD lo sottostima.

Le pagine con pochissimi clic. Una pagina che passa da 2 a 0 clic al giorno ha una variazione infinita sulla scala logaritmica. Conviene escludere in partenza le pagine sotto una soglia minima di traffico, oppure lavorare sulle impressioni, che sono molto più numerose.

La metrica scelta a posteriori. Clic, impressioni, CTR, posizione media, conversioni: se le guardiamo tutte, qualcuna risulterà “significativa” per caso. La metrica principale si decide prima, e le altre restano informazioni di contorno. È il problema dei confronti multipli, e merita un discorso a sé.

I gruppi troppo diversi. Se il sito ha pagine con volumi molto diversi, conviene randomizzare a coppie o a blocchi (per categoria, per fascia di traffico), come abbiamo fatto. Un sorteggio semplice su 40 pagine può produrre, per pura sfortuna, un gruppo test con tutte le pagine stagionali.

E quando non si può sorteggiare?

Fin qui abbiamo dato per scontato di poter scegliere quali pagine modificare. Ma alcune delle decisioni più importanti, e più rischiose, non si possono dividere in due: una migrazione di dominio o di piattaforma, un nuovo template per tutto il sito, il passaggio a HTTPS. In questi casi il gruppo di controllo interno non esiste, perché tutte le pagine cambiano insieme. E il confronto prima/dopo resta inaffidabile come prima.

L’idea della differenza delle differenze, però, sopravvive. Se non possiamo osservare il controfattuale dentro il sito, possiamo ricostruirlo da fuori: da serie che vivono le stesse stagioni e gli stessi aggiornamenti dell’algoritmo, ma che la migrazione non tocca. Un sito gemello dello stesso gruppo, una sezione del sito rimasta fuori dalla migrazione, l’indice di Google Trends per i temi principali. Nel periodo prima stimiamo come il nostro traffico si muove insieme a queste serie; nel periodo dopo usiamo la stessa relazione per prevedere quanto traffico avremmo avuto senza la migrazione. La differenza fra osservato e previsto è l’effetto.

Facciamo un esempio. Simulo 180 giorni di clic di un sito che migra il giorno 121, perdendo il 12% del traffico; dieci giorni dopo un core update toglie il 25% a tutto il settore. Accanto ci sono due serie di controllo: un sito gemello non migrato e Google Trends.

set.seed(3)
giorni <- 1:180; migrazione <- 121                        # 4 mesi prima, 2 dopo
settore <- exp(cumsum(rnorm(180, 0, 0.02))) *             # andamento del settore
           ifelse(giorni %% 7 %in% c(6, 0), 0.75, 1) *     # weekend
           (1 - 0.25 * (giorni > 130))                     # core update di settore
rumore <- function(sd) exp(as.numeric(arima.sim(list(ar = 0.6), 180, sd = sd)))
sito    <- 800 * settore * rumore(0.05) * ifelse(giorni >= migrazione, 0.88, 1)
gemello <- 300 * settore * rumore(0.03)                    # sito gemello, non migrato
trends  <- 60  * settore * rumore(0.05)                    # Google Trends del tema
prima <- giorni < migrazione

mean(sito[!prima]) / mean(sito[prima]) - 1
# [1] -0.273

Il prima/dopo dice −27%: più del doppio dell’effetto vero, perché mette sul conto della migrazione anche il core update. Costruisco allora il controfattuale con una regressione multipla sul periodo prima, in scala logaritmica, e lo proietto sul periodo dopo:

m <- lm(log(sito) ~ log(gemello) + log(trends), subset = prima)
summary(m)$r.squared
# [1] 0.792

previsto <- predict(m, newdata = data.frame(gemello, trends))
exp(mean(log(sito[!prima]) - previsto[!prima])) - 1
# [1] -0.125

sum(exp(previsto[!prima])) - sum(sito[!prima])   # clic persi in 60 giorni
# [1] 4532.7

Le due serie di controllo spiegano il 79% delle oscillazioni giornaliere del sito prima della migrazione. Il confronto con il controfattuale stima un effetto di −12,5%, a un passo dal −12% vero: circa 4.500 clic persi in due mesi, su 36.400 attesi.

Quanto fidarsi di quel −12,5%? I giorni di una serie storica non sono indipendenti fra loro (un giorno buono tende a essere seguito da un altro giorno buono), e un intervallo calcolato come se lo fossero sarebbe troppo ottimista. Anche qui ci viene in aiuto il placebo, questa volta nel tempo: fingiamo che la migrazione sia avvenuta in vari momenti del periodo prima, stimiamo il modello sui giorni precedenti e misuriamo il finto “effetto” sui 30 giorni successivi.

placebo <- sapply(seq(40, 90, by = 5), function(k) {
  mk <- lm(log(sito) ~ log(gemello) + log(trends), subset = giorni < k)
  pk <- predict(mk, newdata = data.frame(gemello, trends))
  exp(mean(log(sito[k:(k + 29)]) - pk[k:(k + 29)])) - 1
})
range(placebo)
# [1] -0.018  0.028

Quando non è successo niente, il metodo “trova” effetti fra −1,8% e +2,8%: è la sua soglia di rumore. Il −12,5% della migrazione sta nettamente fuori da quella fascia, e possiamo considerarlo reale.

Il metodo che abbiamo appena costruito a mano è il cuore di CausalImpact, il pacchetto R sviluppato da Google per questo problema. Al posto della regressione semplice usa un modello bayesiano per serie storiche, che tiene conto di trend, stagionalità e dipendenza fra i giorni, e restituisce direttamente l’effetto con il suo intervallo di credibilità. La logica è la stessa: un controfattuale costruito da serie non toccate dall’intervento.

Domande frequenti

Cos’è uno split test SEO?

È un esperimento che misura l’effetto di una modifica sul traffico organico dividendo a caso un insieme di pagine simili in due gruppi: le pagine test ricevono la modifica, quelle di controllo restano invariate. Confrontando come cambiano i due gruppi si separa l’effetto della modifica da stagionalità, aggiornamenti dell’algoritmo e concorrenza.

Che differenza c’è tra split test SEO e A/B test?

L’A/B test divide gli utenti: ognuno vede una delle due versioni della stessa pagina. Lo split test SEO divide le pagine, perché Google deve vedere una sola versione di ciascuna. Per questo serve un sito con molte pagine dello stesso tipo.

Quanto deve durare uno split test SEO?

Di solito sei-otto settimane di dati prima della modifica e quattro-sei settimane dopo, escludendo i primi giorni in cui Google sta ancora scansionando le pagine modificate. Allungare il periodo aiuta meno che aumentare il numero di pagine.

Si può fare uno split test con poche pagine?

Con poche decine di pagine si scoprono solo effetti grandi, del 15-20% o più. Per effetti tipici del 5-10% servono di norma alcune centinaia di pagine: conviene calcolare la potenza del test prima di partire.

Come si misura l’impatto di una migrazione SEO?

Confrontando il traffico dopo la migrazione con un controfattuale: una previsione di quanto traffico ci sarebbe stato senza migrazione, costruita da serie che la migrazione non tocca (un sito gemello, una sezione non migrata, Google Trends). Il pacchetto R CausalImpact automatizza questo approccio.

Cosa si può testare con uno split test SEO?

Qualunque modifica applicabile a un gruppo di pagine dello stesso template: title e meta description, struttura degli heading, dati strutturati, blocchi di contenuto, link interni, velocità di caricamento. Le modifiche che toccano tutto il sito insieme, come una migrazione, non si prestano: manca un gruppo di controllo interno, e serve un controfattuale costruito da fuori.

Prova tu

Il codice dell’esempio è completo: basta copiarlo in R e cambiare un parametro alla volta.

• Si porta effetto a 1 (la modifica non fa nulla) e si ripete l’analisi con qualche set.seed() diverso. Quante volte il t-test dichiara, per sbaglio, un effetto significativo? (Dovrebbe succedere circa 5 volte su 100.)
• Si riporta effetto a 1,08 e si raddoppiano le pagine, n_pagine <- 400: come si stringe l’intervallo di confidenza?
• Si “rompe” il sorteggio, mettendo nel gruppo test le 100 pagine con più traffico invece di sorteggiarle, e si dà alle pagine grandi una deriva più favorevole. Cosa dice il test placebo?

Per l’ultimo esercizio, un indizio: è il modo più rapido per capire perché il sorteggio non è un dettaglio burocratico.

C’è una domanda che abbiamo sfiorato senza affrontarla. In uno split test guardiamo di solito una metrica principale, ma la tentazione di guardarne dieci è fortissima: clic, impressioni, CTR, posizione, e poi ogni categoria di pagine per conto suo. Ogni sguardo in più è un’occasione in più per trovare un effetto “significativo” che non esiste. Quanto in fretta si accumulano questi falsi allarmi, e come si correggono, è il tema dei confronti multipli: il prossimo passo del nostro viaggio tra le trappole dei dati.

Per approfondire

Sulla sperimentazione online il riferimento, in inglese, è Trustworthy Online Controlled Experiments di Ron Kohavi, Diane Tang e Ya Xu: dalla scelta delle metriche alle insidie dei gruppi di controllo, è scritto da chi ha guidato gli esperimenti di Microsoft, Google e LinkedIn. Per la differenza delle differenze come strumento econometrico, con le sue ipotesi e le sue estensioni, consiglio Introduzione all’econometria di Stock e Watson, che le dedica una trattazione chiara e piena di esempi.

Abbiamo già affrontato un problema vicino, classificare l’intento di una query con il Naive Bayes — ma lì avevamo un ingrediente che oggi ci manca: un insieme di esempi già etichettati da cui imparare. Qui le etichette non ce le ha date nessuno.
È il territorio del clustering, uno degli strumenti più usati del machine learning, e in questo articolo lo costruiamo in R con i suoi due algoritmi classici: il K-means e il clustering gerarchico.

Di cosa parleremo:

• Raggruppare senza etichette: l’idea del clustering
• K-means: i centroidi e il problema di scegliere k
• Leggere i cluster: chi sono questi gruppi?
• Clustering gerarchico: il dendrogramma
• Quale metodo, e le trappole
• Prova tu
• Per approfondire

Raggruppare senza etichette: l’idea del clustering

La differenza con il Naive Bayes è di principio, non di dettaglio. Lì infatti facevamo apprendimento supervisionato: avevamo query già marcate come informazionali, navigazionali o transazionali, e insegnavamo all’algoritmo a riconoscere le nuove. Qui facciamo apprendimento non supervisionato: nessuno ci ha detto quali e quanti gruppi esistano. Il clustering non verifica un’etichetta che già conosciamo: cerca una struttura che non sapevamo ci fosse.

Per raggruppare servono due cose. La prima è descrivere ogni keyword con dei numeri: nel nostro esempio useremo il volume di ricerca, il costo per clic (cpc), la posizione media e il numero di parole.
La seconda è una nozione di distanza: due keyword sono “vicine” se i loro numeri si somigliano. La distanza più comune è quella euclidea, la stessa che useremmo su una mappa, solo calcolata in uno spazio a quattro dimensioni (una per ogni metrica).

C’è però una trappola da disinnescare subito. Il volume si misura in decine di migliaia, il cpc in centesimi di euro: lasciate così, le distanze sarebbero dominate dal volume, e il cpc non conterebbe quasi nulla.
Prima di calcolare qualsiasi distanza dobbiamo mettere tutte le variabili sulla stessa scala, standardizzandole — in R con la funzione scale(), che a ogni colonna sottrae la media e la divide per la deviazione standard. Solo a quel punto un euro di differenza nel cpc e diecimila ricerche di differenza nel volume “pesano” allo stesso modo.

K-means: i centroidi e il problema di scegliere k

L’idea del K-means è quasi ingenua nella sua semplicità. Decidiamo in quanti gruppi (k) vogliamo dividere i dati; l’algoritmo piazza k punti-rappresentanti, i centroidi, e poi ripete due passi finché le cose si stabilizzano: assegna ogni keyword al centroide più vicino, poi sposta ogni centroide nel centro delle keyword che gli sono state assegnate. Ad ogni giro i gruppi diventano un po’ più coesi, finché non si muovono più.

Ciò che l’algoritmo cerca di minimizzare, a parole, è la dispersione interna dei gruppi: la somma delle distanze (al quadrato) di ogni punto dal centroide del proprio cluster. In formula:

dove \( C_k \) è il k-esimo cluster, \( \mu_k \) il suo centroide e la doppia sommatoria scorre tutti i punti di tutti i gruppi. Più la WCSS (within-cluster sum of squares) è bassa, più i gruppi sono compatti.

Resta il punto dolente: k lo dobbiamo decidere noi, prima di iniziare. Un aiuto viene dal metodo del gomito: proviamo diversi valori di k e guardiamo come cala la WCSS. All’inizio aggiungere un cluster aiuta molto, poi i miglioramenti si fanno marginali; il “gomito” della curva — il punto dove la discesa si appiattisce — suggerisce un k ragionevole. Costruisco la tabella di keyword e calcolo la WCSS da 1 a 6 gruppi in R:

kw <- data.frame(
  keyword = c("scarpe running","scarpe running uomo","nike pegasus","nike pegasus 40",
              "migliori scarpe trail 2026","come scegliere scarpe running",
              "scarpe running offerta","comprare scarpe trail online",
              "differenza scarpe trail e strada","scarpe running pronazione",
              "asics gel nimbus","saucony endorphin","recensione scarpe trail",
              "scarpe running scontate","negozio scarpe running milano"),
  volume   = c(40000,18000,12000,8000,2400,1900,3200,880,1300,2100,9000,4000,1500,2600,720),
  cpc      = c(0.45,0.55,0.30,0.35,0.40,0.10,0.95,1.10,0.08,0.30,0.28,0.33,0.15,0.90,0.85),
  posizione= c(3.1,4.2,2.0,5.5,8.1,11.2,6.0,9.4,14.0,7.3,2.5,6.8,12.1,5.9,4.7),
  n_parole = c(2,3,2,3,5,5,3,4,6,3,3,2,3,3,4)
)

# standardizzo le quattro metriche (scale diverse -> stesso peso)
X <- scale(kw[, c("volume","cpc","posizione","n_parole")])

# metodo del gomito: WCSS per k da 1 a 6
set.seed(1)
wss <- sapply(1:6, function(k) kmeans(X, centers = k, nstart = 10)$tot.withinss)
round(wss, 1)
# [1] 56.0 34.4 20.7 12.4  8.7  6.9

Il calo è ripido fino a tre gruppi (56 → 34 → 21) e poi rallenta nettamente (21 → 12 → 9 → 7). Il gomito non è mai una linea netta — è una lettura, non un teorema — ma qui indica con ragionevolezza k = 3. Lancio allora il K-means con tre centroidi:

set.seed(1)
km <- kmeans(X, centers = 3, nstart = 25)
kw$cluster <- km$cluster
table(km$cluster)
# 1 2 3
# 4 7 4

n.b. l’argomento nstart = 25 fa ripartire l’algoritmo 25 volte da centroidi iniziali diversi, tenendo la soluzione migliore: il K-means può infatti incagliarsi in un minimo locale a seconda di dove parte, e ripartire più volte è la difesa standard. Il set.seed(1) serve solo a rendere l’esempio riproducibile (compresa la numerazione dei cluster, che di per sé è arbitraria).

Leggere i cluster: chi sono questi gruppi?

Avere tre gruppi non serve a niente finché non capiamo cosa rappresentano. Il modo più diretto è guardare le metriche medie di ciascun cluster.
Le calcolo sulla scala originale (non quella standardizzata, che è illeggibile):

aggregate(kw[, c("volume","cpc","posizione","n_parole")],
          by = list(cluster = kw$cluster), FUN = mean)
#   cluster volume  cpc posizione n_parole
# 1       1   1775 0.18     11.35     4.75
# 2       2  13300 0.37      4.49     2.57
# 3       3   1850 0.95      6.50     3.50

Adesso i gruppi parlano.
Il cluster 2 raccoglie le query a volume altissimo (in media 13.300 ricerche), corte (due-tre parole), ben posizionate e con cpc modesto: sono le teste generiche e di marca — “scarpe running”, “nike pegasus”, “asics gel nimbus”. Il cluster 1 ha volumi bassi, query lunghe (quasi cinque parole), posizioni arretrate e cpc minimo: è il long-tail informazionale — “come scegliere scarpe running”, “differenza scarpe trail e strada”, “recensione scarpe trail”. Il cluster 3 si distingue per un cpc altissimo (0,95 €) e contiene le query a chiaro taglio commerciale — “scarpe running offerta”, “comprare scarpe trail online”, “scarpe running scontate”, “negozio scarpe running milano”.

Vale la pena fermarsi un istante su cosa è appena successo. Senza dare all’algoritmo alcuna etichetta, i tre gruppi che emergono ricalcano da vicino una distinzione per intento — ricerca informativa, teste generiche e di marca, query commerciali — vicina a quella che con il Naive Bayes avevamo invece dovuto insegnargli a colpi di esempi.
L’allineamento, attenzione, non è magia: emerge perché le metriche che abbiamo scelto (cpc, lunghezza, posizione) tracciano indirettamente l’intento, non perché il clustering lo conosca — di significato delle query, qui, non ne ha vista neppure una parola. La lettura resta comunque immediatamente operativa: il cluster informativo chiede articoli e guide, quello commerciale pagine prodotto e di offerta, quello ad alto volume pagine pilastro robuste.

Clustering gerarchico: il dendrogramma

Il K-means ci ha costretti a scegliere k in anticipo. Il clustering gerarchico ribalta l’approccio: non decide nulla a priori, e costruisce invece un albero completo di raggruppamenti. Parte da ogni keyword come gruppo a sé, poi fonde via via le due più vicine, poi le due più vicine fra quelle rimaste, e così via fino a un unico grande gruppo. Il risultato è un dendrogramma: un albero che mostra a quale “altezza” (cioè a quale distanza) ogni fusione avviene.

Lo costruisco in R calcolando prima la matrice delle distanze, poi l’albero:

d  <- dist(X)                       # distanze euclidee fra le keyword standardizzate
hc <- hclust(d, method = "ward.D2") # albero gerarchico (criterio di Ward)
plot(hc, labels = kw$keyword)       # il dendrogramma

Il bello del dendrogramma è che la decisione su quanti gruppi tenere la prendiamo dopo averlo visto, semplicemente “tagliandolo” a un’altezza scelta: un taglio basso lascia molti gruppetti, un taglio alto pochi gruppi grandi. Taglio a tre gruppi e confronto con il K-means:

kw$cluster_hc <- cutree(hc, k = 3)
table(kw$cluster_hc)
# 1 2 3
# 8 3 4

La partizione non è identica a quella del K-means (qui i gruppi sono da 8, 3 e 4 keyword), ed è normale: i due metodi ottimizzano criteri diversi e su pochi dati le differenze si notano.
Ma la sostanza dei raggruppamenti — il blocco transazionale ad alto cpc, le teste ad alto volume, la coda informazionale — resta riconoscibile in entrambi. Quando due metodi diversi convergono sulla stessa storia, possiamo fidarci un po’ di più di quella storia.

Quale metodo, e le trappole

La scelta fra i due, nella pratica, segue poche regole semplici. Il K-means è veloce ed efficiente anche su decine di migliaia di keyword, ma vuole che gli si dica k e tende a costruire gruppi di forma “sferica” e di dimensioni simili. Il gerarchico non chiede k in anticipo e regala il dendrogramma — prezioso per vedere come i gruppi si annidano l’uno nell’altro — ma diventa pesante quando le keyword sono troppe. La pratica più comune: esplorare in gerarchico su un campione per farsi un’idea del numero di gruppi, poi applicare il K-means all’intero set con il k così individuato.

Un avvertimento, il più importante di tutti: il clustering trova sempre dei gruppi, anche quando non ce ne sono. Diamogli del rumore puro e ce lo dividerà diligentemente in k cluster ordinati. Il numero di gruppi, le metriche scelte per descrivere le keyword, la standardizzazione: sono tutte decisioni nostre, e ognuna cambia il risultato. Un raggruppamento non è una verità scoperta nei dati, è un’ipotesi di lavoro che ha senso solo se regge alla prova del buon senso di business. Se un cluster non riusciamo a spiegarlo a parole, probabilmente non esiste davvero.

C’è poi una questione di dimensioni. Qui abbiamo usato quattro metriche, ma nella realtà operativa le variabili descrittive di una keyword possono essere molte di più, e con tante dimensioni le distanze perdono di significato (tutto tende a sembrare ugualmente lontano).
È esattamente il problema che l’analisi delle componenti principali sa alleggerire, comprimendo molte metriche in poche componenti prima di passare il testimone al clustering.

Prova tu

Il modo migliore per capire il clustering è vederlo cambiare risposta al variare delle scelte. Riprendendo il codice qui sopra:

1. Salta la standardizzazione: lancia il K-means direttamente su kw[, c("volume","cpc","posizione","n_parole")] senza scale(). I gruppi crollano tutti sul volume? È la dimostrazione pratica di perché si standardizza.
2. Cambia k: prova con quattro o cinque gruppi e rileggi le medie. Il cluster informazionale si spezza in sotto-temi sensati o stai solo tagliando il rumore?
3. Cambia il criterio di fusione del gerarchico: method = "complete" o "average" al posto di "ward.D2". Il dendrogramma cambia forma? E i gruppi tagliati a k=3?

Suggerimento: tieni sempre d’occhio le medie per cluster con aggregate(). È lì, e non nel codice, che si decide se un raggruppamento è utile o è solo una partizione elegante di niente.

Abbiamo raggruppato le keyword in base a come si comportano — volume, costo, posizione.
Ma resta fuori la cosa che per un SEO conta di più: il loro significato. Due query possono avere metriche diverse e voler dire la stessa cosa, oppure metriche simili e intenti opposti. Raggruppare per senso, e non solo per numeri, significa trasformare il testo stesso delle query in qualcosa di misurabile: è il mestiere del text mining, dove le parole diventano vettori e la similarità si calcola sul linguaggio. Ed è da lì che ripartiremo.

Per approfondire

Se vuoi approfondire il clustering — K-means, metodi gerarchici, la scelta del numero di gruppi e le insidie dell’interpretazione — An Introduction to Statistical Learning di James, Witten, Hastie e Tibshirani dedica all’apprendimento non supervisionato un capitolo limpido, con i laboratori in R che ricalcano esattamente i passi che abbiamo visto qui. È il riferimento che consiglio a chi vuole passare dall’esempio giocattolo al clustering su dati veri.

Abbiamo avuto modo di vedere, parlando di correlazione, che posizione e CTR si muovono insieme lungo una curva ripida; e che il passo successivo — usare una variabile per prevederne un’altra — è il mestiere della regressione lineare.
Qui i due fili si annodano: trasformiamo quella curva in un CTR atteso e misuriamo, pagina per pagina, di quanto ciascuna se ne discosta. È il modo per smettere di leggere i CTR come numeri assoluti e iniziare a leggerli per quello che sono davvero: scostamenti da una norma.

Di cosa parleremo:

• Perché un CTR, da solo, non significa niente
• Modellare la curva del CTR: tre strade
• Un esempio con dati di Search Console
• Le altre due strade: loess e nls al lavoro
• I residui: chi rende meno di quanto dovrebbe
• Leggere gli scostamenti senza farsi ingannare
• Prova tu
• Per approfondire

Perché un CTR, da solo, non significa niente

Esistono tabelle di settore che dicono quanto “dovrebbe” valere il CTR di ogni posizione: la prima intorno al 25-30%, la seconda sotto la metà, e così via a scendere. Sono utili come orizzonte generale, ma per giudicare le nostre pagine portano fuori strada: il CTR dipende dal tipo di query (un marchio cliccatissimo o una ricerca informativa fredda), dal settore, da quanto la SERP è affollata di annunci e rich snippet.
Il CTR medio di “posizione 3” su un benchmark americano di e-commerce non ha quasi nulla da dire al nostro blog tecnico in italiano.

La via d’uscita è smettere di confrontarci con una tabella esterna e costruirci la curva di riferimento sui nostri stessi dati.
Prendiamo tutte le pagine, le loro posizioni medie e i loro CTR, e tracciamo la curva che descrive l’andamento tipico del CTR al variare della posizione per come funziona il nostro sito. Quella curva diventa il metro: il CTR atteso di una pagina è il valore che la curva le assegna, data la sua posizione.
Lo scostamento fra il CTR reale e quel valore atteso è l’informazione che cercavamo.

Un CTR ha senso solo accanto alla posizione che l’ha prodotto: è lo scostamento dalla curva, non il numero assoluto, a dirci se una pagina sta lavorando bene o sta lasciando clic sul tavolo.

Modellare la curva del CTR: tre strade

Costruire la curva significa stimare una funzione che, data la posizione, restituisca il CTR atteso. La forma di quella curva la conosciamo già a occhio: parte alta, crolla a precipizio nelle prime posizioni e poi si appiattisce verso lo zero. Una retta non la descrive; serve qualcosa che curvi.

C’è però un dettaglio che cambia tutto il modo di ragionare, ed è il tipo di scostamento che ci interessa.
A noi non importa che una pagina prenda “due punti di CTR in meno” dell’atteso: in cima alla SERP due punti sono briciole, in fondo sono un raddoppio. Ci interessa lo scostamento moltiplicativo — “rende la metà di quanto dovrebbe”, “rende il doppio”.
E lo scostamento moltiplicativo si maneggia bene su scala logaritmica, dove un rapporto diventa una differenza.

La forma più naturale per una curva di questo tipo è la legge di potenza, cioè l’idea che il CTR sia proporzionale alla posizione elevata a un esponente negativo:

dove \( a \) fissa il livello generale e \( b \) (negativo) governa la rapidità della discesa. Il bello arriva prendendo il logaritmo di entrambi i lati, che trasforma quella curva in una retta:

In altri termini: il logaritmo del CTR è una funzione lineare del logaritmo della posizione. E stimare una retta è esattamente ciò che sappiamo fare con la regressione. Da qui, tre strade per costruire la curva.

La prima, e quella che consiglio come cavallo di battaglia, è una regressione lineare sui logaritmi — lm(log(ctr) ~ log(posizione)). È in R base, è interpretabile (la pendenza \( b \) è l’elasticità del CTR alla posizione: di quanto cala in percentuale il CTR a ogni punto percentuale di posizione in più), e i suoi residui sono già su scala logaritmica, quindi moltiplicativi, proprio come ci serve.
Si estrapola anche a posizioni poco osservate, e la si può pesare per le impression (weights = impression), così le pagine con due clic in croce non sbilanciano la curva quanto quelle con decine di migliaia di visualizzazioni. È una scelta pragmatica più che il peso teoricamente ottimo (per una proporzione la varianza dipende anche dal CTR stesso), ma nella pratica funziona benissimo.

La seconda è la regressione non lineare con nls, che stima direttamente \( a \) e \( b \) sulla scala naturale del CTR senza passare per i logaritmi. È un raffinamento elegante, ma va innescato con valori di partenza sensati (che si pescano proprio dalla regressione log-log) e su dati sporchi può non convergere. La tengo per quando serve un parametro pulito da mettere in un report, non come punto di partenza.

La terza è il lisciamento locale con loess, che non impone nessuna forma alla curva e la lascia “disegnare ai dati”. È perfetto per vedere l’andamento a colpo d’occhio, ma traballa sulle code (poche pagine in prima posizione) e soprattutto non estrapola: fuori dall’intervallo osservato non sa che dire. È uno strumento esplorativo, non il modello su cui costruire i giudizi.

Dunque: partiamo dalla regressione log-log pesata per le impression come modello di lavoro, la confrontiamo a occhio con un loess per controllare che non stiamo forzando una forma sbagliata, e passiamo a nls solo se ci serve l’esponente esplicito. Vediamola al lavoro.

Un esempio con dati di Search Console

Partiamo da un estratto come quello che chiunque può scaricare da Search Console: una riga per pagina, con le impression, i clic e la posizione media. Nella realtà il CTR è il rapporto fra clic e impression; qui, trattandosi di dati d’esempio, facciamo il percorso inverso — fissiamo un CTR plausibile e ricostruiamo i clic.
Costruisco la tabella in R con dodici pagine di esempio (con dentro, di proposito, un paio di casi anomali):

gsc <- data.frame(
  pagina     = c("/guida-seo-tecnica","/checklist-audit-seo",
                 "/guida-keyword-research","/calcolatore-roi-campagne",
                 "/tutorial-google-analytics","/glossario-statistica",
                 "/recensione-tool-seo","/guida-link-building",
                 "/analisi-dei-competitor","/modello-attribuzione",
                 "/report-posizionamento","/ottimizzazione-meta-tag"),
  impression = c(  9800, 5400, 12500, 2100, 7600, 1500,
                   8300, 4200,  6100,  900, 3300, 1800),
  posizione  = c(  1.3,  2.1,   3.4,  4.0,  4.6,  5.2,
                   2.8,  6.1,   7.0,  8.3,  9.1, 10.2)
)
# CTR osservato (in genere lo si calcola come click / impression)
gsc$ctr   <- c(0.232, 0.150, 0.034, 0.071, 0.066, 0.060,
               0.171, 0.048, 0.041, 0.012, 0.031, 0.028)
gsc$click <- round(gsc$impression * gsc$ctr)

Stimo ora la curva del CTR atteso con la regressione sui logaritmi, pesando ogni pagina per le sue impression:

fit <- lm(log(ctr) ~ log(posizione), data = gsc, weights = impression)
round(coef(fit), 3)
# (Intercept)  log(posizione)
#      -1.240          -1.088

La pendenza è −1,088: un valore vicino a −1 racconta una curva quasi inversamente proporzionale, in cui raddoppiare la posizione (passare, diciamo, dalla 3 alla 6) taglia il CTR all’incirca della metà.
È la stessa caduta ripida che avevamo intravisto misurando la correlazione, ora però scritta in una formula che possiamo interrogare: dato un numero di posizione, ci restituisce il CTR tipico che quella posizione comporta sul nostro sito.

Le altre due strade: loess e nls al lavoro

Abbiamo scelto la regressione log-log come modello di lavoro, ma le tre strade le avevamo promesse tutte. Vale la pena vederle davvero all’opera sugli stessi dodici dati, per capire cosa aggiungono le altre due — e soprattutto dove inciampano.

La regressione non lineare stima \( a \) e \( b \) direttamente sulla scala del CTR, senza passare per i logaritmi. Va innescata con valori di partenza sensati, che peschiamo proprio dalla log-log appena stimata: l’intercetta riportata in scala naturale con l’exp è la nostra \( a \), la pendenza è la nostra \( b \). La faccio partire in R:

start <- list(a = exp(coef(fit)[1]), b = coef(fit)[2])  # innesco dalla log-log
fit_nls <- nls(ctr ~ a * posizione^b, data = gsc,
               weights = impression, start = start)
round(coef(fit_nls), 3)
#      a       b
#  0.315  -1.073

Converge, e restituisce un esponente −1,073, praticamente lo stesso della log-log, ma con un regalo in più: ora \( a \) e \( b \) sono numeri leggibili sulla scala vera del CTR. Un \( a \) di 0,315 dice, in soldoni, che in cima alla SERP il CTR tipico è attorno al 31% — esattamente il genere di parametro pulito da mettere in un report.
Il prezzo lo paghiamo in fragilità: senza quei valori di partenza, o su dati più rumorosi, nls può non convergere affatto e restituirci soltanto un errore.

Il lisciamento locale con loess fa l’opposto: non impone nessuna forma, lascia disegnare la curva ai dati. Lo stimo e gli chiedo il CTR atteso a qualche posizione, inclusa la prima:

fit_lo <- loess(ctr ~ posizione, data = gsc, span = 0.9)
round(predict(fit_lo, data.frame(posizione = c(1, 2, 3, 5))), 3)
# [1]    NA 0.173 0.111 0.029

Ed ecco il limite in un solo output: alla posizione 1, loess restituisce NA. Il minimo che i nostri dati osservano è 1,3, e fuori da quell’intervallo loess si rifiuta di pronunciarsi — non estrapola.
Per una curva di CTR è un difetto serio: la prima posizione, quella che ci interessa di più, è spesso la meno popolata, ed è proprio lì che il metodo locale ci lascia a bocca asciutta.

Messe sullo stesso grafico, le tre strade raccontano tutto in un colpo d’occhio:

Al centro, dove le pagine abbondano, le tre curve quasi coincidono: qualunque metodo va bene quando i dati parlano chiaro. È sulle code che si separano — loess ondeggia dietro le poche pagine che trova e si ferma di netto al bordo dei dati, mentre lm e nls proseguono lisce anche dove le osservazioni scarseggiano.

Dunque: la log-log pesata resta il cavallo di battaglia — interpretabile, estrapolabile, con i residui già in scala moltiplicativa. nls la raffina quando serve un esponente pulito da mettere nero su bianco; loess è l’occhio critico che, prima di fidarci, ci dice se stiamo forzando la forma sbagliata. Tre strumenti diversi per un solo mestiere: trasformare la posizione in un CTR atteso.

I residui: chi rende meno di quanto dovrebbe

Avere la curva significa poter calcolare, per ogni pagina, il suo CTR atteso e confrontarlo con quello reale. Il confronto, lo abbiamo detto, va fatto in termini di rapporto e non di differenza: rapporto = ctr_reale / ctr_atteso. Un valore intorno a 1 dice che la pagina rende quanto previsto; molto sotto 1 che lascia clic sul tavolo; molto sopra 1 che cattura più della sua quota.
Calcolo il CTR atteso, il rapporto e segnalo i casi che si discostano davvero — ma solo se hanno abbastanza impression da rendere il loro CTR affidabile:

gsc$ctr_atteso <- exp(predict(fit))           # torno dalla scala log a quella naturale
gsc$rapporto   <- gsc$ctr / gsc$ctr_atteso

gsc$flag <- ifelse(gsc$rapporto < 0.6 & gsc$impression >= 1000, "SOTTO",
             ifelse(gsc$rapporto > 1.4 & gsc$impression >= 1000, "SOPRA", "ok"))

gsc[order(gsc$rapporto),
    c("pagina","posizione","impression","ctr","ctr_atteso","rapporto","flag")]

n.b. il predict ci dà il logaritmo del CTR atteso, perché è su quella scala che abbiamo stimato il modello: l’exp lo riporta in CTR vero e proprio. A rigore l’exp ci restituisce la mediana del CTR atteso, non la media aritmetica (sotto errori log-normali la media vera è un filo più alta), ma per i rapporti relativi che ci interessano la distinzione è ininfluente.
L’output, ordinato dal rapporto più basso al più alto:

Il caso che salta all’occhio è /guida-keyword-research: sta in terza posizione, dove la curva si aspetterebbe un CTR del 7,6%, e invece raccoglie un misero 3,4% — meno della metà del dovuto, su dodicimila e cinquecento impression che rendono il dato solidissimo.
È un’ipotesi forte e immediatamente azionabile: con ogni probabilità il title e la meta description non stanno facendo il loro lavoro, e una riscrittura potrebbe sbloccare clic che la posizione avrebbe già meritato.

All’estremo opposto c’è /recensione-tool-seo, che in seconda-terza posizione rende quasi il doppio dell’atteso. Non è un problema, è una lezione: qualcosa in quello snippet funziona benissimo — un titolo magnetico, una rich card, una corrispondenza perfetta con l’intento — e vale la pena capire cosa, per provare a replicarlo altrove. I residui non servono solo a trovare i malati: le sovra-performance sono i casi di studio da cui imparare cosa, sul nostro sito, fa cliccare.

Leggere gli scostamenti senza farsi ingannare

C’è un dettaglio nella tabella che è il cuore di tutto il discorso, e che è facile mancare. /modello-attribuzione ha un rapporto di 0,41 — più basso ancora di /guida-keyword-research — eppure non l’abbiamo segnalato. Il motivo è nella colonna delle impression: novecento. Un CTR calcolato su così pochi dati è quasi solo rumore, e il mese prossimo rientrerà verso la sua media a prescindere da qualunque cosa facciamo.
Segnalarlo come “pagina da ottimizzare” ci farebbe inseguire un fantasma. Due pagine con lo stesso scostamento, due verdetti opposti, e a fare la differenza è solo la quantità di dati che li sostiene.

Un avvertimento: il CTR atteso è un valore tipico condizionato — la mediana che la curva associa a una posizione — non una legge di natura. Una pagina può “sotto-performare” per ragioni che con il title non c’entrano nulla: una query di marca che gonfia il CTR dei concorrenti, un featured snippet o un blocco di annunci che si mangia i clic prima del primo risultato organico, un intento puramente informativo che si soddisfa già leggendo lo snippet. E un CTR costruito su poche impression non misura quasi niente: regredirà verso la sua media da solo, come abbiamo visto parlando di regressione verso la media. Un residuo negativo è un’ipotesi da verificare — “forse qui il title rende poco” — non un verdetto da eseguire.

Vale anche la pena ricordare che la curva la abbiamo stimata sui nostri dati, e quei dati la influenzano: una manciata di pagine molto anomale può inclinarla quel tanto che basta a spostare i giudizi sulle altre.
Lo si vede già nella nostra tabella: dieci pagine su dodici hanno un rapporto sopra l’1, ma non è che il sito “sovra-performi” quasi ovunque. È che l’unico grosso scostamento negativo, /guida-keyword-research, pesa moltissimo (dodicimila e cinquecento impression) e tira la curva verso il basso, alzando di riflesso il rapporto di tutte le altre. Il “centro” della nuvola, insomma, non è esattamente 1, e conviene leggere i rapporti in termini relativi — chi sta molto sotto e chi molto sopra il grosso del gruppo — più che rispetto alla soglia secca dell’uno.
Per questo il peso delle impression è prezioso, e per questo conviene rifare la curva ogni volta che il quadro cambia, invece di trattarla come una costante incisa nella pietra.

Prova tu

Il modo migliore per fissare il meccanismo è metterci le mani. Riprendendo il codice qui sopra, ci sono tre direzioni interessanti da esplorare:

1. Aggrega per query invece che per pagina: la stessa pagina può comparire su decine di ricerche con posizioni e CTR diversi, e spesso è lì — sulla singola query — che si nasconde l’occasione persa. La curva e i residui si costruiscono allo stesso identico modo.
2. Togli il peso delle impression — lm(log(ctr) ~ log(posizione)) senza weights — e confronta esponente e verdetti con la versione pesata: quanto sposta le conclusioni l’aver dato più voce alle pagine con più dati? È il modo per sentire quanto conta la pesatura, invece di prenderla sulla fiducia.
3. Cambia la soglia di impression sotto cui non ti fidi del CTR: passando da 1000 a 3000, quali pagine escono dal radar? Il numero giusto non esiste in astratto, dipende da quanto traffico muove il tuo sito.

Suggerimento: la struttura non cambia mai — si stima la curva, si predice l’atteso, si guarda il rapporto. È giocando con la soglia e con il livello di aggregazione che si capisce quanto di ciò che chiamiamo “pagina sotto-performante” sia segnale e quanto, semplicemente, rumore.

Individuare una pagina che rende meno del previsto per la sua posizione è cugino stretto di un altro problema che ogni analista conosce: individuare un giorno che rende meno del previsto nel tempo, un crollo o un picco nel traffico che non torna con l’andamento abituale. È lo stesso ragionamento sui residui — valore osservato contro valore atteso — spostato dallo spazio delle posizioni all’asse del tempo, dove l’atteso lo fornisce l’andamento storico della serie. È esattamente il mestiere dell’anomaly detection: distinguere il segnale dal rumore quando i numeri si muovono nel tempo — il passo naturale da cui proseguire.

Per approfondire

Se vuoi approfondire la regressione, le trasformazioni logaritmiche e la lettura dei residui — l’ossatura esatta del modello che abbiamo costruito qui — Introduzione all’econometria di Stock e Watson è il riferimento che consiglio: spiega con cura sia il “perché” dei logaritmi sia il “come” si interpretano i coefficienti, partendo sempre da problemi applicati. A chi volesse spingersi oltre la legge di potenza, verso i metodi locali come il loess, An Introduction to Statistical Learning di James, Witten, Hastie e Tibshirani offre i capitoli giusti, con i laboratori in R sotto mano.

Il problema è che le query sono tante e sempre nuove, e classificarle a mano non scala. Ci serve un metodo che impari da un po’ di esempi etichettati e poi se la cavi da solo sulle query mai viste. L’algoritmo che fa questo con un’eleganza quasi disarmante è il Naive Bayes, e — come il nome lascia intuire — parte ancora una volta dal teorema di Bayes che ci accompagna da tutto questo percorso.

Di cosa parleremo:

• Dal teorema al classificatore
• Addestrare su query etichettate
• Classificare le query nuove
• I limiti del “naive”
• Prova tu
• Per approfondire

Dal teorema al classificatore

Riprendiamo il filo. Il teorema di Bayes ci dice come aggiornare la probabilità di un’ipotesi alla luce dei dati osservati. Qui l’ipotesi è “questa query appartiene alla classe informazionale” (oppure transazionale), e i dati sono le parole che compongono la query. Vogliamo cioè la probabilità di una classe dato il testo: in simboli, P(classe | parole).

Calcolarla direttamente sarebbe un incubo, perché le combinazioni di parole possibili sono sterminate. Bayes ci permette di girare il problema: invece di chiederci quanto è probabile la classe viste le parole, ci chiediamo quanto sono probabili quelle parole vista la classe — una domanda a cui i dati di addestramento sanno rispondere. La regola, prima a parole e poi in formula, è che la probabilità di una classe data una query è proporzionale alla probabilità a priori della classe moltiplicata per la probabilità di osservare quelle parole se la classe fosse quella:

Sciogliamo i simboli. P(classe) è il prior: quanto è frequente quella classe in partenza, prima di guardare il testo (se metà delle query d’esempio sono informazionali, il prior è 0,5). P(parola | classe) è quanto spesso quella parola compare nelle query di quella classe. Il simbolo ∏ è semplicemente il prodotto: moltiplichiamo i contributi di tutte le parole della query. Il segno ∝ (“proporzionale a”) ci ricorda che stiamo trascurando un denominatore costante, identico per tutte le classi: visto che alla fine ci interessa solo quale classe vince, possiamo ignorarlo senza danni.

Ed eccolo, il punto in cui si annida il “naive”. Moltiplicare le probabilità delle singole parole come se fossero indipendenti l’una dall’altra equivale ad assumere che, nota la classe, la presenza di una parola non dica nulla sulla presenza delle altre. È un’assunzione palesemente falsa nel linguaggio reale — “carta” e “credito” non compaiono certo a caso una indipendentemente dall’altra — ed è proprio questa ingenuità (in inglese naive) a dare il nome all’algoritmo. La cosa sorprendente, che vedremo, è che pur partendo da un’ipotesi così grossolana il metodo funziona benissimo nella pratica.

Addestrare su query etichettate

Addestrare un Naive Bayes vuol dire una cosa sola: contare. Per ogni classe contiamo quante volte compare ciascuna parola nelle query di esempio, e da quei conteggi ricaviamo le P(parola | classe). Niente ottimizzazione, niente iterazioni: si scorrono i dati una volta e si riempie una tabella di frequenze.

Partiamo da un piccolo insieme di query etichettate a mano, cinque informazionali e cinque transazionali. Addestro il classificatore in R così:

train <- list(
  info  = c("come fare un dolce", "cos e la statistica", "guida seo principianti",
            "tutorial r gratis", "come funziona il bayesiano"),
  trans = c("comprare scarpe online", "prezzo iphone offerta", "miglior hosting economico",
            "acquista corso seo", "sconto abbonamento palestra")
)
tok <- function(s) unlist(strsplit(tolower(s), "\\s+"))
vocab <- unique(unlist(lapply(unlist(train), tok)))
counts <- lapply(train, function(docs) {
  w <- table(factor(unlist(lapply(docs, tok)), levels = vocab)); w + 1
})
tots <- sapply(counts, sum); V <- length(vocab)
prior <- sapply(train, length) / length(unlist(train))   # 0.5 / 0.5

Vediamo cosa succede riga per riga. La funzione tok spezza ogni query in parole minuscole (una tokenizzazione spartana ma sufficiente). vocab è il vocabolario, l’elenco di tutte le parole distinte viste in addestramento: qui sono 31. Per ogni classe, table(factor(...)) conta le occorrenze di ciascuna parola del vocabolario; tots è il totale dei conteggi per classe, e prior qui vale 0,5 e 0,5 perché le due classi hanno lo stesso numero di esempi.

C’è un dettaglio in quel w + 1 che merita una sosta, perché è il trucco che tiene in piedi tutto l’edificio. Se una parola non compare mai nelle query di una classe, il suo conteggio è zero, e con esso si azzererebbe l’intero prodotto delle probabilità: una sola parola sconosciuta basterebbe a mandare a zero la probabilità della classe, cancellando il contributo di tutte le altre. È il classico caso in cui “moltiplicare per zero” rovina la festa. La soluzione si chiama smoothing di Laplace: aggiungiamo 1 al conteggio di ogni parola, in ogni classe, prima di calcolare le proporzioni. Nessuna parola ha più probabilità esattamente nulla, solo molto piccola.

Il prezzo dello smoothing è che ai totali per classe va aggiunto il numero di parole del vocabolario (le 31 unità aggiunte una per parola): per questo tots non vale 18 e 15 — i token grezzi delle due classi — ma 49 e 46. Con questi numeri, per esempio, la parola “comprare” (presente una volta fra le transazionali, mai fra le informazionali) ha P(comprare | trans) = 2/46 ≈ 0,043 contro P(comprare | info) = 1/49 ≈ 0,020: più del doppio, ed è proprio questo squilibrio che spinge una query verso l’intento giusto. Una parola neutra come “seo”, che compare una volta per parte, resta invece quasi bilanciata fra le due classi e non sposta l’ago.

Classificare le query nuove

Con la tabella delle frequenze pronta, classificare una query nuova è davvero un giochetto da ragazzi: si tokenizza, si sommano i logaritmi delle probabilità di ciascuna parola (sommare logaritmi anziché moltiplicare probabilità evita che il prodotto di tanti numeri piccolissimi vada in underflow numerico, ma il risultato è lo stesso), si aggiunge il logaritmo del prior e si sceglie la classe con il punteggio più alto. Calcolo in R:

classify <- function(query) {
  w <- tok(query)
  logp <- log(prior)
  for (cl in names(train)) {
    p <- counts[[cl]][w]; p[is.na(p)] <- 1            # parola fuori vocab: peso neutro
    logp[cl] <- logp[cl] + sum(log(as.numeric(p) / tots[cl]))
  }
  names(which.max(logp))
}
cat("'comprare corso seo sconto' ->", classify("comprare corso seo sconto"), "\n")
cat("'come imparare la statistica'  ->", classify("come imparare la statistica"), "\n")

L’output è netto:

'comprare corso seo sconto' -> trans
'come imparare la statistica'  -> info

Come si vede, il classificatore assegna la prima query all’intento transazionale e la seconda all’informazionale, esattamente come avrebbe fatto un essere umano. Vale la pena notare come ci arriva. Nella prima query “comprare” e “sconto” tirano con decisione verso trans, “seo” resta neutra, e nemmeno “corso” — che in addestramento compariva nel transazionale “acquista corso seo” — rema contro: il verdetto è solido. Nella seconda, “statistica” è una parola spiccatamente informazionale, e “imparare”, pur essendo fuori vocabolario, non fa danni grazie a quel p[is.na(p)] <- 1 che assegna alle parole mai viste un peso neutro, identico per entrambe le classi: non potendo dire nulla, semplicemente non vota.

Cinque query d’esempio per parte sono pochissime, eppure il meccanismo è già tutto qui. In un caso reale basta sostituire le manciate di query etichettate con qualche centinaio o migliaio di query estratte dalla Search Console e annotate per intento, e lo stesso codice — invariato nella struttura — diventa un classificatore di intento utilizzabile sul serio.

I limiti del “naive”

Prima di lanciarsi, però, è bene sapere dove il metodo mostra la corda, perché la sua semplicità ha un rovescio.

Il limite più evidente è proprio l’assunzione di indipendenza da cui prende il nome. Trattando ogni parola come slegata dalle altre, il Naive Bayes ignora del tutto l’ordine e il contesto: per lui “scarpe da corsa economiche” e “economia delle scarpe da corsa” sono lo stesso sacchetto di parole (bag of words, come dicono gli anglosassoni). Nella classificazione d’intento questo conta poco, ma in compiti più sottili può ingannare. C’è poi la questione delle parole fuori vocabolario: una query fatta solo di termini mai visti in addestramento finirebbe decisa dal solo prior, cioè da un puro testa o croce — il segnale che il dataset di esempi è troppo magro e va ampliato.

Un avvertimento che vale per qualunque classificatore, e a maggior ragione per uno addestrato su pochi dati: il modello impara esattamente ciò che gli mostriamo, bias compresi. Se le query d’esempio transazionali contengono tutte la parola “comprare”, il classificatore assocerà l’intento d’acquisto a quel termine e arrancherà su un “aggiungi al carrello” altrettanto transazionale ma lessicalmente diverso. La qualità e la rappresentatività dei dati etichettati contano più della raffinatezza dell’algoritmo: un Naive Bayes nutrito di esempi vari e bilanciati batte un modello sofisticato addestrato male.

Detto questo, il Naive Bayes resta un preziosissimo strumento da avere nella cassetta degli attrezzi: è velocissimo da addestrare, richiede pochi dati per partire, è interpretabile (possiamo sempre andare a vedere quali parole hanno spinto la decisione) e nella classificazione di testo regge il confronto con modelli ben più complessi. È spesso la baseline da battere prima di tirare in ballo artiglieria più pesante — ed è qui che si apre la porta sul machine learning vero e proprio, dove la classificazione si fa con alberi, regressioni e reti che lasciano cadere l’ipotesi di indipendenza in cambio di più potenza (e meno trasparenza).

Prova tu

Il codice qui sopra è un terreno di gioco perfetto per costruire l’intuizione. Le query di ricerca non sono solo informazionali o transazionali: ne manca almeno una terza famiglia, quella navigazionale (chi cerca “facebook login” o “gironi blog” vuole solo arrivare a un sito preciso). Ecco qualche modifica da provare:

1. Aggiungi una classe nav al train con quattro o cinque query navigazionali (“facebook login”, “youtube”, “amazon accedi”, “gmail posta”), poi riaddestra: il prior non sarà più 0,5 ma circa un terzo per classe. Come cambiano le classificazioni delle query precedenti?
2. Dài in pasto al classificatore una query ambigua come “recensione iphone” (informativa? transazionale?) e guarda da che parte pende. Aveva senso il verdetto, viste le parole in addestramento?
3. Togli lo smoothing (sostituisci w + 1 con w) e prova a classificare una query con una parola rara: cosa succede al punteggio quando un conteggio è zero? È il modo più rapido per vedere con i propri occhi perché Laplace serve.

Il bello è che la struttura del codice non cambia: aggiungere una classe vuol dire solo allungare la lista train, e tutto il resto — vocabolario, conteggi, prior, regola di classificazione — si adatta da sé.

Con questo chiudiamo il filo bayesiano che abbiamo dipanato di articolo in articolo: dalla stima di un conversion rate al confronto fra varianti, dall’allocazione adattiva del traffico fino a quest’ultimo salto, dal decidere al classificare. Lo stesso teorema, riproposto ogni volta in una veste diversa, si è rivelato un filo conduttore sorprendentemente robusto. Da qui in avanti la strada si biforca verso il machine learning in senso pieno — gli alberi decisionali, la regressione logistica, le reti — dove i metodi rinunciano alle ipotesi più comode in cambio di potenza, e dove Bayes resta sullo sfondo come la grammatica con cui, in fondo, si impara sempre dai dati.

Per approfondire

Se vuoi passare dal Naive Bayes al machine learning vero e proprio restando con i piedi per terra (e con R sotto mano), An Introduction to Statistical Learning di James, Witten, Hastie e Tibshirani è il testo che consiglio. È la porta d’ingresso più accessibile al machine learning applicato: spiega classificazione, alberi e regressione con il rigore giusto ma senza matematica intimidatoria, e ogni capitolo ha laboratori in R che si possono rifare passo passo. La seconda edizione dedica spazio proprio al Naive Bayes, così il salto da questo articolo al resto del percorso è naturale.

Questo articolo fa parte del percorso «L’approccio bayesiano», la guida ragionata agli articoli su statistica e inferenza bayesiana applicate alla SEO.

C’è un modo per ridurre questo conto, e si chiama multi-armed bandit. L’idea è spostare il traffico in modo adattivo verso la variante che sta vincendo mentre il test è ancora in corso, invece di aspettare il verdetto finale. In questo articolo lo costruiamo con uno degli algoritmi più eleganti e pratici, il Thompson sampling, che è la naturale prosecuzione del ragionamento bayesiano che abbiamo seguito finora.

Di cosa parleremo:

• Il dilemma fra esplorazione e sfruttamento
• Thompson sampling: lasciar decidere il posterior
• Quanto si guadagna davvero: il regret evitato
• Quando un bandit ha senso, e quando no
• Prova tu
• Per approfondire

Esplorazione contro sfruttamento

Il nome viene dalle slot machine: un bandito a un braccio solo (one-armed bandit) è la macchinetta del casinò, e immaginiamo di averne davanti diverse, ciascuna con una probabilità di vincita sconosciuta e diversa dalle altre. Abbiamo un numero limitato di gettoni. A ogni giocata dobbiamo scegliere quale braccio tirare. Qual è la strategia che massimizza la vincita totale?

La traduzione per chi fa SEO o marketing è immediata: i bracci sono le varianti (tre versioni di un title tag, di una call to action, di una landing page), i gettoni sono i visitatori, la vincita è la conversione. Ogni visitatore va assegnato a una variante, e vogliamo massimizzare le conversioni totali lungo tutto l’esperimento.

Qui nasce la tensione di fondo, quella che rende il problema interessante. Da un lato vorremmo sfruttare (exploit) la variante che finora sembra la migliore, per incassare più conversioni possibili. Dall’altro dobbiamo continuare a esplorare (explore) anche le altre, perché “finora sembra la migliore” si basa su pochi dati e potrebbe essere un’impressione sbagliata.
È un equilibrio delicato: troppa esplorazione e sprechiamo traffico su varianti mediocri; troppo sfruttamento e rischiamo di incoronare un vincitore sbagliato sulla base di un colpo di fortuna iniziale. Il dilemma esplorazione-sfruttamento è il cuore di ogni problema di multi-armed bandit: ogni scelta è insieme un’occasione di guadagno e un’occasione di apprendimento, e le due cose tirano in direzioni opposte.

Thompson sampling: lasciar decidere il posterior

L’A/B test classico risolve il dilemma nel modo più rozzo possibile: esplora e basta, in parti uguali, fino alla fine. Metà traffico ad A, metà a B, nessun adattamento. Thompson sampling lo risolve in modo molto più astuto, e quasi sorprendente per quanto è semplice.

Riprendiamo il filo bayesiano. Per ogni variante manteniamo un posterior sul suo tasso di conversione: come abbiamo visto stimando il conversion rate, partendo da un prior Beta e osservando esiti binari (conversione sì/no), il posterior di ogni braccio è ancora una distribuzione Beta, che si aggiorna a ogni visitatore. All’inizio, quando non sappiamo nulla, ogni braccio parte da un prior non informativo Beta(1, 1).

La regola di Thompson, a parole prima che in formule, è questa: invece di chiederci “qual è la variante con la media più alta finora?”, a ogni visitatore campioniamo un tasso a caso dal posterior di ciascun braccio, e giochiamo il braccio che ha prodotto il campione più alto. È un modo di scegliere “in proporzione alla probabilità di essere il migliore”: una variante di cui siamo molto incerti può ancora vincere l’estrazione ogni tanto (ed è così che continua a essere esplorata), ma man mano che i dati si accumulano i suoi campioni si concentrano e, se è davvero peggiore, smette di essere scelta quasi da sola.

L’eleganza sta proprio qui: non c’è un parametro di esplorazione da regolare a mano. L’incertezza del posterior è il motore dell’esplorazione. Più un braccio è incerto, più i suoi campioni sono dispersi, più spesso capita che vinca l’estrazione e venga provato; più diventa certo, più i campioni si stringono attorno al valore vero e il braccio viene giocato (o evitato) con decisione.

Simulo in R l’intero processo su tre varianti con tassi reali del 5%, 7% e 9% (che ovviamente l’algoritmo non conosce), su 5000 visitatori:

set.seed(7)
true_rates <- c(0.05, 0.07, 0.09)   # 3 varianti, la terza e' la migliore
K <- length(true_rates); N <- 5000
alpha <- rep(1, K); beta_ <- rep(1, K)   # prior Beta(1,1) per braccio
pulls <- rep(0, K); rewards <- rep(0, K)
for (t in 1:N) {
  theta <- rbeta(K, alpha, beta_)        # campiona un tasso per braccio
  arm <- which.max(theta)                 # gioca il braccio campionato migliore
  r <- rbinom(1, 1, true_rates[arm])      # esito (conv si/no)
  alpha[arm] <- alpha[arm] + r; beta_[arm] <- beta_[arm] + (1 - r)
  pulls[arm] <- pulls[arm] + 1; rewards[arm] <- rewards[arm] + r
}

Il ciclo è tutto qui. A ogni iterazione campioniamo un theta per braccio (rbeta), scegliamo il massimo (which.max), simuliamo l’esito (rbinom) e aggiorniamo i parametri del braccio giocato: una conversione aumenta di uno il suo alpha, una mancata conversione il suo beta_. Nessun’altra logica, nessuna soglia da tarare.

Quanto si guadagna: il regret evitato

Vediamo dove ci ha portato la simulazione. La prima cosa da guardare è come si sono distribuiti i 5000 visitatori fra i tre bracci:

cat("pull per braccio:", pulls, "\n")
cat("conv totali bandit:", sum(rewards), "\n")

Output: pull per braccio = 359, 278, 4363; conv totali bandit = 424.

Dei 5000 visitatori, ben 4363 sono finiti sulla variante migliore, e solo poco più di 600 in totale sulle due peggiori. L’algoritmo, senza che gli avessimo detto nulla sui tassi veri, ha capito da solo quale braccio premiare e ci ha dirottato la stragrande maggioranza del traffico. È esattamente lo sfruttamento che volevamo, raggiunto attraverso un’esplorazione iniziale appena sufficiente a distinguere i bracci.

Ora il confronto che dà la misura del vantaggio. Un A/B test classico avrebbe diviso i 5000 visitatori in parti uguali fra le tre varianti, circa 1667 ciascuna, per tutta la durata. Le conversioni attese in quello scenario sono semplicemente la media dei tre tassi moltiplicata per il numero di visitatori:

exp_ab <- sum(true_rates) / K * N
cat("conv attese A/B equipartito:", round(exp_ab), "\n")
cat("regret evitato (circa):", round(sum(rewards) - exp_ab), "conv\n")

Output: conv attese A/B equipartito = 350; regret evitato (circa) = 74 conv.

Un A/B equipartito si sarebbe portato a casa circa 350 conversioni; il bandit ne ha raccolte 424. La differenza, circa 74 conversioni in più sullo stesso identico traffico, è ciò che in gergo si chiama regret evitato: il rimpianto, cioè le conversioni perse per aver giocato i bracci sbagliati, che l’allocazione adattiva ci ha risparmiato. In termini più chiari e diretti, a parità di visitatori il bandit ha convertito oltre il 20% in più, semplicemente non insistendo sulle varianti deboli.
Si noti che non abbiamo dovuto sacrificare nulla per ottenerlo: alla fine dell’esperimento conosciamo comunque il vincitore (anzi, lo conosciamo con grande sicurezza, visti i 4363 dati raccolti su di esso), e nel frattempo abbiamo convertito di più. È il vantaggio strutturale del bandit sul test a campione fisso.

Quando ha senso (e quando no)

Detto questo, un bandit non è la risposta giusta a ogni domanda, ed è importante capire dove brilla e dove invece un A/B test tradizionale resta preferibile.

Il bandit dà il meglio di sé quando il traffico è continuo e di lungo corso (una pagina sempre attiva, una campagna che gira per mesi) e quando le varianti da confrontare sono molte: lì l’allocazione adattiva ripaga, perché c’è tempo e volume per spostare il traffico e tante varianti deboli da abbandonare in fretta. È ideale per ottimizzazioni continue in cui l’obiettivo è massimizzare le conversioni lungo tutto il percorso, non scattare una fotografia statistica pulita in un dato momento.

Quando invece l’obiettivo è proprio quella fotografia — una stima precisa e imparziale di quanto una variante è migliore, magari da difendere davanti a un cliente o da usare per una decisione strategica — il test a campione fisso resta più adatto: proprio perché esplora in parti uguali, raccoglie dati bilanciati su tutte le varianti e produce stime più nette dell’effetto. Il bandit, concentrandosi presto sul vincitore, raccoglie pochi dati sui perdenti e quindi stima peggio di quanto siano peggiori.

Un avvertimento: il bandit dà per scontato che i tassi di conversione restino stabili nel tempo. Ma il mondo reale è spesso non stazionario — stagionalità, cambi di pubblico, una promozione che parte. Se la variante migliore cambia dopo che l’algoritmo si è già concentrato su un’altra, un Thompson sampling ingenuo come quello visto qui fatica ad accorgersene, perché ha smesso di esplorare le alternative. In contesti che cambiano servono varianti che “dimenticano” i dati vecchi (per esempio scontando gradualmente le osservazioni passate), altrimenti si rischia di restare ancorati a un vincitore che non lo è più.

Prova tu

La simulazione è un terreno di gioco perfetto per costruire l’intuizione. Riprendendo il codice qui sopra, prova a cambiare i numeri di partenza e osserva come si ridistribuiscono i pulls:

1. Avvicina i tassi veri, per esempio true_rates <- c(0.07, 0.08, 0.09): con varianti più simili, quanto più traffico serve prima che il braccio migliore si stacchi? La concentrazione dei pull resta così netta?
2. Riduci drasticamente il traffico (N <- 500): con pochi visitatori il bandit fa ancora in tempo a individuare il vincitore, o l’esplorazione si mangia tutto il budget?
3. Aggiungi varianti: passa a quattro o cinque bracci. Con più alternative da scartare, il vantaggio sul regret evitato rispetto all’A/B equipartito cresce o si assottiglia?

Suggerimento: la struttura del ciclo non cambia mai, basta modificare true_rates e N. È proprio osservando come il vettore pulls si sbilancia (o non si sbilancia) in funzione della distanza fra i tassi che si capisce davvero cosa fa, sotto il cofano, il Thompson sampling.

Finora abbiamo usato Bayes per decidere fra varianti: stimare un tasso, confrontarne due, allocare il traffico in modo adattivo. Ma lo stesso impianto — un prior, dei dati, un posterior — serve anche per un compito diverso e molto comune: classificare, cioè assegnare a ogni nuova osservazione l’etichetta più probabile date le sue caratteristiche. È il salto dal decidere al classificare, e l’algoritmo che lo fa con eleganza disarmante, ancora una volta partendo dal teorema di Bayes, è il Naive Bayes: l’argomento del prossimo articolo.

Per approfondire

Se vuoi approfondire i bandit applicati all’ottimizzazione dei siti web, Bandit Algorithms for Website Optimization di John Myles White è il libro che consiglio. È un volumetto agile e dichiaratamente pratico, che mette a confronto A/B test e algoritmi bandit (epsilon-greedy, softmax, UCB) proprio nell’ottica di chi ottimizza pagine e conversioni, con il codice sotto mano. È il punto di partenza ideale per chi vuole passare dalla simulazione che abbiamo visto a un bandit che gira davvero sul proprio sito.

Questo articolo fa parte del percorso «L’approccio bayesiano», la guida ragionata agli articoli su statistica e inferenza bayesiana applicate alla SEO.

L’approccio bayesiano risponde a queste due domande in modo nativo. In questo articolo lo applichiamo al confronto tra due varianti, riprendendo il filo lasciato in sospeso quando abbiamo stimato il conversion rate di una singola variante.

È la domanda di ogni test di conversione con un risvolto SEO: due versioni della stessa landing page che si contendono lo stesso traffico organico, oppure due formulazioni di title e meta description giudicate dal loro CTR reale rispetto a quello atteso nella SERP. Ovunque ci siano successi su tentativi — clic su impression, iscrizioni su visite, conversioni su sessioni — il ragionamento che segue è lo stesso.

Di cosa parleremo:

• Due posterior invece di uno: una distribuzione per ciascuna variante
• Qual è la probabilità che B vinca davvero
• Di quanto è meglio: la distribuzione della differenza
• Quando fermarsi: expected loss e il problema del peeking
• Prova tu
• Per approfondire

Due posterior invece di uno

Quando abbiamo stimato il conversion rate di una singola variante, abbiamo visto che — partendo da un prior Beta e osservando dati binomiali — il posterior è ancora una distribuzione Beta. La regola di aggiornamento era una semplice aritmetica: se il prior è Beta(α, β) e osserviamo \( k \) conversioni su \( n \) sessioni, il posterior è:

Detto a parole: aggiungiamo le conversioni osservate al primo parametro e le mancate conversioni al secondo, e non serve altro.

In un A/B test non abbiamo una proporzione sola, ne abbiamo due: una per il controllo (A) e una per il trattamento (B). Il meccanismo, però, è identico: costruiamo un posterior per ciascuna variante, in modo indipendente, applicando la stessa regola due volte.

Facciamo un esempio al volo. Abbiamo testato due versioni di una landing page che riceve traffico organico, assegnando i visitatori a caso:

• Variante A (controllo): 90 conversioni su 1000 sessioni → tasso grezzo 9,0%
• Variante B (trattamento): 120 conversioni su 1000 sessioni → tasso grezzo 12,0%

Partiamo da un prior non informativo Beta(1, 1) per entrambe — “non sappiamo nulla, prima dei dati ogni tasso è ugualmente plausibile”. Applicando la regola, il posterior di A è Beta(91, 911) e quello di B è Beta(121, 881).

Costruisco i due posterior in R, campionandoli per simulazione:

set.seed(42)
# Variante A: 90 conv / 1000 ; Variante B: 120 conv / 1000
cA <- 90; nA <- 1000; cB <- 120; nB <- 1000

# Posterior con prior uniforme Beta(1,1)
postA <- rbeta(1e5, 1 + cA, 1 + nA - cA)   # Beta(91, 911)
postB <- rbeta(1e5, 1 + cB, 1 + nB - cB)   # Beta(121, 881)

Adesso abbiamo in mano due distribuzioni, non due numeri. Ed è proprio questo il punto: invece di confrontare 9,0% contro 12,0% come fossero due valori fissi, confrontiamo l’intera incertezza che li circonda. Le domande operative diventano operazioni su queste distribuzioni.

Vale la pena tenere a mente l’immagine: due rilievi di probabilità affiancati sull’asse dei tassi di conversione. Più quello di B è spostato a destra rispetto a quello di A, e meno i due si sovrappongono, più diventa probabile che B sia davvero la variante migliore.

Qual è la probabilità che B vinca?

La prima domanda — quella che il p-value non risponde mai direttamente — è la probabilità che B sia davvero migliore di A.
Con i posterior in mano, il calcolo è disarmante: confrontiamo i campioni di B con quelli di A, coppia per coppia, e contiamo in quale frazione dei casi B supera A. Quella frazione è la probabilità che cerchiamo.

Calcolo in R la probabilità che B batta A:

cat("P(B>A) =", round(mean(postB > postA), 3), "\n")

Output: P(B>A) = 0.985.

C’è il 98,5% di probabilità che la variante B converta meglio della variante A.
Si noti la differenza di registro rispetto al frequentista. Non stiamo dicendo “la differenza osservata è improbabile sotto l’ipotesi nulla”: stiamo dicendo, in modo diretto, che date le evidenze raccolte è quasi certo che B sia la variante migliore. È esattamente l’affermazione su cui vorremmo basare una decisione — e l’approccio bayesiano ce la consegna senza giri di parole.

Di quanto è meglio: la distribuzione della differenza

Sapere che B vince con probabilità del 98,5% non basta a decidere. Un miglioramento c’è quasi di sicuro, ma se fosse di due decimi di punto percentuale, forse non varrebbe la pena di mandare in produzione la nuova pagina. La domanda successiva è quindi: di quanto è meglio?

Finora abbiamo tenuto A e B separati, un posterior ciascuno. Ma l’oggetto che ci interessa davvero non è nessuno dei due preso da solo: è la loro distanza. La risposta vive perciò nella distribuzione della differenza tra i due posterior. Sottraiamo, campione per campione, il tasso di A da quello di B: otteniamo una nuova distribuzione, quella dell’uplift. Da lì leggiamo sia il valore tipico (la media) sia un intervallo di credibilità che ne quantifica l’incertezza.

Calcolo in R la differenza e il suo intervallo al 95%:

diff <- postB - postA
cat("uplift medio (punti %) =", round(mean(diff)*100, 2), "\n")
cat("CI 95% differenza =", round(quantile(diff, c(.025,.975))*100, 2), "\n")

Output: uplift medio = 3.00 punti %, CI 95% = [0.31, 5.68].

Il guadagno atteso è di circa 3 punti percentuali di conversione, con un intervallo di credibilità al 95% che va da 0,31 a 5,68 punti.
Anche qui il significato è diretto, non una proprietà astratta della procedura: c’è il 95% di probabilità che il vero miglioramento di B su A stia tra 0,3 e 5,7 punti percentuali. L’intervallo non tocca lo zero, il che conferma — coerentemente con il 98,5% di prima — che B è quasi certamente superiore. Ma il dato prezioso è l’ampiezza: il miglioramento potrebbe essere modesto (mezzo punto) o robusto (oltre cinque punti), e questa forbice è un’informazione che la decisione operativa deve tenere presente.

Quando fermarsi: expected loss e il problema del peeking

Nell’articolo sull’A/B testing classico abbiamo dedicato spazio a uno degli errori più insidiosi: il peeking, cioè sbirciare i dati intermedi e fermarsi appena la differenza sembra significativa. Nell’impianto frequentista questo gonfia il tasso di falsi positivi, perché ogni occhiata è di fatto un nuovo test sulla stessa ipotesi nulla, e i test ripetuti moltiplicano le occasioni di sbagliare.

L’approccio bayesiano cambia la natura del problema. Qui non ripetiamo un test su un’ipotesi nulla: aggiorniamo una credenza. Il posterior di oggi diventa il prior di domani, e guardare i dati man mano non “consuma” un budget di errore nello stesso modo. Questo non vuol dire che possiamo fermarci a capriccio: ci serve comunque una regola di arresto dichiarata in anticipo. E la regola bayesiana naturale non è “fermati quando P(B>A) è alta”, ma si basa sull’expected loss — la perdita attesa.

L’idea è questa: se scegliamo B ma in realtà fosse A la variante migliore, sbagliamo, e l’entità dell’errore è quanto A batte B in quei casi. La perdita attesa di scegliere B è la media di questo “rimpianto” su tutta l’incertezza residua. A parole: di quanto, in media, ci pentiremmo di aver scelto B se ci sbagliassimo.

Calcolo in R la perdita attesa scegliendo B:

# Expected loss scegliendo B: perdita attesa se in realta' A fosse meglio
loss_B <- mean(pmax(postA - postB, 0))
cat("expected loss scegliendo B =", round(loss_B*100, 3), "punti %\n")

Output: expected loss scegliendo B = 0.007 punti %.

La perdita attesa scegliendo B è di appena 0,007 punti percentuali: trascurabile. In termini più chiari e diretti, anche nello scenario sfortunato in cui ci sbagliassimo, il danno medio sarebbe minuscolo. Si fissa allora una soglia di tolleranza prima di iniziare — per esempio “mi fermo quando la perdita attesa scende sotto 0,01 punti” — e si lascia correre il test finché non la si raggiunge.

Ed è qui che si vede perché la perdita attesa, e non “P(B>A) è alta”, è il criterio giusto. Se rifacciamo i conti a ogni tappa del test, man mano che il traffico arriva, le due grandezze non scattano nello stesso momento: la probabilità che B vinca supera il 95% molto prima che la perdita attesa diventi davvero trascurabile.

Prova tu

Un sito di lead generation testa due varianti del modulo di contatto. Sulla variante A si osservano 45 conversioni su 600 sessioni; sulla B, 52 conversioni su 600 sessioni.

1. Costruisci i due posterior con prior non informativo Beta(1, 1): postA <- rbeta(1e5, 1 + 45, 1 + 555) e l’analogo per B.
2. Calcola P(B>A): B è migliore con probabilità abbastanza alta da convincerti?
3. Calcola uplift medio e intervallo al 95% della differenza: l’intervallo tocca lo zero?
4. Calcola la expected loss scegliendo B. Con questi numeri (più vicini tra loro del caso visto sopra), come cambia rispetto all’esempio dell’articolo?

Suggerimento: la struttura del codice è identica a quella che abbiamo usato. Cambiano solo i conteggi di partenza — e il risultato, molto meno netto, è proprio il motivo per cui l’intervallo e la perdita attesa contano più di un semplice “ha vinto B”.

Finora abbiamo confrontato due varianti a campione fisso: raccogliamo i dati, calcoliamo, decidiamo. Eppure la probabilità che B sia la migliore l’abbiamo appena vista ricalcolarsi a ogni tappa, mentre il traffico arriva — e se una variante si sta rivelando nettamente migliore, perché continuare a mandare metà dei visitatori su quella peggiore? Si può fare di meglio: usare quella probabilità in tempo reale per allocare il traffico in modo adattivo, spostandolo verso la variante che sta vincendo mentre il test è ancora in corso. È il salto dal test al bandit, l’argomento del prossimo articolo.

Per approfondire

Se vuoi approfondire l’A/B testing bayesiano con un taglio pratico e orientato al codice, Bayesian Methods for Hackers di Cameron Davidson-Pilon è il libro che consiglio. Affronta il ragionamento bayesiano partendo dalla programmazione invece che dalla matematica formale, e dedica un capitolo esplicito proprio al confronto bayesiano tra varianti — probabilità che B vinca, distribuzione della differenza, perdita attesa. È pensato per chi impara meglio leggendo codice che dimostrazioni.

Questo articolo fa parte del percorso «L’approccio bayesiano», la guida ragionata agli articoli su statistica e inferenza bayesiana applicate alla SEO.

Il problema nasce sempre allo stesso modo. Un piccolo e-commerce ha raccolto 23 conversioni su 412 sessioni. Il tasso grezzo è 23/412 ≈ 5,6%. Un numero preciso, apparentemente. Ma quanta fiducia gli diamo? Potremmo trovarci davanti al 3% vero o al 9% vero — con quel campione, non lo sappiamo. La stima puntuale “5,6%” non dice niente sulla propria incertezza.

Di cosa parleremo:

• Il modello Beta-Binomiale: perché la Beta è la distribuzione naturale per un conversion rate
• Prior non informativo: lasciar parlare i dati
• Prior informativo: usare lo storico senza barare
• Il posterior di oggi è il prior di domani
• Prova tu
• Per approfondire

Dal click singolo al tasso: il modello Beta-Binomiale

Ogni sessione è un evento binario: l’utente converte oppure no.
Con \( n \) sessioni e \( k \) conversioni, il meccanismo generativo è binomiale. Il parametro che vogliamo stimare — il vero tasso di conversione \( \theta \) — è una proporzione: un valore tra 0 e 1.

Quando il prior su \( \theta \) è una distribuzione Beta e i dati sono binomiali, accade qualcosa di molto comodo: il posterior è ancora una distribuzione Beta. Questo si chiama prior coniugato, e significa che l’aggiornamento bayesiano si riduce a una semplice operazione aritmetica sui parametri.

La regola di aggiornamento è questa: se il prior è Beta(α, β), dopo aver osservato \( k \) conversioni su \( n \) sessioni il posterior è:

In parole: aggiungiamo le conversioni osservate ad α e i fallimenti osservati a β. Il prior Beta(α, β) raccoglie in α le “conversioni già viste” (o una credenza equivalente) e in β i “non-click”. Ogni nuovo dato aggiorna entrambi i contatori.

Prior non informativo: lasciar parlare i dati

Il prior più neutro possibile su una proporzione è la distribuzione uniforme su [0, 1], che corrisponde a Beta(1, 1): tutti i valori del tasso sono considerati ugualmente plausibili prima di vedere i dati.

Il nostro caso: 23 conversioni su 412 sessioni (389 non-conversioni).

Calcoliamo il posterior in R:

# Dati osservati
conv <- 23; sess <- 412; nonconv <- sess - conv

# Prior NON informativo: uniforme Beta(1,1)
a0 <- 1; b0 <- 1
a1 <- a0 + conv; b1 <- b0 + nonconv      # posterior Beta(24, 390)

cat("Non-informativo: media =", round(a1/(a1+b1), 4), "\n")
cat("  CI 95% =", round(qbeta(c(.025,.975), a1, b1), 4), "\n")

Output: media = 0.058, CI 95% = [0.0376, 0.0824].

Il posterior Beta(24, 390) ha media 5,8% e credible interval al 95% compreso tra 3,8% e 8,2%.
Il credible interval bayesiano non è un esercizio statistico astratto: significa direttamente che c’è il 95% di probabilità che il vero tasso di conversione sia tra il 3,8% e l’8,2%. Non una frequenza su ripetizioni infinite — una probabilità diretta sul parametro.

Con 412 sessioni, l’incertezza è ancora apprezzabile: quasi 5 punti percentuali di ampiezza. La stima puntuale 5,6% era fuorviante nella sua precisione.

Un avvertimento: il credible interval bayesiano e l’intervallo di confidenza frequentista hanno numeri simili ma significati profondamente diversi. Il 95% frequentista è una proprietà della procedura (“se ripetessi l’esperimento 100 volte, 95 intervalli conterrebbero il vero parametro”); il 95% bayesiano è un’affermazione diretta sul parametro nel caso specifico che stiamo analizzando.

Prior informativo: usare lo storico senza barare

Il prior non informativo è il punto di partenza onesto quando non sappiamo nulla. Ma spesso sappiamo qualcosa: anni di campagne, storico del settore, benchmark di categoria.
Il nostro e-commerce ha uno storico di quattro stagioni con un conversion rate medio intorno al 4%. Come traduciamo questa conoscenza in un prior?

La distribuzione Beta(8, 192) ha media esattamente 8/(8+192) ≈ 4% e — grazie alla somma α+β = 200 — ha una concentrazione che equivale a “credere” ai nostri dati quanto si crede a 200 sessioni fittizie di storico. Non è un numero arbitrario: è una scelta dichiarata e verificabile.

Calcoliamo il posterior informativo in R:

# Prior INFORMATIVO da storico: media ~4% -> Beta(8, 192)
a0i <- 8; b0i <- 192
a1i <- a0i + conv; b1i <- b0i + nonconv  # posterior Beta(31, 581)

cat("Informativo: media =", round(a1i/(a1i+b1i), 4), "\n")
cat("  CI 95% =", round(qbeta(c(.025,.975), a1i, b1i), 4), "\n")

Output: media = 0.0507, CI 95% = [0.0347, 0.0694].

Il posterior informativo Beta(31, 581) dà media 5,1% e credible interval al 95% tra 3,5% e 6,9%.
Due cose da notare. Prima: la media scende leggermente da 5,8% a 5,1% — il prior “tira” la stima verso il 4% dello storico. Seconda: l’intervallo si stringe (da 4,4 a 3,4 punti percentuali) — lo storico vale come informazione aggiuntiva, quindi l’incertezza cala.

Con pochi dati, il prior informativo aiuta: aggiunge informazione dove i dati non bastano. Con molti dati — migliaia di sessioni — il prior viene sommerso dai dati e la differenza tra prior informativo e non informativo diventa trascurabile. Questa è una caratteristica fondamentale dell’inferenza bayesiana: il prior conta quando i dati sono pochi; i dati vincono sempre, alla lunga.

Il posterior di oggi è il prior di domani

L’eleganza più pratica dell’approccio bayesiano è l’aggiornamento sequenziale. Dopo un mese arrivano nuovi dati: 15 conversioni su 300 sessioni aggiuntive. Non dobbiamo ricominciare da zero — il posterior che abbiamo calcolato diventa il nuovo prior.

Aggiorniamo in R:

# Nuovi dati: 15 conversioni su 300 sessioni aggiuntive
conv2 <- 15; sess2 <- 300
a2 <- a1i + conv2; b2 <- b1i + (sess2 - conv2)   # Beta(46, 866)

cat("Dopo update: media =", round(a2/(a2+b2), 4), "\n")
cat("  CI 95% =", round(qbeta(c(.025,.975), a2, b2), 4), "\n")

Output: media = 0.0504, CI 95% = [0.0372, 0.0655].

Tre stadi a confronto:

Il credible interval si è ristretto ad ogni stadio: 5,3 punti percentuali nel prior puro, 3,4 dopo il primo mese, 2,8 dopo l’aggiornamento. La media è rimasta stabile: i nuovi dati confermano la stima precedente invece di spostarla, e l’incertezza cala come atteso.
Questo è il vero vantaggio operativo: non occorre aspettare che si accumuli un campione “abbastanza grande” prima di fare qualsiasi stima. Si parte da una stima incerta e la si affina progressivamente, con ogni nuovo dato.

Prova tu

Un sito di lead generation ha un tasso di conversione storico intorno al 2%. Dopo una campagna di ottimizzazione, su 150 sessioni si osservano 8 conversioni.

1. Costruisci un prior informativo che rifletta il 2% storico: prova Beta(4, 196) — ha media esattamente 2%.
2. Calcola il posterior dopo le 8 conversioni su 150 sessioni.
3. Calcola il credible interval al 95%.
4. Calcola poi con prior non informativo Beta(1, 1): il posterior cambia molto? Perché?

Suggerimento: la formula è sempre la stessa — qbeta(c(.025, .975), a0 + conv, b0 + nonconv). L’unica cosa che cambia è il punto di partenza.

Quello che abbiamo costruito finora è la stima di un tasso su una singola variante. Il passo successivo è confrontare due varianti — una pagina di controllo e una pagina modificata — e calcolare la probabilità bayesiana che una superi l’altra. È esattamente quello che faremo nel prossimo articolo: l’A/B test bayesiano.

Per approfondire

Se vuoi capire come il ragionamento bayesiano entra nelle decisioni pratiche — dalla previsione dei mercati alla stima dell’incertezza nei dati reali — Il segnale e il rumore di Nate Silver è il libro che consiglio. Silver dedica capitoli espliciti all’aggiornamento bayesiano, mostrandolo in contesti concreti (previsioni meteorologiche, politica, sport) che rendono immediato il concetto di “aggiornare le credenze con nuovi dati”. È divulgativo ma rigoroso, e si legge d’un fiato.

Questo articolo fa parte del percorso «L’approccio bayesiano», la guida ragionata agli articoli su statistica e inferenza bayesiana applicate alla SEO.