La mia battaglia contro le query Not Provided

Quando ho iniziato la mia ricerca per tentare di risalire alle reali query degli accessi “Not Provided” davo già per scontato che non sarei riuscito nell’impresa di risalire ai testi digitati dagli utenti.

Beninteso, non si trattava di mancanza di fiducia ma della normale conseguenza di un’osservazione: i siti su cui approdano gli utenti delle SERP non ricevono apparentemente alcuna informazione sulla query digitata.

E quindi rassegnazione e morta lì, giusto? Sbagliato. E vi spiego il perché…

Informazioni necessarie

Per comprendere i vaneggiamenti che seguiranno, è necessario che voi abbiate dimestichezza con i seguenti concetti e che possediate alcune informazioni minime:

  • dovete sapere in che cosa consiste in fenomeno delle query Not Provided;
  • dovreste conoscerlo abbastanza da sapere che, a differenza di quanto molti credono, esso non è la conseguenza dell’uso di SSL/HTTPS da parte di Google;
  • dovreste conoscere il meccanismo di redirezione usato da Google per veicolare l’utente verso il sito di destinazione.

Un articolo di dettaglio su quanto realmente avviene riguardo il passaggio di informazioni è questo riassunto di Giacomo Pelagatti. Oggi le cose sono un po’ più complesse rispetto a quando l’analisi è stata svolta (sopratutto in funzione di questa novità) ma lo specchietto realizzato da Giacomo mantiene la propria validità per un’alta percentuale dei contesti.

Per ultimo, dovete sopratutto sapere che le analisi che ho svolto hanno l’obiettivo di comprendere se è possibile ottenere sistematicamente le esatte query digitate dall’utente, cosa molto diversa dalla varie tecniche che esistono per “fare un po’ più luce” sugli accessi da query Not Provided in base alle informazioni registrate dalle piattaforme di web analytics.

Una sfida stimolante

Il fenomeno delle query Not Provided è stato oggetto di numerose discussioni sul web, non solo tra coloro che ne hanno sofferto l’introduzione (nessun doppio senso) ma anche tra coloro che fanno notare che i proprietari dei siti non hanno realmente il diritto di ricevere dal visitatore un’intestazione HTTP Referer, veicolo delle query quando l’utente clicca un risultato della ricerca di Google.

Fortunatamente per me e per gli obiettivi della mia ricerca, le discussioni politiche, sociali, di marketing e di privacy devono rimanere irrilevanti. Il mio unico riferimento è la documentazione RFC dei protocolli HTTP e HTTPS, che non impongono l’uso o l’assenza dell’intestazione Referer tranne in un paio di specifici casi, lasciando pertanto al buonsenso dell’ingovernabile far west internettiano il compito di decidere quando e come fare uso dei referer.

Se ho tentato di smontare il giocattolo delle query Not Provided non è stato perché io trovi la loro esistenza qualcosa di intrinsecamente sbagliato o da combattere ma perché si tratta di una sfida insolitamente ardua.

Brancolare nel buio è un’opportunità

In molti casi, un’attività di ricerca consiste nel definire con chiarezza gli obiettivi, un modo per misurare il loro eventuale raggiungimento e la definizione di un metodo attraverso il quale portare avanti la ricerca stessa.

Una torcia nel buioSi tratta di un procedimento molto logico e abbastanza lineare, perché viene definito sin dall’inizio sia il punto di arrivo desiderato sia la strada da percorrere per arrivarci.

Ci sono però delle condizioni in cui una strada può essere solo abbozzata e altre in cui non è nemmeno possibile delinearla, una di queste condizioni è una pesante mancanza di informazioni sull’oggetto o fenomeno che si intende studiare. A volte non esiste documentazione in merito né ricerche pubbliche da studiare per acquisire un minimo di cultura di base.

