-
Questa opera di Enrico Altavilla è concessa in licenza sotto la Licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.
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
Il Panda non c'entra niente, ma ho notato nuova gente improvvisata che ne parla a vanvera ed io non voglio essere da meno.
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.
Ottimo articolo!
l’hanno detto anche alla blueglass che dovremo in futuro attenderci un valore di “not provided” prossimo al 100% 🙂
Ottimo articolo, complimenti!
più che il problema in sé, mi spaventano i casi “disallineati”. Chrome lo implementa, un altro browser no. In un caso c’è il referrer, e lo strumento si adegua, in un altro è vuoto, e segna direct. A me sta (anche) bene avere MENO informazioni, PERO’ le voglio coerenti!
Ciao Marco, spero di aver compreso bene l’aspetto a cui ti riferisci.
In caso di meta tag “origin” il referer non sarà vuoto ma conterrà il nome di dominio del sito di provenienza.
Questo non solo è sufficiente alle piattaforme di web analytics per considerare l’accesso proveniente da un altro sito ma, se il dominio di provenienza è uno di quelli di Google, allora l’accesso verrà considerato anche proveniente da una SERP. Sia GA che altre piattaforme sono già predisposte per comportarsi in questo modo.
Scusa invece se ti riferivi ad un altro contesto.
@Marco : credo di aver capito, adesso, a cosa ti riferivi. 🙂 Non alla specifica implementazione con “origin” ma ad altri valori del tag che creerebbero incongruenze tra browser diversi.
Sì, è una bella schifezza. :-\
Bell’articolo, grazie!
Staremo a vedere! Troveremo cosa fare come al solito.
Grazie 🙂
Nel futuro, chi sarà specializzato in Adwords, avrà le “conoscenze” per sviluppare strategie di posizionamento organico.
LOL – ridiamo per non piangere.
Grazie per l’aggiornamento Enrico, staremo a vedere – come sempre senza dormire 😉
Si, ci baseremo sui dati di GWT 🙂
Addio dati di redditività sulle singole keyword nel caso degli ecommerce!
Vuoi per il mio ottimismo, ma credo che il tracciamento dalle serp sia importante da fornire anche per Google stesso che ha come massima priorità restituire risultati di ricerca appropiati ai propri utenti.
Grazie per l’articolo. Speriamo solo, xcome già fatto notare, che il tag sia correttamente implementato da tutti i browser che è quello che ci si aspetterebbe 😛
Bell’articolo. Complimenti.
Vedremo le alternative…
As usual.
@Marco Cilia:
Per quello c’è
MasterCardAdWords. 😉Condivido la richiesta di Giacomo Pelegatti, avere informazioni coerenti sarebbe già un buon risultato.
In realtà questa strada che Google sta prendendo mi lascia pensare che abbia in mente di profilare meglio gli utenti registrati e quindi vendere meglio adwords, avvicinandosi alla possibilità di profilazione di Facebook. Le cerchie, gli interessi, i dati personali, i +1, faranno da corollario ad una implementazione di Adwords.
Sei sicuro che Google voglia mettere un link diretto al sito? Mi sembra molto strano, la redirezione gli è molto comoda per fare analisi sulla performance della SERP.
Ci sono JS che fanno un po’ questo lavoro, ma non sono affidabili.
Ciao Pierpaolo,
sì, sono certo dell’eliminazione della redirezione, anche perché è esplicitamente detto nel post ufficiale di Google, che linkavo in cima all’articolo.
Quand’anche non fosse stato detto esplicitamente, avremmo potuto congetturare facilmente che la modifica che avrebbe apportato il maggiore incremento di velocità di navigazione sarebbe stata proprio la soppressione della redirezione.
L’eliminazione della redirezione non implica però la rinuncia al tracciamento del click; Google tracciava il click dell’utente anche prima che le pagine di redirezione venissero introdotte nelle SERP.
Per annunciare quest’ultimo cambiamento, posso solo immaginare che Google abbia trovato una soluzione soddisfacente alle proprie esigenze di tracciamento del click.
Vedremo un po’ che cosa si inventeranno. 🙂 Magari useranno una tecnica simile a quella passata, che faceva uso di una richiesta del browser in background, associata ad un evento onMouseDown sul link della risorsa da tracciare.
Complimenti per l’articolo!! chiaro ed esaustivo. ma mi chiedevo se ciò potrà impattare anche sulle statistiche lato server dei siti, tipo software come awstats ed altri sistemi di statistica implementati nei server/domini? L’interpretazione da parte di questi software dei file di log delle visite si complicherà molto! Con aggiornamenti obbligatori dei sistemi di logging delle visite e di statistica.
Ciao Ottaviano, le conseguenze saranno per qualsiasi tipo di software di web analytics, in quanto tutti si basano sull’elemento, l’intestazione HTTP referer, che verrà gestito in modo diverso dai browser che supporteranno il meta tag.
Le soluzioni indicate nell’articolo sono quindi valevoli per qualsiasi genere di tracciamento: basato sui log del server o fatto attraverso JavaScript.
Per quanto mi riguarda, lo so che forse sono controcorrente, ma sono contento!!
Così forse si smetterà di confondere la Web Analytics col tracking puro e semplice e si smetterà di pensare che l’Analisi sia solo chiedersi con che chiave è arrivato un cliente.
Lo so che era comodo e serviva, ma portava veramente fuori strada e di tanto. Così alla fine, tanti “Web Analisti” pensavano che il loro lavoro fosse solo tirar fuori report di quanti visitatori arrivavano per chiave… Ora o si cercano cose più importanti da fare nell’ambito della Web Analytics (che per un ex-analista come me, è tutt’altra cosa) o si cercano un altro lavoro :p :p :p
Forse per Google non è ancora il momento di temere ritorni negativi sull’immagine dello strumento Google Analytics, dal momento che il plus dell’integrazione con gli altri strumenti di Google fa la differenza rispetto a sistemi di web analytics professionali e completi.
Però sono convinto che questo modo di agire che sembra non avere la minima cura nei confronti degli utenti (e non mi riferisco alla politica di Google solo nei confronti degli addetti ai lavori) porterà le sue conseguenze.
L’utente non è stupido (e quello stupido resta su FB direi… Perdonate la caduta di stile).
I risultati delle query “hate google” crescono.
Dal rapporto di amore assoluto che c’era all’inizio per il “don’t be evil”-spirit si è passati all’amore-odio e il divorzio potrebbe non essere lontano.
Pingback: Pinguini, Panda e la morsa del monopolio @merlinox
Però penso anche a una cosa: Google vorrà pur spingere il suo software di analytics giusto? E se molti dati vengono persi o falsati i concorrenti si attiveranno per escogitare tracciamenti migliori e tu utente, sarai incentivato a scegliere il software concorrente e non più GA. Morale, se Google non vuole un abbandono repentino del proprio software dovrà fare in modo di dare dati utili che non tolgano esperienza d’uso (e quindi valore delle keywords, che rappresenta il 70% delle motivazioni d’uso di GA) al software.
Finchè la gente passa da google, il problema non potrà essere bypassato… è come il no provider, capita anche su sitecalyst ma lo chiama “not available” e non riesco nemmeno a filtrarlo 🙂
Scusa Enrico, una sola domanda per vedere se ho ben capito il succo.
L’utilizzo di questo meta refferer da parte di Google non consentirà ai software di analisi di conoscere le specifiche chiavi di ricerca ma solo la provenienza “generica”? Sapremo dunque che un visitatore provenie da Google ma non sapremo cosa ha cercato?
Grazie 🙂
Ciao Alessandro, gli utenti loggati in Google non inviano già la query ai siti di destinazione e non la invieranno nemmeno dopo.
Ecco uno schema riassuntivo di ciò che gli utenti Chrome loggati in Google inviano ai siti di destinazione.
Conseguenze per i software di tracciamento che si adegueranno: la visita continuerà ad essere classificata come “traffico organico”; continueranno a non sapere la query; se avevano filtri basati sugli “altri dati utili”, quei filtri smetteranno di funzionare.
Conseguenze per i software di tracciamento che non si adegueranno: la visita non verrà classificata come “traffico organico” (proveniente da una SERP) ma come traffico da referral (provenienti da siti esterni); se avevano filtri basati sugli “altri dati utili”, quei filtri smetteranno di funzionare.
Grazie Enrico, molto gentile 🙂
Mmmmh non lo sapevo! 🙁 domando, anche il webmastertool perdera’ quei dati oppure li prende in altro modo? perche’ senno resterebbe l’unico strumento utile…
eccolo qui infatti : “Webmasters will continue see the same data in Webmasters Tools—just as before, you’ll receive an aggregated list of the top search queries that drove traffic to their site.” dall’articolo che citi dell’annuncio di due mesi fa… eh be’ , furbini 😉
Bell’articolo! Molto interessante ed istruttivo. E’ anche ben scritto e piacevole da leggere 🙂 lo condivido subito. Grazie