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


Jun 07 2017

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

La nuova dimensione “sessione diretta”

Oggi ho avuto modo di approfondire meglio una segnalazione del mio collega Giulio, che ha trovato una nuova dimensione dentro a Google Analytics. La dimensione si chiama “sessione diretta” ed è esattamente quello che ci aspetteremmo. Quindi prima un po’ di background per ripassare come funziona Analytics e perché questa cosa è interessante.

Il modello “last click non direct”

In tutti i report standard, tranne MultiChannel Funnel e Attribuzione, il modello di attribuzione standard di GA è il cosiddetto “last click non direct”. Si tratta di un modello che attribuisce la sessione corrente (ed eventualmente le conversioni registrate durante essa) all’ultima sorgente registrata da quell’utente TRANNE se questa avviene per via di traffico diretto. Quindi se sono un utente nuovo e arrivo da organico, e domani torno da diretto e converto, GA segna 2 sessioni organiche e 1 conversione organica. Se sono un utente nuovo e faccio diretto e poi diretto, GA segna 2 sessioni al diretto e 1 conversione al diretto. In pratica si dice “il traffico diretto non sovrascrive mai la precedente sorgente, tranne se quella era diretto”.

Come dicevamo prima, la cosa non è vera nei report di canalizzazione multicanale e attribuzione: lì il primo esempio viene correttamente riportato come organico 1 sessione 0 conversioni e diretto 1 sessione e 1 conversione. Nei report di attribuzione si può confrontare il modello last click non direct con il last click puro o con altri messi a disposizione o creati custom.

La nuova dimensione “sessione diretta”

Fino ad oggi questo fenomeno era noto ma indistinguibile, nei report standard. Il totale del traffico organico o di campagna comprendeva sempre una quota di traffico diretto che attribuiva tutto alla sorgente precedente. La nuova dimensione “sessione diretta” invece consente di scindere le due componenti, proprio come desidereremmo:

Come potete notare, applicando la dimensione ho ogni riga spacchettata in due componenti: google/organic “vero” (11.322 sessioni) e google/organic “da traffico diretto che non sovrascrive” (4.641 sessioni). Idem per google/cpc e tutte le sorgenti, tranne il traffico diretto: il traffico diretto può solo essere diretto, quindi è sempre “Yes”.
Inoltre anche la colonna dei nuovi utenti torna alla perfezione: se il traffico da “sessione diretta” è formato da utenti che erano già stati sul sito e tornano da diretto, allora non potranno mai essere new users, e quindi la colonna “nuovi utenti” è sempre 0 (anche qui con l’eccezione del traffico diretto, che ovviamente PUO’ portare nuovi utenti e anche utenti di ritorno che prima erano di nuovo arrivati solo da diretto).

Perché reputo importante questa novità

Per due motivi principalmente: il primo è che da una rappresentazione migliore di cosa accade realmente sul nostro sito, e dei reali apporti “di prima mano” delle varie leve di marketing. E’ sempre meglio sapere piuttosto che non sapere.
Il secondo è che fino ad oggi questa rappresentazione del “reale” esisteva solo nei multichannel funnel, ma limitatamente al traffico che converte; i MCF infatti prendono in considerazione solo coloro che convertono. Grazie alla nuova dimensione possiamo studiare nel dettaglio anche l’apporto del diretto nel traffico che non converte, aumentando le possibilità di comprensione della composizione del nostro traffico e quindi di ottimizzazione.


May 10 2017

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

Google dice, Google fa, Google forse

autore: Marco Cilia categoria: real-time tag:

Uno degli aspetti che a tutt’oggi mi lascia allibito di Google è la leggerezza con la quale fa (o non fa) gli annunci. Voglio dire, sei Google e ci sono milioni di persone che “pendono dalle tue labbra” professionalmente per sapere se e come cambierà la propria professione in futuro: se dichiari che cambi un aspetto dei tuoi strumenti, i professionisti devono studiare perché li usano, o perché ne rispondono ai clienti. Peggio quando li cambi senza dire niente, cosa che ogni tanto accade tutt’ora.