Cercare di risalire alle query Not Provided è stato un po’ come trovarsi in aperta campagna in una notte priva di luna, stelle e qualsiasi altra fonte di luce. Anche avendo in mano una torcia elettrica, non c’è modo di orientarsi, capire dove ci troviamo o dove si trova il punto da raggiungere. Tutto quello che possiamo fare è camminare verso una direzione arbitraria illuminando il terreno con la torcia, nella speranza di trovare qualche indizio per il passo successivo.

A volte si è stanchi di muoversi per una strada che non ha portato frutti per diverso tempo, quindi si cambia direzione nella speranza di avvicinarsi ad un’area più ricca di indizi e a volte si può anche decidere di fare un completo dietro-front.

A prima vista si potrebbe pensare che un’attività di ricerca simile non possa portare risultati qualitativamente paragonabili a quelli di una ricerca metodica e ben definita, tuttavia brancolare nel buio regala una grande opportunità: spesso sul terreno illuminato un po’ a caso è possibile trovare oggetti preziosi. Anche se tali oggetti non sono utili agli obiettivi di quella specifica ricerca, possiedono un valore intrinseco che potrà essere grandemente sfruttato in altre ricerche e occasioni.

La considerazione che mi viene più spontaneo fare è che sarebbe stato difficile trovati tali oggetti preziosi se non ci fosse stata necessità di brancolare nel buio in aperta campagna con una torcia elettrica.

La mia ricerca sulle query Not Provided è una testimonianza reale del fatto che andando per funghi si possono trovare pepite d’oro.

Il deserto delle URL di Google

Quando parlo di buio assoluto, di notte e in aperta campagna, mi riferisco al fatto che non esiste alcuna documentazione (ufficiale o meno) di come siano composte le URL usate da Google per i propri servizi di ricerca.

Sia le URL usate per le SERP sia quelle usate per le pagine di redirezione fanno uso di parametri dalle funzioni sconosciute. Tutti sanno che il parametro “q” nell’URL di una SERP ospita la query che ha generato la ricerca, ma di altri parametri ce ne sono a palate e nessuno sa a che cosa servano, tranne rare eccezioni.

Per farvi comprendere la complessità di un mapping completo dei parametri degli URL usati dai servizi di ricerca, basta dire che essi cambiano a seconda di molte impostazioni lato utente. I parametri che vengono usati per un utente loggato sono leggermente diversi da quelli usati per un utente non loggato. Alcune volte si tratta di reali parametri GET, altre volte vengono usati come fragment identifier (dopo il cancelletto, per intenderci) per come è tipico nelle tecnologie AJAX.

Come se tutto questo non fosse sufficiente, lo scoglio più grande è rappresentato dal fatto che il contenuto di molti parametri fa uso di sintassi criptiche e alfabeti proprietari che in alcuni contesti ho visto persino essere definiti dinamicamente via Javascript! Un delirio. Questo significa che l’unico modo per capirci qualcosa è quello di armarsi di santa pazienza e fare crittoanalisi su quantità corpose di dati.

In passato esisteva una maggiore similitudine tra i parametri usati negli URL e quelli della Search API di Google, nella cui documentazione alcuni di essi venivano spiegati. Tale parziale aderenza è però scomparsa con il passaggio alla nuova versione della API.

La complessità di questo scenario ha sostanzialmente prodotto l’assoluta sconoscenza di che cavolo significhino i dati presenti negli URL usati da Google. Questo è il buio nel quale si brancola e al quale mi riferivo. In giro potrete trovare delle mappature parziali dei parametri, ma nulla di realmente significativo.

Ovviamente, non sapendo a che servono quei parametri, non sappiamo nemmeno se nascondono opportunità e se potrebbero esserci utili per qualcosa, a cominciare dalla web analytics. Insomma, qualcuno prima o poi doveva pur tentare di far luce.

Analisi dei parametri degli URL verso l’esterno

Il grande stravolgimento dei parametri usati da Google nelle URL che puntano ai siti esterni o che redirigono a siti esterni è avvenuto nel 2009, a seguito dell’introduzione di Google Caffeine: a pochi e semplici parametri dalla funzione di facile comprensione sono stati aggiunti molti nuovi parametri del tutto criptici.

