Sep 30 2015

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

I dati come i LEGO

autore: Marco Cilia categoria: tagmanager

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.


Mar 18 2015

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

Caso d’uso reale dei segmenti sequenza

autore: Marco Cilia categoria: generale

Un altro brillante caso risolto grazie alla segmentazione avanzata, Watson!

Business Problem:
Dopo la migrazione a Universal Analytics, quasi tutta la revenue viene attribuita al referral sella.it (o in generale al vostro/i gateway di pagamento). Questo è chiaramente impossibile perché:
a) prima della migrazione non era così
b) ha pochissimo senso

Technical explanation:
Qualcuno si è dimenticato di inserire il dominio sella.it nella lista di esclusione dei referral, che su Universal Analytics è requisito necessario al funzionamento. NORMALMENTE essa contiene il dominio stesso del tracking – o i domini in caso di tracciamento multidominio – ma se il funnel di acquisto esce dal sito e ci rientra con un link o un redirect ALLORA dovreste inserire anche il gateway. Questo perché a differenza di Analytics classico, Universal Analytics crea SEMPRE una nuova sessione quando si arriva da un referrer, ANCHE se siamo all’interno dei 30 minuti in cui normalmente questo non avveniva su GA classico

Business Request:
“d’accordo, ma io voglio sapere le reali sorgenti delle transazioni che sono state attribuite male prima della correzione”

L’intuizione:
Tutti coloro che escono dal sito verso il gateway, poi ci rientrano e convertono all’istante (convertono direttamente sulla thankyoupage). In questa esatta sequenza, e senza niente altro nel mezzo.

Svolgimento:
Creiamo tanti diversi segmenti avanzati di tipo SEQUENZA, uno per ogni sorgente o mezzo da analizzare, con queste regole (esempio per riattribuire il cpc):

segmento-sequenza-cpc-sella

Il segmento mostra la revenue delle sessioni in cui l’UTENTE fa una qualsiasi sessione da CPC seguita immediatamente da un’altra sessione da sorgente che contiene “sella” in cui però converte.
Se ne faccio un altro con mezzo organic e poi sorgente “sella” riattribuisco la quota parte del traffico all’organico e così via

Success Story:
C’erano da riattribuire 776 transazioni: ovviamente la somma dei risultati di segmenti sequenza come questi non potrà mai essere precisa al 100% con il segmento “tutto il traffico”, ad esempio perché un utente nel periodo fa due transazioni in due giorni diversi, tuttavia la somma fatta per controllo restituisce 782, con una scarto piccolissimo. Le revenue sono state quindi riattribuite alle corrette fonti di traffico e il caso è chiuso.

Elementare, Watson 🙂


Apr 08 2013

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

Perché il totale transazioni non coincide col report transazioni?

autore: Marco Cilia categoria: report

Ecco un caso infido, una delle sfide che mi piace affrontare nel quotidiano per capire sempre di più come ragionano gli ingegneri che stanno dietro al sistema e provare quindi a capire un po’ meglio lo strumento.
Che il totale delle transazioni registrate da Google Analytics possa non coincidere con quanto registrato dal sistema e-commerce è normale, oserei dire quasi fisiologico; in tanti anni ho visto uno ed un solo e-commerce con aderenza 100% tra registrato e GA. Le cause possono essere molteplici, si va dagli utenti che comprano senza avere javascript abilitato (quindi invisibili a GA), a errori bloccanti nell’esecuzione dello script, lentezza della pagina e posizione sbagliata del codice, redirect fantasiosi, insomma avete capito.

Il caso di cui parliamo oggi invece è diverso, perché rappresenta una discrepanza interna dello strumento: in un dato giorno l’overview ecommerce dice che ci sono 102 transazioni e 13.084 euro di entrate, e il report delle transazioni elenca solo 47 record, per lo stesso ammontare di entrate (clic sulla seconda immagine per ingrandire).

102-transazioni
47-transazioni

Il problema non sarebbe nemmeno tanto grave una volta appurato quale dei due è quello corretto (quello del report, vi rovino la sorpresa 😀 ), se non fosse che nell’overview è presente il dato del valore medio, che è un KPI importante in un e-commerce, e che in quel caso viene calcolato usando il numero di transazioni dell’overview.

Un po’ di background tecnico, per cominciare

Tutti ormai dovremmo sapere almeno a grandi linee come funziona Google Analytics, anzi come fa ad inviare le informazioni ai server di Google: richiama una gif trasparente 1×1 pixel e ci attacca una lunga serie di parametri, con i dati che servono. Tra le tante informazioni che invia, ne esiste una particolare che dice allo strumento che tipo di hit sta arrivando: se si tratta di una pagina vista (il default), di un evento, di un prodotto o di una transazione.
Esatto, ogni prodotto e ogni transazione generano una nuova chiamata alla gif, per cui la thankyoupage di un ecommerce in cui ho fatto un acquisto con 4 prodotti avrà almeno 6 chiamate alla gif: la pageview, la transazione e una chiamata per ogni prodotto.

Quindi?

Quindi la discrepanza è semplicemente dovuta a gif di tipo transazione che vengono conteggiate in un caso e nell’altro no. Come me ne sono accorto? facendo un semplice custom report con metrica “transazioni” e dimensione “transazione” (clic per ingrandire)

