Arriva il meta referrer: conseguenze per la web analytics

Un paio di mesi fa Google annunciò una novità che sarebbe stata introdotta nel codice HTML delle SERP.

Con l’obiettivo di rendere la fruizione delle SERP più veloci per l’utente e di farlo approdare sulla pagina di destinazione il più velocemente possibile, Google ha deciso di implementare il meta tag referrer, una proposta del Web Hypertext Application Technology Working Group che rende possibile ai siti web di chiedere ai browser come gestire i contenuti dell’intestazione HTTP referer.

Questa soluzione, quando verrà applicata, cambierà nuovamente le carte in tavola per la web analytics.

Questo articolo mostra i primi tentativi di implementazione del meta tag referrer sulle SERP di Google, che conseguenze esso avrà per i siti sulle SERP e qualche problemino temporaneo che mi è capitato di osservare.

L’intestazione HTTP referer

Se siete un SEO dovreste sapere come funziona un browser e il protocollo HTTP e quindi potete saltare a piè pari questa sezione.

L’intestazione HTTP referer è una delle intestazioni HTTP che i browser possono inviare in fase di richiesta di una risorsa, per indicare al server che gestisce quella risorsa quale URL conteneva il link che puntava alla risorsa stessa.

Se la pagina all’URL http://ciccio.it/ contiene un link verso http://nonnapapera.it/ e l’utente clicca quel link, la richiesta che il browser farà della risorsa http://nonnapapera.it/ includerà tra le altre cose il seguente header HTTP:

Referer: http://ciccio.it/

In questo modo il browser dice a Nonna Papera che l’utente le è stato mandato da Ciccio. Su questa intestazione HTTP si basa l’intero meccanismo del tracciamento delle fonti da cui gli utenti arrivano ad un sito web. Non importa quale piattaforma di analytics si usi: tutte si basano su quell’intestazione per capire da dove l’utente è arrivato.

Questo dovrebbe farvi intendere che il tracciamento corretto delle fonti è di per sé un obiettivo effimero e, ve ne accorgerete col tempo, sempre meno alla portata dei siti di destinazione.

Sono i browser a decidere se e quando concedere un’intestazione HTTP referer alla risorsa richiesta e sopratutto quale URL scrivere dentro tale intestazione. In altre parole, tutte le piattaforme di web analytics si fidano di quanto i browser asseriscono e questa è anche la ragione per la quale esiste il referer spamming, ma qui divago…

Quando il browser chiede una risorsa specificando il referer, significa che l’utente proveniva da là. Quando il browser chiede una risorsa senza specificare il referer, può significare due cose:

• la visita è diretta (es: l’utente ha digitato l’url della risorsa nella barra degli indirizzi del browser)
• la visita non è diretta (ovvero l’utente proviene da un’altra risorsa) tuttavia il browser non ha specificato un’intestazione referer per qualche ragione

E’ lecito chiedersi per quale cavolo di ragione il browser non conceda al sito di destinazione uno straccio di intestazione HTTP referer quando l’utente proviene da un’altra risorsa.

Beh, una causa può essere che l’utente abbia configurato il browser o un suo plugin per negare espressamente l’uso di intestazioni referer. In questo modo tutte le richieste di quell’utente a qualsiasi sito/server appariranno come richieste dirette anche quando scaturiscono dal click di un link su qualche pagina web.

Alcuni browser, per esempio, possiedono una modalità di navigazione “anonima” che tra le varie tecniche di anonimizzazione adottate si premura anche di non produrre mai intestazioni HTTP referer alla richiesta delle risorse.

Una seconda causa può essere proprio l’oggetto di questo articolo: il meta tag referrer.

Come funziona il tag meta referrer

Per farla breve, se un browser supporta il meta tag referrer allora si impegna a gestire i contenuti dell’intestazione HTTP referer secondo le istruzioni impartite dalla pagina web che contiene il meta tag.

Riprendendo lo scenario da fattoria già usato, succede che la risorsa http://ciccio.it/ spiega al browser che contenuti deve avere l’intestazione HTTP referer che verrà inviata dal browser a http://nonnapapera.it/ quando l’utente cliccherà il link.

Attraverso il meta tag referrer, Ciccio può chiedere al browser una delle seguenti quattro cose; anche se per semplicità negli esempi faccio riferimento solo a Nonna Papera, fate conto che le indicazioni del meta tag referrer si applicano a qualsiasi link l’utente clicchi sulla pagina Ciccio:

• <meta name=”referrer” content=”default“> : gestisci l’intestazione HTTP referer come si è sempre fatto, ovvero includila tra le intestazioni HTTP quando l’utente cliccherà il link verso Nonna Papera, tranne nel caso in cui Ciccio sia stato chiesto col protocollo HTTPS e Nonna Papera invece verrà richiesta col protocollo HTTP.
• <meta name=”referrer” content=”never“> : quando l’utente cliccherà il link verso Nonna Papera, non inviare alcuna intestazione HTTP referer a quest’ultima.
• <meta name=”referrer” content=”always“> quando l’utente cliccherà il link verso Nonna Papera, invia sempre un’intestazione HTTP referer a quest’ultima, anche nel caso in cui Ciccio sia stato chiesto attraverso il protocollo HTTPS e Nonna Papera verrà chiesta attraverso il protocollo HTTP.
• <meta name=”referrer” content=”origin“> : quando l’utente cliccherà il link verso Nonna Papera, invia sempre (anche nel caso di HTTPS>HTTP) un’intestazione HTTP referer a quest’ultima contenente non l’URL esatto che conteneva il link bensì solo il nome di dominio di Ciccio.

Per rissumere il tutto, attraverso il meta tag referrer le pagine linkanti hanno modo di decidere se verrà inviato un referer alle risorse che i browser richiederà a seguito del click su un link ed eventualmente che contenuti dovrà avere l’intestazione, secondo le regole sopra esposte.

Nel momento in cui scrivo, 4 maggio 2012, l’unico browser diffuso che supporta il tag meta referrer è Google Chrome. Ma questo basta a Google per iniziare a cambiare, ancora una volta, le carte in tavola.

Come cambieranno le SERP

Da questo punto in poi spiegherò che cosa succederà alle SERP di Google, limitatamente a quelle prodotte per gli utenti loggati, che accedono al motore di ricerca attraverso il protocollo HTTPS.

Al momento Google usa per le SERP una pagine di redirezione, che viene richiamata quando l’utente clicca su una risorsa. Tale redirezione serve per tracciare il click e raccogliere un po’ di informazioni sul link cliccato e sulla risorsa di destinazione.

Per facilitare la comprensione, date un’occhiata all’immagine seguente e fate attenzione ai protocolli usati per la pagina della SERP e per quella di tracciamento.

Come potete notare, la SERP è sotto protocollo HTTPS mentre la pagina di redirezione è sotto protocollo HTTP. Secondo il funzionamento standard dell’intestazione HTTP referer, quando l’utente clicca sul link della SERP il browser non deve inviare alcuna intestazione HTTP referer alla pagina di redirezione. I siti di destinazione, invece, ricevono sempre un’intestazione HTTP referer, che corrisponde all’URL della pagina di redirezione.

L’idea di Google per velocizzare la navigazione dell’utente è quella di eliminare del tutto la pagina di redirezione e linkare direttamente sulla SERP il sito di destinazione.

Togliere le pagine di redirezione crea però un problema a Google: essendo le SERP erogate sotto protocollo HTTPS, un click dell’utente verso una qualsiasi risorsa esterna che fa uso del protocollo HTTP indurrebbe il browser dell’utente a non presentare alcuna intestazione HTTP referer al sito di destinazione. Questo scenario è molto, molto peggio che ricevere un’intestazione HTTP referer priva delle keyword cercate dall’utente, come già avviene.

Per ovviare al problema, Google ha deciso di usare il meta tag referrer, che è in grado di chiedere al browser di produrre un’intestazione HTTP referer anche quando si passa da protocollo HTTPS (la SERP) a protocollo HTTP (le maggior parte delle risorse di destinazione).

Voi penserete: “Figo, Google userà un meta tag referrer di tipo always, e quindi al sito di destinazione arriverà sempre e comunque un’intestazione HTTP referer che corrisponde all’URL della SERP, come avveniva un tempo! Le query Not Provided moriranno; dov’è lo Champagne?”.

Ah ah ah! Beata ingenuità… Siccome nell’URL della SERP può esserci anche il testo della query fatta dall’utente e siccome Google non vuole che il sito di destinazione conosca le keyword cercate dagli utenti loggati, Google userà invece un meta tag referrer di tipo origin. Se ridate un’occhiata al significato di questo meta tag, vedrete che esso induce il browser a produrre un’intestazione HTTP referer contenente solo il nome di dominio (www.google.it/com/de/ecc.) e non la pagina esatta su cui stava il link (la SERP).

