Jul 10 2018

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

In arrivo il vero report cross device

autore: Marco Cilia categoria: generale tag: , ,

Oggi durante il Google Marketing Live 2018 Google ha annunciato che Analytics presto sarà fornito di report cross-device.
Sento già levarsi le voci e vedo i nasi storti in chi sta per dirmi “hai preso una botta in testa? Google Analytics HA GIA’ i report cross-device, basta passare uno USERID uguale tra desktop e mobile, ed è fatta”.

Si, lo so, ma quella è una funzione “volontaria”, sta al webmaster o a chi implementa i tracker far si che la magia accada. Google oggi ha annunciato una cosa che mi sono sentito chiedere in almeno la metà dei corsi che ho tenuto negli ultimi dieci anni, ovvero il fatto che il ricongiungimento dei dati verrà fatto direttamente dalla piattaforma sulla base dei segnali che normalmente usa per identificare gli utenti su più dispositivi, il più semplice da immaginare e capire è l’essere loggati ad un google account (gmail, youtube, eccetera…)

Ho visto questi report quasi un anno fa a San Francisco, spero che abbiano fatto che passi in avanti perché seppur stupendevoli e sicuramente utilissimi, gli ingegneri non erano ancora riusciti a fugare un paio di dubbi che i clienti più avanzati ed esigenti vorrebbero risolti da una funzionalità come questa, guarda caso sempre legata a iOS e Safari 😀

In ogni caso preparatevi, perché se funzionerà a dovere e con una significatività statistica decente, questo cambierà completamente le vostre attuali valutazioni dei ritorni di marketing!

Che ne pensate?


May 23 2018

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

Arriva la cancellazione dei dati del singolo utente

autore: Marco Cilia categoria: API tag: ,

Quasi al fotofinish, il GDPR entra in vigore tra due giorni, Google rilascia la User Deletion API che come si intuisce dal nome è la funzione per cancellare i dati dalla piattaforma i dati puntuali di un singolo utente, dove “utente” sta per clientID, userID o identificativo dell’utente dentro a una app.

L’API prende come input sostanzialmente tre parametri: il tipo di identificativo che stiamo passando (appunto, se si tratta di un client/user ID o di un’app), l’identificativo stesso e la property (web o Firebase) dove cancellare i dati.
Esiste poi un ulteriore parametro che però sinceramente non ho compreso bene: si tratta del DeletionRequestTime, che dovrebbe indicare una data fino a quando cancellare i dati; io non ho capito se si intende “da oggi indietro e fino a…” oppure “dall’inizio dei dati e in avanti fino a…”, anche se propenderei per la prima ipotesi.

Il fatto che sia stata rilasciata un’API da un lato è sensato, perché si può automatizzare facilmente il lavoro, dall’altro rende difficile cancellare un singolo utente per chi non è affine al mondo delle interfacce programmatiche. In ogni caso secondo me basterà aspettare un pochino e si vedranno fiorire servizi basati su questa API. So per certo che l’autore del package di R “GoogleAnalyticsR” ha già implementato la feature e la sta testando, per cui se siete soliti utilizzare quel package è solo questione di tempo…


Apr 12 2018

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

Clamoroso! Grazie al GDPR potrete cancellare dati da GA

autore: Marco Cilia categoria: generale tag: , ,

Spesso su questo blog vi ho raccontato che mi pregio di essere un utente “della prima ora” di Google Analytics, ovvero di essermi iscritto e di avere un profilo con dati dal giorno 1 della sua esistenza, il 14 novembre 2005. Da allora, Google non ha mai cancellato niente, nonostante su alcune versioni del contratto di servizio avesse il diritto di farlo per i dati più vecchi di 36 mesi (ora mi sembra questa dicitura sia scomparsa).

Oggi invece gli utenti di Google Analytics hanno ricevuto l’ennesima email di aggiornamento sugli adempimenti che Google sta portando avanti per adeguarsi al nuovo regolamento europeo sulla protezione dei dati (o in breve GDPR), che entra in vigore il prossimo 25 maggio: il contenuto della mail è clamoroso perché per la prima volta nella storia di questo strumento introduce una nuova opzione nel pannello di controllo che permette di cancellare *alcuni* dati più vecchi di una certa data, rolling di mese in mese. L’avviso è riportato anche accedendo all’interfaccia di Google Analytics.

