Jul 15 2015

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti

L’unico sensato – ma ancora da venire – modo di bloccare i ghost referrals

autore: Marco Cilia categoria: generale tag: , , ,

Questo post è il complementare dello scorso “L’unico vero – ma insensato – modo per bloccare i ghost referrals” e ne riprende naturalmente il titolo 🙂

Si diceva che se Google dovesse fare un sistema di blocco preventivo dei ghost referrals dovrebbe studiare un sistema simile a quello descritto nel post, almeno a detta del sottoscritto. Si diceva nei commenti che forse un altro modo potrebbe essere un “segnala come spam” simile a quello di Gmail, ma che la cosa potrebbe avere problemi di workflow di approvazione.

Com’è, come non è, oggi thesempost.com ci informa che Adam Singer, Analytics advocate a Google, ha detto chiaramente durante il Mozcon che Google sta lavorando per risolvere il problema alla radice. Non ci sarà quindi da rivolgersi a terze parti ma soprattutto Singer – secondo l’articolo – ha detto che Google sta lavorando al problema in modo che la soluzione sia scalabile, ovvero che possa risolvere il problema adesso e per sempre, anche se gli spammer cambiassero i loro pattern di invio dei dati fasulli. Sembrerebbe quindi un qualcosa più simile ai filtri antispam di Gmail, ma ovviamente senza prima vederlo in azione non possiamo sbilanciarci troppo.

La creazione di un sistema definitivo spiegherebbe anche la relativa latitanza da parte di Google negli ultimi mesi durante i quali il problema è balzato alle cronache. Meglio tardi che mai, no? 🙂


Jun 30 2015

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo rosso - articolo per esperti

L’unico vero – ma insensato – modo per bloccare i ghost referrals

autore: Marco Cilia categoria: codice di monitoraggio tag: , , ,

Sul fenomeno dei cosiddetti ghost referrals hanno scritto più o meno tutti, ma come direbbe il buon Corrado Guzzanti interpretando uno dei suoi personaggi più riusciti (Quelo) “la risposta che cerchi è dentro di te. Solo che è SBAGLIATA!” 🙂

I ghost referrals sono delle visite che vengono registrate dai vostri Google Analytics, ma che non sono originate da veri e propri visitatori sul vostro sito. “sono bot?” no, non sono nemmeno bot, o meglio non nel senso classico con cui siamo abituati a pensare a un agente automatico che NAVIGA il sito. La gente ha difficoltà a comprendere ciò che non riesce a visualizzare, e in questo caso ciò che non riesce a visualizzare è che da qualche tempo si possono inviare dati a Google Analytics anche SENZA l’ausilio del tipico codice javascript, attraverso una cosa chiamata Measurement Protocol.

Intendiamoci, è una cosa che si è sempre potuta fare, bastava copiarsi una richiesta HTTP dell’immagine _utm.gif che veniva usata – prima di Universal Analytics – per inviare i dati ai server Google e che conteneva nei parametri tutte le informazioni necessarie al calcolo delle visite. Con il measurement protocol la cosa è stata standardizzata e ufficializzata, dando peraltro l’avvio a tutta una serie di nuove possibilità di tracking veramente incredibili (tracciare la macchinetta del caffé?)
Quello che accade è che un qualche server da qualche parte del mondo viene istruito per comporre ed effettuare centinaia di chiamate fasulle a tutte le property del mondo. Che sia un fenomeno distribuito e completamente automatizzato se ne è accorto il mio amico Enrico Pavan creando una property di un sito inesistente che ha iniziato a tracciare visite da ghost referrer, ed è confermata da alcune opinioni secondo cui le property che terminano con numeri diversi da 1 (tipo UA-XXXXXXXX-2 e oltre) non sono soggette al problema. Ora, perché non potete semplicemente fare un filtro? perché gli spammer vincono sempre, sono troppi e fanno grossi danni con poco sforzo: voi passate 3 ore a configurare 80 filtri? domani qualche spammer cambierà una lettera nel pattern delle informazioni che invia e passerà i filtri. Quindi, tanto per essere chiari:

  • potete usare la “lista esclusione referral” che trovate nella configurazione della property? no, per il motivo sopra ma SOPRATTUTTO perché essa serve a trasformare in dirette (e quindi a non sovrascrivere la sorgente di traffico) le visite da alcuni domini. Quindi peggiorereste il problema
  • potete filtrare uno a uno i domini referrer? se proprio volete farlo, il buon vecchio Simo Ahava ha creato un tool per voi, lo spam insertion tool che vi evita gran parte del lavoro. Ma tanto poi lo dovrete mantenere nel tempo…
  • potete fare un filtro di inclusione che includa solo le visite al vostro dominio/hostname? tra tutte le alternative è forse quella che può mitigare meglio il problema, ma poiché anche l’hostname può essere inviato come parametro del measurement protocol, alcuni spammer particolarmente ostinati potrebbero aggiungere della logica per controllare l’UA su ogni host e bypassare il problema