Questi sono due aspetti – bianco o nero – della stessa storia, ma in realtà ci sono anche tutte le sfumature intermedie: Google annuncia una cosa, e poi la cosa si fa, ma diversa da come l’han detta. Prendiamo ad esempio il fatto che GA360 è praticamente in real time in alcuni report. IN – ALCUNI – REPORT. Quali? non lo dicono, ma dicono quali NON LO SARANNO, vedi sempre il mio post precedente dove ad esempio dico “Tutti i report con almeno una tra le dimensioni Sorgente, Mezzo, Campagna”.
Ora, potrebbe essere che fossi ubriaco quando l’ho scritto, se non fosse che l’ho chiaramente copiato dalla pagina di help ufficiale

https://support.google.com/analytics/answer/7084038#where

“Reports that include the Source, Medium, or Campaign dimension”

Poi attivano la feature, apri il classico report sorgente / mezzo e…

voilà, near-real-time anche lì. Che per carità, se devo pensare a un report nel quale è utile – immaginiamo lo start di una campagna – è proprio quello, che però secondo l’help invece non dovrebbe goderne.

Oppure la nuova Home di Analytics: annunciata il 19 aprile, l’ho vista per sbaglio solo su un cliente, ma è sparita dopo un refresh. Non pervenuta.

Oppure i report “qualità della sessione” e “lifetime value”, addirittura non annunciati sul blog ufficiale, che è in silenzio da quasi un mese (vabbeh, mi direte voi, senti chi parla… 😀 ). Alcune volte mi domando se facciano dei test, tipo “vediamo quanto velocemente si diffonde la voce di questo nuovo report se non lo annunciamo”, ma non so darmi una vera e propria risposta precisa. Ci avete mai pensato? vi siete dati una spiegazione?


Apr 12 2017

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

Cosa resterà, di questi anni 80?

autore: Marco Cilia categoria: generale tag:

Volevo parlarvi del nuovo report “Qualità della sessione” che presto farà capolino anche nei vostri Analytics, ma tutto sommato il post di Enrico Pavan è completo e buono, e se volete anche qualcosa in inglese vi punto verso AnalyticsPros.

Tanto per riassumere ai pigri che non cliccheranno i link, Google Analytics userà un sistema di machine learning per attribuire un punteggio di qualità alle sessioni sul sito – deve essere un ecommerce, e anche con dei volumi interessanti – in modo da suddividere il totale in sessioni con bassa o altissima propensione alla conversione. Da qui a farne dei segmenti, audience, liste di remarketing il passo è breve, e le strategie di marketing che si possono applicare sono ovviamente molte e interessanti.

Più che altro colgo lo spunto per una riflessione sul ruolo dell’analista del futuro, adesso che praticamente abbiamo:

Il machine learning ci ruberà il lavoro?
io credo di no, non nell’immediato almeno. Vedete, il grande problema che si cela dietro a tutta questa automazione è che si basa sul presupposto che l’Analytics sia perfetto, o per lo meno “giusto”. E di Analytics impeccabili nella mia vita ne ho visti ben pochi, nonostante tutto. Non avete idea del numero di volte in cui ancora nel 2017 riecheggia in ufficio la frase di Bartali “Gl’è tutto sbagliato, gl’è tutto da rifare” aprendo Analytics di nuovi clienti.

Come dico da praticamente sempre, se entra spazzatura nel sistema, dal sistema esce spazzatura. Ci riferivamo all’analisi prima, figuriamoci cosa succede se un algoritmo cataloga le vostre sessioni e crea automaticamente le liste sulle quali vengono spesi parte dei budget di campagna.