Questi URL e i parametri che essi contengono corrispondono a quanto i browser degli utenti inseriscono nelle intestazioni HTTP Referer in fase di richiesta della risorsa cliccata sulla SERP.

Questi URL e questi parametri sono dunque tutto ciò che i sistemi di analytics possiedono per comprendere da dove l’utente proviene. Se in questi URL Google decide di non specificare la query della ricerca, il sito di destinazione si attacca al tram e classifica quell’accesso come query “Not Provided” (cioè, letteralmente, non fornita da Google).

Vi elecherò i parametri che, più di altri, contengono informazioni che potrebbe essere utile approfondire per obiettivi di web analysis.

ParametroSpiegazione
eiil valore di questo parametro cambia ad ogni query e potrebbe essere un identificativo della ricerca effettuata; non mi riferisco al testo cercato ma alla ricerca stessa. Non si può escludere che contenga informazioni sull’utente o sul momento in cui la ricerca è stata effettuata. La sua lunghezza è variabile e rimane il parametro più ostico da interpretare.
usgcontiene informazioni sull’URL di destinazione della redirezione, ovvero della risorsa su cui l’utente approderà. Potrebbe coincidere con un semplice identificatore della risorsa di destinazione. Quando tale identificatore fa riferimento ad un URL diverso da quello verso il quale la redirezione intende inviare l’utente, il sistema se ne accorge e mostra all’utente una richiesta di conferma.
sig2è presente solo nel caso in cui l’utente sia loggato e per associazione col parametro “sig”, usato in passato in altri servizi di ricerca di Google, è molto probabile che contanga informazioni per l’identificazione dell’utente e forse utili alla sua autenticazione.
vedcontiene informazioni sul link cliccato. E’ una delle pepite d’oro trovate, come spiegato in seguito.

Le strade finora battute

Di fronte a URL nel referrer che non contengono il testo della query, ho iniziato ad pensare a tutte le possibili tecniche per cercare di risalire all’informazione in maniera più o meno diretta.

Querystring codificato

Sono innanzitutto partito cercando di capire se il testo della query, oltre che essere esplicitato nel parametro “q”, poteva per caso essere stato codificato in un altro parametro dell’URL.

Lucchetto chiusoLa ricerca ha un senso, perché non può essere dato per scontato che il parametro “q” sia l’unico usato dal motore di ricerca per identificare il testo della query. Del resto, l’URL di destinazione delle redirezioni vengono identificati attraverso due parametri distinti e tale modello, che ha senso dal punto di vista informatico, potrebbe essere stato adottato anche per i testi delle query.

Il risultato dell’analisi ha determinato che non esiste un parametro degli URL, oltre a “q”, che fa riferimento al solo testo cercato. E’ invece probabile che esista un identificatore della query stessa, a cui il testo cercato può essere associato internamente da Google. Il candidato migliore è il parametro “ei”.

Giusto per chiarezza: spero che sia ben chiara la differenza tra testo cercato e query. La query è l’attività di interrogazione fatta dall’utente a Google ed ha come risultato che il motore effettua una ricerca all’interno dei propri archivi.

Fingerprint del referrer

La seconda attività di ricerca svolta è stata quella di prendere tutti i parametri del referer e comprendere se, assieme, potevano costituire un fingerprint da attribuire al testo della query ricevuto.

L’idea alla base è che se fosse possibile associare un fingerprint univoco al testo di una query conosciuta, allora sarebbe in teoria possibile per il sito di destinazione costruire un database di fingerprint associati ai testi delle query e, di fronte ad una query Not Provided, calcolarne il fingerprint e individuare nel database il testo della query ad esso associato.

Purtroppo i parametri presenti negli URL dei referrer non consentono questo approccio, perché ciascuno di essi possiede funzioni molto specifiche che non aiutano alla costruzione di un fingerprint.

L’eccezione a questa regola è il parametro “usg”, che è un identificatore della risorsa di destinazione, ma da solo non è sufficiente alla creazione di fingerprint associabili al testo delle query.