e quindi? quindi l’unica soluzione secondo me valida dal punto di vista tecnico, ancorché completamente insensata, l’ho letta sul blog di Himanshu Sharma, Optimizesmart e consiste in un complicato metodo di codifica/decodifica di tutte le hit inviate. Per la precisione:

  1. Si decide una stringa di sicurezza, ad esempio “dhffjsrr12353fdf4253kc“, per mantenere il suo esempio
  2. Si antepone la stringa di sicurezza a tutte le chiamate a GA. Per farlo si modifica il codice di GA ad esempio così
    ga('send', 'pageview','dhffjsrr12353fdf4253kc' + location.pathname); o si usa un TagManager. ATTENZIONE che l’esempio riportato tronca tutte le query interne, quindi ad esempio la pagina /ricerca.html?key=asd viene tracciata solo come /ricerca.html. Dovrete ingegnarvi con un po’ di javascript per gestire tutti i casi.
  3. Si crea un filtro di inclusione di tipo custom con “includi – URI della richiesta – corrisponde a espressione regolare – ^/dhffjsrr12353fdf4253kc
  4. Si crea un filtro cerca e sostituisci per evitare di avere nei report degli URL orrendi. quindi filtro custom – cerca e sostituisci – URI della richiesta – cerca ^/dhffjsrr12353fdf4253kc/ – sostituisci con /. Nell’ordine dei filtri questo deve stare sotto al precedente, altrimenti non funziona nulla

Come vedete è una soluzione radicale, che va aggiustata e testata per bene prima di essere portata in produzione, e che a me sinceramente fa anche abbastanza orrore, concettualmente, perché costringe tutti a un lavoro grande e potenzialmente pericoloso per i dati. Ma è anche vero che se dovessi pensare a un metodo radicale per Google di evitare a tutti noi i ghost referrals senza uccidere il measurement protocol non mi viene in mente qualcosa di tanto diverso. Magari la chiave di sicurezza potrebbe essere generata direttamente da GA, e così il filtro di inclusione e replace, e il codice di monitoraggio potrebbe già essere fornito funzionante, ma la sostanza del problema non cambia di molto.


Jan 30 2012

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti

Escludere dai report un referrer spam

autore: Marco Cilia categoria: filtri tag: ,

Avevo iniziato a scrivere un commento direttamente sul post, ma stava diventando troppo lungo per cui mi scuso sin da ora se ne faccio un post a mia volta. Mi è capitato l’occhio su questo articolo di Filippo Sogus su come filtrare i referrer spam forex-ninjas.com e rock.to, che alcuni di voi potrebbero aver visto nei propri report (a me è successo). Non conosco Filippo, e spero che non se ne avrà a male se faccio due correzioni, la prima delle quali mi consente anche di affrontare un equivoco che ho sempre dimenticato di chiarire su questo blog:

  1. il primo errore è nel filtro: “traffico dai domini” è la traduzione letterale di “traffic from domains” dell’interfaccia inglese, ma entrambe si prestano a un errore di base; quel che noi dobbiamo filtrare sono le visite con un certo referrer, mentre quel campo agisce sul dominio geografico del visitatore (il fornitore della connessione, ad esempio fastweb o tiscalinet). Si veda l’articolo dell’help ufficiale “che cos’è un filtro?“, dove si legge chiaramente “Escludi il traffico proveniente dai domini: utilizza questo filtro per escludere il traffico proveniente da un dominio specifico, ad esempio un ISP o una rete aziendale.”. Il filtro che serve a noi è quindi un filtro PERSONALIZZATO di tipo ESCLUDI, con campo filtro REFERRAL e pattern filtro forex\-ninjas\.com (oppure rock\.to).
  2. il secondo errore è nella frase “A questo punto, ritornando nei report Referral avrete una lista ripulita dai domini spammer.”. I filtri non sono retroattivi (i segmenti avanzati invece lo sono), quindi applicare il filtro avrà effetto solo dal momento in cui si preme SALVA in avanti. Ne consegue anche che un referrer spam può essere eliminato solo dopo che si verificano le prime visite, giacché è impossibile filtrare tutto preventivamente.

