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.

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

È lo stesso inganno che abbiamo incontrato chiudendo l’articolo sulla regressione verso la media: lì selezionavamo le pagine messe peggio — un istante estremo nello spazio dei dati — e ci facevamo ingannare dal loro rientro. Qui selezioniamo un istante estremo nel tempo: ci fermiamo appena il test ci dà ragione. Il meccanismo è cugino, il rischio identico.

Cos’è il peeking

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

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

Non è la solita molteplicità di chi confronta dieci varianti insieme. Qui la molteplicità è nascosta nel tempo: una sola variante, guardata tante volte. È la stessa logica per cui se si lancia una moneta una volta sola un risultato strano è raro, ma se ci si concede di guardare dopo ogni lancio e di fermarsi al primo momento favorevole, prima o poi quel momento arriva — e lo si scambia per un segnale.

Quanto costa sbirciare: una simulazione

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

set.seed(2025)

p_vero  <- 0.10    # stesso conversion rate per A e B (H0 vera)
n_arm   <- 2000    # visitatori per variante a fine test
n_sim   <- 4000    # numero di esperimenti simulati
alpha   <- 0.05
sguardi <- 20      # quante volte "sbirciamo" durante la raccolta
look_at <- round(seq(n_arm / sguardi, n_arm, length.out = sguardi))

# p-value z-test due proporzioni, due code
pval_ab <- function(xa, na, xb, nb) {
  pp <- (xa + xb) / (na + nb)
  se <- sqrt(pp * (1 - pp) * (1 / na + 1 / nb))
  2 * pnorm(-abs((xa / na - xb / nb) / se))
}

# un esperimento A/A: TRUE se dichiara un (falso) vincitore
esperimento <- function(soglia, guarda) {
  a <- cumsum(rbinom(n_arm, 1, p_vero))
  b <- cumsum(rbinom(n_arm, 1, p_vero))
  for (k in guarda) {
    p <- pval_ab(a[k], k, b[k], k)
    if (!is.na(p) && p < soglia) return(TRUE)
  }
  FALSE
}

Cominciamo dal comportamento corretto: un solo test, alla fine, sui 2.000 visitatori per variante. Lo eseguo 4.000 volte e conto quante dichiarano un vincitore:

# orizzonte fisso: un solo test, alla fine
fisso <- mean(replicate(n_sim, esperimento(alpha, n_arm)))
cat(sprintf("Orizzonte fisso: %.1f%% falsi positivi\n", 100 * fisso))
# Orizzonte fisso: 5.0% falsi positivi

Esce 5,0%: esattamente il livello che avevamo dichiarato con la soglia al 5%. Il test, usato come si deve, mantiene la promessa.
Ora cambio una cosa sola: invece di guardare una volta alla fine, guardo venti volte durante la raccolta e mi fermo al primo momento in cui il p-value scende sotto 0,05. Aggiungo gli sguardi intermedi e rieseguo:

# peeking: test a ogni sguardo, stop al primo significativo
peek <- mean(replicate(n_sim, esperimento(alpha, look_at)))
cat(sprintf("Peeking (%d sguardi): %.1f%% falsi positivi\n", sguardi, 100 * peek))
# Peeking (20 sguardi): 24.3% falsi positivi

Da 5,0% a 24,3%.
Gli stessi dati, lo stesso test, la stessa soglia: l’unica cosa cambiata è quando abbiamo deciso di guardare, e il tasso di falsi positivi è quasi quintuplicato. Quasi un test A/A su quattro, in cui le due varianti sono identiche per costruzione, ci convince di aver trovato un vincitore. Il 24,3% della nostra simulazione e il 30% riportato da Optimizely raccontano la stessa storia con dati diversi: sbirciare non è un peccato veniale, è il modo più efficace per ingannarsi da soli.

Soluzione 1: l’orizzonte fisso

La cura più semplice è anche la più antipatica: decidere prima quanti dati raccogliere, e poi avere la disciplina di aspettare fino alla fine senza fermarsi in anticipo, qualunque cosa dica la dashboard nel frattempo.
È quello che la simulazione ci ha appena mostrato: con un solo test alla fine, il falso positivo resta inchiodato al 5% promesso. Nessuna magia, solo l’aver eliminato gli sguardi opportunistici.

“Quanti dati” non è una cifra a caso: dipende da quanto è piccola la differenza che vogliamo essere in grado di cogliere e da quanta certezza pretendiamo. È il calcolo della dimensione campionaria, che si fa prima di lanciare il test con il nostro calcolatore di significatività e che poggia sui concetti di effect size e power analysis.
Fissato quel numero, l’orizzonte fisso è la strada più sicura: nessuna correzione statistica da applicare, nessuna soglia da ritoccare. Si paga però un prezzo in pazienza — bisogna resistere alla curiosità per giorni o settimane — e questo, nella realtà operativa, è esattamente ciò che quasi nessuno riesce a fare.

Soluzione 2: guardare senza barare

E se monitorare in corsa fosse davvero necessario — perché un test che sta andando malissimo va fermato, perché gli stakeholder vogliono aggiornamenti?
Allora la strada non è guardare di nascosto con la soglia di sempre, ma guardare apertamente con una soglia più severa. L’idea è semplice: se a ogni sguardo alziamo l’asticella, rendendo più difficile gridare al vincitore in ciascuna occasione, possiamo fare in modo che l’errore complessivo — sommato su tutti gli sguardi — resti il 5% che volevamo. Calibro in R la soglia per-sguardo, provando valori via via più stringenti sugli stessi venti sguardi di prima:

