Google Analytics in 30 secondi

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()]

Mi sembra di intravedere una certa regolarità negli upgrade ad Analytics da parte di Google; a giro si dedica alll’interfaccia, alle funzionalità e all’integrazione. Direi che questo è il periodo dell’integrazione, e infatti abbiamo due novità relative ad AdWords nel giro di pochi giorni.

La prima è che adesso si possono importare gli obiettivi di conversione e le transazioni e-commerce da Analytics ad AdWords, per ottimizzare le campagne direttamente dentro ad esso e poter usare lo strumento di ottimizzazione delle campagne. Stiamo parlando però, ovviamente, di obiettivi che ricevono traffico (e conversioni) da campagne AdWords.
I passi da effettuare per avere questa integrazione sono abbastanza semplici: per prima cosa è necessario abilitare la condivisione dei dati almeno con i prodotti Google (“Solo con altri prodotti Google”), dal menu Modifica dell’account -> Condividi i miei dati Google Analytics, dopodiché dall’interfaccia AdWords, pagina delle conversioni, cliccare su “collega obiettivi e transazioni di Analytics”, selezionare quali obiettivi importare dalla lista e salvare.

La seconda novità è che Google ha sanato una situazione che si era venuta a creare a Marzo, quando per motivi di sicurezza venne richiesto che l’import dei costi AdWords verso Analytics fosse possibile solo dopo aver collegato i due account. Coloro i quali avevano gli account collegati, avevano l’auto tagging delle campagne ma non applicavano l’import dei costi si erano ritrovati a vedere come diretto del traffico che in realtà veniva da AdWords. Da oggi questo problema non si presenta più e il traffico torna ad essere conteggiato come mezzo cpc e sorgente google.

Sul forum ufficiale di Google Analytics da qualche tempo appaiono e continuano ad apparire richieste di correzione di un errore che attribuisce le visite al traffico diretto invece che al traffico pagato. Una cosa analoga era successa ai primi di marzo, ma era rientrata da sé; questa volta invece il problema perdura.

La prima cosa da sapere è che non si tratta di un baco, né di un errore. Leggendo questo topic una dipendente di Google ha detto ufficialmente

Please check if auto-tagging is enabled and cost data is applied. Going forward, your CPC data will be reported only if these two are enabled. If you enable auto-tagging and do not apply cost data, you will see an increase in direct traffic.

(per favore controlla se hai abilitato l’autotagging e l’import dei costi. D’ora in avanti, i dati CPC saranno riportati solo se hai abilitato entrambe le opzioni. Se abiliti l’auto-tagging ma non applichi l’import dei costi, vedrai un incremento del traffico diretto)

La modifica è avvenuta tra il 23 e il 24 marzo, ma la cosa assurda è che non se ne fa menzione nè sul blog ufficiale di Adwords né su quello di Analytics.

Se avete un account Adwords collegato a quello di Analytics è probabile che abbiate sentito parlare del famoso doppio filtro per avere le chiavi cercate invece di quelle acquistate. Le istruzioni per creare il filtro sono in questo post su semvironment, e una discussione sull’argomento è sul forum Seonida.
Non mi dilungo sul filtro perché non è oggetto di questo post.

Una domanda che mi è stata fatta ieri è questa:

Il Campo A del filtro personalizzato del primo passo di estrazione delle chiavi cercate, tira fuori dal Referral la sequenza (\?|&)(q|p|qs|_nkw)=([^&]*)

Il Campo B tira fuori dal Mezzo della Campagna cpc|ppc
L’output finisce in Campo personalizzato 1, con la stringa $A3

Ma allora, il campo B a che serve, visto che nel campo personalizzato 1 non si prende il considerazione?

La risposta sta in questa immagine, presa dal post di semvironment

Il campo B in effetti guarda dentro al mezzo della campagna e capisce se questo mezzo è cost per clic o pay per clic, ma non fa altro. L’output di quella parte di filtro non solo non viene estratto, ma non verrebbe nemmeno salvato per un uso successivo nè trascritto in un altro campo. A tutti gli effetti quello è un campo che potremmo definire “di controllo“, poiché è un campo obbligatorio ma non genera un output. Se però la condizione non è soddisfatta, se l’output fosse vuoto, il filtro non agirebbe, perché appunto l’impostazione è “campo B obbligatorio”.

Nello specifico un controllo sul solo referrer non è sufficiente, perché non è affatto scontato che il referrer (un qualsiasi referrer) non contenga almeno un parametro tra q, p e qs. Più difficile, ma non impossibile, _nkv…
Il campo B quindi serve solo ed esclusivamente a prevenire che un referrer con uno di quei parametri possa mettere erroneamente in azione il filtro.