Quali dati si potranno cancellare? tutti quelli legati a un cookie, un identificativo utente (userID) o un identificativo advertiser (Doubleclick cookie, identificativi dei device) o un evento. I dati aggregati invece non saranno cancellabili, il che significa probabilmente che il numero di sessioni non si azzererà mai, mentre il numero di utenti (basato sul conteggio dei cookie unici) potrebbe. Le sorgenti di traffico, quando viste per numero di sessioni, dovrebbero essere un report che non cambia mai, il report degli eventi potrebbe variare. E così via…

Il nuovo setting lo potete trovare se avete privilegi di MODIFICA su una property, andando nelle impostazioni della property, nella sezione Informazioni sul tracking e poi Data Retention.

Come vedete le opzioni disponibili sono da uno a cinque anni + due mesi fissi, oppure disabilitato. ATTENZIONE PERCHE’ DI DEFAULT IL SETTING E’ IMPOSTATO SU 26 MESI

La cancellazione dei dati viene fatta una volta al mese in base al setting che viene scelto. La scelta può essere annullata entro 24 ore, quindi se adesso modifico l’opzione ho tempo fino a domani alla stessa ora per annullare. Dopodiché GA prenderà atto della nuova scelta e alla prossima cancellazione opererà di conseguenza.
L’altra opzione disponibile permette di calcolare il lasso di tempo sulla base dell’ultimo evento inviato da un identificativo. Ovvero se dico che il mio periodo di retention è 14 mesi ma imposto su ON l’opzione “Reimposta in caso di nuova attività”, allora se l’utente visita il sito ogni mese non verrà cancellato mai, se invece non visita per 14 mesi verrà cancellato.

Quindi meglio ripetere il concetto: se lasciate tutto così com’è, a partire da Giugno Google Analytics cancellerà ALCUNI dati associati a cookie che non si sono presentati sul sito per 26 mesi
Non confondete questa cosa con il fatto che di default se un utente non torna per 24 mesi, GA lo considera nuovo utente alla prossima visita. Qui si sta parlando di MODIFICHE ai dati di due anni fa.

Ma c’è una seconda novità, sempre preannunciata dalla mail. Tra poco Google introdurrà uno strumento per cancellare PUNTUALMENTE i dati di un utente, basandosi sul clientID standard del cookie di Google Analytics, su uno userID o su un identificativo app se si usa Firebase. Questo potrebbe anche significare poter cancellare le proprie sessioni e transazioni di test su un ecommerce, tra l’altro.

Che dire, si tratta di un cambiamento epocale per come siamo abituati a pensare al prodotto e alle sue caratteristiche più intrinseche: il famoso detto “i report vecchi non cambiano mai” non sarà più del tutto vero, e finalmente quando un cliente dirà “ho rifatto a distanza di mesi lo stesso esatto report e i risultati sono diversi” avremo qualcosa a cui pensare davvero, invece di liquidarlo perché sappiamo (sapevamo, tra poco) che non è possibile…


Mar 01 2018

Finalmente i gruppi negli utenti di GA!

autore: Marco Cilia categoria: codice di monitoraggio

Il blog di Google Analytics ci informa con un post che una delle feature più attese da SEMPRE, almeno per gli utenti di livello medio ed enterprise, è giunta nei nostri account: i gruppi di utenti.

Innanzitutto i gruppi di utenti si possono creare soltanto dentro a un’ORGANIZATION, ovvero un’entità superiore all’account Analytics che può essere creata partendo dal link 360suite.google.com. Se siete organization admin o user admin di una organization, cliccando il “+” nell’interfaccia di creazione utenti dell’organization potete scegliere se creare (aggiungere) un singolo user o un gruppo, e in questo secondo caso dovrete dare un nome al gruppo e aggiungere i singoli indirizzi email. Più sotto potrete dare accesso al gruppo ai singoli prodotti linkati in quella organization, con un controllo abbastanza capillare. Ad esempio invece di aggiungere 10 utenti a 4 account Analytics, un Tag Manager e un Optimize, si può creare un gruppo, e poi dare accesso a questo gruppo, risparmiandosi innumerevoli decine di clic.

Inoltre, per i casi più complessi, c’è una feature potente ma da maneggiare con cautela: dentro ai gruppi si possono aggiungere altri gruppi! Maneggiare con prudenza 🙂

