Google Analytics in 30 secondi

Google ha scritto sul proprio blog ufficiale di Analytics che sta testando un plugin per browser in grado di evitare che gli utenti che non lo desiderano vengano tracciati.
Esistono già parecchi modi per fare questa operazione, ma la maggior parte di essi presuppone conoscenze tecniche; gli altri non hanno quasi mai avuto la fama necessaria. Il fatto che il plugin sia sviluppato da Google stessa invece ci fa ben sperare sulla sua possibilità di arrivare a una massa critica.

Dal punto di vista di chi invece le statistiche le guarda, invece, questa forse non è una buona notizia: significa che chi lo desidererà diventerà completamente invisibile ai vostri occhi. Si tratta di un altro passo verso il pieno rispetto dei requisiti che un sistema di web analytics serio deve rispettare: Yahoo Web Analytics offre già un link dove impedire che i futuri cookie del suo sistema vengano scritti sul proprio computer (qua l’indirizzo), idem Webtrends (ecco la pagina, il link è piccolo in fondo). Esiste anche una specifica pagina che raccoglie tutti questi link, su world privacy forum.
Il problema di questi sistemi è che si basano su cookie tanto quanto i sistemi di web analytics, quindi soffrono del problema della cancellazione dei cookie da parte dell’utente/azienda. Il sistema di Google sarà basato sul browser (quale browser, però? tutti?) e dovrebbe esserne immune: chissà se anche altri vendor di sistemi di web analytics vorranno salire sul carro e approfittare dell’occasione, o se resteranno con i loro invisibili link e un metodo che prima o poi tende a far ritracciare l’utente.

Recentemente le autorità tedesche avevano ribadito la necessità di un sistema di opt-out chiaro per i sistemi di web analytics, e poiché anche per questo GA era finito sulle prime pagine delle testate informative in Germania, la mossa mi sembra alquanto scontata.

Ecco un interessante script realizzato da Allaedin Ezzedin di e-nor, che permette di conoscere in tempo reale quale è la fedeltà del visitatore. La fedeltà è espressa in Google Analytics dal numero di visite – compresa quella corrente – che ogni utente ha fatto sul vostro sito. Nei report trovate questa informazione cliccando su VISITATORI -> fedeltà visitatori -> fedeltà.

Nei segmenti avanzati è invece possibile guardare solo il traffico realizzato – ad esempio – da chi è alla decima visita (e SOLO alla decima) creando un segmento con i parametri conteggio delle visite -> corrisponde esattamente -> valore: 10.
Se ad esempio vi accorgeste che in generale l’utente converte meglio tra la quarta e la sesta visita, come potreste usare questa informazione? non sarebbe bello potergli presentare una call-to-action personalizzata, magari in una posizione ancora più favorevole? o al contrario, potreste usare l’informazione per cercare di migliorare le conversioni nelle visite che il report vi dice non convertono mai.

Lo script di Allaedin serve proprio a questo: permette di leggere il cookie __utma del visitatore e quindi di sapere il numero di visita nel quale esso ricade. Lo script è questo

function get_visit_count(str)
{
var i, vc='-';
if (str != '-') {
   i = str.lastIndexOf(".");
   i++;
   vc = str.substring(i);
   }
return vc;
}

e restituisce un numero intero corrispondente al numero di volte in cui l’utente che sta navigando è stato sul vostro sito.

Esiste anche la versione con il numero di pagine viste, però all’interno di una sessione: ad esempio potrebbe servirvi per “premiare” un visitatore che ha sorpassato le 20 pagine viste in una sola visita. Di nuovo, ecco il codice, questa volta basato sul cookie __utmb:

function get_pageview_count(utmb,utmc)
{
var i, j, pc='-';
if(utmb != '-' && utmc != '-'){
   utmc=utmc+'.';
   i=utmc.length;
   j=utmb.indexOf(".", i);
   pc=utmb.substring(i,j);
   }
return pc;
}

entrambi gli script sono disponibili in un file, scaricabile dal sito di e-nor.com, che contiene anche un altro pezzo di codice essenziale al funzionamento. Il file è disponibile nel post, e le istruzioni dicono di aggiungere la chiamata a SessionTracker.js subito DOPO il codice di Google Analytics, in modo che alle funzioni vengano passati i valori già aggiornati di visita e numero di pagine viste.

Marco, non mi ricordo mai quali sono i parametri obbligatori quando si crea una URL per una campagna di Google Analytics

