Jan 13 2016

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

La dimensione “dimensione del browser”

autore: Marco Cilia categoria: report tag: , ,

Il sempre ottimo blog di e-nor qualche giorno fa ha postato una cosa interessante: è disponibile la dimensione “browser size” nei report (nell’interfaccia italiana si chiama “dimensione del browser”).
Che GA collezionasse questo dato è noto da tempo; possiamo infatti risalire sino a questo post del 2012 e all’uso che ne fecero con il non brillante report “dimensione del browser” all’interno dei non brillanti report di InPage Analytics.

Ora, qualcuno a Mountain View deve averci pensato sopra e deve aver detto “che diamine, lasciamo che le persone ne facciano un po’ quel che gli pare, esponiamo il dato come semplice dimensione”. Detto fatto, tra le dimensioni secondarie ecco comparsa “dimensione del browser“. Attenzione, la dimensione del browser è diversa dalla risoluzione dello schermo: specialmente su schermi grandi è difficile che gli utenti navighino con browser a schermo pieno, e in ogni caso il viewport (lo spazio effettivo per il contenuto) non sarebbe lo stesso uguale allo schermo.

La prima considerazione saltata in mente ai ragazzi di e-nor è “usiamola per vedere chi genera visite fraudolente”, ad esempio con degli iframe a 0 pixels tipici degli affiliation più subdoli. Come vedete dal loro screenshot, si tratta di un fenomeno reale

Il loro consiglio è quello di raggruppare tramite un filtro tutte le dimensioni sospette, per avere il colpo d’occhio della situazione.

La seconda intuizione è nei commenti su Google+: “possiamo usare questa informazione per combattere i ghost referral“? si e no.
Si, perché se fate due prove vedrete che alcuni ghost referral rientrano nella regular expression suggerita: ^0x|x0$
Si, perché altri (molti) ghost referral hanno semplicemente (not set) come dimensione del browser
No, perché anche visite legittime hanno (not set): non sono molte, ma se a GA non arriva quell’info mentre le atre si, ci scrive (not set).
No, perché anche questa dimensione può essere inviata tramite measurement protocol ( si veda qui ) quindi tra qualche tempo gli spammer bypasseranno anche questo blocco

I benefici sono quindi tutti in termini di studio della UI/UX e di effettiva visibilità degli elementi in pagina.


Jan 06 2016

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

Sessioni, utenti, conversion rate

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

Ciao, e buon anno innanzitutto. Le meritate ferie mi hanno dato il tempo di leggiucchiare qua e là alcune cose su Google Analytics, e sono rimasto un po’ colpito da questo articolo di qualche settimana fa: Why You Shouldn’t Trust the Conversion Rate in Google Analytics. Il titolo, come al solito, mi sembrava un po’ troppo altisonante per essere davvero concreto, per cui mi sono immerso nella lettura.

Il presupposto esplicitamente citato in apertura è: “che succede se il tool non riporta quel che la gente si aspetta che riporti? che accade se non puoi fidarti di tutte le metriche su GA?” roba bella tosta, non credete? e così ci addentriamo nella lettura e scopriamo che il motivo per cui – secondo l’articolo – non potete fidarvi dei dati è che… le sessioni non sono i visitatori. Pensa te! (peraltro l’ultimo dei quattro punti – se un visitatore inizia la sessione su un sottodominio e poi passa al principale, inizia una nuova visita – è anche falso se avete configurato bene tutto o se usate Universal Analytics). L’articolo prosegue, cito traducendo, con la frase “L’errore è di equiparare una sessione a un visitatore”. Il conversion rate dell’ecommerce è calcolato sulle sessioni (transazioni * 100 / sessioni). La soluzione è usare delle custom dimension che registrino uno userID.

PERBACCO NO! la soluzione è: IMPARA A LEGGERE I REPORT PER QUEL CHE SONO! (e se proprio vuoi usare uno userID, abilita una vista userID enabled con Universal Analytics!). Ma chi ha mai detto che il fulcro di GA siano i visitatori? GA è da sempre uno strumento “session based”, e tutti i report sono costruiti su questo concetto. Soltanto da qualche tempo si inizia a parlare di report “user based”, e ovviamente il futuro è di trasformare tutto il sistema in qualcosa incentrato sull’utente. Ma sino a che questo non accade, lo strumento fa i report per come è progettato, e questo non c’entra nulla con la fiducia nei dati sottostanti!