Servizi di Google per risalire alla query

Non si può escludere che esistano servizi che si fondino su parametri degli URL differenti da “q” per produrre accidentamente altri URL contenenti in chiaro il testo della query oppure maggiori informazioni o indizi su di esso.

Finora non sono stato in grado di individuare servizi di questo genere ma non demordo, perché in passato e in altri contesti è stato possibile individuarne alcuni con caratteristiche simili.

Le strade da battere

Oltre alle opportunità di analisi già indicate nella precedente sezione, un’ultima strada da battere potrebbe essere quella di approfondire il ruolo ed il funzionamento del parametro “ei”, al momento il più criptico ma anche quello più probabilmente correlabile ad un identificatore della query fatta.

Uscendo per un attimo dal contesto della ricerca di una tecnica per risalire alla query, esistono inoltre altre strade per ridurre nel complesso la quantità di query Not Provided, per esempio ripristinare la query negli URL delle SERP attraverso plugin dei browser. Si tratta tuttavia di un percorso del tutto diverso dall’approccio intrapreso finora e quindi al momento non vi ho dedicato tempo.

La considerazione generale non è diversa rispetto a quella che facevo prima di iniziare la mia ricerca: le speranze sono pressoché nulle.

E se anche fosse possibile?

Una considerazione che vale la pena di fare è che se anche riuscissi a trovare un metodo, la sua divulgazione implicherebbe per certo una reazione da parte di Google, come è avvenuto in passato in occasioni di reverse engineering simili.

Un’occasione la ricordo bene: quando resero impossibile elencare le risorse di un sito in ordine di PageRank, grazie ad un hack che avevo individuato. Fu sufficiente che l’informazione si diffondesse un minimo sul forum di Webmasterworld per indurre Google, che seguiva il forum anche attraverso il famigerato Googleguy (chi se lo ricorda?), a prendere provvedimenti immediati e definitivi.

A questo punto è inevitabile domandarsi che senso ha perseguire un obiettivo che si sa essere pressoché impossibile e di breve durata quando eventualmente raggiunto.

La risposta la fornisco con l’ultima sezione di questo articolo.

Le pepite d’oro

C’è generalmente poca comprensione di quanto si possa ottenere con le attività di ricerca e di reverse engineering.

Per essere chiari, non mi è mai capitato in dieci anni di analisi di Google un solo caso in cui un’analisi che non abbia dato frutti concreti e utilizzabili nel lavoro quotidiano. Mai, persino in quei casi in cui non era stato possibile trovare la specifica informazione che l’analisi auspicava di ottenere.

Come spiegato all’inizio dell’articolo, l’opportunità stessa di poter smanettare in alcuni contesti può consentire di trovare delle vere e proprie miniere d’oro.

Mi sento di elencarne almeno due, ottenute brancolando nel buio in cerca di una destinazione utopica.

Pepita d'oroLa prima pepita è rappresentata da una ben maggiore comprensione della funzione dei parametri degli URL usati da Google per le redirezioni o per i link che puntano alle risorse esterne. Queste informazioni sono quanto Google è disposto ad offrire ai siti linkati sulle SERP e definendo con chiarezza la loro funzione e l’interpretazione dei loro contenuti è possibile per le piattaforme di analytics classificare e valutare meglio l’utente che approda sul sito web.

Ma la vera miniera d’oro a cielo aperto è costituita dal parametro “ved” e dalle informazioni che contiene.

Attraverso il parametro “ved” è possibile ottenere un dettaglio altissimo sul link cliccato dall’utente sulla SERP:

  • E’ possibile conoscere l’indice dal quale la risorsa linkata è stato estratto (blog? news? video? semplice pagina web?). Google Universal Search viene praticamente sviscerato e l’aspetto più importante è che è possibile comprendere con massima chiarezza quali indici di Google stanno portando maggiore traffico, arrivando persino a calcolare un “ROI” per indice. Per le testate registrate in Google News, i cui contenuti sono indicizzati sia su Google News sia sull’indice web generico, questa possibilità di dettaglio di analisi ha un valore altissimo.
  • E’ possibile conoscere la posizione del link cliccato con un livello di dettaglio ben maggiore di quello fornito dal parametro “cd”, tipicamente usato dalle piattaforme di analytics proprio per determinare la posizione della risorsa sulla SERP.
  • E’ possibile conoscere la tipologia di link, per esempio se testuale o se immagine.

