May 26 2016

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti semaforo giallo - articolo avanzato semaforo rosso - articolo per esperti

Il plugin per duplicare gli invii a più property

autore: Marco Cilia categoria: codice di monitoraggio

Inviare gli stessi dati a più property è una cosa che capita spesso, molto più spesso di quanto si possa immaginare; il caso classico è la presenza di una property locale e di una di “rollup” che include anche dati di altre property, ma in realtà i casi sono disparati.
La letteratura classica prevede la doppia sintassi, la presenza di tracker nominati e l’invio di qualsiasi pagina o evento due volte. Ad esempio così


ga('create', 'UA-12345-1', 'auto');
ga('create', 'UA-67890-9', {'name':'b'});

ga('send', 'pageview');
ga('b.send', 'pageview');

Con il TagManager basta duplicare ogni tag e cambiare l’UA al quale si invia.
Ma quel geniaccio di Simo Ahava ha postato un plugin per Universal che invece fa tutto da solo: ecco il post “simple tracker duplication for universal analytics

Non vi voglio riportare tutte le istruzioni, quanto piuttosto segnalare il post. Dopo aver creato il file con il js (o comunque incluso il codice) è sufficiente cambiare il codice base così (uso l’esempio di sopra)


ga('create', 'UA-12345-1', 'auto');
ga('require', 'simolatorDuplicator', {'newId' : 'UA-67890-9'});
ga('send', 'pageview');

e il resto vien da sè. Facile, veloce, pulito, proprio come piace a noi 🙂


Feb 12 2015

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti semaforo giallo - articolo avanzato semaforo rosso - articolo per esperti

Come funziona l’instant remarketing?

autore: Marco Cilia categoria: codice di monitoraggio

Dopo alcune prove sono finalmente riuscito a capire come funziona l’instant remarketing di cui abbiamo parlato qualche giorno fa; in effetti era più facile del previsto, si vede che sto invecchiando 😀

Partiamo dal principio:
Google Analytics usa cookie di prima parte per memorizzare le informazioni che gli servono: 4/5/6 cookie se si usa la versione classica, 1 solo se si usa Universal Analytics. Usare cookie di prima parte significa che il codice di monitoraggio deve inviare forzatamente i cookie insieme ad ogni hit, ed è istruito a farlo.
Il remarketing (e le display features) si riescono ad usare se l’utente Analytics (cioè l’identificativo che sta nel cookie __utma o _ga) viene associato a quello del cookie doubleclick, che è un cookie di terza parte e risiede nel dominio doubleclick.net. Per questo motivo fino ad ora era richiesta la modifica della linea di codice da