Il secondo punto è a mio avviso ancora più debole: in soldoni dice che il bounce rate di per sé non indica nulla sulla bontà o meno della qualità della visita ricevuta. Bella forza! Se l’utente arriva, e senza fare nulla legge un numero di telefono sulla pagina, chiama e compra servizi per 4000 euro, GA segna un bounce a fronte di un grosso incasso. L’articolo ci rende edotti sull’esitenza di un “adjusted bounce rate”, di cui ho parlato secoli fa, e su cui ho anche già espresso le mie perplessità: dovrebbe essere basato sullo scrolling? o sul tempo di permanenza? se è basato sullo scrolling e il numero di telefono dell’esempio sopra è above the fold non cambia nulla. Se è basato sul tempo bisogna trovare un tempo sensato, e in ogni caso il sistema continua a non dirci se l’utente ha letto davvero la pagina o se gli ha squillato il telefono e s’è alzato dalla sedia…
Quindi ti ritrovi con più casistiche da interpretare, e con interpretazioni che dipendono strettamente da cosa hai scelto di fare. Anche questo però, ovviamente, non ha niente a che fare con quel che il sistema ti da di base e con la fiducia nei dati sottostanti.

Allora, già che ci sono, voglio porvi una domanda: voi nutrite dei seri dubbi sui dati di Google Analytics? se si, quali, in quale area, per quale motivo? intavoliamo una discussione sensata, nel caso…


Dec 16 2015

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

impariamo a parlare una lingua comune :)

autore: Marco Cilia categoria: generale tag:

Le incomprensioni cliente/fornitore esistono dalla notte dei tempi, sono anche un po’ figlie del fatto che ognuno sa fare il suo mestiere e non quello degli altri. Ma finché io che sono un web marketer non riesco a spiegare che problema abbia il motore della mia auto al meccanico, potrebbe anche starci. Quando fatico a capire quel che mi dice un altro web marketer, abbiamo un problema di comunicazione :)

Il web analyst poi è una bestia un po’ speciale, lo sappiamo: è abituato ai numeri e alla logica, e sebbene magari non sia al livello di nerdismo del programmatore, la barzelletta che ultimamente è ritornata in auge sui social

“Caro, stamattina me ne sono scordata… per favore fa’ un salto al supermercato, e compra una bottiglia di latte!”
“Certo cara, vado e torno!”
“ah… se ci sono le uova prendine sei ”
“Sicuro ! Ciao!”

Il marito va, e dopo un po’ ritorna con sei bottiglie di latte. La moglie :

“Ma perché hai preso sei bottiglie !?!?”

“Perché c’erano le uova.”

un po’ gli si addice. Per cui io, che magari sono anche particolarmente problematico, quando leggo una frase tipo

“ho bisogno di una vista delle sessioni organiche (con aggregazione mensile) da gennaio a novembre di tutta l’area XYZ.”

mi faccio tutte le seguenti domande:

  • vuoi una vista nuova filtrata su organic e la sezione? immagino di no, perché i dati varrebbero solo da ora in avanti
  • vuoi un segmento organico di quelli che vedono l’area XYZ?
  • ma quelli che vedono l’area XYZ, per te sono quelli che INIZIANO la visita su una pagina di quell’area o quelli che ci TRANSITANO in un momento qualsiasi della sessione?

Capite che la risposta (e i numeri conseguenti) varia parecchio a seconda di quel che si intende, e che una frase di una riga produce almeno tre domande importanti. Diciamo che con un po’ di fatica immagino cosa vorresti fare, ma tu poi mi rispondi con

“questo mi garantisce di vedere le visite da tutte le pagine dell’area XYZ?”

Oiboh, le visite sarebbero SU tutte le pagine dell’area XYZ (e ancora non sappiamo se vuoi sessioni/landing page, sessioni con segmento su “vede nella visita”, pageview uniche delle pagine dell’area o cos’altro), certamente non DA. le visite DA le pagine dell’area possono essere i referrer interni (ma non sono visite), ma non sappiamo se intendi DA pagina XYZ A pagina XYZ o DA pagina XYZ ad altre sezioni del sito, oppure al limite le visite che ESCONO dal sito (ma al più avremmo i click e i click unici)