Tranquillo, sei solo l’ultimo della serie, è una cosa comune (e comunque anche io ogni tanto devo dare una rinfrescatina 🙂 ). Come ho detto nel post dettagliato in cui descrivo come si gestiscono le campagne, i parametri obbligatori sono utm_campaign, utm_medium, e utm_source.

Ma che mondo sarebbe se qualcuno non si fosse preso l’onere di controllare se questa affermazione è totalmente vera? Così hanno fatto quelli di Lunametrics, arrivando a una conclusione inaspettata: fintanto che si include utm_source, la campagna funzionerà e il cookie __utmz verrà aggiornato correttamente, se invece il parametro manca il cookie non viene modificato affatto (esattamente come avviene usando il parametro utm_nooverride=1). L’inclusione del solo utm_source genera correttamente un record nel report campagne, attribuendo però al mezzo e alla fonte il valore di (not set).

Il consiglio dei ragazzi inglesi è quindi di mettere sempre per primo nell’URL l’utm_source, in modo che siano minimizzate le possibilità che esso venga troncato (si pensi ad esempio a un client email che fa l’accapo automatico dopo un tot di caratteri).

La cosa veramente buffa è che ho avuto un esempio sotto gli occhi per molto tempo, ma non ci ho mai fatto caso. Al vecchio URL cui puntava la campagna di Google Acqua che ho ospitato a inizio anno, e che è da poco tornata online, mancava del tutto il parametro utm_campaign, a meno che non fosse generato automaticamente lato server assumendo che tutti gli ingressi a quella pagina fossero provenienti dalla stessa – e unica – campagna.

Mi sono accorto che pur avendone parlato più volte non ho mai scritto il post di riferimento della funzione _setVar(stringa). Questa funzione serve a scrivere un valore all’interno del cookie __utmv, e il valore è a discrezione del webmaster del sito; una volta che il contenuto del cookie è impostato, esso verrà trasmesso in tutti i successivi invii di codice a Google Analytics (ovvero ogni volta che verrà richiamata la gif trasparente), permettendo così di “taggare” il visitatore (attenzione: il visitatore e non le visite).
Un esempio tipico è quello di assegnare tramite _setVar il valore “loggato” a chi effettua il login sul sito, in modo da poter discernere la sua attività da quella di chi non l’ha fatto.

L’uso è molto semplice, si tratta di impostare la riga

trackPageview._setVar('miovalore');

in un punto qualsiasi della pagina, sull’onclick di un elemento, sull’onload del body. Ovunque insomma ci sia bisogno di impostare il cookie che da lì in poi – e per i successivi due anni – manterrà il valore, a meno che esso non sia sostituito da un’altra funzione _setVar impostata dal medesimo codice di GA (quindi le _setVar di due siti diversi non interferiscono, come è ovvio che sia). Su un blog WordPress, ad esempio, sarebbe possibile assegnare un valore corrispondente al livello dell’utente che si collega (Administrator, Editor, Contributor, ecc.).
Il famoso sistema supercookie per tracciare tutte le fonti di una conversione separa diversi valori di setvar con un segno | (pipe), e lo fa per ovviare all’unico vero grande limite di questa gestione da parte di GA: esiste un solo cookie __utmv, quindi si può attribuire un solo valore ad ogni utente; oppure si possono assegnare più valori come nel supercookie, ma essi verranno sempre riportati come aggregati (per intenderci, ogni valore è una riga del report).
La speranza di tutti noi è che un giorno Google decida di aumentare i possibili valori di questo cookie mantenendoli però separati, perché la gestione della funzione _setVar() è molto comoda.

A livello di report il valore impostato da _setVar() viene scritto nel campo “Definito dall’utente” (User Defined se usi l’interfaccia inglese) e lo si può trovare nel report omonimo all’interno del gruppo “visitatori” oppure come valore utilizzabile nel menu a tendina delle segmentazioni. Una lettura esaustiva, in inglese, sui report relativi alla segmentazione viene da morevisibility.com, da cui si evincono due informazioni interessanti:

• nel caso in cui un utente cambi il valore di _setVar() durante una sessione di visita, GA attribuirà l’eventuale conversione al primo valore letto per quella sessione.
• le pagine viste, al contrario, vengono tutte attribuite all’ultimo valore