La seconda riflessione va nella direzione ancora poco esplorata a mio modo di vedere della data integration, ovvero delle possibilità offerte a un brand, e solo a lui, dall’unione dei dati di Analytics con quelli proprietari. Certo, alla fine si tratta sempre di portare tutto dentro Google (anche se qualche workaround esiste), ma le possibilità di targeting che vengono sbloccate, la capacità di segmentazione della user base, la pletora di nuove strategie di marketing che si possono mettere in atto sono veramente tantissime. E per fare quel lavoro, al di là della praticità o dell’essere un system integrator, richiede una conoscenza degli strumenti e una capacità di disegnare la struttura dei dati che al momento nessun robot può eseguire.

Quindi si, qualcosa di questi anni 80 resterà 🙂


Mar 03 2017

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

GA360 praticamente in real time

autore: Marco Cilia categoria: generale tag: ,

No, non stiamo parlando dei report real time, che sono governati da logiche leggermente diverse dai report standard. Stiamo dicendo che in base all’ultimo post ufficiale i fortunati possessori di Google Analytics 360 (ex Google Analytics Premium) beneficeranno di un aggiornamento dei report standard del giorno odierno ogni 10 minuti.

Anche se a prima vista può sembrare tantissimo (in realtà lo è, ma ormai siamo abituati talmente bene che non lo sembra) gli utilizzatori di Premium più accorti sanno che la media rilevata per la cosiddetta freshness del dato è di circa 45 minuti, a fronte di una garanzia contattuale di massimo 4 ore.
Significa che se prendo i dati di oggi ed è mezzogiorno, sono certo contrattualmente che il dato più vecchio è delle 8 del mattino, ma che verosimilmente vedrò già anche i dati fino alle 11:15.
Quando il near real time sarà introdotto su tutti gli account, vedrò anche i dati fino alle 11:50.
Questo varrebbe anche per i custom report, le estrazioni via API e prossimamente anche per il trasferimento di dati verso BigQuery, la piattaforma di BigData che consente di fare interrogazioni ai dati di GA come se fosse un enorme database.

Esisteranno alcune notabili eccezioni a questo comportamento, ed è anche facile capire perché: un aggiornamento così veloce è possibile solo in presenza di elaborazioni non complesse e solo sui dati “propri” di Analytics. Ecco l’elenco dei report dove il near real time non sarà disponibile, almeno inizialmente:

  • Tutti i rapporti dentro a viste contenenti dati da proprietà che hanno oltre 2 miliardi di hits al mese
  • Tutti i rapporti dentro a viste di tipo USERID
  • Tutti i rapporti dentro a viste che hanno filtri basati su campi importati tramite data import
  • Tutti i rapporti dentro a viste che hanno filtri basati su Sorgente, Mezzo o Campagna
  • Tutti i rapporti dentro a viste che hanno filtri basati su dati provenienti da piattaforme terze (Adwords, Doubleclick, ecc)
  • Tutti i report che comprendono dati importati tramite data import
  • Tutti i report con almeno una tra le dimensioni Sorgente, Mezzo, Campagna
  • Tutti i report che comprendono dimensioni importate da altre piattaforme terze (Adwords, Doubleclick, ecc)

Se la delusione per la presenza del limite su sorgenti/mezzi può essere tanta, come noterete non si parla di Ecommerce, e questo è cosa buona e giusta! 🙂
Come nota di colore, ho tirato fuori uno screenshot supersegreto del Partner Summit 2015, in cui Google diceva “l’obiettivo è di avere entro un anno freshness a 1 minuto”. Ce ne sono voluti due, e siamo a 10 minuti, ma almeno sappiamo che se una cosa è in roadmap, prima o poi arriva 🙂


Feb 11 2017

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

Tutti pazzi per DataStudio

autore: Marco Cilia categoria: datastudio tag: ,

La “novità” del momento sembra proprio essere DataStudio. Tutti parlano di DataStudio, tutti usano DataStudio.
Google ha aggiunto il connettore per la search console, evviva! 🙂
Google ha aggiunto il connettore per il centro clienti AdWords, hip hip hurrà!
Addirittura ho letto in giro che “Google ha introdotto una versione free di DataStudio”.

