Mar 18 2015

Caso d’uso reale dei segmenti sequenza

autore: Marco Cilia categoria: generale tag: ,

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 :)


Mar 03 2015

Non guardare il report Ecommerce negli eventi

autore: Marco Cilia categoria: codice di monitoraggio

Uno dei misteri più grandi di questo strumento per i non addetti ai lavori è la cosiddetta attribuzione: ci sono varie cose dentro a Google Analytics che devono essere “attribuite” affinché i report abbiano senso: le conversioni vanno attribuite ad una sorgente, e per farlo c’è un modello di attribuzione: last click non direct in Acquisizione, Last Click puro nei Multichannel Funnel. I goal vanno attribuiti alla sessione in cui si verificano, perché ci possono essere più goal (diversi) nella stessa sessione, ma non lo stesso goal. Le transazioni vanno attribuite tanto quanto, ma se ne possono avere più di una per sessione. Il valore della conversione va attribuito alla sessione (per session value) e alle pagine (per page value). E così via…

Le conversazioni con i clienti vertono sempre più spesso su come Google Analytics attribuisce le “cose” nei vari report, ma oggi voglio farvi una confessione: non dovreste MAI guardare la sezione Ecommerce dei report degli eventi, e ora vi spiego perché:

Quando atterro su un sito, navigo, e faccio una conversione e/o una transazione, avvengono nella mente di Analytics molte cose: un certo visitatore arriva da una sorgente di traffico, su una landing page, vede in un certo ordine alcune pagine, alcune di queste sono state impostate come “importanti” dall’amministratore del profilo (sono GOAL), questi goal possono avere un valore monetario (fisso o variabile), poi l’utente invia una transazione con un certo valore.

Se partiamo dall’assunto che la sessione è UNA, ci accorgiamo che alcune di queste cose hanno un rapporto 1:1 con la sessione, mentre altre hanno un rapporto molti a uno con essa. Esiste UNA sola sorgente per sessione, quindi è facile attribuire il valore di goal ed ecommerce alle sorgenti. Esiste UNA sola landing page per sessione, quindi è semplice calcolare il valore incamerato per ogni landing page. Esiste UN solo goal per sessione (per tipo, quindi max 20 goal per sessione, dato che su GA ci sono max 20 diversi goal), anche qui tutto facile. Possono esistere MOLTE transazioni per sessione, ma GA le somma e le attribuisce a tutto quanto detto sopra (sorgenti, landing page, ecc.).

Invece in una sessione ci sono, tipicamente, MOLTE pagine. Se in quella sessione si raggiunge un goal o si fa una transazione, non ha senso attribuire tutto il valore a tutte le pagine visitate, verrebbe un numero spropositato. Infatti gli ingegneri si sono inventati la metrica “valore pagina” (page value in inglese, l’ex index$) che attraverso un determinato calcolo spalma il valore su tutte le pagine viste durante la sessione.

E gli eventi? anche per gli eventi c’è una relazione, tipicamente molti a uno, con goal e transazioni. Ma qui gli ingegneri non hanno inserito una metrica apposta per spalmare il valore, mentre il report Ecommerce nel report eventi è consultabile (e ve lo dico chiaramente, secondo me è un errore!). In questo caso, banalmente, lo strumento MOLTIPLICA il valore delle transazioni per ogni record del report che state guardando. Esempio reale: in un dato periodo un ecommerce incassa 226.320,50 euro con 1.907 transazioni, secondo il report Panoramica Ecommerce. Guardando il report Categorie dell’evento per lo stesso periodo, sezione Ecommerce, si vede:
categorie-ecommerce

spostandosi su Azione evento, sempre Ecommerce:
azioni-ecommerce

e infine su Etichetta evento:
etichette-ecommerce

Sostanzialmente il sistema non ATTRIBUISCE la transazione ad una sola categoria di evento, o azione o etichetta (magari l’ultimo avvenuto), ma a TUTTI gli eventi che si sono registrati nella sessione: se nella sessione faccio molti eventi di categorie diverse, o stessa categoria ma azioni diverse e così via, i valori Ecommerce sono moltiplicati.