La cosa potrebbe dall’altro verso complicare un pochino gli assessment degli utenti, perché i gruppi nell’interfaccia degli utenti dei prodotti, ad esempio Analytics, compaiono come gruppi e non come singoli account email. Ergo non c’è modo di conoscere lo status degli accessi degli appartenenti ad un gruppo senza essere anche un Organization admin, mentre oggi con il giusto privilegio l’elenco degli utenti è sempre visibile nella sua interezza. E’ una cosa che secondo me andrebbe migliorata, L’interfaccia dovrebbe mostrare i singoli account e semmai a quale gruppo appartengono, oppure permettere un livello di drill-down dal gruppo ai suoi componenti. Può darsi che in futuro sarà possibile.

L’altra novità che il post ci segnala è l’applicazione più restrittiva delle regole di abilitazione utenti: le regole di abilitazione dettano i criteri affinché un utente possa o non possa essere aggiunto ai prodotti della suite Google (sia free sia a pagamento), ma se fino a ieri l’infrazione della regola provocava solo una notifica (del tipo “ecco l’elenco degli utenti che non soddisfano la tua regola”), da oggi è possibile far si che le norme siano restrittive e bloccanti!

Quindi io in qualità di Organization Admin potrei dire che si possono abilitare solo account che contengono @dominiocliente.it e @dominioagenzia.com e se qualcuno provasse ad aggiungere una gmail riceverebbe un errore e non potrebbe farlo. Esattamente come in questa immagine esplicativa

Un deciso passo avanti verso uno standard di prodotto di livello enterprise, anche se in realtà si applica anche alla versione free, che renderà molto più semplice la gestione degli utenti, in special modo nella big corporation, dove si sono sempre fatti i salti mortali per tenere tutto allineato sotto questo punto di vista.


Jan 23 2018

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

Ecco la prima integrazione GA360 – Salesforce

autore: Marco Cilia categoria: ga-premium tag: ,

Una delle situazioni più comuni con cui mi trovo ad avere a che fare in ambito GA360 è la presenza in azienda di Salesforce, in una o più delle sue incarnazioni. La cosa non deve essere affatto isolata, tanto è vero che qualche mese fa Google e Salesforce hanno annunciato una partnership per integrare più a fondo le loro piattaforme.
Pensandoci la cosa ha perfettamente senso: da un lato GA contiene tutto lo scibile sul marketing online di un brand, i tracking, i risultati, gli spending e i ROI, la storia degli utenti e la capacità di segmentazione. Ma spesso, specialmente nel caso di siti di lead generation, si ferma al potenziale contatto.
Salesforce, d’altro canto, è una potenza incredibile per quanto riguarda tutto quel che avviene “dopo”: CRM, marketing cloud, marketing automation, ecc ma sa poco o nulla di quanto è accaduto prima del lead.

Esistevano già dei metodi “caserecci” per provare a fare questa integrazione, ma erano tutti basati su presupposti che non ho mai trovato perfettamente sensati. Come tutte le forzature, non è detto che il risultato fosse quello atteso o sperato.

Da qualche giorno invece l’integrazione tra Salesforce Sales Cloud e GA360 è realtà, e permette di importare dentro a Google Analytics le informazioni riguardanti i “cambi di stato” di un lead, per tutta la sua storia offline. Ogni cambio di stato viene sparato verso GA con un evento, che viene legato all’utente e al lead poiché la form di Salesforce invia anche l’identificativo del cookie di Analytics, e questi eventi possono poi essere usati per creare dei goal in grado di dare una visione qualitativa dei lead. Ad esempio si potrà capire che un dato canale porta molti lead, ma che si fermano quasi tutti al primo step della pipeline, mentre altri canali magari ne portano meno, ma poi vengono chiusi quasi tutti offline.

Come detto, Salesforce importerà questi cambi di stato come eventi, che avranno categoria “Lead” o “Opportunity” (a seconda che provengano da form del modulo Lead o form del modulo Opportunity, ovviamente), action “New” oppure “Change” e label variabile a seconda della vostra implementazione e definizione degli status all’interno di Salesforce Cloud. Nessun nuovo report, quindi, ma un sacco di informazioni utili per le analisi, le segmentazioni, il remarketing (si può creare una lista di remarketing di tutti i clientID che sono passati in un certo status, e pusharla immediatamente su AdWords o Doubleclick). Possibilità interessantissime a portata di click 🙂