Due righe che producono un bel po’ di questioni da risolvere, no? :)


Dec 11 2015

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

Smart Goals: lascia che Analytics decida le tue conversioni

autore: Marco Cilia categoria: generale tag: , ,

Se vi ricordate, ad aprile 2014 Google introdusse le liste di remarketing “smart”, ovvero liste create da un algoritmo per targhettizzare utenti ritenuti interessanti e con alta probabilità di convertire.
Oggi il blog ufficiale annuncia che una tecnologia simile, basata sul medesimo algoritmo di machine learning, è ora disponibile per creare Smart Goals (Obiettivi intelligenti nell’interfaccia italiana): ad ogni visita viene attribuito un punteggio, e le migliori vengono conteggiate come smart goal. Per farlo, l’algoritmo seleziona circa il 5% del miglior traffico AdWords e controlla comportamenti similari anche nel resto del traffico, determinando quindi le sessioni “migliori” da conteggiare negli obiettivi intelligenti.

I prerequisiti per usarli sono ovviamente aver collegato AdWords e Analytics, oltre al fatto di aver avuto nel mese precedente almeno 1000 click verso url inclusi nella vista dove si sta cercando di attivare gli smart goals. La view non deve ricevere più di 1 milione di hits al giorno (paradossalmente, gli utenti Premium hanno meno possibilità di usarli) e dovete aver abilitato la spunta nella condivisione dei dati dell’account con altri prodotti e servizi Google: sfortunatamente questo setting è quello più inviso al garante per la privacy sul tema cookielaw.

L’attivazione è abbastanza semplice, se avete tutti i requisiti necessari durante la creazione di un nuovo goal avrete la possibilità di selezionare “obiettivi intelligenti” come tipologia di goal; nessun altro setting necessario. La buona notizia è che in realtà il report relativo funziona già anche se non avete creato il goal (che comunque occupa uno dei 20 slot disponibili, esattamente come gli altri). Questo vi da la possibilità di comprendere come funzionerebbero già prima di attivarli. Perché allora consumare uno slot, direte? perché senza l’attivazione gli smart goal non possono poi essere importati su AdWords per ottimizzare le campagne, o per la creazione di custom report con la metrica apposita che viene creata.

Cosa ne dite, li attiverete o no?


Nov 14 2015

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

I primi dieci anni di Google Analytics

autore: Marco Cilia categoria: generale tag:

Brian Clifton qualche giorno fa postava su G+ che il compleanno di GA era il 10 novembre. Gli ho detto – linkando il post ufficiale del 2005 sul blog Google – che era il 14, e lui ha modificato il post. Due giorni fa Paul Muret ha scritto che era il 12. Noi, come da tradizione (ecco il 2009, il 2010, il 2011, il 2012 l’ho saltato, il 2013, e l’anno scorso) festeggiamo rigorosamente il 14.

Mantenendo il paragone con il crescere di un bambino, questo è l’anno dell’esame di 5° elementare, il primo vero e grande esame nella vita scolastica. Invece di soffermarci sul passato e chiedere, come fanno tutti, quale è la feature più apprezzata mai introdotta, facciamo il contrario: quale feature vi immaginate introdurranno da qui a un anno? e quale invece da qui a tre anni (cioè quando finirà le medie 😀 )?

In ogni caso, nonostante i termini del contratto indichino che i dati possono essere cancellati dopo 24 mesi, ecco uno screen di un profilo che esiste dal primo giorno di vita di GA:

le prime hit di GA
prime-hit

10 anni di dati (click per ingrandire)
10-years-of-data


Nov 12 2015

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

Lo strano caso del campionamento invisibile

autore: Marco Cilia categoria: generale tag:

L’altro giorno mi è capitato uno di quei casi da Sherlock Holmes che all’inizio sembra che vada tutto a rotoli, ma poi si risolve brillantemente escludendo tutte le possibilità e osservando bene, proprio come il buon vecchio investigatore ci ha insegnato a fare (a dire il vero, sono un patito della versione interpretata da Benedict Cumberbatch, così lo sapete :) )