Giusto per dovere di chiarezza 🙂


Jul 06 2011

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti

Traccia i referrer da Google+ separatamente

autore: Marco Cilia categoria: filtri tag: ,

Secondo TechCrunch Google+ è diventata in breve tempo una delle fonti principali di traffico al loro blog. Non si può sapere se per via dell’euforia della novità o perché effettivamente costituisce un buon veicolo di informazioni (il che farebbe ben sperare, dato che al momento tutto va fatto a mano e non ci sono meccanismi di import automatico di nulla)…

Comunque sia, visto che Google+ è attestato sul protocollo https per questioni di maggiore sicurezza, i link postati lì dentro non dovrebbero generare referrer secondo le specifiche HTTP. Ma Google ha optato per un redirect intermedio [edit 7/7/11: non è un redirect lato server, ovviamente. Se avete curiosità tecniche Simone Rinzivillo ha un post in cui spiega come fa Google a tenere il sorgente “pulito” ma indirizzare verso un indirizzo intermedio] su http normale che invece il referrer lo genera. E quindi le visite a link cliccati su Google+ vengono viste dai sistemi di tracking come Google Analytics come normali referrer, però essendo di una property della serie “google.com” essi sono affogati nello stesso referrer di Google Reader, ad esempio.

Se per qualche motivo volete separarlo e tracciare Google Plus separatamente, basta un solo filtro (clicca per ingrandire):

Filtro GooglePlus – personalizzato / avanzato
Campo A -> Estrai A: Referral – google\.com/url\?sa\=z
Campo B -> Estrai B: (vuoto)
Output in -> Constructor: Sorgente Campagna – google-plus
Campo A obbligatorio: Sì
Campo B obbligatorio: No
Sovrascrivi campo output: Sì
Maiuscole/minuscole: No

Il risultato è esattamente quello atteso, cioè la separazione delle visite provenienti da Google+ da quelle del resto della galassia Google:


Jun 30 2011

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti

dimensione FullReferrer nei custom report

autore: Marco Cilia categoria: report tag: ,

Che cosa è la dimensione “fullReferrer” che si vede quando si crea un custom report nella versione v5?

a prima vista potrebbe sembrare la soluzione all’annoso problema del filtro per il referrer completo; come molti di voi sanno infatti, l’elaboratore di Analytics taglia via tutta la parte di referrer che si trova dopo il punto di domanda di un url, a meno che noi non impostiamo un filtro che la preservi e la salvi da qualche parte.

Smorzo subito gli entusiasmi, perché ci sono cascato anche io. Quella dimensione non preserva niente, ed è niente meno che il “percorso completo referrer”, lo stesso che si può vedere partendo dal report sui referral e selezionando prima un dominio e poi ogni indirizzo, purché con url non dinamici. La cosa è verificabile anche dal fatto che quella dimensione funziona solo se la sorgente è “referral” e non funziona per organic, ad esempio. Se non altro il filtro ci dava il referrer in tutti i casi, a prescindere dal reale mezzo della campagna usato!


Jan 19 2011

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo giallo - articolo avanzato

Tracciamento dei sottodomini: best practices

autore: Marco Cilia categoria: codice di monitoraggio tag: , , ,

Traduco un post di ROIrevolution, perché mi sembra interessante: riguarda alcuni consigli per il tracciamento dei sottodomini