Dec 24 2017

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

“Utenti” in tutti i report, ma fate attenzione!

autore: Marco Cilia categoria: report tag: , ,

Qualche giorno fa il blog ufficiale di Analytics ci ha informato di alcune novità apportate al prodotto:

  1. introduzione della metrica “utenti” in molti report
  2. Lifetime value nel report esplorazione utenti
  3. Audience nei report
  4. Probabilità di conversione

Sono tutte cose molto interessanti, ma vorrei soffermarmi in particolare sulla prima. Le tre metriche standard dei report che seguono il modello Acquisizione/Comportamento/Conversione per la sezione Acquisizione al momento sono Sessioni, % nuove sessioni e nuovi utenti. Andando nelle impostazioni delle proprietà si potrà scegliere se abilitare il flag Abilita la metrica utenti nei report per far si che questo trittico cambi in Utenti, nuovi utenti e sessioni.

La prima nota è che la metrica di default diventerebbe Utenti, e così anche il grafico standard che adesso invece è impostato su Sessioni. In alcuni casi le due metriche hanno andamenti molto diversi, e la cosa ha un impatto visivo non da poco.

Users everywhere

La seconda nota è più importante, e ha a che fare con il campionamento. Come abbiamo detto più volte su questo blog, i report standard non sono mai campionati, tranne alcune notabili eccezioni. Ovvero, se apro un report che esce “così com’è” dalla mente degli ingegneri, e non applico segmenti o dimensioni secondarie (insomma, se non faccio fare calcoli a GA), il report non è campionato. Questo accade perché i calcoli vengono fatti in fase di analisi, e le metriche intermedie (giornaliere, tipicamente) vengono poi sommate per il periodo temporale che selezioniamo.

Ma quindi cosa succede se abilitiamo la nuova funzione?
Nella sostanza succede che stiamo cambiando lo schema di interrogazione dei dati, trasformiamo TUTTI i report in report non standard, quindi soggetti a campionamento. Questo accade per due motivi:

  1. la metrica utenti non si può sommare mai. Come ci ricorda il famoso problema dell’hotel, 1 utente ogni giorno non necessariamente sono 3 utenti in 3 giorni, potrebbe essere sempre lo stesso e “sommerebbe” 1. Nella pratica questo si traduce nell’impossibilità di precalcolare il numero di utenti di un qualsiasi periodo temporale.
  2. Per venire incontro a questo problema, Google Analytics sta “predigerendo” questa metrica in qualche modo che non mi è chiaro, ma non lo può fare per il passato. Hanno iniziato a farlo in un momento imprecisato del passato, ma qualsiasi interrogazione che vada a chiamare dati precedenti produce un calcolo, quindi potenzialmente produce campionamento.

In sostanza se le vostre analisi sommano spesso più di 500k sessioni o se avete l’abitudine di fare analisi su lunghi periodi temporali passati, potrebbe non convenirvi abilitare questa metrica. Per fortuna a quanto ne so la cosa è reversibile, quindi potete provare e semmai tornare indietro, fintanto che la cosa non sarà forzata dagli ingegneri.


Dec 05 2017

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

il report dei contenuti a 1M di righe

autore: Marco Cilia categoria: ga-premium,report tag: , ,

Qualche settimana fa mi sono imbattuto in un fenomeno curioso, ma prima di scrivere un post aspettavo conferme; qualche giorno fa ho visto fugacemente un post su Google+ per la stessa cosa e m’è tornato in mente di verificare. Ora vi spiego tutto, ma prima un minimo di ripasso delle basi.

quante righe può contenere ogni report?

La domanda sembra banale, specialmente se si ha a che fare con siti di piccole dimensioni, o se il setup è stato fatto cum grano salis, ma non lo è affatto quando si guarda l’Analytics di siti grandi o giganteschi. La risposta infatti non è “infinite” 🙂
Il numero di righe di un report in gergo tecnico viene definita cardinalità, e prima di proseguire la lettura vi consiglio un ripassino di questo post evergreen: la voce (altro) nei report