Una comprensione piena dei contenuti del parametro “ved” è già in corso e mi son posto l’obiettivo di definire con chiarezza la sintassi che viene usata per codificare le informazioni, peraltro usata anche in altri contesti da Google.

Insomma, come al solito una ciliegia tira l’altra… :)

P.S.
Pensavo che sarebbe interessante parlare di argomenti simili in qualche evento. Giusto per dire.

24 Responses to La mia battaglia contro le query Not Provided

  1. Marco scrive il 19 April 2012 at 09:36

    Ciao Enrico,
    volevo chiederti, in base al prospetto fatto da Giacomo cosa è variato dopo la nuova dichiarazione di google?

    Un articolo di dettaglio su quanto realmente avviene riguardo il passaggio di informazioni è questo riassunto di Giacomo Pelagatti. Oggi le cose sono un po’ più complesse rispetto a quando l’analisi è stata svolta (sopratutto in funzione di questa novità) ma lo specchietto realizzato da Giacomo mantiene la propria validità per un’alta percentuale dei contesti.

    Grazie

    • LowLevel scrive il 19 April 2012 at 10:20

      Ciao Marco,

      non se se le cose sono già cambiate, perché non ho fatto un test. Tuttavia è certo che cambieranno presto secondo quanto prevede il “protocollo” del meta tag referrer, del quale puoi leggere qua il funzionamento.

  2. Pasquale Gangemi scrive il 19 April 2012 at 09:57

    Eccezionale, come sempre…

    • LowLevel scrive il 19 April 2012 at 10:21

      Troppo buono, Pasquale. :)

  3. andrea "gareth jax" scarpetta scrive il 19 April 2012 at 10:11

    Domanda: quando si preme il tasto destro su un risultato nella serp, scatta un meccanismo che trasforma la url “in chiaro”, nella query su google codificata. Secondo te si riesce a debuggare quello che succede in quel momento ? (ci proverei anche con firebug, ma ho poco tempo)

    • LowLevel scrive il 19 April 2012 at 10:23

      Ciao Andrea.
      Sì, sostanzialmente viene sovrascritto il contenuto inserendogli l’URL di redirezione, che contiene tra le altre cose i parametri indicati nell’articolo. Ecco un dettagliato articolo di Simone Rinzivillo sull’argomento.

      “ei” viene popolato con valori differenti ad ogni nuova query, in quanto è proprio un identificatore della query.

  4. andrea "gareth jax" scarpetta scrive il 19 April 2012 at 10:13

    Tra l’altro notavo che la stessa query, da sloggati e da loggati, produce due valori differenti

  5. Simone Rinzivillo scrive il 19 April 2012 at 10:19

    @andrea ho approfondito la cosa lo scorso Giugno, leggi qui: http://www.simonerinzivillo.it/blog/motori_di_ricerca/google_serp_click_tracking_com/

  6. andrea "gareth jax" scarpetta scrive il 19 April 2012 at 10:19

    Dio santo il parametro EI cambia anche se mi loggo con un account 😀

    E questa è la query in modalità mobile simulata con una estensione di firefox : http://www.google.it/url?sa=t&source=web&cd=2&ved=0CEYQFjAB&url=http%3A%2F%2Fwww.genertel.it%2F&ei=ocmPT_HpDYimhAeGqZyoBA&usg=AFQjCNEvZSdwpNhjVfLPSlG2nyb0qgkb-A&sig2=x0JKVzwI6wG5KFFRoDNZzg

    E’ meglio della settimana enigmistica.

  7. Simone Rinzivillo scrive il 19 April 2012 at 10:40

    il parametro EI “rappresetenta un ID univoco della ricerca dell’utente e cambia ad
    ogni sua query. Una specie di session ID, ma con un ciclo di vita molto
    più breve e legato ai momenti di ricerca della persona”

    in pratica cambia ad ogni tua query

  8. Marco Cilia scrive il 19 April 2012 at 11:11

    la risposta a “a cosa servirebbe riuscirci” ce l’ho: una montagna di soldi. E forse senza nemmeno che Google reagisca :)

    • LowLevel scrive il 19 April 2012 at 11:14

      @Marco: se tenessi per me l’informazione, allora sì, potrebbe essere monetizzabile. :)

  9. Marco Cilia scrive il 19 April 2012 at 13:19

    io pensavo più a un servizio, codice criptato, sulla cloud. Ti mando il referrer, mi restituisci quel che mi serve :)

  10. Luca Bove scrive il 19 April 2012 at 16:12

    Nel parametro VED riesci a vedere anche i risultati della place search (delle mappe)?

    Finora questo monitoraggio era impossibile. E se fosse possibile sarebbe un’altra grossa pepita…

    • LowLevel scrive il 19 April 2012 at 17:08

      @Luca: sì, vale per qualsiasi tipo di risorsa. Il “ved” contiene sempre l’identificatore della tipologia di indice dal quale la risorsa è stata pescata, a prescindere da quale indice sia.

  11. Marco cilia scrive il 19 April 2012 at 17:15

    Web-service! Web-service! Web-service! 😀

    • LowLevel scrive il 19 April 2012 at 18:02

      @Marco: non sarebbe una decisione oculata. Queste informazioni sono destinate a diventare pubbliche, prima o poi. Un business basato sulla loro segregazione avrebbe vita breve. :)

  12. Luca Bove scrive il 19 April 2012 at 17:19

    Ottimo…
    mi metto a studiarla meglio allora, davvero interessante.

    E grazie per le informazioni, veramente utili!

  13. Marco scrive il 24 April 2012 at 13:42

    Ciao Enrico.
    Come al solito ..Grazie :)
    Stavo notando alcune query, ad ipotesi questa:
    https://www.google.it/#hl=it&output=search&sclient=psy-ab&q=casa+udine&oq=casa+udine&aq=f&aqi=&aql=&gs_nf=1&gs_l=hp.3…10615.12638.0.13293.10.9.0.0.0.0.1330.2114.6-1j1.2.0.yHvYSh8afsY&pbx=1&bav=on.2,or.r_gc.r_pw.r_qf.,cf.osb&fp=a2c838adb192cf42

    Da loggato…
    Perdonami ma allora non ho capito il discorso: non vedo ad esempio nessun parametro da te citato nella stringa.

    Dove sbaglio?

    • LowLevel scrive il 1 May 2012 at 22:24

      Ciao Marco, gli URL in cui appaiono i parametri discussi nell’articolo non sono quelli delle SERP ma quelli usati dalla “pagina” che fa la redirezione verso il sito di destinazione. :)

  14. seowebmaster scrive il 16 June 2012 at 12:47

    molto interessate… premesso che io non sono un programmatore, che uso programmi WYSIWYG per fare siti dinamici ad esempio in aspx, quindi a livello di query ho molto da imparare.

    sarebbe interessante scoprire quanti di questi parametri agiscono a livello di client (tramite javascript e cookies) e quanti lato server! cioe’ disabilitando javascript oppure i cookies, che cosa cambia ??? almeno nella versione http non quella SSL ha bisogno di aprire una sessione nel browser per funzionare.

    Perche’ nelle SERP si notano dei cambiamenti nei risultati, se loggati o meno, se con navigazione anonima o senza, etc..

    ma nella pagina o URL che fa’ redirect cosa cambia ???

    bisogna far luce in questa direzione, secondo me.

Lascia un commento

More in Analytics
Cagate SEO virali: web analysis di un fenomeno sociale

Mi sono reso conto con un po' di stupore di non aver ancora affrontato su questo blog il tema della...

Close