Query anonimizzate in Search Console: perché i dati non tornano

I numeri di Search Console non tornano perché il report non mostra tutto ciò che conta nei totali. Le query anonimizzate vengono incluse nei clic e nelle impressioni complessive, ma le loro parole non compaiono mai nella tabella: per questo la somma delle righe per query è quasi sempre inferiore al totale in alto, e diventa ancora più bassa quando si incrociano più dimensioni. A questo si sommano i limiti sul numero di righe esportabili e il modo in cui i dati vengono aggregati per sito o per pagina.

Se ti sei mai chiesto perché il totale per pagina non coincide con quello per query, o perché un'esportazione non somma al numero visto a schermo, non stai sbagliando filtro e non c'è un bug da segnalare. Sono regole di progettazione, e conoscerle serve a decidere quali confronti sono legittimi, quali vanno evitati e come spiegare lo scarto a un cliente o a un responsabile che vede due cifre diverse per la stessa cosa.

Che cosa sono le query anonimizzate

Una query anonimizzata è una ricerca che Google non riporta per esteso nel rapporto sul rendimento, per ragioni di privacy. La documentazione ufficiale la descrive come una query così rara da non essere stata digitata da più di un numero ristretto di utenti in un arco di alcuni mesi. Se una ricerca è troppo specifica, per esempio contiene un nome e cognome, un numero di ordine, un indirizzo o una frase molto personale, potrebbe permettere di risalire a chi l'ha scritta. Google sceglie allora di non mostrarla.

La parte che sorprende chi la incontra per la prima volta è che la query sparisce dall'elenco, ma non dai conteggi. I clic e le impressioni che ha generato restano nel totale del grafico e nei dati a livello di sito. Semplicemente non hanno un'etichetta testuale. Nel report esistono quindi due piani: quello dei totali, che è completo, e quello delle righe per query, che è una selezione.

Google non pubblica l'elenco esatto delle soglie né dice quante query rientrino nella categoria per un dato sito, e non lo farò nemmeno io: qualsiasi percentuale generica sarebbe inventata. Quello che si può dire con sicurezza è il meccanismo. Più il sito riceve ricerche lunghe, rare e molto specifiche, più cresce la quota di traffico che non ha una query leggibile. Un sito di ricette con poche ricerche generiche molto ripetute avrà uno scarto diverso da un sito di assistenza tecnica, dove gli utenti incollano messaggi di errore o codici prodotto.

Perché il totale in alto non coincide con la somma delle righe

Apri il rapporto Risultati della ricerca, guarda i clic totali in alto e poi scorri la tabella per query. Se sommi le righe, ottieni meno. La differenza è, almeno in gran parte, il traffico delle query anonimizzate. Non è una perdita di dati: è una parte del totale che la tabella per scelta non dettaglia.

Il confronto si può verificare da soli in pochi passaggi. Imposta un intervallo di date fisso, annota i clic totali, poi aggiungi un filtro sulla query con un'espressione che includa tutto, per esempio una regex che accetta qualsiasi stringa. Il totale cambia, e si abbassa. Il motivo è che applicare un filtro sulla query esclude automaticamente le righe senza query, cioè quelle anonimizzate. La differenza tra i due valori è la misura pratica del traffico anonimizzato per quel periodo, per quel sito e per quel tipo di ricerca.

Attenzione a un errore di interpretazione frequente: quella differenza non indica query di bassa qualità né traffico inutile. Nella coda lunga, le ricerche molto specifiche sono spesso quelle con intento più chiaro. Sono invisibili come testo, non come valore.

• Totale in alto: include tutto, anche le query anonimizzate.
• Tabella per query: mostra solo le query con etichetta leggibile.
• Qualsiasi filtro o dimensione sulla query toglie dal conto le righe anonimizzate.
• La quota anonimizzata varia da sito a sito e da periodo a periodo: va misurata, non assunta.

Perché il totale per pagina non coincide con quello per query

Il secondo scarto nasce dal modo in cui Search Console aggrega i dati. Quando guardi il sito nel suo insieme, le impressioni e i clic sono contati a livello di proprietà. Quando passi alla dimensione Pagine, i conteggi sono associati all'URL che compariva nel risultato. Le due viste non sono progettate per sommarsi in modo identico, perché una stessa pagina può comparire più volte nello stesso risultato oppure un sito può avere più URL nella stessa ricerca.