Detto fatto, più un sito ha un distinto numero di pagine univoche (vere pagine uniche, o anche semplicemente parametri non filtrati nell’URL), più la voce (other) pesa nel report dei contenuti; parliamo di contenuti perché difficilmente si arriva a 50k record al giorno su altre dimensioni, in ogni caso il problema si porrebbe su qualsiasi tabella.

Cosa è cambiato di recente?

Di recente, da qualche settimana, il valore di (other) nel report dei contenuti è sceso moltissimo sugli analytics di siti giganteschi cui ho accesso, ed è praticamente sparito su siti grossi. Possiamo affermare con relativa tranquillità che il nuovo limite massimo giornaliero è passato da 50k a 1 milione, un incremento pazzesco se ci pensate. Oltretutto dai primi riscontri sembrerebbe che la cosa valga anche sugli Analytics standard, non è una prerogativa di Premium/360. Il cruccio delle analisi sui contenuti, tanto care anche ai nostri amici SEO, è adesso minore e non costringe ad artifizi e trucchi vari per venire a capo lo stesso del problema. Ma c’è di più:

Le custom tables (se hai GA360) e il loro ruolo nei report standard

Se hai accesso a un GA360, e hai i privilegi sufficienti, puoi creare le custom tables, o tabelle personalizzate nella UI italiana, che sono praticamente dei custom report che vengono permanentemente salvati ed elaborati preaggregati. Significa cioè che su quelle tabelle i dati sono sempre puntuali e mai campionati, entro 1M di righe e a patto che eventuali dimensioni secondarie o segmenti siano specificati già in fase di creazione della custom table.
Bene, ma questo cosa c’entra col problema iniziale? ecco, ora ti spiego la magia: quando tu fai una qualsiasi richiesta a GA, lui interroga uno schema, ovvero una “mappa” delle combinazioni possibili di dimensioni e metriche. I report preaggregati hanno uno schema predefinito, l’aggiunta di una dimensione secondaria tra quelle previste provoca l’interrogazione di uno schema diverso, ma non predefinito.

Però se tu crei una custom table (che un limite di cardinalità di 1M di righe) che ricalca esattamente lo schema di un report preaggregato (che ha un limite di cardinalità di 50k righe), quando tu chiedi il report standard, lo schema “punterà” alla custom table, regalandoti il report standard con 1M di righe, anche se non è il report dei contenuti che abbiamo visto poco sopra. Fico eh? 🙂

L’unica cosa da tenere presente è che ovviamente le custom tables non sono retroattive, o meglio vengono rimpolpate con i 30gg precedenti alla creazione, non oltre. Meglio di niente, in ogni caso…


Oct 17 2017

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

gtag.js aggiunge il supporto ad AdWords, come previsto

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

Proprio come dicevamo nell’ultimo post, gtag.js ha da poco aggiunto il supporto nativo per AdWords: questo significa che se avete un sito che sta già tracciando tramite il nuovo gtag.js, basterà aggiungere una riga di configurazione specificando l’account AdWords nel quale inviare i dati, così:


<script>
    window.dataLayer = window.dataLayer || [];
    function gtag(){dataLayer.push(arguments)};
    gtag('js', new Date());

    gtag('config', 'GA_TRACKING_ID');
    gtag('config', 'AW-123456789');
  </script>

e tracciare l’azione da monitorare come conversione, così:


<script>
      gtag('event', 'conversion', {'send_to': 'AW-123456789/AbC-D_efG-h12_34-567',
        'value': 1.0,
        'currency': 'USD'
      });
  </script>

Le opzioni per mantenere il conteggio delle conversioni accurato, per prevenire i problemi introdotti da Apple e dal suo Intelligent Tracking Prevention, sono in ogni caso attualmente tre:

  1. passare a questo nuovo formato di script. Questo permette di salvare i GCLID di AdWords in cookie di prima parte, che non vengono toccati dall’ITP di Safari/IOS
  2. usare Google Analytics collegato ad AdWords. GA già da settembre si occupa di salvare il gclid in un cookie di prima parte, favorendo poi AdWords
  3. usare Google Tag Manager per inserire un nuovo tipo di tag, il conversion linker tag su tutte le pagine, che fa sempre la stessa cosa