Non esiste un articolo specifico nell’help ufficiale dedicato al tracciamento dei sottodomini. Il più vicino è questo, che raccomanda quanto segue:


// questa è solo la parte modificata
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-12345-1']);
_gaq.push(['_setDomainName', '.example-petstore.com']);
_gaq.push(['_setAllowHash', false]);
_gaq.push(['_trackPageview']);

Propongo invece alla maggior parte dei siti con sottodomini, di usare il codice seguente:


// questa è solo la parte modificata
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-12345-1']);
_gaq.push(['_setDomainName', 'example-petstore.com']);
_gaq.push(['_addIgnoredRef', 'example-petstore.com']);
_gaq.push(['_trackPageview']);

Cosa c’è di sbagliato nel codice raccomandato da Google? ci sono tre aspetti che potrebbero generare problemi evitabili:

1. Disabilitare l’hashing è male

Disabilitare l’hashing del sito, tramite [‘_setAllowHash’, false] oppure [‘_setDomainName’,’none’] è necessario affinché il tracciamento cross-domain abbia successo. E’ una necessità sfortunata, tuttavia, perché l’hashing del dominio è una cosa veramente utile.

Per definizione, uno script non può identificare il dominio di un cookie; questa informazione non è disponibile a meno che essa non faccia parte del nome del cookie o sia scritta nel suo contenuto. Includere l’hash fornisce quella informazione, così il codice di Google Analytics può leggere il set di cookie corretto in situazioni dove potrebbero essercene più d’uno.

Disabilitare l’hash significa che il codice non ha modo di capire quale set di cookie sia quello corretto. La maggior parte delle volte esiste un solo set, quindi non è un problema. Ma se avete già usato Google Analytics senza il tracciamento dei sottodomini, allora finirete per avere due set di cookie per lo stesso dominio nel caso di un visitatore di ritorno (dopo la modifica, ndMC): un set creato dal codice vecchio, e un set creato dal codice nuovo. Questo accade più spesso nei sottodomini, ma può anche accadere sul dominio principale.

Eduardo Cereto ha un post che approfondisce questo problema con più dettagli e fornisce un altro caso in cui _setAllowHash genera problemi. La morale qui è che avete bisogno di _setAllowHash per il tracciamento cross-domain, ma se invece avete solo a che fare con sottodomini non è necessario e anzi potrebbe causarvi problemi.

2. Il punto messo come prefisso causa il reset dei cookie

Le pagine del Google Code offrono la seguente spiegazione per l’uso del punto prima del dominio quando si usa _setDomainName:

“se volete tracciare attraverso differenti sottodomini:
* dogs.petstore.example.com e
* cats.petstore.example.com

è richiesto un punto prima del nome di dominio”.

Se il vostro sito usa sottodomini allora avrete indubbiamente bisogno di quel punto, pena il non funzionamento del tracciamento. Se il vostro sito non usa sottodomini, comunque,sarebbe meglio non usare il punto.
Il motivo è ancora una volta l’hash. L’hash che viene generato dal codice di Google Analytics quando si usa il punto è differente da quello generato quando invece il punto non si usa. Ma l’hash generato quando non si usa il codice per tracciare i sottodomini sul sito principale è identico a quello generato quando si tracciano i sottodomini senza l’uso del punto.

Questo significa che se non si stavano tracciando i sottodomini in precedenza, usare il punto istruirà il codice di GA a distruggere i vecchi cookie perché l’hash non combacia, che è appunto simile a quanto descritto al punto 1.

Semplicemente, non includere il punto se non è necessario significa avere minori probabilità di reset dei cookie, cosa che facilità la transizione al tracciamento dei sottodomini.

3. Non utilizzare _addIgnoredRef causa problemi di auto-referrer

Se il vostro sito non ha sottodomini il GATC è capace di riconoscere quando la sessione di visita è scaduta tra due pagine visualizzate ed evitare di sovrascrivere il referrer esistente con un auto-referrer o un referrer-interno (cioè evita di far comparire il vostro stesso sito come referrer ndMC).

Questa “protezione” è tuttavia rimossa quando ci sono dei sottodomini, anche se il vostro codice usa la soluzione standard per il loro tracciamento. Questo può risultare in una percentuale elevata di auto-referrer anche se sembra che abbiate fatto le cose per bene.