Un’altra cosa su cui vale la pena di ragionare è che _setVar() rappresenta l’unico punto di ingresso in GA in cui è possibile inserire un valore arbitrario. Tutti gli altri valori infatti dipendono dall’attività di navigazione e sono dati puri o derivati da calcoli. Questo cosa significa? significa che, fatte salve le limitazioni sulla privacy imposte dai termini del servizio, dentro al cookie __utmv possiamo infilare qualsiasi cosa ci sia utile avere direttamente dentro all’interfaccia di Google Analytics affinché possa essere incrociata con gli altri dati, ad esempio i dati demografici dei visitatori da utilizzare successivamente per il bidding demografico di AdWords.

[edit: è uscito giusto in questi giorni un post sul blog ufficiale che parla dei segmenti definiti dall’utente e di _setVar()]

Giovanni mi segnala per email un articolo molto molto interessante per chi ha il cruccio del last cookie win / first cookie win. Ricordo infatti a tutti che Google Analytics è un sistema “last cookie win”, in cui la conversione viene attribuita all’ultima sorgente che ha portato la visita, con alcune regole specifiche per il traffico diretto. Altri sistemi invece preferiscono la logica del “first cookie win” (e su GA possiamo impostarla sulle campagne taggate tramite il parametro no_override), ma quale che sia la logica applicata il difetto che tutti riconoscono è quello di non consentire di tenere traccia di tutte le diverse sorgenti che hanno contribuito a formare nel cliente la decisione di convertire.

So che alcuni sistemi stanno provando (non l’ho mai provato, e correggetemi se sbaglio, ma mi pare che sitovivo abbia una soluzione di questo tipo) a sviluppare logiche miste di attribuzione di una conversione a più sorgenti, ma da oggi grazie al lavoro di un Google Analytics Authorized Consultant possiamo avere qualcosa di similare – ancorché abbastanza di base – per tracciare tutte le sorgenti che hanno concorso ad una conversione: loro lo chiamano “super cookie“.

Questo super cookie si occupa di raccogliere il referrer di ogni visita, di salvarlo in un nuovo cookie chiamato _utmcw e di chiamare la funzione _setVar() impostando il valore di questo cookie come parametro della funzione stessa. I vari referrer non vengono sovrascritti ma messi in coda e separati da un carattere |.
Attraverso un rapporto personalizzato, composto almeno dal parametro “totale completamenti all’obiettivo” e della dimensione “valore definito dall’utente”, avremo modo di verificare tutte le sorgenti che hanno generato conversioni, nella forma (e nell’ordine esatto) ad esempio di:

direct|google(organic)(keyword1)|yahoo(organic)(keyword2)|direct|referral(www.sitoesterno.it)

che ad esempio si riferisce ad una conversione avvenuta alla quinta visita, la prima delle quali diretta (digitazione dell’url o bookmark, ad esempio), la seconda da google con ricerca keyword1, la terza da yahoo con ricerca keyword2, la quarta diretta e la quinta tramite un link dal sito sitoesterno.it. Tramite il super cookie si possono ad esempio conoscere esattamente TUTTE le parole chiave e le frasi che sono state cercate dall’utente prima di convertire

Il punto forte di questo script è che ricostruisce da solo la sorgente, evitando il problema della discrepanza di scrittura del cookie quando avvengono due referral nella stessa sessione di cui vi ho già parlato.

Il punto debole, come ho fatto notare nel post degli autori, è che non è previsto (ma non saprei nemmeno come implementare) un meccanismo di pulizia del super cookie, che continua ad essere aggiornato anche dopo la conversione. Per un visitatore regolare che non pulisce mai i cookie c’è il rischio che esso si gonfi senza sosta. Un punto intermedio è che il supercookie traccia e scrive solo visite provenienti dalle sorgenti “standard”, quindi traffico diretto, referral, ricerche organiche e CPC. Per tracciare anche le campagne, ad esempio le campagne email taggate, il sorgente javascript dello script andrebbe modificato, e sono sicuro che essendo GAAC loro possono sicuramente farvi avere un preventivo per questa operazione 🙂

L’utilizzo dello script è abbastanza semplice. si tratta di scaricare il file dal post linkato, aprire il file cw-algorithm.js e modificare la riga 7
var __ignore = "www.ignore.co.uk";
inserendo l’indirizzo del sito che ospita lo script. Dopodiché caricare i due file sul server web e modificare il codice di tracciamento di Analytics come segue:

<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" src="/cw-setup.js"></script> 
 
<script type="text/javascript"> 
var cookieTracker = _gat._getTracker("UA-XXXXXX-X");
cookieTracker._trackPageview();
</script> 
 