Per chiudere il discorso, ecco quello che succederà limitatamente agli utenti loggati su Google e che usano Google Chrome, al momento l’unico a supportare il meta tag referrer:

• la navigazione sulle SERP sarà più veloce, perché Google produrrà per i browser Chrome delle SERP nelle quali i link ai siti esterni saranno diretti, senza alcuna pagina di redirezione
• i siti di destinazione non riceveranno più le URL delle pagine di redirezione (perché tali pagine non esisteranno più) e quindi nemmeno tutti i parametri che esse contengono
• i siti di destinazione riceveranno solo un’intestazione HTTP referer contenente il nome di dominio di Google

Effetti sulla web analysis

Diverse piattaforme di web analytics riconoscono un utente proveniente da una SERP controllando la presenza di un parametro “q” nell’URL di provenienza. Questo parametro, per convenzione diffusa tra i motori di ricerca, contiene le keyword digitate dall’utente in fase di ricerca.

Quando Google cela le keyword al sito di destinazione non omette il parametro “q” dall’URL della pagina di redirezione ma lo mantiene volutamente, rendendolo però vuoto. Controllando la semplice presenza di un parametro “q” nell’URL del referer, la piattaforma di analytics del sito di destinazione è in grado di sapere che l’URL di provenienza era una SERP, anche nel caso in cui le keyword non siano specificate.

Nel momento in cui Google implementerà il meta tag referrer sulle SERP, i siti di destinazione riceveranno dagli utenti che usano Chrome solo intestazioni HTTP referer contenenti il nome di dominio Google.it (o .com o quello che l’utente ha usato). Tale URL sarà priva di parametri e gli strumenti di analytics che cercavano nelle URL dei referer il parametro “q” per capire se la fonte era una SERP si attaccheranno a chilometriche carovane di tram…

… tuttavia, la soluzione è dietro l’angolo ed è stata già implementata dalle piattaforme di analytics più importanti e qualche importante piattaforma di analytics, come Adobe SiteCatalyst, l’ha già implementata (grazie a Marco Cilia per aver segnalato il mio eccessivo ottimismo): quando un utente mostra come referer l’home page di Google, si può dare per scontato che l’utente provenga in realtà da una SERP, visto che Google non è certo abituato a linkare siti esterni dalla propria home page (tranne eccezioni temporanee). Furbo, no?

Dovreste informarvi se la vostra piattaforma di web analytics si è già mossa per implementare la soluzione appena descritta oppure se tocca a voi configurarla per ottenere il corretto riconoscimento della provenienza.

Esistono comunque altri effetti secondari che per alcune persone potrebbero essere molto sgradevoli. Per esempio, visto che non ci saranno più parametri negli URL indicati nelle intestazioni referer, smetteranno di funzionare anche tutti quei “filtri” delle piattaforme di web analytics che si basavano su specifici parametri dei referer.

Per esempio, sicuramente qualcuno avrà prodotto dei “filtri” per gestire il parametro “cd” presente negli URL dei referer che attualmente arrivano dalle SERP di Google. E’ un parametro spesso utile, perché contiene la posizione sulla SERP del link cliccato dall’utente ed è possibile attraverso di esso calcolare posizioni media nelle SERP e sapere in che posizione stava una risorsa quando un utente ha cliccato il link.

Ecco, questi filtri non funzioneranno più e non ci sarà modo di risolvere il problema.

Prove tecniche di confusione

Se pensate che l’intero casino appena descritto tarderà ad arrivare, vi sbagliate, perché qualche giorno fa ho dato un’occhiata al codice HTML di una SERP erogata ad un browser Chrome e ci ho trovato dentro il famigerato meta tag referrer, come testimonia lo screenshot che allego.

Si è trattato sicuramente di un test temporaneo, sopratutto perché l’introduzione del meta tag non era in coppia con la contestuale eliminazione della pagina di redirezione, producendo come orrendo effetto collaterale l’assenza di alcuna intestazione HTTP referer erogata ai siti di destinazione. Successivamente le intestazioni sono scomparse, poi riapparse, poi scomparse di nuovo e adesso non so, controllate voi. 😉

Che cosa riserva il futuro?

Chrome è solo il primo dei browser che implementerà il meta tag referrer ed è possibile che altri browser seguiranno la scia, anche se magari non presto.

La tendenza è palese e non servono esperti per rendersene conto: il tracciamento delle provenienze dalle SERP di Google è destinato a diventare sempre più utopico, fateci l’abitudine.

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