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 🙂


Aug 25 2008

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

Transazioni negative, la mia opinione

autore: Marco Cilia categoria: codice di monitoraggio

NegativeInserire transazioni negative in un sistema di web analytics, principalmente quando si parla di e-commerce, ha il vantaggio di tenere sempre allineata la situazione dei ricavi reali con quelli presentati dal sistema. Vediamo come si inserisce una transazione negativa in Google Analytics: innanzitutto è necessario creare una pagina html qualsiasi ed editarla, incollando lo script di Analytics e le funzioni che si vogliono annullare, _addTrans(), _addItem() (o entrambe) e sicuramente _trackTrans().

E’ poi necessario assicurarsi di inserire lo stesso id_ordine della transazione che si vuole annullare. Infine il campo “totale” conterrà un numero negativo, il campo “quantità” un numero sempre negativo ma un “prezzo” positivo (in modo che la moltiplicazione dei due generi un numero negativo), i campi “tasse” e “spedizione” devono azzerare gli stessi campi della transazione con totali negativi.
A questo punto salvando la pagina e visualizzandola su un browser mentre si è connessi ad internet verrà eseguita _trackTrans() e i dati saranno inviati ai server di Google, che provvederà ad annullare la transazione nei conteggi e nei report.
E’ importante notare due cose: la prima è che bisogna assicurarsi di eseguire la pagina una e una sola volta, altrimenti si rischia di inserire transazioni negative pure (+100, -100, -100 fa -200), la seconda è che le singole transazioni restano visibili anche dopo l’annullo. Per cui se il primo del mese si registra una transazione per 3 oggetti e 300 euro, e il 15 del mese una transazione negativa per 1 oggetto e 100 euro, il totale considerando un periodo uguale o superiore al 1-15 del mese sarà 2 oggetti e 200 euro, guardando invece solo l’1 o un suo intorno sempre 3 e 300 e guardando solo il 15 o un suo intorno sarà -1 e -100 (nel caso semplificato in cui non ci siano altre transazioni nel mese).

Alcuni prodotti di e-commerce integrano la possibilità di tracciare le transazioni con Analytics, facilitando la gestione, e alcuni di questi permettono nativamente la gestione di ordini negativi, quindi evitano di dover editare a mano file HTML.

Veniamo alla mia opinione: Brian Clifton nel suo libro sconsiglia l’uso delle transazioni negative, perché falsano la metrica del ritorno dell’investimento. Se investi in advertising una somma X e poi vendi per 10volte X il tuo ROI è quello, e inserendo i resi si modificherebbe falsando le tue decisioni sui prossimi investimenti.

Eppure bisogna anche considerare che indipendentemente da quanto investi, se torna indietro il 100% della merce è giusto che il tuo ROI sia zero: primo perché così sarai costretto a interrogarti sulla qualità dei tuoi prodotti, secondo perché forse non è il caso di puntare su una categoria di prodotti che non soddisfano il pubblico. Quando si tratterà di allocare il prossimo budget di web marketing, si potranno fare scelte più oculate.

Alla fine l’inserimento o meno delle transazioni negative è un’opportunità da considerare attentamente: se si stanno valutando le performance del sito e i ritorni degli investimenti pubblicitari, cioè se si analizza il sito in modo slegato dal mondo fisico, può avere ragione Clifton. Se si fa una valutazione più globale, che abbracci tutta la filiera – dall’acquisizione di un nuovo cliente alla sua soddisfazione finale col prodotto in mano – può sicuramente avere senso inserire le transazioni negative.

[photo credit: jaqian on flickr]


Aug 19 2008

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

funzioni: _addTrans()

autore: Marco Cilia categoria: funzioni

Sempre nell’ambito delle funzioni specificamente pensate per l’e-commerce, _addTrans(id_ordine, affiliazione, totale, tasse, spedizione, città, area, nazione) crea un oggetto-transazione del valore specificato. Come nel caso di _addItem() se un visitatore chiama due volte la funzione con uno stesso id_ordine (non sku, che in questo caso non è previsto) la seconda chiamata sovrascrive la prima. I parametri che _addTrans prevede, tutti stringhe, sono i seguenti:

  • id_ordine: l’identificativo dell’ordine (lo stesso di _addItem – obbligatorio)
  • affiliazione: nome del negozio o del partner che produce la transazione (facoltativo)
  • totale: il costo totale sostenuto dal cliente (obbligatorio)
  • tasse: l’ammontare dei costi per tasse sostenuti dal cliente (facoltativo)
  • spedizione: l’ammontare dei costi di spedizione sostenuti dal cliente (facoltativo)
  • città: la città associata alla transazione facoltativo)
  • area: l’area associata alla transazione (può essere lo stato USA, o la regione italiana ad esempio – facoltativo)
  • nazione: la nazione associata alla transazione (facoltativo)

Questa funzione ha anche un elemento di ritorno, utile in caso di debug. Questo oggetto è _gat.GA_Ecomm_.Transactions_ ed è l’identificativo dell’oggetto-transazione che è stato modificato dalla chiamata alla funzione.
Un utilizzo tipico di _addTrans() è quello che segue:

pageTracker._addTrans(
     "12345", // id_ordine
     "libreria ponte vecchio", // affiliazione
     "35.99", // totale
     "3.00", // tasse
     "5.99", // spedizione
     "Palermo", // città
     "Sicilia", // area
     "Italia" // nazione
     );

Anche questa volta, nel caso di parametri facoltativi, è necessario inserire le virgolette e lasciare vuoto il contenuto.