In realtà DataStudio esiste da mesi (anni per chi ha partecipato alle preview alpha e beta), e in Italia è circa da maggio che si può usare; l’unica novità è la rimozione del limite a 5 report. Così adesso si possono fare dei bei lenzuoloni di 87 report, che non verranno letti tanto quanto i powerpoint di 87 slide 😀
Rispetto ai connettori, è ovviamente meglio averli nativi: più supporto, meno passaggi, più mantenibili, ma in realtà non c’è niente che si possa fare ora che non si potesse fare anche prima con un minimo di lavoro in più, tipicamente passando per Google Drive.

La vera sfida, secondo me, sarà vedere quando Google supporterà – e come e quali – servizi esterni che attualmente invece hanno connettori specifici su altri strumenti di dashboarding: penso a tool come Pingdom, Moz, Searchmetrics, Optimizely, Mailchimp, eccetera…
Riguardo a DataStudio in sé, ci trovo ancora parecchie limitazioni piuttosto insensate. due su tutte?

  • se includo due datasource in un report, non posso fare la somma della stessa metrica
  • non posso calcolare al volo/rappresentare la % sul totale di una metrica

E voi? avete trovato dei grossi limiti, o riuscite a fare tutto quel che vi serve?


Jan 14 2017

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

Un errore da principianti con TagManager

autore: Marco Cilia categoria: tagmanager tag: ,

In questo back-to-basic voglio affrontare un classico errore da principiante che su Google Tag Manager è potenzialmente molto dannoso: si tratta dell’editing delle regole di attivazione direttamente da dentro alla configurazione di un tag.

Come saprete, l’interfaccia v2 di GTM consente ampia libertà nel configurare Variabili, Attivatori e Tag: oltre che nelle sezioni apposite e con l’uso del pulsante “NUOVO”, si può creare una attivatore o una variabile anche mentre si configura un tag, con schermate successive che si sovrappongono all’attuale. Ecco, secondo me l’aggiunta di regole (la modifica più che altro) direttamente dall’interfaccia dei tag dovrebbe essere limitata. Facciamo il caso pratico:

Il cliente chiama e dice “mi serve questo tag solo sul sottodominio italiano”. Tu prendi, configuri il tag e crei una regola di attivazione tipo – ipotizziamo – “page Host uguale a it.sitodelcliente.com”. Pubblichi, funziona e te ne dimentichi.
Dopo tre mesi il cliente richiama e dice “sai quel tag? dobbiamo estenderlo anche ai sottodomini francese e tedesco”.

Qualcuno potrebbe avere la bella idea di andare nel tag, aprire l’attivatore, cambiargli nome e cambiare la regola in “page Host corrisponde alla regex (it|fr|de)\.sitodelcliente\.com”. D’altronde in italiano è esattamente quel che ci ha chiesto il cliente, estendere un tag ad altri sottodomini.

ERRORE!

L’errore è quello di pensare all’attivatore come parte di un tag, cosa che l’interfaccia un po’ ti spinge a fare. Ipotizziamo che un’altra agenzia nel frattempo abbia messo un suo tag solo sul dominio italiano. Se cambiamo l’attivatore, lo cambiamo PER TUTTO IL TAGMANAGER, non solo per quel tag. Ovvero, estendiamo il campo di azione di TUTTI i tag associati a quell’attivatore.

Se invece di aprire il tag andassimo nella sezione degli attivatori, la cosa sarebbe più chiara perché ogni attivatore riporta vicino il numero di tag associati ad esso. E in ogni caso noi staremmo solo cambiando un attivatore, senza riferimento a nessun tag, e la cosa potrebbe farci nascere sospetti se ripensassimo alle parole esatte del cliente.

In buona sostanza il mio consiglio è quello di evitare per quanto possibile di modificare variabili e attivatori da dentro a un tag, in modo da rimuovere il legame mentale tra il tag e gli altri elementi, e lasciare che il concetto più corretto del GTM pervada la nostra mente: MODULARITA’ 🙂