Perché lo fa? OPINIONE PRETTAMENTE PERSONALE, perché distribuire il valore per tutti gli eventi, che sono tipicamente tanti, sarebbe oneroso da calcolare e porterebbe a valori molto piccoli, tanti più sono gli eventi tracciati. Sempre opinione personale, allora tanto varrebbe eliminare quella sezione di report, no?

Il modo in cui si comporta il report assomiglia molto al risultato che avreste creando dei segmenti di tipo sessione basati sull’occorrenza di ogni categoria di evento, e poi provaste a sommare i risultati: sarebbero quasi sempre superiori al totale registrato.


Feb 12 2015

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo rosso - articolo per esperti

Come funziona l’instant remarketing?

autore: Marco Cilia categoria: codice di monitoraggio tag: ,

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 :D

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 :)


Feb 11 2015

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo rosso - articolo per esperti

Cosa sono le analisi coorte?

autore: Marco Cilia categoria: report tag: , ,

Apparse negli account già da qualche giorno, soltanto oggi la pagina Google+ di GA ci rende edotti del fatto che le analisi coorte sono tra noi: le analisi CHE???

Le cohort analysis sono analisi basate sul tempo che servono a mettere in relazione il comportamento degli utenti che hanno manifestato un certo tratto in comune in un dato lasso temporale. Più facilmente, di solito, si tratta di guardare all’evolversi di una metrica da parte degli utenti che sono stati insieme sul sito in un dato momento.

Se vi ricordate, era già possibile fare qualcosa di simile usando una delle ultime feature dei nuovi e potenziati segmenti avanzati:

Schermata 2015-02-09 alle 23.07.56

Le analisi coorte sono simili, ma godono di una rappresentazione visuale tutta loro, e molto carina.
Esempio classico, ovvero come si presenta il report appena lo aprite: NON potete selezionare il range temporale, perché le coorte comprendono già un arco temporale tutto loro (ultimi 7, 14, 21 o 30 giorni): di default gli ultimi 7 giorni escluso oggi. Al momento l’unica coorte possibile è sulla data di acquisizione, cioè il primo giorno del periodo. La dimensione può essere il giorno, la settimana o il mese, la metrica predefinita è la fidelizzazione, cioè il fatto che gli stessi utenti tornino o meno sul sito nei giorni (settimane, mesi) successivi.

Quindi come si legge il report? innanzitutto si noteranno due cose, la prima è che il totale degli utenti non corrisponde al totale degli utenti unici del report PANORAMICA per lo stesso periodo. La seconda è che quel numero è la somma dei singoli giorni. ORRORE, direte voi – lo sanno anche i bambini che i visitatori unici non si sommano mai (cfr. the hotel problem)! corretto, se non che quel numero in realtà NON è il mero numero di visitatori unici di ogni giorno, ma credo si avvicini di più al numero di nuovi utenti.

Per ogni riga quindi viene indicato quanti dei nuovi utenti ritornano negli n giorni successivi. Variando la metrica il report varia di conseguenza, e la colorazione delle celle anche.
Si tratta di un report molto importante, che acquista ancora maggiore valore se utilizzato in una vista che fa uso dello USERID di Universal Analytics, che quindi sorpassa il problema dei device multipli e della moltiplicazione degli utenti.


Jan 31 2015

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

Remarketing istantaneo e conversione valuta in AdWords

autore: Marco Cilia categoria: report tag: , ,

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 27 2015

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

TOTALE! Anche GA ora ha il suo “cestino”

autore: Marco Cilia categoria: generale tag: , ,

A quanti di voi è mai successo di cancellare una vista (ne ho visti tantissimi), una property (meno, ma erano dolori) o un account (me ne hanno raccontato uno, una volta)?
La procedura per recuperarli è sempre esistita, con restrizioni più o meno ampie, ma era farraginosa e necessitava l’assistenza di un partner certificato Google Analytics, o qualche santo in terre AdWords/Analytics.