Un esempio. Una ricerca genera una pagina dei risultati in cui due tue URL sono visibili. A livello di proprietà conta come un'impressione per il sito nel suo complesso. A livello di pagina, invece, ciascuna delle due URL riceve la propria impressione. Sommando le pagine ottieni più impressioni del totale del sito. Lo scarto va quindi in direzione opposta rispetto a quello delle query anonimizzate, e in un singolo confronto i due effetti possono compensarsi in parte, nascondendo entrambi.

Per questo il confronto corretto non è mai "somma delle pagine uguale totale". Il totale del sito è la cifra di riferimento per il volume complessivo. I dati per pagina servono per confrontare le pagine tra loro e per vedere l'andamento di una singola URL, non per ricostruire il totale per somma. Lo stesso vale per la posizione media: è una media pesata sulle impressioni e la sua definizione cambia a seconda della dimensione che stai osservando, quindi non si può mediare a mano tra le righe.

• Totale del sito: riferimento per il volume complessivo.
• Dati per pagina: utili per confronti relativi e per l'andamento di una URL.
• Posizione media: non sommabile né mediabile a mano tra righe diverse.
• Se una stessa ricerca mostra più tue URL, le impressioni per pagina possono superare il totale del sito.

Incrociare dimensioni: il totale scende a ogni filtro

C'è un effetto collaterale che molti scoprono solo quando provano a costruire un report. Ogni dimensione in più richiede un dettaglio maggiore, e più il dettaglio è fine, più righe finiscono sotto la soglia di privacy. Il totale per sola pagina è quindi più alto del totale ottenuto guardando pagina più query insieme, perché nella seconda vista le combinazioni rare vengono omesse.

In pratica, se estrai le coppie pagina e query e le sommi, ottieni meno clic di quelli che la stessa pagina mostra da sola. Più incroci (paese, dispositivo, aspetto nella ricerca), più la somma si allontana dal totale. Non è un difetto del tuo filtro: è la conseguenza del fatto che le combinazioni troppo rare non vengono riportate.

La regola operativa è semplice. Scegli la dimensione che serve davvero alla domanda che stai facendo e fermati lì. Se ti interessa quanto traffico porta una pagina, usa la vista per pagina. Se ti interessa quali ricerche portano traffico a un gruppo di pagine, accetta che la vista per query sia un campione parziale, ma abbastanza rappresentativo per individuare i temi principali.

I limiti di righe: interfaccia, esportazione e API

Il terzo motivo per cui i dati sembrano incompleti non riguarda la privacy ma i limiti tecnici. L'interfaccia mostra un numero massimo di righe per tabella, e l'esportazione dal report si ferma a un tetto di righe molto più basso di quanto molti si aspettino per un sito grande. Se il tuo sito ha decine di migliaia di pagine o un'enorme coda lunga di query, l'esportazione dal pulsante di download è un estratto delle righe principali, non l'elenco completo.

L'API di Search Console permette di scaricare molte più righe con richieste paginate, ma anche lì esiste un limite giornaliero documentato per combinazione di proprietà, tipo di ricerca e giorno. Oltre quel limite, le righe meno rilevanti non vengono restituite. Conviene quindi verificare nella documentazione ufficiale il valore in vigore, perché può cambiare, e non darlo per scontato nei report.

L'esportazione in massa verso BigQuery, dove disponibile, ha una caratteristica utile per questo tema: tiene le righe anonimizzate contrassegnate da un campo dedicato, senza il testo della query ma con i relativi clic e impressioni. In questo modo il traffico anonimizzato diventa una riga esplicita nella tabella invece di una differenza da dedurre. Se devi costruire un report con totali che tornano, è la via più solida, purché l'esportazione sia stata attivata prima: non recupera il passato.

• Interfaccia: tabelle limitate nel numero di righe visibili.
• Esportazione da pulsante: estratto, non elenco completo per siti grandi.
• API: più righe, ma con un limite giornaliero per proprietà e tipo di ricerca.
• BigQuery: righe anonimizzate esplicite, ma solo dal momento dell'attivazione.

Altre cause di scarto da escludere prima di cercare un bug