Il problema suona all’incirca così: “Marco, succede che selezionando i dati di un mese ho queste transazioni da cpc, ma se applico la dimensione secondaria categoria del dispositivo, sono meno. I dati non sono campionati”. (se ti serve un ripassino di cosa sia il campionamento…)
Ovviamente la cosa non ha senso, vista da questa prospettiva, per cui come al solito debbo smanacciare un po’ con i dati direttamente per capire sino in fondo cosa succede. Ecco le mie prove:

  • seleziono il mese, vado nel report acquisizione -> tutto il traffico, seleziono solo google / cpc, mi annoto le transazioni (661), applico la dimensione secondaria categoria del dispositivo, guardo le transazioni: 655. L’occhio si sposta sul riquadro del campionamento, il rapporto è basato sul 100% delle visite
  • torno indietro al report tutto il traffico, FILTRO per google / cpc, mi annoto le transazioni (661). Il report è preaggregato, e non sarebbe campionato nemmeno con 20 milioni di visite, quindi il numero è corretto. Applico la dimensione secondaria categoria del dispositivo, guardo le transazioni: 655. Il rapporto è basato sul 100% delle visite
  • mi sposto nel report mobile -> panoramica, applico la dimensione secondaria sorgente / mezzo, FILTRO AVANZATO per google / cpc e guardo le transazioni: 655. Anche qui 100% di campionamento.
  • Applico un segmento avanzato su google / cpc: 655 transazioni. Lo tolgo, 661 transazioni da cpc. Sempre 100%
  • Custom report, stessi risultati
  • Cambio approccio: invece di usare categoria del dispositivo, uso un’altra dimensione: stesso comportamento. Rapporti basati sul 100% delle sessioni. Inizio a temere un bug di Google Analytics
  • Abbandono la ricerca su cpc e faccio le stesse prove sui totali. Invece di 6, mancano in tutto 22 transazion

Ho provato moltissime combinazioni di custom report, segmenti, dimensioni secondarie, ma il problema invariabilmente si presentava. I dati considerati erano quelli di gennaio 2015. Sui dati di novembre, niente problema. Ma allora che cavolo di bug è? proviamo con i dati di febbraio 2015: perfetti, il totale con e senza dimensione secondaria combacia. Marzo 2015, problema presente. Testo i dati 1-15 gennaio, combaciano. 16-31 gennaio, combaciano. Faccio la somma a mano e viene 661. Rimetto tutto gennaio, GA mostra 655. La cosa prende una piega terrificante. Sposto l’attenzione sulle sessioni, anche quel numero non combacia con la dimensione secondaria applicata o senza. Mi gira la testa…

Ci prepariamo a scrivere a Google, con copiosi screenshot a supporto della nostra bizzarra situazione, quando alla review finale ho l’illuminazione. GA ha presumibilmente si un baco, ma non è dove crediamo che sia. Riguardo gli screenshot per assicurarmi che si veda bene che segni sempre 100% di campionamento e noto il numero totale delle sessioni del mese: 503.472. Ferma tutto, da che mondo e mondo, con il selettore su “report più lenti, maggior precisione”, il sistema non campiona se non deve fare calcoli su meno di 500.000 visite. Quindi qui ce ne sono di più, poche di più… vuoi vedere che?

500.000 / 503.472 * 100 = 99,31%

BINGO! il bug è che il riquadro, sebbene normalmente istruito per mostrare due decimali nel fattore di campionamento, arrotonda lo stesso 99,31 a 100. Quindi sta campionando, ma non sembra. Il che significa anche che in quelle 3.472 sessioni che mancano quando campiona su 500k ci sono 22 transazioni, con un conversion rate dello 0,63% che è perfettamente in linea con la media del sito in questione, e che conferma la bontà dell’algoritmo di campionamento.

Moriarty, c’hai provato anche ‘sta volta ma t’è andata male! 😀


Oct 22 2015

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

Un esempio d’uso delle nuove metriche calcolate

autore: Marco Cilia categoria: report tag: ,