# soglia per-sguardo più severa che riporta l'errore complessivo ~5%
for (sg in c(0.05, 0.02, 0.01, 0.005)) {
  fp <- mean(replicate(n_sim, esperimento(sg, look_at)))
  cat(sprintf("  soglia %.3f -> %.1f%% complessivo\n", sg, 100 * fp))
}
#   soglia 0.050 -> 25.1% complessivo
#   soglia 0.020 -> 11.7% complessivo
#   soglia 0.010 ->  6.6% complessivo
#   soglia 0.005 ->  3.3% complessivo

Come si vede, la soglia abituale dello 0,05 produce un 25,1% di errore complessivo (di nuovo il disastro del peeking), ma man mano che la rendiamo più severa l’errore rientra: intorno allo 0,01 — una soglia cinque volte più stringente di quella standard — l’errore complessivo torna vicino al 5% nominale. È il prezzo da pagare per il diritto di sbirciare: a ogni singolo sguardo si pretende molta più evidenza, in cambio della libertà di guardare spesso.

Quella appena mostrata è una versione artigianale e a soglia costante dell’idea. I confini “da manuale” — più raffinati, con soglie che cambiano nel corso del test, come quelli di Pocock o O’Brien-Fleming — si ottengono in R con il pacchetto gsDesign, e i tool commerciali come Optimizely usano una variante always-valid (la cosiddetta mSPRT) della stessa idea di fondo.
Cambia la matematica fine, non il principio: per guardare spesso senza barare bisogna chiedere, a ogni sguardo, più evidenza di quanta ne chiederebbe un test singolo.

Un avvertimento: un risultato visto durante il test, da solo, non prova niente: conta quando si è deciso di guardarlo.
Lo stesso p-value sotto 0,05 significa cose diverse a seconda che sia l’unico test a orizzonte fisso o il primo dei venti in cui ci si è riservati di fermarsi. Senza dichiarare in anticipo come e quando si guarderanno i dati, qualunque “vincitore” emerso in corsa è sospetto.

Prova tu

Per sentire il meccanismo da vicino, si parte dallo script e si cambia un solo parametro: il numero di sguardi.
Si prova a passare da un monitoraggio settimanale (pochi sguardi) a uno giornaliero (molti sguardi) e si riesegue la simulazione del peeking. Cosa aspettarsi: più di frequente si sbircia, più sale il tasso di falsi positivi — la frequenza degli sguardi è la benzina del problema. Poi si rifà la calibrazione della soglia con quel nuovo numero di sguardi e si verifica che, scegliendo una soglia abbastanza severa, l’errore complessivo torna comunque sotto controllo. È la dimostrazione, fatta in prima persona, che il peeking non è una maledizione: è solo un conto che va pagato.

C’è un’ultima trappola di questa famiglia, forse la più subdola, perché non si nasconde nei nostri dati ma in quelli che ci raccontano gli altri. Quando leggiamo il case study di un’agenzia — “abbiamo aumentato le conversioni del 300% con questa tattica” — stiamo guardando un sopravvissuto: i mille tentativi identici che sono falliti non li racconta nessuno. È il survivorship bias, il motivo per cui i case study mentono anche quando dicono il vero, ed è il prossimo passo del nostro viaggio tra i tranelli dei dati di marketing.

Per approfondire

Su peeking, arresto anticipato e test sequenziali il riferimento — in inglese — resta Trustworthy Online Controlled Experiments di Ron Kohavi, Diane Tang e Ya Xu: scritto da chi ha guidato le piattaforme di sperimentazione di Microsoft, Google e LinkedIn, dedica pagine esplicite a tutti i modi in cui un A/B test in corsa può ingannarci, e a come difendersi. È il libro che tira fuori dal cassetto chiunque debba prendere sul serio gli esperimenti online.

Lo stesso identico inganno ci aspetta ogni volta che guardiamo i dati di un sito e decidiamo se un nostro intervento “ha funzionato”.

Vale la pena chiarire subito una cosa sul nome, perché trae in inganno: la regressione verso la media non ha niente a che vedere con la regressione lineare, il modello che traccia una retta tra due variabili. Qui “regressione” va inteso nel senso comune di ritorno, rientro: i valori estremi che tornano indietro verso la loro media. Sono due cose diverse che condividono solo una parola.

Cos’è la regressione verso la media

Il meccanismo è semplice, e una volta visto non si riesce più a non vederlo.
Quasi ogni numero che misuriamo è la somma di due parti: un valore “vero”, stabile, e una dose di rumore — fluttuazione casuale del momento. La posizione media in SERP di una pagina in un certo mese dipende dalla sua reale rilevanza, ma anche dal caso: l’algoritmo che oscilla, un competitor che quel mese ha spinto, la stagionalità della query, un pugno di clic in più o in meno.

Ora, quando isoliamo i casi estremi — le pagine messe peggio, il mese andato peggio — stiamo quasi sempre selezionando situazioni in cui il rumore ha spinto tutto nella stessa direzione sfavorevole.
Alla misura successiva quel rumore non si ripeterà identico, e il valore tenderà a risalire verso la sua media vera — senza che nessuno abbia fatto nulla. È un fatto puramente statistico, non un fenomeno SEO: più una misura è estrema, più è probabile che la prossima sia meno estrema.

L’ottimizzazione che ha funzionato per caso