ga.src = (‘https:’ == document.location.protocol ? ‘https://ssl’ : ‘http://www’) + ‘.google-analytics.com/ga.js’;

a

ga.src = (‘https:’ == document.location.protocol ? ‘https://’ : ‘http://’) + ‘stats.g.doubleclick.net/dc.js’;

(o aggiungere ga(‘require’, ‘displayfeatures’); se si usa Universal)

il file dc.js è identico a ga.js, solo che siccome invia la hit al server doubleclick forza il browser ad inviare anche il cookie con l’ID doubleclick. In questo modo si legano l’ID di GA e quello di Doubleclick e si possono creare segmenti di utenti in GA e utilizzarli in AdWords.

L’instant remarketing invece funziona così:

quando si crea un nuovo cookie _ga viene inviato nella hit anche un parametro aggiuntivo ( &_r=1 ); se questo parametro è presente e nel parametro &tid=UA-XXXXXX-Y c’è una property che non aderisce all’instant remarketing non succede nulla e la hit viene processata normalmente. Se c’è _r=1 e nel tid una property che ha attivato l’opzione apposita, allora il server è istruito per rispondere al volo con un 302 (redirect temporaneo) da

http://www.google-analytics.com/r/collect?v=1 eccetera…

a

https://stats.g.doubleclick.net/collect?v=1 eccetera…

e questo basta ad inviare anche il cookie doubleclick e quindi – di nuovo – a legare l’ID GA a quello DBCLK 🙂


Jan 31 2015

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti semaforo giallo - articolo avanzato semaforo rosso - articolo per esperti

Remarketing istantaneo e conversione valuta in AdWords

autore: Marco Cilia categoria: report

In ordine inverso rispetto al titolo, sulla pagina Google+ di Analytics ci dicono che AdWords adesso converte le valute da account che spendono diversamente da come avete impostato i report. Fino ad ora infatti se avete collegato due account AdWords al vostro GA, di cui uno in Euro e uno in yen giapponesi, il rapporto dello speso era meramente la somma: 100 euro e 100 yen contavano 200 euro, ammesso che la vista fosse configurata in euro naturalmente.

Da qualche giorno invece il sistema applica il tasso di cambio del giorno mediano del periodo selezionato (quindi su tutto gennaio prende il 15/1) e converte gli yen in euro. Il sistema non è esente da falle, è vero, se si pensa alle fluttuazioni che ci possono essere su periodi lunghi, ma per analisi brevi è sicuramente d’aiuto.

Altra novità su AdWords è la possibilità di attivare le funzioni inserzionista (remarketing, ma anche dati demografici) senza dover più modificare il codice di monitoraggio: se prima era richiesta la modifica di una riga (o una spunta aggiuntiva sul TagManager), adesso si può fare tutto comodamente da pannello di controllo (instant activation), andando su Amministrazione -> Impostazioni proprietà -> Attiva le funzioni inserzionista (beta).

Devo essere sincero, ho fatto due prove ma ancora non ho i risultati nel pannello, ma non capisco come faccia. Modificando la riga, nella versione classica del codice, si inviavano i dati Analytics al server doubleclick, forzando quindi anche l’invio del cookie doubleclick, che poi permetteva a Google di estrarre sesso, età e categorie di interesse.
Con Universal l’aggiunta della riga “require: displayfeatures” comportava che ad inizio sessione e poi ogni 10 minuti venisse inviata ANCHE una hit ai server doubleclick, con il clientID del cookie GA, che quindi permetteva l’associazione.
In questo modo, poiché il codice di GA è unico per tutti e non parametrizzato, cambiare un setting in piattaforma non produce nessun effetto nelle chiamate generate dal codice, quindi non c’è (o almeno, io al momento non vedo) modo affinché doubleclick sappia chi sono per Analytics. Farò altre indagini, perché ovviamente io VOGLIO sapere! 🙂

Altra piccola novità, sempre per i report AdWords, è l’introduzione della dimensione “numero di parole” per le query di ricerca. Si poteva fare con espressioni regolari, o esportando e usando Excel, ma naturalmente avere la possibilità di farlo direttamente dall’interfaccia è decisamente più comodo.


Jan 30 2013

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti semaforo giallo - articolo avanzato semaforo rosso - articolo per esperti

Guida pratica alle opzioni del tag GA nel tagmanager

autore: Marco Cilia categoria: tagmanager

Non conoscere tutte le funzioni possibili da utilizzare nello script di Google Analytics porta molte persone a domandarsi cosa siano tutte le opzioni disponibili quando si configura un tag di Google Analytics usando il Google Tag Manager. Ho pensato di farvi cosa utile riportando uno screenshot con le varie opzioni e il loro equivalente nella notazione “classica”, cioè quella che si deve fare quando non si usa il GTM.

Un paio di annotazioni:
– le funzioni che hanno solo la spunta sono, ovviamente, accese o spente, vere o false.
– le funzioni che si occupano dei timeout vogliono il tempo espresso in millisecondi, mentre l’interfaccia del tag manager ci facilita chiedendo i SECONDI (in verde nello screenshot); tenetelo presente se le usate o se dovete tradurre funzioni già in essere.
– se la funzione di cui avete bisogno non è tra quelle indicate, non c’è altra soluzione che usare un tag HTML personalizzato, dentro al quale dovrete riscrivere TUTTO il codice di Google Analytics che normalmente avete sulla pagina. Tanto per essere chiari, se dovete usare la funzione _setSiteSpeedSampleRate, che non è prevista dal GTM, vi tocca per adesso fare un tag HTML custom con dentro


<script type="text/javascript">
  var _gaq = _gaq || [];
  _gaq.push(['_setAccount', 'UA-XXXXX-Y']);
  _gaq.push(['_setSiteSpeedSampleRate', 5]);
  _gaq.push(['_trackPageview']);

  (function() {
    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
  })();

</script>

Detto questo, ecco la legenda. Clic per ingrandirla:

GTM-explanation


Jul 04 2012

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti semaforo giallo - articolo avanzato semaforo rosso - articolo per esperti

Google Analytics market share: nuova rilevazione di Pingdom

autore: Marco Cilia categoria: codice di monitoraggio

Royal Pingdom è uno dei mie blog preferiti, perché coniuga i numeri con le storie, produce spesso ottime infografiche e spesso ci fa riflettere su quanto siamo piccoli all’interno del mare magnum di internet (e sono svedesi 🙂 ).
Un loro post recente ha nuovamente fatto il punto sulla diffusione del nostro sistema di web analytics preferito: prendendo la top 10.000 di Alexa, Google Analytics è presente su più del 62% dei siti.

Questo numero scende a poco meno del 50 se si restringe alla top 1.000, e al 22,7 se si guardano solo i primi 100: normale se si considera che più si sale, più i siti sono corporate, e-commerce, trafficati e quindi è più facile che abbiano esigenze che possono essere soddisfatte anche da altri sistemi di web analytics. La crescita della diffusione all’interno della top 10.000 parla chiaro: in due anni il numero è cresciuto del 25%!

Interessante anche l’ultimo punto: già che scansionavano i siti, i ragazzi di Pingdom si sono presi l’onere di controllare quante chiamate a ga.js ci fossero e quante invece a urchin.js, la versione obsoleta dello script che nessuno al mondo dovrebbe più usare. Ebbene, a distanza di cinque anni dall’introduzione di ga.js, il 6,5% dei siti usa ancora la vecchia versione dello script di tracciamento. Credo che questo numero sia ancora troppo alto per far propendere Google verso la sua totale cancellazione (e sicuramente loro, che stanno nella “stanza dei bottoni”, sanno quale sia il reale utilizzo del file), però non si può mai dire…


Jun 14 2011

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti semaforo giallo - articolo avanzato semaforo rosso - articolo per esperti

Attenzione agli apostrofi nel codice ecommerce

autore: Marco Cilia categoria: codice di monitoraggio

“Per un punto Martin perse la cappa” è un vecchio detto popolare che mette in guardia da un errore apparentemente di scarsa entità ma che invece comporta conseguenze spesso disastrose. E’ il detto che mi è venuto in mente rileggendo un vecchio articolo di AnalyticsPros riguardante gli errori dei codici di tracciamento e-commerce. Probabilmente un problema che noi italiani sentiamo meno, ma che vale la pena comunque di sottolineare.

Le funzioni javascript del codice asincrono (ma anche quelle del vecchio codice asincrono per la verità) vanno incapsulate tra apici singoli (carattere sotto al punto interrogativo nella tastiera italiana). Questo è un requisito fondamentale affinché il codice funzioni. Ma cosa succede se un prodotto ha un apostrofo nel suo nome? vi ricordo che il nome del prodotto non è un parametro strettamente necessario al funzionamento del sistema, ma non ho mai visto un e-commerce che omette i nomi dei prodotti e valuta le prestazioni del suo sito con Google Analytics usando solo gli SKU code.

Quindi, se nella nostra thank-you page abbiamo un codice così:


  _gaq.push(['_addItem',
      '1234',         // order ID
      'DD44',         // SKUcode
      'Nettare d'ambrosia',      // nome del prodotto
      'bevande', // categoria
      '11.99',        // prezzo unitario
      '1'             // quantità
   ]);

il sistema va a scatafascio perché nella riga del prodotto ci sono tre apostrofi. Il prodotto diventa nettare d, ambrosia sarebbe la categoria, bevande il prezzo, 11.99 la quantità, 1 sarebbe ignorato. E peraltro mancando una virgola dopo il nome del prodotto Google Analytics non ci capirebbe nulla.

La checklist proposta nel post è piuttosto semplice: se sapete di avere prodotti che contengono l’apostrofo nel nome andate in Analytics, report dei prodotti, e cercate \’ (backslash e apostrofo, senza spazi); se non vedete nessun risultato significa che quei prodotti non vengono mai registrati da GA, e che siete affetti dal problema.
Le soluzioni possibili sono:

  1. Modificare i nomi dei prodotti
  2. Operare una sostituzione lato server PRIMA di eseguire il comporre il codice di Google Analytics
  3. inserire un backslash prima dell’apostrofo in modo che la riga diventi ‘Nettare d\’ambrosia’, // nome del prodotto

Tutto questo lavoro per un semplice apostrofo? pensate a Martin! 😉


Jun 01 2011

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti semaforo giallo - articolo avanzato semaforo rosso - articolo per esperti

Due concetti basilari che vale la pena ricordare

autore: Marco Cilia categoria: javascript

Di recente mi è capitato di dover dare un’occhiata all’Analytics di due grandi siti italiani, di cui ovviamente non posso/voglio fare i nomi (anche perché irrilevante), e di riscontrare errori. Banali errori o semplici sviste che però sono in grado di inficiare i dati.

Il primo concetto da tenere sempre a mente è che javascript è case sensitive, cioè è sensibile al fatto che il codice sia scritto con le maiuscole e le minuscole corrette. Se avete mai personalizzato almeno una riga di codice dello script di Google Analytics, avrete forse notato che le funzioni sono scritte con la notazione che i programmatori chiamano “CamelCase“: per cui _trackPageview (con la P maiuscola), _setDomainName (con la D e N maiuscole), _addTrans (T maiuscola) e così via. Scrivere la funzione _trackpageview invece di _trackPageview porta al risultato di non vedersi tracciate le pagine, perché il codice cerca una funzione che non esiste.

Il secondo fatto sconcertante è che ad alcune persone non è ancora chiaro che il codice deve stare su tutte le pagine, e non solo sulla home page. Analytics non è un polipo vorace in grado di insinuarsi nel vostro sito, non germoglia tra i rami del vostro albero di navigazione, è semplicemente un codice javascript che viene eseguito insieme alla pagina. Ho usato il singolare appositamente, viene eseguito insieme alla pagina. Ad ogni pagina. Il flusso concettuale è facile:

  1. vedo una pagina
  2. viene eseguito il codice
  3. l’informazione sulla pagina (e quindi visita e tutti i correlati) viene inviata subito a Google

Se manca il passaggio due, niente passaggio tre. Lineare 🙂

Bonus: il dominio che indicate in fase di apertura di un account GA non è rilevante o vincolante ai fini della raccolta dei dati. Analytics raccoglie i dati da qualsiasi pagina su qualsiasi dominio nella quale ci sia il vostro codice di monitoraggio (a meno che non abbiate dei filtri sul nome host, chiaro). Per questo motivo alla domanda: “devo fare qualcosa al codice se sposto il sito da un dominio a un altro”? la risposta è sempre “se non hai filtri sull’host, no!”.


Apr 12 2011

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti semaforo giallo - articolo avanzato semaforo rosso - articolo per esperti

La più grande promessa mancata di Analytics

autore: Marco Cilia categoria: generale

Breve e conciso: il tracciamento dei link in uscita.

La prima volta che ho sentito dire “sarebbe bello che tracciasse automaticamente i link in uscita” deve essere stato il mese dopo il lancio del prodotto, quindi sei anni fa. La prima volta che ho sentito dire a un ingegnere di Google “vi daremo il tracciamento automatico dei link” non la ricordo con esattezza, ma si parla comunque di oltre tre anni fa. Poi qualcuno scoprì che il report era bello e pronto, e che le funzioni necessarie erano già presenti nel javascript, ma niente. Anche nella nuova versione v5 di prossimo rilascio, di quella funzionalità non c’è traccia.

D’accordo che le alternative sono tante, ma perché esattamente ci vuole così tanto ad attivare una funzione usata da tantissimi utenti?


Apr 05 2011

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti semaforo giallo - articolo avanzato semaforo rosso - articolo per esperti

Più dati nelle richieste di GA

autore: Marco Cilia categoria: codice di monitoraggio

Come spiego sempre durante i miei corsi, ogni singola azione che l’utente compie nel nostro sito e che deve essere trasmessa a Google Analytics, sia essa una pagina vista, una transazione ecommerce o un evento, necessita di una chiamata a una immagine .gif trasparente 1×1 pixel, a cui sono “appesi” una serie di parametri che poi il sistema trasforma nei dati che vediamo nei report.

Questa richiesta è sempre stata trasmessa con il metodo HTTP GET, che ha una limitazione tecnica di 2048 byte; le richieste che eccedevano questo limite venivano troncate, e i dati persi. Ad esempio se nella stessa richiesta state impostando 5 variabili personalizzate con nome+valore abbastanza lungo, potreste incorrere in quel limite.
Il blog ufficiale di GA ieri ci ha informato che da adesso lo script è in grado autonomamente di capire se la richiesta che stiamo per fare eccede quel limite, ed eventualmente se lo fa trasmetterla ai server di Analytics usando il metodo HTTP POST, che ha una limitazione quattro volte più alta: 8192 bytes.

Ovviamente la nostra speranza è anche un’altra: se c’è più spazio per inviare informazioni, Analytics potrebbe darci più spazio per memorizzare “cose”: ad esempio potrebbero aumentare il numero di variabili personalizzate possibili 🙂


Mar 14 2010

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti semaforo giallo - articolo avanzato semaforo rosso - articolo per esperti

riscrivere tutte le URL con _trackPageview()

autore: Marco Cilia categoria: codice di monitoraggio

Sempre il buon Andrea mi pone una domanda, e ne approfitto di nuovo per un post: mi fa sempre piacere scoprire cosa non è chiaro alle persone, dato che io con Google Analytics ci faccio anche colazione e quindi tendo a dare per scontate troppe cose 🙂

Il suo quesito è all’incirca “Non sono d’accordo con una persona che sostiene che trackpageview può essere utilizzato anche per rimappare l’url corrente della pagina e fare in modo che sia possibile poi utilizzare il nuovo indirizzo all’interno dei goals per verificare chi converte e chi no. Io ritengo che la funzione del trackpageview è quella si di assegnare una pagina virtuale, ma nel caso in cui si scateni un evento a cui questo è stato associato”

L’errore nasce dal fatto che _trackPageview noi lo vediamo solo in due forme. La prima è all’interno del codice di monitoraggio classico, dove viene sempre richiamata senza parametri, la seconda è quando creiamo pagine virtuali e quindi le passiamo come parametro un indirizzo fittizio. La funzione in realtà è sempre la stessa, e il suo scopo è quello di “fare il punto della situazione” nel codice di monitoraggio, scrivere i cookie nel computer del visitatore e sparare i dati verso i server di Google. Se non gli si passa un parametro, essa invia per impostazione predefinita l’url corrente della pagina così com’è.
Ma nessuno ci vieta, ad esempio, di usare una funzione lato server per inserire dinamicamente all’interno di un codice di monitoraggio degli indirizzi più leggibili ai fini delle nostre analisi.

Ipotizziamo di non avere modo di riscrivere le URL attraverso i metodi “normali” – quali .htaccess o filtri ISAPI per webserver Microsoft – e di aver scritto una funzione in PHP (abbellisciURL() ) che ci restituisce un simil-URL nella forma /categoria/marca/nomeprodotto.html

Se modificassimo il GATC così


<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
try{
var pageTracker = _gat._getTracker("UA-xxxxxx-x");
pageTracker._trackPageview(<?php abbellisciURL(); ?>);
} catch(err) {}</script>

dentro a Google Analytics avremmo SOLO ED ESCLUSIVAMENTE i nostri url abbelliti.

Potrete poi usare questi url per definire gli obiettivi? ASSOLUTAMENTE SI, dato che non sappiamo esattamente QUANDO GA elaborerà i dati, e dato che gli url modificati sono I SOLI ad essere stati inviati ai server di Google, è assolutamente lecito e possibile definire dei goal usando gli url fittizzi. Anzi, non potreste fare altrimenti!

_trackPageview() quindi si rivela anche un potente strumento per rendere i vostri report più semplici e chiari, più leggibili, ed eventualmente anche per facilitarvi la vita nell’impostazione degli obiettivi.