La soluzione è usare _addIgnoredRef, ma come usarla spesso non è capito fino in fondo. Le raccomandazioni di Google sono di usare un codice simile a questo:

_gaq.push(['_addIgnoredRef', 'www.sister-site.com']);

Ho guardato in profondità nel sorgente di ga.js e osservato che una cosa così effettivamente non funziona. La ragione è che il codice di tracciamento considera www.sister-site.com identico a sister-site.com, quindi aggiungere www.sister-site.com come referrer ignorato non risolve granché. Usare un punto prima del dominio fallisce anche qui. Questo invece funziona benone:

_gaq.push(['_addIgnoredRef', 'sister-site.com']);

e ancora meglio

_gaq.push(['_addIgnoredRef', 'sister-site']);

Il GATC controlla ogni riga di referrer ignorati che aggiungete e usa il metodo javascript IndexOf per determinare se la stringa è contenuta o meno nel dominio referente. Se uno di questi controlli risulta essere positivo, allora il referrer è ignorato. Poiché il dominio principale senza il punto sarà contenuto anche in tutti i sottodomini, passarlo a _addIgnoredRef funziona bene. Questo elimina anche la necessità di aggiungere un _addIgnoredRef separato per ogni sottodominio.

Possono comunque esserci auto-referrer residui, ma non più di quanti ce ne sarebbero senza i sottodomini. La ragione è che _addIgnoreRef funziona soltanto quando il cookie contiene già informazioni di referrer. Se un nuovo visitatore arriva al vostro sito su una pagina senza codice di Analytics e poi naviga verso una pagina che invece ce l’ha, il risultato sarà che il vostro sito compare tra i referrer, a prescindere dalle accortezze che avrete usato per evitarlo.

Questi tipi di auto-referrer possono essere evitati assicurandosi di aver taggato ogni pagina del sito. Quindi se ci sono pagine che hanno questo problema, potete utilizzare GA per determinare esattamente quali esse siano, e siccome state usando _addIgnoredRef sarà facile isolarle dato che non avrete altri falsi positivi generati senza apparente ragione.

La cosa importante da ricordare, quindi, è che _addIgnoredRef dovrebbe essere inclusa per definizione ogni volta che si tracciano sottodomini, non solo se si notano auto-referrer

[update 27/1: Analyticpros chiarisce ancora meglio come funziona la routine per l’aggiornamento del cookie __utmz; le condizioni per aggiornarlo sono due: se nel DOM document.referrer è diverso da document.domain e se si tratta di una nuova sessione. Ne consegue che anche nell’ipotesi di codice ottimale se un visitatore è nel sito principale e ci resta 40 minuti, e poi clicca un link che lo porta ad un sottodominio, poiché entrambe le condizioni sono verificate il codice di GA provvederà ad aggiornare il cookie, causando un auto-referrer]


Jul 29 2009

Risultati illustrati come sorgente separata e con keyword

autore: Marco Cilia categoria: filtri tag: , , ,

Qualche giorno fa mi ha scritto Maurizio Petrone con una domanda insolita, almeno per me: ha modificato un metodo noto per tracciare le ricerche Universal Search di Google per tenere conto solo dei click effettuati sulle immagini, ovvero quelli che Google stessa indica come “risultati illustrati” (vedi immagine sotto)

risultati-illustrati

Dico “domanda insolita” perché io non ho mai avuto un sito di foto come cliente, quindi non mi sono mai posto questo tipo di problema che invece è del tutto lecito. Guardando gli url di destinazione dei click (che sono poi i referrer dei siti monitorati con Google Analytics), per la ricerca “montagna” – sul mio browser e in questo momento, ma la sostanza non cambia – i risultati illustrati per una foto puntano a questo indirizzo

http://www.google.it/imgres?imgurl=http://agenda.filastrocche.it/wp-content/uploads/2008/09/montagna.jpg&imgrefurl=http://agenda.filastrocche.it/%3Fp%3D1849&h=600&w=800&sz=166&tbnid=Gvcrgtm0c9eaFM:&tbnh=107&tbnw=143&prev=/images%3Fq%3Dmontagna&hl=it&usg=__ePp09iMbJpQU99vjyP6TqM79NC4=&ei=2QdwSv6CJaGwnQPn-9G5Bw&sa=X&oi=image_result&resnum=5&ct=image

