Paolo Gironi - appunti di analisi dei dati,seo,statistica, retroinformatica

Clustering delle keyword: raggruppare migliaia di query con K-means e clustering gerarchico

Capita spesso che si esporti l’elenco delle keyword da Search Console o da un tool, e ci si ritrovi davanti a migliaia di righe. Tremila, diecimila query.
Leggerle una per una è impensabile, e raggrupparle a mano “a sentimento” è un lavoro lento, soggettivo e impossibile da rifare.
Eppure quel raggruppamento serve: vogliamo capire quali grandi famiglie di ricerche esistono nel nostro mercato, per decidere dove creare contenuti, quali pagine costruire, su cosa puntare.
La domanda è: possiamo lasciare che siano i dati a rivelarci i gruppi, invece di imporli noi? Trasformare quella montagna di query in pochi insiemi omogenei è il lavoro del clustering delle keyword.

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.

CTR atteso vs reale: trovare le pagine che rendono meno della loro posizione

Chi passa le giornate dentro Search Console conosce bene una situazione di questo tipo: una pagina è stabilmente in terza posizione, eppure i clic sono pochi, un CTR che parrebbe da fondo pagina.
La domanda che ci poniamo, di solito, è quella sbagliata: non «quanti clic prende?», ma quella più scomoda — «quanti clic dovrebbe prendere, stando dov’è?».
Finché non abbiamo un termine di paragone, un CTR del 3% non dice niente: per la posizione 8 sarebbe ottimo, per la 2 un piccolo disastro.
Quello che ci manca, per giudicare, è un CTR atteso: il valore con cui confrontare quello reale.

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.

Naive Bayes: classificare l’intento delle query con il teorema di Bayes

Nell’articolo sul multi-armed bandit abbiamo usato Bayes per decidere fra varianti: spostare il traffico verso quella che converte di più mentre il test è ancora in corso. Adesso facciamo un passo di lato, restando però nello stesso impianto di ragionamento: invece di scegliere fra opzioni, vogliamo classificare, cioè attaccare a ogni nuova osservazione l’etichetta più probabile date le sue caratteristiche.
Il caso concreto è uno che chiunque faccia SEO conosce bene: l’intento dietro una query di ricerca. Chi cerca “come fare un dolce” vuole imparare qualcosa; chi cerca “comprare scarpe online” è pronto a tirare fuori la carta di credito. Sono due mondi diversi, e servono contenuti diversi: una guida, un tutorial, un glossario per il primo; una scheda prodotto, un listino, una call to action ben visibile per il secondo. Sbagliare l’intento significa rispondere alla domanda giusta nel modo sbagliato.

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.

Multi-armed bandit: ottimizzare le varianti mentre il test è ancora in corso

Nell’articolo sull’A/B test bayesiano abbiamo confrontato due varianti a campione fisso: si raccolgono i dati per tutta la durata pianificata, si calcola la probabilità che B batta A, si decide. È un metodo solido, ma porta con sé un costo che di solito passa sotto silenzio.
Quel costo è il traffico che, per tutta la durata del test, continuiamo a mandare sulla variante peggiore. Se a metà esperimento B sta già stravincendo, ogni visitatore assegnato ad A è una conversione che probabilmente stiamo buttando via. Il test a campione fisso ci fa pagare l’informazione che raccogliamo: per sapere quale variante è migliore, dobbiamo continuare a mostrare anche quella che sospettiamo essere la peggiore.

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.

A/B test bayesiano: non solo “se” B è meglio di A, ma “di quanto”

Abbiamo avuto modo di esaminare, nell’articolo sull’A/B testing classico, come confrontare due varianti con il test per due proporzioni: calcoliamo una statistica, otteniamo un p-value, decidiamo se rifiutare l’ipotesi nulla. Funziona, ed è il pane quotidiano di chi fa esperimenti online. Ma c’è uno scarto sottile tra quello che il p-value ci dice e quello che vorremmo davvero sapere.
Il p-value risponde a una domanda contorta: “se A e B fossero identiche, quanto sarebbe improbabile osservare una differenza grande come questa?”. La domanda che ci interessa nella realtà operativa è un’altra, molto più diretta: qual è la probabilità che B sia meglio di A? E, subito dopo: di quanto è meglio, e quanto possiamo fidarci di quel “di quanto”?

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.