<script type="text/javascript" src="/cw-algorythm.js"></script> 
 
<script type="text/javascript"> 
cookieTracker._setVar(ConversionWorks);
</script> 
 
<script type="text/javascript"> 
var pageTracker = _gat._getTracker('UA-XXXXXX-X');
pageTracker._trackPageview();
</script> 

sostituendo ai vari UA-XXXXXX-X il vostro numero di UA. Notare che la parte di codice riferita a cookieTracker non è un errore, e serve a non sporcare i vostri cookie di default con i valori del super cookie.

In definitiva mi sembra un’aggiunta utile a chi non è soddisfatto del modo in cui vengono attribuite le conversioni alle sorgenti, e una fonte di informazioni utili a prescindere per tutti gli altri. Se il vostro “Valore definito dall’utente” (e/o la vostra funzione _setVar() ) è vuoto, questo può sicuramente essere un sistema valido per usarlo.

Post originale su conversion works e pacchetto da scaricare

image credit: conversionworks.co.uk

Come vi ho detto qualche tempo fa, nei nuovi codici di monitoraggio che copiaincollate da Google Analytics è sparita la riga relativa a initData(), funzione soppressa dagli ingegneri di Google e chiamata implicitamente ed automaticamente dallo script. Se non avete provveduto a modificare i vostri codici di tracciamento (GATC) avete, appunto, uno zombie in casa: una funzione morta che cammina ancora tra le vostre pagine 🙂

Non fa male, di per sé, tranne per il caso citato oggi da Lunametrics, ovvero se avete alcune pagine con initData e alcune pagine senza; ad esempio perché avete aggiunto delle pagine nuove e avete copiato il codice dal pannello di Analytics invece che da una vostra pagina vecchia. In questo caso i cookie di GA possono essere scritti in forme leggermente differenti, e questo è fonte di errori e perdita del tracciamento del percorso del visitatore, quindi è male.
E’ un problema che nemmeno i controlli automatici come SitescanGA possono individuare, per cui è vostra cura assicurarvi di avere un GATC coerente su tutte le pagine.

Ricapitolando quindi le due regole fondamentali:

• non possono coesistere chiamate a urchin.js e ga.js nella stessa pagina; possono coesistere nello stesso sito, ma è sconsigliato. Se possibile usate solo ga.js
• se avete codici che contengono la chiamata a initData() dovrete scegliere se rimuoverla da tutte le pagine in cui è presente o aggiungerla in tutte le pagine in cui è assente

Quando le cose da tenere d’occhio iniziano ad essere molte e variegate bisogna fare attenzione: Google Analytics fornisce gli strumenti, ma bisogna stare attenti a possibili effetti collaterali non documentati. Prendiamo ad esempio l’ultimo post di Lunametrics, che riporta una situazione con un codice di monitoraggio per più domini di questo tipo:

var pageTracker = _gat._getTracker("UA-xxxxxxx-y");
pageTracker._setVar(’buyer’);
pageTracker._setAllowAnchor(true);
pageTracker._setAllowLinker(true);
pageTracker._setAllowHash(false);
pageTracker._trackPageview();

questo codice inizializza l’oggetto di tracciamento, poi scrive nel cookie __utmz il valore buyer (ovvero assegna il visitatore al segmento compratori), poi permette l’uso del cancelletto nelle campagne, poi permette di trasportare il cookie da un dominio a un altro, disabilita il check dell’integrità dei cookie basato sul dominio (quando si raccolgono dati da più sottodomini in un unico account), e infine raccoglie i dati e li invia al server di Google.

Quale è il problema di questo codice? il problema è che _setAllowHash di fatto cambia il formato di scrittura del cookie, e ci sono due funzioni che scrivono cookie: _setVar che si trova prima di setAllowHash e trackPageview che invece si trova dopo.
In questo modo GA va in confusione e perde informazioni sulla sessione e sul referrer, assegnando a traffico diretto la seconda – falsa – visita.

La soluzione è quella di chiamare _setVar() sempre dopo _setAllowHash() (o _setDomainName(‘none’); se lo usate); bisogna sempre tenere presente che il javascript di Google Analytics ha a che fare con i cookie, e che alla fine sono loro che “comandano” quel che poi vediamo nei nostri report.