mentre i risultati di Google Immagini per la stessa keyword, e per la stessa immagine di destinazione, puntano invece a

http://images.google.it/imgres?imgurl=http://agenda.filastrocche.it/wp-content/uploads/2008/09/montagna.jpg&imgrefurl=http://agenda.filastrocche.it/%3Fp%3D1849&usg=__1RZ-MlgZ2o5X1eCCBAZnKb73aLg=&h=600&w=800&sz=166&hl=it&start=5&sig2=wSQ01ux59X1UE3WRa7VRUA&um=1&tbnid=Gvcrgtm0c9eaFM:&tbnh=107&tbnw=143&prev=/images%3Fq%3Dmontagna%26hl%3Dit%26safe%3Dactive%26rlz%3D1B3GGGL_it___IT259%26sa%3DN%26um%3D1&ei=IwpwSvunIcf0_AbX25SjCQ

tralasciando il dominio di provenienza (www.google.it piuttosto che images.google.it) potete vedere che le informazioni passate sono leggermente differenti. L’esigenza di Maurizio e di Globopix quindi è chiara, e lecita.

Quello che ci serve quindi è estrarre la keyword usata per la ricerca, cambiare il mezzo di provenienza e la fonte dell’accesso. Servono tre filtri per fare queste operazioni (hey, Google, a quando i filtri con output su più campi? 😉 ), e precisamente:

Risultati illustrati – cambia sorgente
Filtro personalizzato, avanzato
Campo A -> Estrai A -> Referral -> (.*)oi=image(.*)
Campo B -> Estrai B -> Referral -> prev=/images%3Fq%3D([^&]*)
Output in -> Constructor -> Sorgente campagna -> Google (risultati illustrati)
Campo A: Obbligatorio
Campo B: Obbligatorio
Sostituisci campo output: SI

Risultati illustrati – estrai keyword
Filtro personalizzato, avanzato
Campo A -> Estrai A -> Referral -> (.*)oi=image(.*)
Campo B -> Estrai B -> Referral -> prev=/images%3Fq%3D([^&]*)
Output in -> Constructor -> Termine della campagna -> $B1
Campo A: Obbligatorio
Campo B: Obbligatorio
Sostituisci campo output: SI

Risultati illustrati – cambia mezzo
Filtro personalizzato, avanzato
Campo A -> Estrai A -> Referral -> (.*)oi=image(.*)
Campo B -> Estrai B -> Referral -> prev=/images%3Fq%3D([^&]*)
Output in -> Constructor -> Mezzo della campagna -> Organic
Campo A: Obbligatorio
Campo B: Obbligatorio
Sostituisci campo output: SI

Questi tre filtri applicati a un profilo inseriranno una nuova riga tra le sorgenti di traffico, che potrà poi essere segmentata per parola chiave. Il lato negativo è che le frasi di ricerca composte da due o più termini, ad esempio “mare genova” vengono codificate nel referral tramite il carattere ASCII esadecimale %2B, equivalente al segno più (quindi mare%2Bgenova). Poiché un filtro cerca e sostituisci che tenti di cambiare qualsiasi cosa con uno spazio non si può fare, o lo cambiate esplicitamente con un + o lo tenete così. Non si può avere tutto 🙂 (o meglio, si può a patto di modificare tramite javascript il referrer PRIMA di inviarlo a Google Analytics, ma la cosa esula da questo articolo).

Una cosa interessante che ho notato è che nel referrer è presente anche l’indicazione della posizione dell’immagine cliccata. Nell’immagine qui sopra, cliccando per esempio l’ultima immagine il parametro resnum sarà impostato a 6: modificando il filtro risultati illustrati – estrai keyword in questo modo:

Risultati illustrati – estrai keyword e posizione
Filtro personalizzato, avanzato
Campo A -> Estrai A -> Referral -> (.*)oi=image(.*)
Campo B -> Estrai B -> Referral -> prev=/images%3Fq%3D([^&]*)(.*)resnum=([^&]*)
Output in -> Constructor -> Termine della campagna -> $B1 (pos: $B3)
Campo A: Obbligatorio
Campo B: Obbligatorio
Sostituisci campo output: SI