Interessante anche la conferma finale nel post sul blog di AdWords riguardo al fatto che a Novembre aggiungeranno anche il supporto per DoubleClick Search, confermando quindi che il nuovo gtag.js potrà tendenzialmente gestire anche quella parte di piattaforma, diventando moooolto interessante per chi non può o non vuole passare a GTM.


Sep 07 2017

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

Cosa è il nuovo gtag.js e cosa cambia all’utente medio?

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

Senza nemmeno troppa pubblicità, il team di Google Analytics ha introdotto un nuovo snippet di codice da utilizzare “per il page tagging”: cosa si intende esattamente? sicuramente si può utilizzare per inviare dati a Google Analytics, come vedremo tra poco. E-nor riporta anche che presto la libreria includerà conversion.js di AdWords. Questo rende il discorso interessante sotto alcuni punti di vista. Ma andiamo con ordine.

Lo snippet da installare appena dopo l’apertura di HEAD è più corto del classico di Universal, vediamo come è fatto


<!-- Global Site Tag (gtag.js) - Google Analytics -->
<script async src="https://www.googletagmanager.com/gtag/js?id=GA_TRACKING_ID"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments)};
  gtag('js', new Date());

  gtag('config', 'UA-XXXXXXX-Y');
</script>

La prima cosa che si nota è che non c’è il comando per l’invio del pageview, e la cosa è voluta. Questo codice, da solo, fa quel che faceva il vecchio codice di base. Se anzi volessi disabilitare l’invio del pageview per qualche motivo, dovrei forzarlo con un parametro aggiuntivo


gtag('config', 'GA_TRACKING_ID', { 'send_page_view': false });

La seconda novità è che si possono gestire i multicodici con più facilità. Ipotizziamo, nemmeno con troppa fantasia, che debba mandare i dati a 4 properties. Oggi dovrei istanziare 4 tracker e fare 4 send pageview, come minimo. Domani, in presenza di un codice così


gtag('config', 'UA-111111-11', {'groups': 'default'});
gtag('config', 'UA-222222-22', {'groups': 'access'});
gtag('config', 'UA-333333-33', {'groups': 'access'});
gtag('config', 'UA-444444-44', {'groups': 'access'});

Verranno inviate 4 pageview, ma potrei anche decidere che un evento lo mando solo alle tre property del gruppo access, tramite l’uso di send_to (che in ogni caso supporta anche la specifica degli ID delle property). Su installazioni complesse e ridondanti può essere un toccasana.

Oltre ai pageview, sappiamo che si possono inviare eventi. gtag.js ovviamente li supporta, in un modo un po’ inusuale però. Sebbene sia possibile sempre fare un “classico” evento con category, action e label, la sintassi della documentazione ufficiale parla genericamente di parametri


gtag('event', 'event_name', {
  // Event parameters
  'parameter_1': 'value_1',
  'parameter_2': 'value_2',
  // ...
});

che a me ricorda MOOOOOLTO DA VICINO un dataLayer.push 🙂
Eventi normali quindi sempre possibili, ma c’è un ma… la guida parla di RECCOMENDED EVENTS e RECCOMENDED PARAMETERS, e qui avviene la magia. Per esempio questo


gtag('event', 'login');

invierà un evento con categoria engagement, action login e nessuna label. Se volessi mandarlo alle 4 property raggruppate come sopra, mi basterebbe fare


gtag('event', 'login', {'send_to': ['default', 'access']});

Simpatico, no? 🙂

Dove troviamo l’elenco degli eventi raccomandati? nella documentazione ovviamente. Se faccio un evento add_to_whishlist, GA registra categoria ecommerce, action add_to_whishlist e label vuota. Se faccio un evento begin_checkout, lui si aspetta i parametri value, curency, items, coupon.
Ora, perché sono importanti questi eventi raccomandati? per due motivi:

  1. standardizzazione: sebbene sia lasciata facoltà di personalizzare tutto, gli eventi più comuni possono essere tracciati con nomi automatici, favorendo aggregazioni e confronti e facilitando la lettura dei dati
  2. se scorriamo la lista degli eventi, troviamo anche cose interessanti, ad esempio che che gli item parameter hanno origin e destination, e si specifica anche (travel). Non ricorda i parametri del remarketing dinamico per il vertical dei viaggi? e se si, non fa il paio con quanto dice E-nor sul fatto che domani gtag potrebbe incorporare anche lo script di AdWords? in questo modo una sola riga di codice farebbe entrambe le cose…