Ho letto questa notizia su tre diversi blog, ma ho aspettato a segnalarla finché non è apparsa su una fonte che ritengo autorevole: Google ha modificato il modo in cui conteggia i bounce rate in presenza della funzione _setVar(). [edit: ecco il post sul blog ufficiale | e in italiano]

Fino ad oggi se un visitatore guardava una sola pagina, non veniva conteggiato come bounce se nella stessa pagina chiamavate la funzione _setVar(), che serve ad attribuire il visitatore ad un segmento personalizzato tramite scrittura del cookie aggiuntivo __utmz. Infatti per ovviare a questo problema Lunametrics aveva proposto un workaround che vi segnalai a tempo debito.

Da oggi questo fatto non è più vero, e una visita di una sola pagina vista sarà considerata un bounce a prescindere dalla presenza della funzione. Tra le altre cose questa modifica si rifletterà anche sul tempo medio sul sito e sulla pagina, poiché in presenza di due timestamp GA è in grado di calcolare un tempo, cosa che invece ovviamente non può essere vera per un utente che rimbalza. In precedenza invece Analytics assegnava tempi brevissimi (zero, uno o due secondi, a seconda della velocità di caricamento della pagina e del tempo trascorso tra la chiamata a _trackPageview() e _setVar() ) alla pagina.

Da quel che ho capito, il comportamento non cambia in presenza di un evento, come scrissi in questo post

Image credit: Greencolander on Flickr

La funzione che va maggiormente tenuta da conto quando si instaurano delle campagne è _setCookietimeout(stringa); il motivo risiede nella gestione del cookie __utmz da parte dello script di Analytics: il cookie contiene le informazioni relative alla provenienza, ad esempio:
205114892.1220963346.1.1.utmccn=(organic)|utmcsr=google|utmctr=world+browser+stats |utmcmd=organic
(si viene da una ricerca su google con chiave “world browser stat”)

oppure:
219072577.1223545748.1.1.utmgclid=CITpr_XumZYCFQVOtAodAmkD7g|utmccn=(not%20set)|utmcmd=(not%20set)|utmctr=hotel%20roma
(provenienza campagna AdWords con chiave “hotel roma”)

Questo cookie ha una vita predefinita di sei mesi, o meglio 15.552.000 secondi, e le informazioni contenute sono sovrascritte secondo le famose regole:
– Le visite provenienti da una campagna, un referral, una visita organica o un adword aggiornano sempre il cookie.
– Il traffico diretto viene sempre sovrascritto da referrer, organico e campagne taggate o adword.

Questo significa che se un visitatore arriva sul vostro sito tramite una ricerca da Google per “hotel roma” e poi se ne va, per i successivi sei mesi una sua eventuale visita diretta con conversione verrà attribuita a Google organico. Allo stesso modo, se proviene da una campagna fatta su una mailing list, si salva l’indirizzo nei preferiti e poi torna dopo cinque mesi e converte, la conversione è assegnata alla campagna della mailing list.

Per vari motivi questo tempo può essere ritenuto inaccettabile: Google Analytics mette a disposizione la funzione setCookieTimeout per prendere il controllo della data di scadenza del cookie __utmz. La funzione prende in ingresso come parametro il numero di secondi trascorsi i quali il cookie scadrà e il visitatore smetterà di essere marchiato con la campagna. Si usa così:
pageTracker._setCookieTimeout("5184000");

Vi lascio anche un breve elenco di date convenzionali trasformate in secondi:
1 giorno = 86400 secondi
7 giorni = 604800 secondi
14 giorni = 1209600 secondi
15 giorni = 1296000 secondi
30 giorni = 2592000 secondi
60 giorni = 5184000 secondi
90 giorni = 7776000 secondi
120 giorni = 10368000 secondi
180 giorni = 15552000 secondi

Uno dei grafici più noti e familiari che si vedono quando si accede alla dashboard dei profili è quello delle fonti di traffico, a meno che non sia stato eliminato per scelta. Rappresenta, come noto, la ripartizione percentuale delle provenienze dei visitatori, e di solito ha tre colori, rosso, verde e blu che rappresentano le tre fonti “classiche” di traffico: le visite dirette, i siti di riferimento e le visite da motore di ricerca.

(due diversi grafici delle fonti di traffico)