avremo anche la posizione dell’immagine nella SERP al momento del click 🙂


Dec 23 2008

Raggruppare i social network

autore: Marco Cilia categoria: filtri tag: , ,

Riprendendo l’idea di Brian Clifton di raggruppare tutte le visite provenienti da social network in modo da poterle analizzare aggregate, ho testato e modificato la sua regular expression per riflettere meglio il traffico italiano.
Naturalmente ogni sito ha una sua storia e una sua collocazione, e fonti di traffico diverse, per cui non è affatto detto che la mia regex calzi a pennello: penso tuttavia che sia un buon punto di partenza per le vostre personalizzazioni.

Il filtro è di tipo avanzato personalizzato.
Campo A -> Estrai A: Sorgente Campagna. Espressione regolare:
wikipedia|stumbleupon|netvibes|groups\.google|bloglines|groups\.yahoo\.com|linkedin|facebook|oknotizie|del\.icio\.us|digg|twitter|technorati|faves\.com|newsgator|segnalo|wikio|liquida\.it|blogbabel|kipapa|bookmark\.it
Campo B -> Estrai B: vuoto
Output in -> Constructor: Mezzo della campagna. Nome: social network
Campo A obbligatorio: Sì
Campo B obbligatorio: No
Sostituisci campo di output: Si
Maiuscole/minuscole: No

Questo filtro lo si vedrà in azione nel report Sorgenti di traffico -> tutte le sorgenti di traffico e selezionando la dimensione Mezzo, come in figura:
filtro social network in azione
Una cosa da notare è che il filtro cambia il mezzo di arrivo sul sito da parte dei visitatori, per cui tutti i siti di riferimento che inviano visitatori scompaiono dal report referrer e vengono mostrati solo qui. E’ una precisazione importante che va fatta prima di decidere se applicare o meno la modifica ai profili.

un sentito grazie a Maurizio Petrone per la consulenza sui social network italiani, che forse userò anche per un’altra cosa da proporvi


May 15 2008

Youtube Insight ora mostra anche le keyword

autore: Marco Cilia categoria: generale tag: , ,

All’interno del grande disegno unificatore della web analytics fornita da Google, di cui vi ho parlato recentemente (vedi post “il futuro di google analytics“), al servizio di statistiche di Youtube si poteva rimproverare la mancanza di dati come i referral o le keyword usate per trovare i nostri video. Per chi fa web analytics questi due dati sono molto importanti, e lo sono ancora di più se pensiamo che in un video l’ottimizzazione tradizionale delle keyword puà avvenire solo con un margine di manovra ristretto all’interno dei title del video e della sua descrizione, che Youtube mostra a lato.

Da qualche giorno questi dati vengono mostrati:

Nella voce video correlati troveremo gli identificativi dei video che ci hanno portato visitatori, player incorporato sono le visualizzazioni da siti e blog esterni che hanno incollato il codice embed del nostro video, ricerche su youtube ci mostra le keyword usate nel motore interno per arrivare fino a noi, Link esterni mostra un elenco di domini (non URL esatti) che hanno linkato la pagina contenente il video; in Altro e Youtube (altro) finiscono le situazioni in cui questi dati non sono ricostruibili.

La segmentazione di questi dati è possibile, anche se non proprio intuitiva: dalla pagina principale di Insight è possibile scegliere un arco temporale differente (5 giorni, 1 mese, 3 mesi, 6 mesi, 1 anno, tutto il periodo esistente di statistiche) o una zona geografica specifica, e l’indicazione in alto a destra si modificherà di conseguenza, ad esempio scrivendo “Mostra dati per Europa 15/02/08 – 14/05/08”. Fino a che non cambieremo questa visualizzazione essa sarà mantenuta, per cui i dati dei referral e delle keyword saranno relativi solo all’Europa e agli ultimi tre mesi, nel caso in esempio.

Questa mi sembra una ulteriore conferma della mia teoria che presto o tardi questa interfaccia verrà completamente integrata in Google Analytics