Infine, le mappe per le custom metric e dimension: supponiamo che dobbiate si mandare i dati a due o tre property, ma che gli indici delle custom metric e dimension non coincidano affatto. Un grande classico, peraltro. Ecco che ci viene in aiuto la mappatura preventiva, così:


gtag('config', 'UA-111111-11', {'groups': 'default', 
   'custom_map': {
     'dimension2': 'age',
     'metric5': 'avg_page_load_time'
   }});
gtag('config', 'UA-222222-22', {'groups': 'access', 
   'custom_map': {
     'dimension33': 'age',
     'metric66': 'avg_page_load_time'
   }});

Questo codice in pratica dice: “sulla property -11 l’età (age) la si manda sulla dimensione 2, e il tempo medio di caricamento della pagina sulla metrica 5. Sulla property -22 invece età va nella custom dimension 33 e load time sulla custom metric 66.”
A questo punto facendo ad esempio un semplice

gtag('event', 'add_to_whishlist', {'age': 'eta', 'avg_page_load_time': 14.5, 'send_to': ['access', 'default']});

avremo gli stessi valori inviati a due property e per giunta negli slot corretti! Interessante, no?

Ora, venendo all’utente medio, la domanda è naturalmente “dovrei migrare o no? questa cosa sostituisce Tag Manager?”
Questo tag NON SOSTITUISCE Tag Manager, che resta per ora il metodo di implementazione consigliato. La sua versatilità è enorme, e va ben oltre l’installazione di Google Analytics. Quindi restano in ballo solo i nuovi e vecchi progetti che vogliono migrare che per un motivo o per l’altro non vogliono o possono usare GTM sulle loro pagine. Per tutti coloro gtag.js è indubbiamente il futuro, sebbene al momento esso ancora non supporti i content experiment (ma che, ancora non sei passato a Google Optimize free? che aspetti? 🙂 ), i custom task e i custom plugin.

Se queste limitazioni non vi dicono nulla, e non avete GTM, allora vi consiglierei di provare a fare una migrazione. Se poi come dice Enor anche altri prodotti tipo AdWords saranno inglobati nel Global Tag, potrebbe essere vantaggioso avere già una installazione pronta.


Jul 19 2017

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

Parla con Analytics

autore: Marco Cilia categoria: generale tag: ,

Non poteva non venirmi in mente questa fantastica scena di Star Trek 4 per la notizia che Google Analytics Assistant sarà presto disponibile anche su Desktop.
Si tratta di un interprete del linguaggio naturale al quale sarà possibile fare domande, e ovviamente ottenere risposte. Ad esempio potremmo chiedere “quanti utenti dalla Russia divisi per tipo di device ho avuto il mese scorso?” e il sistema ci mostrerà il dato, e un grafico ove possibile.

Certo, in realtà dovremo ancora per un po’ scrivere, invece di parlare, ma il passo secondo me è breve perché la tecnologia in casa Google ce l’ha già. La comodità però è abbastanza evidente, poiché per alcune richieste molto semplici, ma che comunque comportano una serie di passaggi (apri il report geografico, mettilo per Paese, isola la Russia, applica la dimensione secondaria “tipo del device”) basterà solo fare la domanda. O incollare la domanda da una mail, quando sarà disponibile in italiano 🙂

Infatti il punto che mi piace di questa novità è che va ESATTAMENTE nella direzione che vado ripetendo nei coaching da ormai 5 anni: la vera forza dell’analista sta anche nel SAPER FARE LA DOMANDA GIUSTA allo strumento. Cioè conoscere bene quali metriche e dimensioni sono coinvolte nella domanda che mi porterà alla risposta, se sono disponibili nel progetto, se si possono incrociare tra di loro, eccetera…

L’help ufficiale della nuova feature si sposta un passo avanti, dicendo che – per fortuna – il sistema è in grado di capire i sinonimi, quindi ad esempio “locations” e “countries” vengono trattati allo stesso modo.
Ancora una volta, non credo che questo toglierà lavoro a qualcuno, ma indubbiamente rappresenta una scorciatoia molto interessante e utile per togliere tempo a domande semplici, o di routine, e quindi averne di più da dedicare alle analisi serie! 🙂