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 🙂


Mar 03 2015

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

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.