Vediamo cosa combina questo meccanismo nel lavoro di tutti i giorni. Immaginiamo di tenere d’occhio la posizione media in SERP di 300 pagine per due mesi consecutivi. Simulo in R lo scenario, dando a ogni pagina una posizione “vera” stabile e aggiungendo a ciascun mese una fluttuazione casuale:

set.seed(48)

# 300 pagine, ognuna con la sua posizione "vera" in SERP (stabile nel tempo)
pos_vera <- runif(300, 3, 40)

# due mesi consecutivi: stessa posizione vera, rumore casuale diverso
mese1 <- pos_vera + rnorm(300, 0, 8)
mese2 <- pos_vera + rnorm(300, 0, 8)

# le 60 pagine messe peggio nel mese 1 (in SERP "peggio" = numero più alto)
peggiori <- order(mese1, decreasing = TRUE)[1:60]

round(mean(mese1[peggiori]), 1)   # posizione media di partenza
# [1] 39.1

Le nostre 60 pagine peggiori partono da una posizione media di 39,1: roba da fondo della terza pagina. Decidiamo di intervenire — riscriviamo i title, aggiorniamo i contenuti, sistemiamo i link interni — e il mese dopo ricontrolliamo.
Ecco il risultato, senza che nel frattempo l’algoritmo sia cambiato e, soprattutto, senza che nella simulazione io abbia toccato davvero nulla:

round(mean(mese2[peggiori]), 1)   # un mese dopo
# [1] 33

Da 39,1 a 33: circa sei posizioni guadagnate. Un balzo che in un report farebbe un figurone, e che chiunque sarebbe tentato di attribuire all’ottimizzazione appena fatta.
Peccato che nel codice non ci sia nessuna ottimizzazione: le pagine sono migliorate da sole, perché erano state scelte proprio in quanto estreme e il rumore che le aveva affossate nel mese 1 non si è ripetuto. Per dare la misura: la posizione media di tutte le 300 pagine è circa 22, ed è verso quel valore che le peggiori stanno rientrando.

Come non farsi ingannare: il gruppo di controllo

Se il miglioramento arriva comunque, come facciamo a sapere se la nostra ottimizzazione ha avuto un qualche effetto reale?
La risposta è la stessa che useremmo per un farmaco: serve un gruppo di controllo. Dividiamo le 60 pagine peggiori in due metà a caso: una la “ottimizziamo”, l’altra la lasciamo deliberatamente in pace. Poi confrontiamo quanto migliorano:

# divido le 60 peggiori in due gruppi casuali
gruppo <- sample(rep(c("ottimizzate", "controllo"), each = 30))

# miglioramento medio (mese1 - mese2) nei due gruppi
round(tapply(mese1[peggiori] - mese2[peggiori], gruppo, mean), 1)
# controllo ottimizzate
#       6.0         6.1

Il gruppo “ottimizzato” guadagna 6,1 posizioni, quello di controllo — lasciato intatto — ne guadagna 6,0.
Praticamente lo stesso identico miglioramento. La nostra ottimizzazione, nella simulazione, non ha aggiunto nulla: tutto il guadagno era regressione verso la media, e il controllo lo smaschera mostrando che sarebbe successo comunque.

La lezione è questa: un miglioramento, da solo, non prova niente.
Quando intervieni proprio sulle pagine (o sulle campagne) che andavano peggio, una parte della loro ripresa è garantita a prescindere da te. Senza un confronto con ciò che non hai toccato, non puoi sapere quanto del risultato è merito tuo e quanto è solo rientro verso la media.

È lo stesso ragionamento, va detto, che sta dietro a un A/B test fatto come si deve: confrontare la variante con un controllo concorrente, non con il “prima”. Ed è cugino stretto della trappola che abbiamo visto parlando di correlazione e causazione: anche qui scambiamo una sequenza temporale (“ho agito, poi è migliorato”) per un nesso causale.

Prova tu

Per fissare il meccanismo, prova a ricostruire lo scenario cambiando un solo dettaglio: invece delle 60 pagine peggiori, seleziona le 60 migliori del mese 1 (order(mese1)[1:60], senza decreasing) e guarda come si comportano nel mese 2.

Cosa aspettarti: anche le campionesse rientrano verso la media, ma peggiorando — le posizioni di vertice contengono fortuna che non si ripete. È la faccia speculare dello stesso fenomeno, e spiega perché “quel mese d’oro” o “quella pagina che volava” così spesso non si riescono a replicare: non avevi perso il tocco magico, stavi solo tornando verso la tua media.

C’è una variante ancora più insidiosa di questa trappola, perché si nasconde dentro gli strumenti che usiamo proprio per decidere con rigore. Se guardiamo un test mentre è ancora in corso e ci fermiamo appena i numeri ci piacciono, stiamo selezionando un istante estremo esattamente come abbiamo selezionato le pagine peggiori — e ci faremo ingannare allo stesso modo. È il peeking problem, ed è il prossimo passo del nostro viaggio tra i tranelli dei dati di marketing.

Per approfondire

Il racconto degli istruttori di volo con cui abbiamo aperto viene da Pensieri lenti e veloci di Daniel Kahneman, premio Nobel per l’economia: è il libro che ha reso popolari la regressione verso la media e decine di altri bias del nostro ragionamento, raccontati con esempi che restano addosso. Se di questo articolo vuoi tenere una cosa sola, tienilo: è una vaccinazione contro l’illusione di aver capito perché i numeri si muovono.