Poco fa il team ha annunciato che invece, a partire da adesso (ma se fossi in voi non sperimenterei tanto per fare… :P ) le cose cancellate finiranno per 35 giorni in un “cestino” ispezionabile a livello di account, da dove si potranno poi recuperare. Una feature che allinea il prodotto agli standard cui ormai siamo abituati da anni su Gmail e Google Drive, ad esempio.
Per i più curiosi ecco l’articolo dell’help con i dettagli, ma attenzione, secondo me c’è un errore: nell’esempio 3 la dinamica iniziale è identica all’esempio 1, ma il risultato diverso poiché di vuole restorare una vista. Credo che in realtà l’esempio che volessero fare sia questo:

  • V2 è spostata nel cestino. Successivamente, Account A è spostato nel cestino. Ripristinare V1 automaticamente ripristinerà P1 e A1, ma non V2. V2 rimane nel cestino.

In ogni caso, una bella funzionalità, che come al solito vedremo comparire negli account progressivamente, nel giro di qualche settimana.


Jan 17 2015

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

Anteprima della dimensione di un segmento e condivisione

autore: Marco Cilia categoria: generale tag: ,

Da qualche giorno tutti gli account dovrebbero aver ricevuto la nuova interfaccia di creazione dei segmenti avanzati. Niente di trascendentale, in realtà, ma migliorie interessanti.
Prima di tutto i tasti “salva”, “annulla” e “anteprima” sono stati spostati in alto, a fianco del del nome segmento: questo evita di dover scrollare verso l’alto e il basso molte volte durante il processo di creazione.
Secondo, e più importante, è stato aggiunto un riepilogo visuale della “dimensione” (in utenti e sessioni) che si aggiorna man mano che componiamo il segmento.

anteprima-segmenti

Appena si apre la creazione ovviamente è al 100%, e man mano che aggiungiamo condizioni esso varia mostrandoci quale percentuale di utenti e visite sarebbero incluse nel segmento. E’ una specie di tasto “anteprima” ma in real-time. Il vantaggio qui è notevole, se anche a voi capita spesso di creare segmenti solo per sapere un numero totale di riferimento. Ad esempio sto analizzando un certo fenomeno e mi chiedo “si ma questo altro fenomeno collegato quanto cuba?” e questo mi costringe o ad aprire un altro report abbandonando quello corrente, o ad aprire un’altra finestra, o a creare e applicare un segmento sul report corrente. In questo modo invece posso aprire la creazione di un nuovo segmento, impostare i filtri, e vedere di quante sessioni stiamo parlando.

L’altra novità riguarda lo share dei segmenti: fino ad oggi essi sono stati disponibili solo per la mail che li creava, e si potevano applicare a tutte le viste o solo alla vista corrente. Per mostrare il segmento a un cliente o a un collega bisognava inviargli un link a un template, bisognava che lui lo cliccasse e importasse il tutto e poi applicasse. Ora invece cliccando la voce “il segmento è visibile in tutte le viste Modifica” in alto a destra, compare questa finestra:

disponibilita-segment

Le prime due voci sono le stesse di prima, mentre la terza ci dice che possiamo condividere direttamente il segmento con tutti gli utenti con privilegi di “Collabora” che vedono questa vista. Decisamente più comodo! :)


Jan 07 2015

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

Il report “nomi host”

autore: Marco Cilia categoria: report tag:

Buon 2015, e ben riletti dopo una bella pausa rigenerativa!

Oggi parliamo del report “nomi host“, uno dei più sconosciuti ma potenzialmente più utili per fare debug di situazioni strane.
Innanzitutto, dove sta. Sta sotto a PUBBLICO -> Tecnologia -> Rete, cambiando la dimensione principale da “Fornitore di servizi” a “nome host”.
Secondo, cosa elenca: il nome dell’host è praticamente il dominio del sito, senza http:// e senza l’indicazione della pagina.

Infatti ogni volta che il codice di Google Analytics viene eseguito, una delle informazioni che viene inviata è “dove mi trovo?” (su quale dominio?), e questa informazione serve anche a popolare questo report; vi ricordo altresì che GA non fa nessun tipo di controllo sulla provenienza dei dati, e che l’indirizzo che vi chiede quando si configura l’account è puramente “di bellezza” (serve in realtà a comporre gli URL quando si preme l’icona “apri questa pagina”).