Come sarebbe a dire “quali metriche calcolate?” Non avete letto l’annuncio sul Google+ di Analytics? :)

Le metriche calcolate sono un altro tassello mancante del GAP tra le piattaforme di Analytics considerate storicamente enterprise e Google Analytics; come si può facilmente immaginare dal nome, rappresentano delle metriche che non solo non esistono nativamente in piattaforma (anche le custom metrics non esistono se non le creiamo noi), ma che vengono prodotte attraverso calcoli che il sistema fa al posto nostro. In alcuni casi quindi non sarà più necessario esportare i dati su Excel solo per mettere in relazione due o più metriche già presenti nel sistema. Ad esempio la pagina di help ufficiale riporta come caso d’uso la metrica calcolata “Entrate per utente”, che si calcola con la semplice formula {{Entrate}} / {{Utenti}}

Siccome le ho avute in beta da parecchi mesi, vi riporto un semplice caso d’uso differente da quelli dell’help center: analisi dello sconto medio.
Il business need è quello di fare valutazioni più ampie rispetto alle Entrate riportate dal sistema, che nel caso in esame vengono registrate al netto di sconti; ad esempio una domanda potrebbe essere “quanta revenue ho incassato in meno questo mese per via delle promozioni in corso?”. Oppure “quale è lo sconto medio di tutti i prodotti dello store Svedese?”

Per arrivare al report come concordato con chi ne avrebbe usufruito siamo partiti dal registrare, tramite una custom metric di prodotto, lo sconto percentuale applicato, per cui se compro due prodotti da 100 euro l’uno, uno a prezzo pieno e l’altro in sconto del 15 percento, sulla thankyou page registro:

– prodotto1: entrate 100 sconto 0
– prodotto2: entrate 85 sconto 15
(sconto è la mia custom metric, che in piattaforma chiamo SommaSconto%)

La metrica calcolata “sconto medio” è di tipo “percent” e la formula è questa
{{SommaSconto%}} / {{Quantità}} / 100

che nel caso in esame produce una metrica media del 7,5%, segmentabile e filtrabile esattamente come qualsiasi altra metrica presente in Google Analytics.
Questa metrica non risponde alla domanda “quanta revenue in meno ho incassato”, ma nessuno ci vieta di fare un’altra metrica calcolata (questa volta di tipo “valuta”) con formula

{{Entrate generate dal prodotto}} * 100 / (100 – {{SommaSconto%}})

In questo modo su un custom report possiamo esporre le Entrate reali e quelle potenziali, affiancate, segmentabili per paese, prodotto, categoria, eccetera…

Facile, comodo e veloce, non trovate? :)


Oct 13 2015

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

Il conteggio ufficiale delle hit, a portata di mano

autore: Marco Cilia categoria: generale tag: ,

Oggi, mentre mi aggiravo nei meandri più reconditi dell’interfaccia di amministrazione di Analytics cercando di risolvere un problema, mi sono accorto che nelle impostazioni della proprietà (property nell’interfaccia inglese) E’ stato aggiunta una sezione con il conteggio – ufficiale – delle hit del giorno prima, degli ultimi 7 giorni e degli ultimi 30 giorni.

hit-counter-exposed

In realtà era già possibile avere questo numero, attraverso un custom report; vedo peraltro adesso che hanno anche sistemato l’interfaccia: prima infatti nell’interfaccia inglese dei custom report c’era la metrica HITS e la metrica VISITS. Poi visits è diventato SESSIONS, ma poco importa. Nell’interfaccia italiana invece hits è stato sempre tradotto con VISITE, e poi c’erano le (vere) VISITE :-/ (poi il caos: visite è diventato SESSIONI e hits/visite è rimasto visite, ma figurati scambiare visite (che erano hits) pensando a sessioni e fare un report così, tremendo!!!). In ogni caso un report costruito così, ad esempio

hit-custom-report

su una property senza filtri, mostrerebbe gli stessi identici risultati del pannello di amministrazione.

Prima ancora il metodo empirico consisteva nella rude somma di pagine viste, eventi, interazioni social, transazioni e item, con l’aggravante del sitespeedsamplerate che si scatena solo in alcuni casi, consumando hit aggiuntive.