Diciamo subito cosa la correlazione non è, perché è qui che nascono i guai.
La correlazione misura se e quanto due variabili si associano; non dice che una causa l’altra, e non costruisce un modello per prevedere l’una dall’altra.
Quel secondo passo — la previsione — è il mestiere della regressione, di cui ci occuperemo a parte.
Qui restiamo al passo precedente: capire, con un solo numero, se due metriche viaggiano insieme.

Dalla covarianza alla correlazione

L’idea di partenza è semplice. Se due variabili si muovono insieme, quando una sta sopra la propria media anche l’altra tende a stare sopra la sua; quando una scende sotto, l’altra la segue.
Possiamo misurare questa tendenza moltiplicando, per ogni osservazione, lo scarto di x dalla sua media per lo scarto di y dalla sua, e facendone la media.
È la covarianza:

dove x̄ e ȳ sono le medie delle due variabili e n il numero di osservazioni.
Quando gli scarti hanno lo stesso segno (entrambi sopra o entrambi sotto la media) il prodotto è positivo; quando hanno segni opposti è negativo.
Una covarianza positiva segnala dunque che le due variabili tendono a crescere insieme, una negativa che quando l’una sale l’altra scende.

La covarianza, però, ha un difetto che la rende inutilizzabile come metro di confronto: dipende dalle unità di misura.
La covarianza tra sessioni e secondi di permanenza è un numero, quella tra sessioni e tasso di conversione un altro, e i due non si possono paragonare perché parlano lingue diverse.
Per ottenere una misura pulita la dividiamo per le due deviazioni standard, in modo da spogliarla delle unità e costringerla in un intervallo fisso.
Otteniamo così il coefficiente di correlazione di Pearson:

Il numeratore non è altro che la covarianza (a meno del fattore n); il denominatore è il prodotto delle due variabilità, e serve appunto a normalizzare.
Il risultato è un numero puro compreso tra −1 e +1: vale +1 quando i punti stanno esattamente su una retta crescente, −1 quando stanno su una retta decrescente, 0 quando non c’è alcuna associazione lineare.
Quanto più r si avvicina agli estremi, tanto più stretta è la relazione lineare.

Pearson: l’associazione lineare (e la sua trappola)

Mettiamolo subito al lavoro su un caso che chi fa SEO conosce a memoria: il legame tra la posizione in SERP e il CTR, la percentuale di clic. Sappiamo tutti che più si scende nella pagina dei risultati, meno si viene cliccati. Prendiamo dieci posizioni con i rispettivi CTR osservati e calcoliamo in R il coefficiente di Pearson:

pos <- 1:10
ctr <- c(28.5, 15.7, 11.0, 7.2, 8.0, 5.1, 4.0, 3.2, 2.8, 2.6)  # CTR % per posizione

cor(pos, ctr)
# [1] -0.852

Il coefficiente è −0,852: forte, negativo, esattamente come ci aspettavamo. Eppure c’è qualcosa che non torna. Il legame tra posizione e CTR è ferreo — non capita quasi mai che una posizione più bassa renda più clic — e ci aspetteremmo un valore ancora più vicino a −1. Perché Pearson si ferma a −0,85?

La risposta è il punto più importante di tutto l’articolo. Pearson misura solo l’associazione lineare, cioè quanto bene i punti si dispongono lungo una retta. Ma la curva del CTR non è una retta: crolla a precipizio dalla prima alla terza posizione e poi si appiattisce. La relazione è fortissima, solo che è curva. Pearson, che cerca rette, vede quella curvatura come “imperfezione” e abbassa il voto. Non sta sbagliando: sta rispondendo a una domanda — “quanto è lineare?” — che in questo caso non è quella giusta.

Spearman e Kendall: l’associazione monotòna

Per molte relazioni del mondo SEO ci interessa una cosa più debole della linearità: ci basta sapere se, quando una variabile cresce, l’altra cresce sistematicamente (o cala sistematicamente), senza pretendere che lo faccia a passo costante. Una relazione del genere si dice monotòna, e per misurarla esiste il coefficiente di correlazione per ranghi di Spearman, indicato con ρ (rho).

Il trucco di Spearman è elegante: invece di lavorare sui valori, lavora sui loro ranghi.
Sostituisce a ogni numero la sua posizione in classifica (il più piccolo diventa 1, il successivo 2, e così via) e poi calcola un normale Pearson su questi ranghi. In questo modo la forma esatta della curva sparisce — conta solo l’ordine — e ciò che resta è quanto fedelmente l’ordine di x riproduce quello di y.

Lo calcoliamo sugli stessi dati di prima:

cor(pos, ctr, method = "spearman")
# [1] -0.988

Adesso il coefficiente è −0,988, schiacciato contro −1. È la fotografia corretta della situazione: man mano che la posizione peggiora, il CTR cala quasi senza eccezioni. (Quel “quasi” non è un caso: nei dati ho lasciato una piccola inversione realistica, la posizione 5 che rende più della 4, come capita quando un rich snippet gonfia il CTR di un risultato; è esattamente il genere di increspatura che impedisce a ρ di toccare il −1 esatto.). Dove Pearson vedeva un’associazione “buona ma non ottima”, Spearman riconosce la relazione monotòna quasi perfetta che effettivamente c’è.

Esiste una terza misura che vale la pena conoscere, il tau di Kendall (τ). Anch’essa lavora sull’ordine, ma con una logica diversa: conta, su tutte le coppie di osservazioni, quante sono concordi (se x cresce, cresce anche y) e quante discordi, e ne fa il bilancio. La calcolo in R sempre sugli stessi dati:

cor(pos, ctr, method = "kendall")
# [1] -0.956

Kendall restituisce −0,956, anch’esso vicino agli estremi ma tipicamente un po’ più prudente di Spearman.

Nella pratica quotidiana la scelta è meno complicata di quanto sembri: Pearson quando ci interessa una relazione lineare e i dati non hanno code o valori anomali violenti; Spearman quando la relazione è monotòna ma curva, o quando i dati sono già ranghi (posizioni, classifiche), o quando un paio di outlier rischiano di sballare Pearson; Kendall quando le osservazioni sono poche o ci sono molti valori a pari merito, situazione in cui le sue proprietà statistiche reggono meglio.

La matrice di correlazione

Raramente abbiamo solo due metriche da confrontare. Più spesso ne abbiamo una manciata — sessioni, durata media, conversioni, frequenza di rimbalzo — e vorremmo vedere tutte le associazioni a colpo d’occhio. La funzione cor() di R, applicata a un intero data frame, restituisce la matrice di correlazione: il coefficiente di ogni variabile con ogni altra.
La costruisco su dodici pagine di esempio:

ga4 <- data.frame(
  sessioni      = c(120, 340, 210, 560, 430, 780, 650, 290, 510, 880, 360, 720),
  durata_media  = c(31,  55,  48,  44,  58,  63,  71,  52,  46,  68,  60,  64),
  conversioni   = c(3,   8,   4,   21,  11,  24,  19,  9,   17,  29,  7,   22),
  freq_rimbalzo = c(70,  61,  66,  44,  57,  41,  46,  59,  52,  38,  63,  45)
)

round(cor(ga4), 2)
#               sessioni durata_media conversioni freq_rimbalzo
# sessioni          1.00         0.73        0.98         -0.97
# durata_media      0.73         1.00        0.58         -0.62
# conversioni       0.98         0.58        1.00         -0.99
# freq_rimbalzo    -0.97        -0.62       -0.99          1.00

Si legge come una tabella a doppia entrata: sulla diagonale ci sono tutti 1 (ogni variabile è perfettamente correlata con sé stessa), e la matrice è simmetrica perché la correlazione di x con y è la stessa di y con x. Come si vede, sessioni e conversioni viaggiano quasi all’unisono (0,98: più traffico, più conversioni — niente di sorprendente), la frequenza di rimbalzo è correlata negativamente con tutto il resto, mentre la durata media si associa alle conversioni molto meno di quanto l’intuizione suggerirebbe (0,58).
Una matrice del genere è una mappa di partenza preziosa per decidere dove guardare. È utile visualizzarla come heatmap (con pacchetti come corrplot), dove l’intensità del colore rende immediato cogliere i legami forti.

Un avvertimento: una matrice di correlazione non è una mappa causale.
Ci dice quali numeri si muovono insieme, non quale muove quale, né se a muoverli sia un terzo fattore che non abbiamo nemmeno in tabella.

Correlazione non è causazione

È la frase più ripetuta della statistica, e la più disattesa nei fatti.
Vale la pena vedere dove inciampa, perché in SEO l’inciampo è quotidiano. Prendiamo l’osservazione classica: gli articoli più lunghi si posizionano meglio. Misuriamo l’associazione tra lunghezza del contenuto e un punteggio di ranking (più alto = meglio piazzato):

lung       <- c(620, 850, 1100, 1300, 1500, 1800, 2100, 2400, 2800, 3200)
rank_score <- c(3,   8,   6,    11,   9,    7,    14,   10,   16,   15)

cor(lung, rank_score)
# [1] 0.842

Un bel 0,842: la correlazione c’è, ed è robusta.
La tentazione di concludere “allungo gli articoli e salgo in classifica” è fortissima — e quasi sempre sbagliata. Davanti a una correlazione, prima di parlare di causa, dobbiamo metterci sul tavolo almeno tre spiegazioni alternative.
Potrebbe essere una causa diretta (la lunghezza aiuta davvero il ranking). Potrebbe essere una causa inversa (le pagine che già rankano bene ricevono più cure e vengono ampliate nel tempo).
Oppure — il caso più frequente e più insidioso — potrebbe esserci un fattore confondente che muove entrambe: l’autorevolezza del sito. Un dominio autorevole tende sia a produrre contenuti più approfonditi (quindi più lunghi) sia a posizionarsi meglio (per ragioni che con la lunghezza non c’entrano). La lunghezza e il ranking salgono insieme non perché l’una causi l’altro, ma perché un terzo elemento li traina entrambi.

Questo terzo elemento nascosto è la radice di alcuni degli errori più spettacolari nell’analisi dei dati: arriva persino a invertire il segno di una relazione quando i dati vengono aggregati nel modo sbagliato, il fenomeno che va sotto il nome di paradosso di Simpson.
Stabilire un nesso causale è un mestiere a sé, che richiede esperimenti controllati o tecniche dedicate; la correlazione, da sola, non ci arriverà mai. Il suo compito è un altro, ed è prezioso: segnalarci le coppie di metriche che vale la pena indagare più a fondo.

Prova tu

Per fissare il meccanismo, ecco un esercizio con dati verosimili. Abbiamo, per dieci pagine, il numero di domini referral che le linkano e il loro traffico organico mensile, e vogliamo capire quanto i due si associno:

bl  <- c(5, 12, 8, 25, 18, 40, 33, 60, 52, 95)        # domini referral
org <- c(180, 240, 420, 510, 760, 690, 1250, 1100, 1900, 1650)  # sessioni organiche/mese

Il compito: calcolare sia il coefficiente di Pearson con cor(bl, org), sia quello di Spearman con cor(bl, org, method = "spearman"), e ragionare sul perché differiscono.

Per controllare i conti: Pearson vale 0,815 e Spearman 0,855. Sono entrambi alti e raccontano la stessa storia di fondo — più domini referral, più traffico — ma il fatto che Spearman sia un po’ più alto di Pearson ci dice qualcosa: la relazione è più monotòna che lineare, segno che oltre una certa soglia ogni link aggiuntivo porta meno traffico marginale di quanto la retta vorrebbe. E, naturalmente, nessuno dei due numeri ci autorizza a dire che comprare backlink farà salire il traffico: anche qui l’autorevolezza del sito potrebbe star muovendo le due cose insieme.

Con la correlazione abbiamo imparato a rispondere alla domanda se, e quanto, due metriche si associano — scegliendo di volta in volta Pearson, Spearman o Kendall a seconda della forma del legame. È il gradino indispensabile prima della domanda successiva, quella che chiunque analizzi dei dati finisce per porsi: data un’associazione, posso usare una variabile per prevedere l’altra, e tracciare la retta che le lega? Da qui in poi non misuriamo più soltanto la forza di un legame, ma lo modelliamo: è il territorio della regressione lineare, dove quel coefficiente r che abbiamo appena conosciuto torna protagonista, questa volta al servizio della previsione.

Per approfondire

Per i fondamenti di correlazione e regressione spiegati con rigore ma senza inutili tecnicismi, il manuale italiano che tengo più volentieri a portata di mano è Statistica di Newbold, Carlson e Thorne: i capitoli sull’associazione tra variabili coprono Pearson, Spearman e le insidie dell’interpretazione causale con la chiarezza che serve a chi parte dalle applicazioni.

Le due domande hanno un nome preciso. La prima — quanto è grande? — è l’effect size. La seconda — con i dati che ho, avrei potuto vederlo, un effetto del genere? — è la potenza del test, e il ragionamento che ci porta a rispondere si chiama power analysis. Le esaminiamo una alla volta, come sempre con un esempio sotto mano.

Significativo non vuol dire grande

Partiamo da una situazione che a chi gestisce test online capita più spesso di quanto vorrebbe. Mettiamo di aver provato due title tag su una pagina ad altissimo traffico, e di aver raccolto un milione di sessioni per variante. Il CTR della versione A è il 3,00%, quello della versione B il 3,05%: cinque centesimi di punto di differenza. Verifichiamo in R se lo scarto è statisticamente significativo:

# un milione di sessioni per variante, CTR 3,00% contro 3,05%
prop.test(c(30000, 30500), c(1000000, 1000000), correct = FALSE)$p.value
# [1] 0.03899

Il p-value è 0,039, sotto la soglia dello 0,05. Da manuale, dovremmo brindare: la differenza è “significativa”. Ma fermiamoci un attimo. Stiamo davvero per riscrivere i title di tutto il sito per guadagnare cinque centesimi di punto di CTR? Quel risultato significativo nasconde un effetto di dimensioni ridicole, reso rilevabile soltanto dalla mole spropositata di dati.

Questo è il punto da cui non si torna indietro: con un campione abbastanza grande, qualsiasi differenza diventa statisticamente significativa, anche la più trascurabile. Il p-value misura quanto siamo sicuri che l’effetto non sia zero; non misura quanto l’effetto sia grande. Sono due cose diverse, e confonderle è l’errore che porta a inseguire vittorie che sul fatturato non lasciano traccia. L’effect size esiste proprio per rimettere la grandezza al centro.

L’effect size: misurare il “quanto”

L’idea dell’effect size è semplice e, vista una volta, difficile da dimenticare: invece di chiederci solo se due gruppi differiscono, misuriamo di quanto differiscono, in una scala che non dipende dalla dimensione del campione. È la differenza tra dire “B è meglio di A” e dire “B è meglio di A di mezza deviazione standard”. La prima è una notizia; la seconda è un’informazione su cui si può decidere.

Di misure di effect size ne esistono diverse, ciascuna tagliata su un tipo di confronto. Ne vediamo a fondo due — una per le medie, una per le proporzioni — perché coprono il grosso del lavoro quotidiano; delle altre daremo un cenno alla fine, con i rimandi giusti.

Cohen’s d: l’effetto fra due medie

Quando confrontiamo due medie — il tempo medio sulla pagina di due varianti, la durata media di sessione di due segmenti — la misura di riferimento è il Cohen’s d. L’intuizione è questa: prendiamo la differenza tra le due medie e la esprimiamo in “unità di deviazione standard”, così da renderla confrontabile tra contesti diversi. Una differenza di tre secondi pesa molto se le sessioni durano tutte attorno a quel valore, pochissimo se variano di minuti.

In formula, il Cohen’s d è il rapporto tra la differenza delle medie e la deviazione standard combinata dei due gruppi:

dove x̄_A e x̄_B sono le medie dei due gruppi e s_p è la deviazione standard pooled, cioè una media ponderata delle due deviazioni standard, che mette insieme la variabilità interna di entrambi i gruppi:

con n_A, n_B le numerosità e s_A, s_B le deviazioni standard dei due gruppi. Il denominatore non è altro che il modo corretto di fondere due variabilità in una sola misura di riferimento.

Facciamo un esempio. Abbiamo misurato la durata di sessione (in secondi) su due versioni di una pagina, dodici sessioni per versione. Calcolo il Cohen’s d in R appoggiandomi al pacchetto effsize, che fa il conto e ci restituisce anche l’etichetta qualitativa:

A <- c(48, 55, 52, 60, 46, 58, 51, 57, 49, 54, 53, 50)  # versione A
B <- c(50, 58, 52, 62, 49, 57, 60, 53, 61, 51, 59, 54)  # versione B

library(effsize)
cohen.d(B, A)

# Cohen's d
#
# d estimate: 0.6254922 (medium)
# 95 percent confidence interval:
#      lower      upper
# -0.2416187  1.4926030

Il d stimato è 0,63, che effsize classifica come effetto medio. Le soglie convenzionali, proposte da Jacob Cohen, sono 0,2 per un effetto piccolo, 0,5 per uno medio, 0,8 per uno grande — ma vanno prese per quello che sono: convenzioni utili a orientarsi, non leggi di natura. Lo stesso Cohen raccomandava di interpretarle alla luce del proprio campo, non di applicarle a scatola chiusa. Nella pratica quotidiana della SEO, un d di 0,63 sul tempo di sessione è un cambiamento che ha senso prendere sul serio.

C’è però un dettaglio che vale tutto il resto dell’articolo, ed è già visibile qui sopra: l’intervallo di confidenza del d va da −0,24 a 1,49. Attraversa lo zero. In altri termini, con dodici sole sessioni per gruppo, l’effetto stimato è medio, ma i dati non bastano a escludere che quello vero sia nullo. E infatti, se sottoponiamo gli stessi numeri a un t-test, troviamo un p-value tutt’altro che rassicurante:

t.test(B, A)
#
# 	Welch Two Sample t-test
# t = 1.5321, df = 21.9, p-value = 0.1398

Un effetto medio che il test dichiara non significativo. Non è una contraddizione: è esattamente il fenomeno che la potenza di un test serve a spiegare. Teniamolo a mente, ci torniamo tra poco.

L’effect size per le proporzioni (CTR e conversioni)

Il tempo sulla pagina è una media, ma il pane quotidiano di chi fa SEO sono le proporzioni: CTR, tasso di conversione, percentuale di rimbalzo. Qui il Cohen’s d non si applica direttamente, e la misura naturale di effect size è il Cohen’s h, costruito apposta per la differenza tra due proporzioni.

Il dettaglio tecnico che lo rende affidabile è una trasformazione — l’arcoseno della radice della proporzione — che serve a stabilizzare la variabilità (in una proporzione, la variabilità dipende dal valore stesso, ed è massima attorno al 50%). La formula è:

dove p₁ e p₂ sono le due proporzioni a confronto. Non serve calcolarla a mano: ce la fornisce la funzione ES.h del pacchetto pwr. Ma prima di vederla all’opera conviene introdurre l’altra metà del discorso, perché è lì che il Cohen’s h dà il meglio di sé.

Prima però chiudiamo il capitolo effect size con un cenno onesto alle altre misure. Quando i gruppi a confronto sono più di due — il classico scenario dell’ANOVA — la misura tipica è l’eta quadro (η²), che dice quale frazione della variabilità totale è spiegata dal fattore che stiamo studiando; ne abbiamo gettato le basi parlando di analisi della varianza. Quando invece il risultato è binario — converte / non converte — l’effect size si esprime spesso come odds ratio, il rapporto tra le quote di successo, lo stesso oggetto che governa la regressione logistica. Strumenti diversi per domande diverse, ma l’idea di fondo non cambia: mettere un numero sulla grandezza, non solo sull’esistenza.

La potenza di un test: avremmo potuto vederlo?

Torniamo al nostro effetto medio dichiarato non significativo. Come è possibile che un d di 0,63 produca un p-value di 0,14? La risposta sta in un concetto che chiude il cerchio dell’inferenza: la potenza di un test.

Quando facciamo un test delle ipotesi rischiamo due tipi di errore. Il primo, l’errore di tipo I, è gridare a un effetto che non c’è: lo teniamo sotto controllo con la soglia α (di solito 0,05). Il secondo, l’errore di tipo II, è il suo opposto ed è molto più subdolo: non vedere un effetto che invece c’è. La probabilità di commetterlo si indica con β, e la potenza è il suo complemento:

Detto in termini più chiari e diretti, la potenza è la probabilità di accorgersi di un effetto reale quando c’è davvero. Una potenza di 0,80 — lo standard a cui si punta — significa che, se l’effetto esiste delle dimensioni ipotizzate, il nostro test lo individua quattro volte su cinque.

Il punto cruciale è che potenza, soglia α, effect size e dimensione del campione non sono quattro manopole indipendenti: sono legate da un vincolo. Fissati tre di questi valori, il quarto è determinato. Questa è l’intera idea della power analysis, ed è ciò che la rende così utile: a seconda di quale incognita lasciamo libera, risponde a due domande operative diverse.

Ed ecco perché il nostro effetto medio è rimasto invisibile. Con dodici sessioni per gruppo la potenza del test era bassissima: il test era, semplicemente, cieco. Un risultato non significativo, in queste condizioni, non dice “l’effetto non c’è”; dice “non avevo occhi abbastanza buoni per vederlo”. Confondere le due cose è uno degli errori più costosi che si possano fare leggendo un A/B test.