Ed ora le molteplici proprietà di questo report:
– ci vedi solo un dominio, e guarda caso è quello che stai tracciando? OTTIMO! :)
– ci vedi solo un dominio e “translate.googleusercontent.com”? va bene anche così, come dicevamo prima se nel frame del traduttore di Google viene richiamata una pagina col codice, esso parte ma segna il nome host di Google
– ci vedi tanti domini, e fanno tutti parte del tuo progetto? bene, spero che tu abbia configurato opportunamente il codice per il tracking multidominio (per non duplicare utenti e sessioni), da questo report puoi effettivamente controllare che sia tutto in ordine
– ci vedi tanti domini, e alcuni non sai nemmeno cosa siano? ecco, questo è male, significa che il tuo codice di monitoraggio è ANCHE su pagine su altri siti (nomi host), fino ad arrivare a casi nemmeno tanto rari di siti interamente clonati a fini più o meno malevoli. Questo report ti aiuta a capire dove il tuo codice viene eseguito.

Fra le altre cose interessanti che si possono dire su questo report ne segnalo una in particolare, che deriva da come Google Analytics conteggia le sessioni: una sessione riceve un incremento solo alla prima hit che invia. Quindi se io atterro su eng.miosito.it e poi mi sposto su ita.miosito.it, il report nomi host segnerà una sola sessione su eng.miosito.it. Questo è utile nel caso vogliate sapere quanto cuba il traffico di un certo tipo che atterra su un certo sottodominio, in assenza di altri e più specifici interventi (viste filtrate, ad esempio).


Dec 14 2014

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

Venerdì 19 al convegno GT

autore: Marco Cilia categoria: tagmanager tag: ,

Non sia mai che mi dimentichi di avvisarvi che durante il convegno GT Venerdì prossimo, 19 dicembre alle 14.20 in sala workshop (o in streaming), terrò un intervento di 80 minuti dal titolo un po’ provocatorio: “Google Tag Manager: smetti di leggere post che ne parlano e impara ad usarlo!” :)

La cosa vorrebbe anche risolvere in parte un problema che molti mi pongono da qualche mese, cioè dove ci si possa formare sullo strumento; lo strumento è ancora più criptico di Google Analytics, e vi devo confessare che non ci sono tante risorse. Vi elenco quel che uso io, oltre che tante tante tante prove:

Non è molto, lo so, il resto sono post che mi capitano sotto agli occhi “di seconda mano”, cioè sharati da qualcuno dei miei contatti. Serendipity, la chiamano…

Ci vediamo al convegno GT? passi a salutarmi? :)


Dec 01 2014

Nuovi limiti per viste e property

autore: Marco Cilia categoria: generale tag: ,

[Prima di leggere questo post è propedeutica una ripassata alla struttura degli account in Google Analytics: la trovi nel post “la matrioska di Google Analytics: cosa devi sapere su account e profili“]

Fino ad oggi c’è sempre stato un solo limite, nella creazione di nuove viste: 50 viste per account. Come sapete tra le viste e l’account ci sono di mezzo le property, per cui erano valide tutte le opzioni come ad esempio 1 property con 50 viste, 50 property con 1 vista ciascuna, 2 property con 25 viste, eccetera.

Con un post su Google Plus il team ci annuncia che le cose stanno per cambiare e quella limitazione sarà rimossa e sostituta con queste due:

  • Ogni account potrà avere 50 property
  • Ogni property potrà avere 25 viste

Se pensiamo quindi al limite totale siamo davanti ad un grande aumento: si passa da 50 a 1250 viste.
Se pensiamo invece alla flessibilità di avere un solo codice UA con 50 viste, questo non sarà più possibile. Per chi avesse già superato questi limiti, non cambierà nulla. Le strutture esistenti che non rispettano il nuovo requisito non saranno toccate, mentre sarà disponibile nell’interfaccia di amministrazione il conteggio delle property e delle viste usate e restanti, in modo da potersi preparare per tempo alla corretta strutturazione dell’account.