In ogni caso mi sembra un’aggiunta interessante, specialmente per chi fa largo uso di eventi ed è vicino alla soglia critica dei 10 milioni di hits mensili, oltre la quale si è fuori dai Termini del Servizio di Google Analytics Free.


Sep 30 2015

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

I dati come i LEGO

autore: Marco Cilia categoria: tagmanager tag: ,

Ultimamente, sempre più spesso, mi è capitato di parlare con persone e intuire come nella loro testa fosse difficile capire le relazioni che ci sono tra gli strumenti che utilizziamo, il modo di trasportare i dati e la loro rappresentazione nel sistema. Grossomodo è la stessa relazione esistente tra chi dice genericamente “il posizionamento” sui motori di ricerca, e un SEO attento che invece conosce la differenza tra fasi distinte di crawling, indicizzazione e ranking (lo so, anche questa è una semplificazione).

La cosa è evidente soprattutto quando si parla di Enhanced Ecommerce e quando di mezzo c’è il/un TagManager. Vediamo di provare a fare chiarezza.

I bei tempi andati

Nei tempi che furono esisteva una relazione stretta, quasi 1:1, tra quel che si faceva in pagina con Google Analytics e la rappresentazione che ne usciva fuori nello strumento: metto il codice di base? ho le pageview. Metto un trackEvent su un pulsante? ogni volta che lo premo avrò un evento su Analytics. Facile, preciso, indolore. Il controllo era assoluto, e ogni azione provocava una reazione. Ho un Ecommerce? metto un ALTRO tag particolare sulla thankyou page per dire ad Analytics che l’utente ha comprato, e cosa, e quanto ha speso eccetera…

l’avvento del TagManager

Il primo “scollamento” tra la relazione stretta è stato l’inserimento del TagManager. Non esiste più una relazione 1:1 tra quel che faccio in pagina e quel che ritrovo sullo strumento (o almeno, non necessariamente anche se si può fare in modo che accada), semplicemente perché in mezzo c’è un altro sistema che possiede una logica propria ed è in grado di “fare cose”. Metto il contenitore del TagManager e dentro c’è il codice di base di GA? ho le pageview. Dentro ci metto un evento GA con la stessa regola? allora avrò per OGNI pagina ANCHE un evento su Google Analytics (non fatelo, non ha senso :) ). Creo un evento GA che parte solo sul click di un bottone, che intercetto con GTM? allora avrò un evento esattamente quando mi serve. Il problema, se così vogliamo chiamarlo, deriva da una scelta infelice degli ingegneri del TagManager, che hanno creato un metodo per pompare informazioni dentro al dataLayer (la struttura di dati che viene letta automaticamente dal GTM) dandogli un naming particolare: event. Ora, quando si usa la sintassi

dataLayer.push({'event': 'video', 'titolo': 'video corso di GA'});

NON si sta creando un evento Google Analytics con category “video” e action o label “video corso di GA” (infatti il TagMAnager non serve solo per GA, questo in teoria dovrebbe essere sufficiente a chiarire la cosa, ma così non è). Si sta semplicemente dicendo al TagManager che c’è una situazione (purtroppo si chiama evento, ma possiamo chiamarlo message, o push) e che la parte di dataLayer che si chiama titolo va aggiornata con l’informazione “video corso di GA”. Se vogliamo farne un evento GA dovremo configurare un tag GA di tipo evento, con category fissa e action o label presi da una variabile dataLayer che legge “titolo”.
Se questa parte di dataLayer esisteva già, l’event fa l’update, se invece non esisteva la crea. E qui inizia il gioco delle costruzioni con i mattoncini. Per ulteriori dettagli tecnici vi invito a leggere il GTMtips #26 di Simo Ahava

l’Enhanced Ecommerce sul TagManager