Power analysis in R: quanti dati servono

La prima domanda che la power analysis sa risolvere è quella che ogni test dovrebbe affrontare prima di partire: quanti dati mi servono? Riprendiamo il nostro effetto medio. Se volessimo progettare un test capace di rilevare un d di 0,63 con potenza 0,80 e soglia 0,05, calcolo in R con il pacchetto pwr:

library(pwr)
pwr.t.test(d = 0.63, sig.level = 0.05, power = 0.80, type = "two.sample")
#
#      Two-sample t test power calculation
#               n = 40.53396
#               d = 0.63
#       sig.level = 0.05
#           power = 0.8
#     alternative = two.sided
# NOTE: n is number in *each* group

Servirebbero circa 41 sessioni per gruppo, non dodici. Ecco perché il nostro test era muto: stava cercando un effetto medio con un terzo dei dati necessari. La power analysis, fatta a monte, ci avrebbe risparmiato un test inconcludente — ed è esattamente il ragionamento che alimenta il calcolatore di sample size: dimensione del campione e potenza sono le due facce della stessa medaglia.

La seconda domanda è speculare e si pone a posteriori, quando il test l’abbiamo già fatto: con i dati che avevo, quanta potenza avevo davvero? Lo vediamo meglio su un caso concreto.

Un caso pratico: l’A/B test che “non ha funzionato”

Mettiamo di aver testato due landing page. La A ha convertito 60 visitatori su 1.500 (4,0%), la B ne ha convertiti 78 su 1.500 (5,2%). A occhio la B sembra nettamente migliore — un punto e due decimi di conversione in più non è poco. Verifichiamo in R se la differenza regge:

prop.test(c(60, 78), c(1500, 1500), correct = FALSE)
#
# 	2-sample test for equality of proportions
# X-squared = 2.461, df = 1, p-value = 0.1167

Il p-value è 0,117: sopra lo 0,05. Verdetto da manuale: differenza non significativa, test fallito, si archivia. Ma noi adesso sappiamo di non fermarci qui. Calcoliamo la potenza che quel test aveva davvero, partendo dall’effect size osservato:

library(pwr)
h <- ES.h(0.052, 0.040)   # Cohen's h tra le due proporzioni
h
# [1] 0.0574024

pwr.2p.test(h = h, n = 1500, sig.level = 0.05)
#               power = 0.3492384

La potenza era 0,35. In altri termini: anche se la B fosse stata davvero migliore di quel tanto, avevamo poco più di una probabilità su tre di accorgercene. Il test non ha “dimostrato che le due pagine sono uguali”: era semplicemente troppo debole per pronunciarsi. E quanti dati sarebbero serviti per arrivare a una potenza decente?

pwr.2p.test(h = h, power = 0.80, sig.level = 0.05)
#               n = 4764.053

Quasi 4.800 visitatori per variante, contro i 1.500 che avevamo. La differenza tra un test che “non ha funzionato” e un test mai realmente in condizione di funzionare è tutta qui — e si vede solo se all’effect size affianchiamo la potenza. Attenzione dunque a derubricare un risultato non significativo a “nessun effetto”: quasi sempre stiamo solo guardando un test sottodimensionato.

Prova tu

Per fissare il meccanismo, ecco un esercizio con dati verosimili. Stiamo progettando un A/B test su un modulo di contatto. Il tasso di conversione attuale (baseline) è il 2,5%, e considereremmo un successo portarlo al 3,0%: mezzo punto di miglioramento. Vogliamo un test con potenza 0,80 e soglia 0,05.

Il compito: calcolare l’effect size con ES.h(0.030, 0.025), passarlo a pwr.2p.test fissando power = 0.80, e leggere quanti visitatori per variante servono. Poi, come controprova, calcolare la potenza che avremmo se ci fermassimo a 3.000 visitatori per variante con pwr.2p.test(h = ..., n = 3000, ...).

Per controllare i conti: l’effect size è h = 0,031, servono circa 16.759 visitatori per variante per avere una potenza dello 0,80, e con soli 3.000 la potenza crollerebbe a 0,22. La morale è quella che ormai conosciamo: più l’effetto che cerchiamo è piccolo, più dati servono per vederlo: dimezzare la differenza minima rilevabile non raddoppia il campione necessario, lo quadruplica.

Effect size e potenza completano la triade che il p-value, da solo, lasciava monca: non più soltanto l’effetto esiste?, ma anche quanto è grande? e avrei potuto vederlo?. Sono le tre domande che trasformano un test da rito propiziatorio in uno strumento di decisione. E tutte e tre, a ben guardare, dipendono da una scelta che viene prima del test: quanti dati raccogliere, e come. È il terreno del disegno sperimentale e del campionamento — il punto in cui la statistica smette di limitarsi a giudicare i numeri che le mettiamo davanti e comincia a dirci quali numeri andare a cercare.

Per approfondire

Sull’uso rigoroso di effect size, potenza e dimensionamento nel contesto degli esperimenti online, il riferimento più completo resta Trustworthy Online Controlled Experiments di Ron Kohavi, Diane Tang e Ya Xu: i capitoli su come dimensionare un test e interpretarne i risultati valgono da soli l’acquisto. Per i fondamenti statistici alle spalle di questi concetti — errori di tipo I e II, potenza, inferenza — un buon manuale italiano di riferimento è Statistica di Newbold, Carlson e Thorne.