Prima di concludere che i dati siano sbagliati, conviene passare in rassegna alcune cause più banali. La prima è il tipo di proprietà. Una proprietà di dominio raccoglie tutti i protocolli e i sottodomini, una proprietà con prefisso URL solo quelli indicati. Due proprietà sullo stesso sito possono mostrare totali diversi senza che nessuna abbia torto.

La seconda è il ritardo e la finestra dei dati. I giorni più recenti sono provvisori e possono essere aggiornati, e la cronologia è conservata per un periodo limitato, circa sedici mesi. Un confronto fra esportazioni fatte in giorni diversi può dare numeri leggermente diversi sullo stesso intervallo. La terza è il tipo di ricerca selezionato: web, immagini, video e notizie hanno conteggi separati, e un filtro dimenticato altera il totale.

Infine, il confronto con Google Analytics non va preteso identico. Search Console conta i clic sui risultati di ricerca, Analytics conta le sessioni avviate sul sito, dopo consenso ai cookie, blocchi del browser e rimbalzi prima del caricamento. Sono misure diverse di eventi diversi, e confrontarle richiede di accettare una tolleranza. Un clic può non diventare mai una sessione misurata, e una sessione organica può essere attribuita altrove.

Come tenere conto dello scarto nei report

Il modo più efficace di gestire i dati incompleti è renderli espliciti. Nel report scegli una cifra di riferimento per ogni domanda e dichiarala: il totale del sito per il volume, i dati per pagina per i confronti tra pagine, la tabella per query per capire i temi. Poi aggiungi una riga che mostra la quota non attribuita, calcolata come differenza tra totale e somma delle query visibili nello stesso periodo.

Una quota non attribuita che resta stabile nel tempo è una buona notizia per la leggibilità dei dati. Se invece cresce improvvisamente, vale la pena chiedersi se siano cambiati il tipo di contenuti, il mix di ricerche o l'intervallo considerato, prima di sospettare un problema tecnico. Una pagina nuova che intercetta molte ricerche molto specifiche, per esempio, sposta parte del traffico verso la coda lunga e quindi verso le query senza etichetta.

Un secondo accorgimento è lavorare sui rapporti, non sui valori assoluti. Il CTR di una query visibile è calcolato solo sulle impressioni di quella query, quindi resta affidabile per le righe che vedi. Confrontare periodi omogenei, con gli stessi filtri e la stessa finestra di date, riduce l'effetto dello scarto, perché la parte nascosta cambia in modo simile in entrambi i periodi.

Infine, conserva nel tempo ciò che ti serve. Poiché la cronologia in interfaccia è limitata, un archivio periodico delle esportazioni, fatto con lo stesso metodo ogni volta, evita di scoprire fra un anno che i confronti storici non sono ricostruibili. Annota sempre nel file il metodo usato: filtri, tipo di ricerca, proprietà e data di estrazione.

• Dichiara per ogni domanda quale vista è il riferimento.
• Mostra la quota non attribuita come differenza tra totale e somma delle query visibili.
• Confronta periodi omogenei con gli stessi filtri.
• Archivia le esportazioni con metodo e data annotati.

Errori frequenti quando si leggono questi dati

Il primo errore è trattare la somma delle righe per query come il traffico totale e concludere che una parte del traffico sia "scomparsa". Non è scomparsa: è nel totale, priva di etichetta. Il secondo è usare la somma delle pagine per rifare il totale del sito, dimenticando che una stessa ricerca può attribuire impressioni a più URL.

Il terzo è prendere l'esportazione da pulsante come elenco completo e costruirci sopra un'analisi di copertura delle parole chiave. Se il sito è grande, mancano righe per semplice limite di esportazione, e le query escluse non sono casuali: sono quelle con meno clic. Il quarto è confrontare Search Console con Analytics aspettandosi una cifra identica e poi cercare a lungo un errore di configurazione che non c'è.

Un ultimo punto riguarda la comunicazione. Quando un cliente o un responsabile vede due totali diversi, la reazione naturale è la sfiducia verso i dati. Una breve nota metodologica in apertura del report, che spiega le tre fonti di scarto e indica quale cifra fa da riferimento, costa poche righe e previene discussioni lunghe. Il rapporto migliora quando chi lo legge sa in anticipo che cosa aspettarsi da ciascuna vista.