Il secondo scollamento totale tra quel che si fa in pagina, come viaggiano i dati e che risultato otteniamo in interfaccia è stato l’Enhanced Ecommerce. Per far si che l’Enhanced Ecommerce funzioni a dovere, è necessario fornire i dati in un certo modo. Se si usa il Google TagManager alla pagina linkata ci sono le istruzioni e le configurazioni necessarie affinché questo accada. Ma sono un po’ fuorvianti :)
Bisogna capire per bene i tre momenti distinti che servono per arrivare al risultato finale:

  1. devo mettere nel GTM le informazioni necessarie, facciamo l’esempio di 4 impressions. La parte rilevante è QUANDO riesco ad avere queste informazioni. Il programmatore potrebbe averle già quando si crea la pagina, e metterle nel dataLayer che c’è in HEAD. Oppure potrebbe avercele solo ad un certo punto del sorgente della pagina, e quindi fare un dataLayer.push nel body, dopo il contenitore.
  2. devo inviare le informazioni a GA: se le informazioni sono nel dataLayer in HEAD, mi basta il tag di base di GA opportunamente provvisto della spunta “usa Ecommerce avanzato” e “usa struttura livello dati”. Il sistema accoda le informazioni sulle impression a quelle della pageview, per risparmiare hit. Finito. Se invece il programmatore ha dovuto fare un push dopo il contenitore (quindi al 99% DOPO CHE LA PAGEVIEW è già partita verso i server di Google), allora le mie impressions stanno si nel dataLayer, ma ci restano finché non si comunica di nuovo con i server PRIMA di cambiare pagina: ricordate che il dataLayer riparte da zero ad ogni cambio pagina. Allora mi servirà un evento Google Analytics, anche un evento fake inutile per le analisi, che provvisto delle stesse spunte di cui sopra mi fungerà da trasporto per i dati delle impressions

La cosa è spiegata bene solo nell’esempio della thankyou page

EE-purchase

“pusha i dettagli della transazione nel dataLayer usando l’action purchase, insieme ad un evento che azionerà un tag evento con le opzioni ecommerce. In questo esempio, i dettagli della transazione sono conosciuti nel momento in cui la pagina carica, e saranno inviati con una pageview quando si aziona gtm.js (cioè quando si apre la pagina, ndMC)”

conclusioni

Con gli strumenti a disposizione oggi è necessario comprendere bene quale sia il flusso dei dati in fase di collezionamento e di invio. Dimentichiamoci delle relazioni dirette: la pagina parla col dataLayer, che parla col TagManager, che parla con Google Analytics (che parla con noi :) ). Ognuno di questi passaggi ha delle peculiarità e dei punti di attenzione, ma presenta anche grandi opportunità di modifica, razionalizzazione e pulizia dei dati.


Sep 02 2015

Come funziona Tag Assistant Recording

autore: Marco Cilia categoria: codice di monitoraggio

La novità dell’estate del mondo Google Analytics, anche se arriva a fine agosto, è la disponibilità di Tag Assistant Recording, una sorta di v3 del plugin di controllo/debug dei tag Google, di cui vi avevo già accennato in questo post.

Se non sapete di cosa si tratta, partite dallo scaricare l’estensione di Chrome da questo link. In breve l’estensione controlla su ogni pagina la presenza di tag di marketing by Google, quindi Google Analytics, AdWords, Doubleclick, Google Tag Manager. Per ognuno di questi sono disponibili molte informazioni, e si può cambiare il livello di dettaglio di esse utilizzando le opzioni dell’estensione; ad esempio l’estensione potrebbe dire che su una pagina ci sono due Floodlight, due Analytics versione classica e uno Universal dentro a un container TagManager. Che uno dei tag è nella posizione sbagliata, che altri tag non funzionano come previsto, insomma una marea di informazioni utili.

La funzionalità nuova e più interessante però è quella di recording, ovvero l’estensione registra una navigazione e poi vi consente di riguardarla step-by-step con vari livelli di informazioni. Per utilizzarla è necessario premere il pulsante “RECORD“, nella parte bassa dell’interfaccia dell’estensione: da quel momento un classico pallino rosso ci avvisa che l’estensione sta registrando. Dopo aver navigato le pagine che ci interessano ed aver fatto tutte le azioni che desideriamo controllare si può stoppare la registrazione ed avere un rapido sommario che somiglia a questo:

TA-recording-sommario