In alcuni casi però il grafico si presenta con quattro colori, aggiunge il giallo, e la quarta fonte è “altro”; questo significa che abbiamo iniziato a usare e gestire le campagne. La gestione delle campagne è un passaggio praticamente obbligato nella vita del monitoraggio di un sito web tramite Google Analytics, poiché ci consente di sapere con esattezza quale fonte invia quali visitatori, quale banner porta più conversioni, quale servizio porta visite più qualificate. A differenza delle fonti “tradizionali” le campagne sono impostate da noi e sono molto più granulari: possiamo avere una campagna su una sola pagina di un sito, su tutte le pagine di un sito oppure tre campagne diverse sulla stessa pagina. si può usare la stessa campagna su una newsletter oppure usare una campagna per ogni tipologia di destinatario, e ancora usare campagne differenti per due link differenti nella stessa newsletter. Poiché la gestione è nostra, non c’è limite di utilizzo, salvo poi la difficoltà di lettura dei report.

Come si crea una campagna? A differenza degli obiettivi non c’è bisogno di fare nulla nell’interfaccia di GA, una campagna parte nel momento in cui la prima visita arriva tramite un link opportunamente preparato (“taggato”) con alcuni parametri. Questi parametri possono essere fino a cinque, e precisamente:

• utm_campaign: è il nome della campagna. Va pensato come a un “contenitore” delle varie attività di promozione tramite campagne che ci apprestiamo a fare. Ad esempio per lanciare un prodotto potremmo fare campagne su newsletter, link da siti partner e banner, ma il nome della campagna sarà comune e sempre uguale, ad esempio “lancio XR100”
• utm_medium: è il mezzo della campagna, il veicolo attraverso il quale la campagna giunge ai potenziali clienti. Va pensato rispondendo alla domanda “tramite quale mezzo sto lanciando il messaggio?” (ad esempio: email, banner, affiliazione, ecc.)
• utm_source: è la fonte delle visite, la provenienza dei visitatori per quella campagna e risponde alla domanda “chi?” (esempio: goanalytics.info, google, sito honda italia)
• utm_content: è il contenuto dell’annuncio, e può essere usato per dare maggior dettaglio o per scopi di test, ad esempio facendo un test A/B per capire quale annuncio genera i risultati migliori.
• utm_term: è il termine comprato, nel caso si stia taggando una campagna di keyword advertising.

Di questi cinque parametri, solo i primi tre sono obbligatori. Tecnicamente non è del tutto vero, ma per comodità si assume che sia così: usandoli tutti e tre si usufruirà in toto dei benefici della gestione delle campagne. Per avviare una campagna si dovrà quindi provvedere a modificare il link che punta al nostro sito aggiungendo questi parametri. Ipotizziamo che stiamo lanciando il prodotto XR100 e che abbiamo approntato una pagina apposita sul nostro sito, www.miosito.it/xr100.php. la prima campagna viene effettuata sulla newsletter in questo modo:
http://www.miosito.it/xr100.php?utm_source=newsletter&utm_medium=email&utm_campaign=lancio-xr100

la seconda campagna è un banner sul sito di honda italia
http://www.miosito.it/xr100.php?utm_source=honda-italia&utm_medium=banner&utm_campaign=lancio-xr100

il terzo caso riguarda due link presenti su un sito affiliato, che decidiamo di studiare particolarmente perché in passato campagne simili hanno dato risultati contrastanti. Saranno inseriti due link, uno nella sidebar di tutte le pagine e uno nel footer di tutte la pagine.
Il link nella sidebar sarà
http://www.miosito.it/xr100.php?utm_source=sitoaffiliato.com&utm_medium=link&utm_content=sidebar&utm_campaign=lancio-xr100

mentre quello nel footer
http://www.miosito.it/xr100.php?utm_source=sitoaffiliato.com&utm_medium=link&utm_content=footer&utm_campaign=lancio-xr100

In questo modo, andando a scavare nel report sorgenti di traffico -> campagne sarà possibile capire con esattezza quale di questi mezzi ha generato più conversioni e addirittura quale sia la posizione più redditizia per inserire un link su sitoaffiliato.com nella prossima campagna.
Per facilitare la creazione di url taggati correttamente Google mette a disposizione uno strumento di costruzione degli URL raggiungibile a questa pagina del supporto.

E’ necessario ricordare ancora una cosa sulle campagne: quando un visitatore clicca uno dei link taggati in questo modo il cookie utmz viene opportunamente modificato per registrare questa informazione; come già visto in precedenza, però, per due click da campagne successive il cookie viene sempre modificato, e la conversione viene attribuita all’ultima campagna cliccata. Per ovviare a questo comportamento vi ho già parlato del parametro aggiuntivo utm_nooverride=1.