102-rettificato

ci sono si 102 transazioni, ma ce n’è una di nome “undefined” con 55 transazioni. 47 transazioni “vere” + le 55 undefined fa proprio 102.
Al sistema quindi arrivano, per motivi da debuggare in seguito, delle hit di tipo transazione con transaction ID (il primo parametro obbligatorio della funzione _addTrans) vuoto (o undefined). L’overview e-commerce mostra semplicemente il numero di hit di tipo transazione, il report delle transazioni invece è filtrato a monte per mostrare solo ID di transazioni “reali”, o meglio per nascondere i valori undefined. Da cui la discrepanza.

E abbiamo portato a casa un altro pezzo di conoscenza del sistema 🙂


Feb 13 2013

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

Transazioni multivaluta, finalmente!

autore: Marco Cilia categoria: codice di monitoraggio

Una delle cose che a mio avviso è sempre mancata in Google Analytics era un modo semplice per inviare transazioni multivaluta, un problema molto sentito dagli e-commerce internazionali. Poiché nel codice di tracciamento e-commerce non è mai specificata la valuta, essa veniva impostata a livello di di profilo tramite l’apposita opzione nell’amministrazione.
Se il tuo e-commerce vende in molti paesi con valute diverse, la soluzione è sempre stata “converti tutto in una unica valuta PRIMA di inviare la transazione”.

Oggi non è più così perché il team di Google Analytics ci informa tramite un post sul blog che è arrivata la multivaluta: GA provvederà ad effettuare la conversione nella valuta principale che è stata specificata nel profilo.

Prima domanda: quale tasso usano i server di Google? usano il tasso medio di conversione del giorno precedente all’analisi, ricavato dallo stesso server di Google Billing (che se non ho capito male dovrebbe essere lo strumento ufficiale di fatturazione di Google, giacché non esiste un servizio che si chiama così).

Seconda domanda: come faccio ad usare il multivaluta? basta aggiungere una sola funzione e conoscere il codice ISO 4217 corrispondente alla valuta. Attualmente sono supportate 31 diverse valute in Google Analytics.
Ad esempio una transazione in euro avrà questa funzione prima di _trackTrans


_gaq.push(['_set', 'currencyCode', 'EUR']);

mentre una transazione in peso messicani avrà questa funzione


_gaq.push(['_set', 'currencyCode', 'MXN']);

A livello di report saranno poi disponibili specifiche metriche relative alle transazioni nella loro valuta originale. Se ne possono vedere alcune nello screenshot postato sul blog di Analytics

multicurrency

Terza domanda: ho un ecommerce in una sola valuta. devo cambiare i miei tracciamenti? no, questa operazione è necessaria SOLO se si vogliono registrare transazioni in più valute e si vuole che Google si occupi della conversione automaticamente.


Sep 21 2012

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

Migliorati i filtri su ecommerce e variabili personalizzate

autore: Marco Cilia categoria: filtri

Sebbene sia un caso un po’ di nicchia, potrebbe esservi capitato di avere due domini o sottodomini tracciati con lo stesso codice, quindi di avere almeno due profili filtrati sulla base del nome host, in cui uno di essi usa il tracking dell’ecommerce; vi sarete sicuramente accorti che le transazioni finiscono in entrambi i report, che non sono filtrabili. Più in generale, i dati dell’ecommerce non venivano mai legati ai dati di livello pagina (altra cosa che non si poteva fare era un filtro del tipo “escludi le transazioni provenienti dalla pagina x”).

Nel prossimo futuro invece questa situazione verrà risolta, ed inoltre verrà esteso il supporto all’utilizzo delle variabili personalizzate nei dati di ecommerce.


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! 😉


Nov 25 2010

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

Revenue ed entrate e-commerce

autore: Marco Cilia categoria: report

Mi ha scritto un lettore chiedendomi come mai il numero indicato nella panoramica dei rapporti e-commerce (le vendite di x prodotti hanno generato…) sia differente da quanto indicato nel report panoramica del prodotto (entrate generate dal prodotto). Il suo problema in realtà è leggermente differente, e vedremo di risolverlo, ma la domanda si pone all’interno di un filone piuttoto ricorrente sulle discrepanze dei numeri tra report differenti.

Spesso è solo un banale problema di traduzione dell’interfaccia, anzi di coerenza, perché Google Analytics dà a volte nomi differenti alle stesse cose. Nella fattispecie, quando guardiamo al report panoramica del prodotto il numero espresso è il prezzo dei prodotti netto, senza spese né tasse. Il numero indicato nella panoramica e-commerce è invece la REVENUE,cioè gli introiti totali comprensivi di tasse e spese di spedizione.
L’interfaccia sbaglia di grosso quando presenta nei due report sottostanti la colonna revenue per entrambi: nel primo caso (prodotti) il dato indicato sono le entrate, nel secondo caso invece (sorgente/mezzo) è davvero la revenue. Non che la cosa sia consolatoria, ma il problema c’è anche nell’interfaccia inglese, quindi si tratta di un vero e proprio errore di etichetta del dato: l’etichetta corretta di quella colonna dovrebbe essere Entrate generate dal prodotto (product revenue in inglese).