Il click su “show full report” ci porta ad una interfaccia divisa in due macrosezioni: la prima riguarda un report sui TAG che vengono inviati, quindi tutti quelli supportati da Tag Assistant. Le seconda invece è prettamente dedicata a Google Analytics. Ma andiamo con ordine: il report dei Tag su un sito complesso può assomigliare a qualcosa del genere

TA-vg

e subito notiamo la possibilità di filtrare solo i tag che ci interessano. Di base, il sistema permette di vedere le pagine registrate e per ogni pagina mostra: URL, timestamp della richiesta, tempo di caricamento, numero di tag totali, numero di errori, warning e suggerimenti. Per ogni tag di ogni pagina mostra i metadati, ovvero un riassunto di cosa fa un tag (advertiserID per Floodlight, o UA di Analytics, per esempio), le ottimizzazioni possibili se ce ne sono e le richieste (un tag potrebbe infatti generare più richieste). Per ogni richiesta generata, infine, mostra i metadati, ovvero l’elenco dei parametri, alcuni dei quali sono tradotti in un linguaggio comprensibile mentre altri restano da decifrare.

Spostandosi nella sezione “Google Analytics report” invece l’interfaccia cambia, e a seconda che la mail con la quale siete loggati in Chrome/Analytics abbia o no accesso alla property GA che state analizzando, le possibilità variano. Innanzitutto il menu laterale, che è fatto così:

TA-GA-section

  1. Update report permette di ricaricare il report dopo aver fatto modifiche nella configurazione.
  2. Select Views permette di switchare tra i vari recording di GA, se le pagine inviavano dati a più properties. Nel caso in cui non abbiate accesso ai dati, esce il messaggio “The recording contains hits sent to this property, but you (email@email.ext) don’t have permissions in Google Analytics for its views. You won’t be able to see view-specific information.
  3. Change Location permette di simulare la visita come proveniente da una differente località o da un diverso indirizzo IP
  4. Open permette di caricare un file con una sequenza di hit e Save di salvare la sequenza corrente, per riusi futuri

Nella parte destra invece troviamo un recording summary, con informazioni generali come l’ora della registrazione, il totale delle pagine e dei tag, la property selezionata, ecc, seguita da una sezione di alert, in cui il sistema da una valutazione di quel che ha visto, una sezione di “views summary” che esiste solo se state guardando i dati che andrebbero ad una property cui avete accesso, e che riassume così la visita (clicca per ingrandire)

TA-behavior

Ricordate che siamo FUORI da GA, quindi se avere informazioni su Browser e OS è banale, vi invito a guardare la sezione “conversions” 😉
Il caso d’uso praticamente è questo: voi su un Analytics settate una conversione, poi andate sul sito e registrate la sessione mentre convertite, poi chiedete a Tag Assistant se quella sarebbe stata una conversione; se vi dice no, modificate il setting del Goal, tornate su Tag Assistante e fate Update Report e controllare in tempo reale se la modifica ha senso. Notevole no?
Altra cosa che potete fare, questa però non l’ho provata, è vedere se una richiesta passa indenne o viene modificata da un filtro, nella sezione FLOW -> Hit -> Mutuations

Per finire, se salvate una sessione la potete riusare in futuro; i file hanno estensione .harz
Già questo può essere interessante perché potete scambiarvi o farvi inviare da un cliente la sua navigazione, e controllare come la vede GA senza essere fisicamente da lui o nelle sue “condizioni di rete” (proxy, location, rete, eccetera). Più interessante ancora è che i file HAR sono uno standard per gli archivi di richieste HTTP, e quindi ci sono moltissimi software che possono generarli (un semplice Chrome dal pannello NET, Fiddler, Firefox dalla versione 41 in su, secondo questa lista).
Altro caso d’uso quindi: per strettissime policy aziendali e insormontabili problemi tecnici, è impossibile vedere gli ambienti di staging del nuovo sito del cliente, quindi si dovrebbe configurare alla cieca o quasi. Si va dal cliente, si fa esattamente il percorso di conversione e si registra con Tag Assistant. Dopo si torna in ufficio e lo si testa infinite volte man mano che la configurazione dell’account procede.

Non c’è praticamente limite alle possibilità di debuggare ogni più piccola virgola, in tempi sempre più ristretti e con risultati sicuramente più veloci.