Sep 30 2015

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

I dati come i LEGO

autore: Marco Cilia categoria: tagmanager tag: ,

Ultimamente, sempre più spesso, mi è capitato di parlare con persone e intuire come nella loro testa fosse difficile capire le relazioni che ci sono tra gli strumenti che utilizziamo, il modo di trasportare i dati e la loro rappresentazione nel sistema. Grossomodo è la stessa relazione esistente tra chi dice genericamente “il posizionamento” sui motori di ricerca, e un SEO attento che invece conosce la differenza tra fasi distinte di crawling, indicizzazione e ranking (lo so, anche questa è una semplificazione).

La cosa è evidente soprattutto quando si parla di Enhanced Ecommerce e quando di mezzo c’è il/un TagManager. Vediamo di provare a fare chiarezza.

I bei tempi andati

Nei tempi che furono esisteva una relazione stretta, quasi 1:1, tra quel che si faceva in pagina con Google Analytics e la rappresentazione che ne usciva fuori nello strumento: metto il codice di base? ho le pageview. Metto un trackEvent su un pulsante? ogni volta che lo premo avrò un evento su Analytics. Facile, preciso, indolore. Il controllo era assoluto, e ogni azione provocava una reazione. Ho un Ecommerce? metto un ALTRO tag particolare sulla thankyou page per dire ad Analytics che l’utente ha comprato, e cosa, e quanto ha speso eccetera…

l’avvento del TagManager

Il primo “scollamento” tra la relazione stretta è stato l’inserimento del TagManager. Non esiste più una relazione 1:1 tra quel che faccio in pagina e quel che ritrovo sullo strumento (o almeno, non necessariamente anche se si può fare in modo che accada), semplicemente perché in mezzo c’è un altro sistema che possiede una logica propria ed è in grado di “fare cose”. Metto il contenitore del TagManager e dentro c’è il codice di base di GA? ho le pageview. Dentro ci metto un evento GA con la stessa regola? allora avrò per OGNI pagina ANCHE un evento su Google Analytics (non fatelo, non ha senso 🙂 ). Creo un evento GA che parte solo sul click di un bottone, che intercetto con GTM? allora avrò un evento esattamente quando mi serve. Il problema, se così vogliamo chiamarlo, deriva da una scelta infelice degli ingegneri del TagManager, che hanno creato un metodo per pompare informazioni dentro al dataLayer (la struttura di dati che viene letta automaticamente dal GTM) dandogli un naming particolare: event. Ora, quando si usa la sintassi

dataLayer.push({'event': 'video', 'titolo': 'video corso di GA'});

NON si sta creando un evento Google Analytics con category “video” e action o label “video corso di GA” (infatti il TagMAnager non serve solo per GA, questo in teoria dovrebbe essere sufficiente a chiarire la cosa, ma così non è). Si sta semplicemente dicendo al TagManager che c’è una situazione (purtroppo si chiama evento, ma possiamo chiamarlo message, o push) e che la parte di dataLayer che si chiama titolo va aggiornata con l’informazione “video corso di GA”. Se vogliamo farne un evento GA dovremo configurare un tag GA di tipo evento, con category fissa e action o label presi da una variabile dataLayer che legge “titolo”.
Se questa parte di dataLayer esisteva già, l’event fa l’update, se invece non esisteva la crea. E qui inizia il gioco delle costruzioni con i mattoncini. Per ulteriori dettagli tecnici vi invito a leggere il GTMtips #26 di Simo Ahava

l’Enhanced Ecommerce sul TagManager

Il secondo scollamento totale tra quel che si fa in pagina, come viaggiano i dati e che risultato otteniamo in interfaccia è stato l’Enhanced Ecommerce. Per far si che l’Enhanced Ecommerce funzioni a dovere, è necessario fornire i dati in un certo modo. Se si usa il Google TagManager alla pagina linkata ci sono le istruzioni e le configurazioni necessarie affinché questo accada. Ma sono un po’ fuorvianti 🙂
Bisogna capire per bene i tre momenti distinti che servono per arrivare al risultato finale:

  1. devo mettere nel GTM le informazioni necessarie, facciamo l’esempio di 4 impressions. La parte rilevante è QUANDO riesco ad avere queste informazioni. Il programmatore potrebbe averle già quando si crea la pagina, e metterle nel dataLayer che c’è in HEAD. Oppure potrebbe avercele solo ad un certo punto del sorgente della pagina, e quindi fare un dataLayer.push nel body, dopo il contenitore.
  2. devo inviare le informazioni a GA: se le informazioni sono nel dataLayer in HEAD, mi basta il tag di base di GA opportunamente provvisto della spunta “usa Ecommerce avanzato” e “usa struttura livello dati”. Il sistema accoda le informazioni sulle impression a quelle della pageview, per risparmiare hit. Finito. Se invece il programmatore ha dovuto fare un push dopo il contenitore (quindi al 99% DOPO CHE LA PAGEVIEW è già partita verso i server di Google), allora le mie impressions stanno si nel dataLayer, ma ci restano finché non si comunica di nuovo con i server PRIMA di cambiare pagina: ricordate che il dataLayer riparte da zero ad ogni cambio pagina. Allora mi servirà un evento Google Analytics, anche un evento fake inutile per le analisi, che provvisto delle stesse spunte di cui sopra mi fungerà da trasporto per i dati delle impressions

La cosa è spiegata bene solo nell’esempio della thankyou page

EE-purchase

“pusha i dettagli della transazione nel dataLayer usando l’action purchase, insieme ad un evento che azionerà un tag evento con le opzioni ecommerce. In questo esempio, i dettagli della transazione sono conosciuti nel momento in cui la pagina carica, e saranno inviati con una pageview quando si aziona gtm.js (cioè quando si apre la pagina, ndMC)”

conclusioni

Con gli strumenti a disposizione oggi è necessario comprendere bene quale sia il flusso dei dati in fase di collezionamento e di invio. Dimentichiamoci delle relazioni dirette: la pagina parla col dataLayer, che parla col TagManager, che parla con Google Analytics (che parla con noi 🙂 ). Ognuno di questi passaggi ha delle peculiarità e dei punti di attenzione, ma presenta anche grandi opportunità di modifica, razionalizzazione e pulizia dei dati.


Sep 02 2015

Come funziona Tag Assistant Recording

autore: Marco Cilia categoria: codice di monitoraggio

La novità dell’estate del mondo Google Analytics, anche se arriva a fine agosto, è la disponibilità di Tag Assistant Recording, una sorta di v3 del plugin di controllo/debug dei tag Google, di cui vi avevo già accennato in questo post.

Se non sapete di cosa si tratta, partite dallo scaricare l’estensione di Chrome da questo link. In breve l’estensione controlla su ogni pagina la presenza di tag di marketing by Google, quindi Google Analytics, AdWords, Doubleclick, Google Tag Manager. Per ognuno di questi sono disponibili molte informazioni, e si può cambiare il livello di dettaglio di esse utilizzando le opzioni dell’estensione; ad esempio l’estensione potrebbe dire che su una pagina ci sono due Floodlight, due Analytics versione classica e uno Universal dentro a un container TagManager. Che uno dei tag è nella posizione sbagliata, che altri tag non funzionano come previsto, insomma una marea di informazioni utili.

La funzionalità nuova e più interessante però è quella di recording, ovvero l’estensione registra una navigazione e poi vi consente di riguardarla step-by-step con vari livelli di informazioni. Per utilizzarla è necessario premere il pulsante “RECORD“, nella parte bassa dell’interfaccia dell’estensione: da quel momento un classico pallino rosso ci avvisa che l’estensione sta registrando. Dopo aver navigato le pagine che ci interessano ed aver fatto tutte le azioni che desideriamo controllare si può stoppare la registrazione ed avere un rapido sommario che somiglia a questo:

TA-recording-sommario

Il click su “show full report” ci porta ad una interfaccia divisa in due macrosezioni: la prima riguarda un report sui TAG che vengono inviati, quindi tutti quelli supportati da Tag Assistant. Le seconda invece è prettamente dedicata a Google Analytics. Ma andiamo con ordine: il report dei Tag su un sito complesso può assomigliare a qualcosa del genere

TA-vg

e subito notiamo la possibilità di filtrare solo i tag che ci interessano. Di base, il sistema permette di vedere le pagine registrate e per ogni pagina mostra: URL, timestamp della richiesta, tempo di caricamento, numero di tag totali, numero di errori, warning e suggerimenti. Per ogni tag di ogni pagina mostra i metadati, ovvero un riassunto di cosa fa un tag (advertiserID per Floodlight, o UA di Analytics, per esempio), le ottimizzazioni possibili se ce ne sono e le richieste (un tag potrebbe infatti generare più richieste). Per ogni richiesta generata, infine, mostra i metadati, ovvero l’elenco dei parametri, alcuni dei quali sono tradotti in un linguaggio comprensibile mentre altri restano da decifrare.

Spostandosi nella sezione “Google Analytics report” invece l’interfaccia cambia, e a seconda che la mail con la quale siete loggati in Chrome/Analytics abbia o no accesso alla property GA che state analizzando, le possibilità variano. Innanzitutto il menu laterale, che è fatto così:

TA-GA-section

  1. Update report permette di ricaricare il report dopo aver fatto modifiche nella configurazione.
  2. Select Views permette di switchare tra i vari recording di GA, se le pagine inviavano dati a più properties. Nel caso in cui non abbiate accesso ai dati, esce il messaggio “The recording contains hits sent to this property, but you (email@email.ext) don’t have permissions in Google Analytics for its views. You won’t be able to see view-specific information.
  3. Change Location permette di simulare la visita come proveniente da una differente località o da un diverso indirizzo IP
  4. Open permette di caricare un file con una sequenza di hit e Save di salvare la sequenza corrente, per riusi futuri

Nella parte destra invece troviamo un recording summary, con informazioni generali come l’ora della registrazione, il totale delle pagine e dei tag, la property selezionata, ecc, seguita da una sezione di alert, in cui il sistema da una valutazione di quel che ha visto, una sezione di “views summary” che esiste solo se state guardando i dati che andrebbero ad una property cui avete accesso, e che riassume così la visita (clicca per ingrandire)

TA-behavior

Ricordate che siamo FUORI da GA, quindi se avere informazioni su Browser e OS è banale, vi invito a guardare la sezione “conversions” 😉
Il caso d’uso praticamente è questo: voi su un Analytics settate una conversione, poi andate sul sito e registrate la sessione mentre convertite, poi chiedete a Tag Assistant se quella sarebbe stata una conversione; se vi dice no, modificate il setting del Goal, tornate su Tag Assistante e fate Update Report e controllare in tempo reale se la modifica ha senso. Notevole no?
Altra cosa che potete fare, questa però non l’ho provata, è vedere se una richiesta passa indenne o viene modificata da un filtro, nella sezione FLOW -> Hit -> Mutuations

Per finire, se salvate una sessione la potete riusare in futuro; i file hanno estensione .harz
Già questo può essere interessante perché potete scambiarvi o farvi inviare da un cliente la sua navigazione, e controllare come la vede GA senza essere fisicamente da lui o nelle sue “condizioni di rete” (proxy, location, rete, eccetera). Più interessante ancora è che i file HAR sono uno standard per gli archivi di richieste HTTP, e quindi ci sono moltissimi software che possono generarli (un semplice Chrome dal pannello NET, Fiddler, Firefox dalla versione 41 in su, secondo questa lista).
Altro caso d’uso quindi: per strettissime policy aziendali e insormontabili problemi tecnici, è impossibile vedere gli ambienti di staging del nuovo sito del cliente, quindi si dovrebbe configurare alla cieca o quasi. Si va dal cliente, si fa esattamente il percorso di conversione e si registra con Tag Assistant. Dopo si torna in ufficio e lo si testa infinite volte man mano che la configurazione dell’account procede.

Non c’è praticamente limite alle possibilità di debuggare ogni più piccola virgola, in tempi sempre più ristretti e con risultati sicuramente più veloci.


Aug 25 2015

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

Sequenze di tag nel TagManager

autore: Marco Cilia categoria: tagmanager tag: ,

Una delle più recenti e utili aggiunte al TagManager è quella delle “sequenze di tag“: si è sempre detto infatti che i tag lanciati sono tutti asincroni, e che il TagManager li lancia appena può. Questo è sempre vero, anche se in realtà esistono da tempo almeno alcuni strumenti che provano a mitigare il problema.

agganciare i tag a diversi eventi del TagManager: un tag agganciato a gtm.js verrà SEMPRE sparato prima di uno agganciato a gtm.dom, a sua volta lanciato prima di gtm.load. Si tratta di conoscere l’ordine con cui sono eseguiti i tre eventi fondamentali che avvengono sempre al caricamento di una pagina

– usare la “priorità di attivazione dei tag” nelle opzioni avanzate di un tag: di default i tag hanno tutti priorità 0, ma se si varia quel numero con uno maggiore, il GTM proverà a inviare prima quelli con il numero più alto. Nessuna garanzia di successo, in ogni caso…

– usare eventCallback o “hit richiamata”, che sono proprietà che hanno gli eventi su TagManager e i tag di Analytics: ogni volta che un push viene fatto o un tag GA viene eseguito, si può conoscere lo stato di OK o KO ed eseguire un altro comando. Maggiori dettagli in questo post di Simo Ahava

– giocare – pericolosamente – con catene di dataLayer.push(), custom HTML tag e attivatori specifici

L’opzione nativa di sequenza dei tag invece permette di specificare, dato un tag che chiameremo PRINCIPALE, un tag da eseguire PRIMA di esso (Simo li chiama setup tag) e un tag da eseguire DOPO di esso (cleanup tag). E’ possibile specificare se i tag dipendenti devono essere lanciati o no quando un tag non completa con successo il suo compito. Di default le opzioni dicono che non si blocca nulla, ma avete comunque la possibilità di variare la scelta. La cosa funzione anche per i tag di tipo custom HTML, anche se in maniera un po’ più complessa e tramite l’uso della nuova variabile HTML ID: per questo punto vi rimando direttamente al post di Simo che è sufficientemente articolato.

Poiché uno stesso tag può essere chiamato con un evento principale (ad esempio, l’apertura di una pagina) e anche come tag di setup e cleanup di un altro tag su un’altra pagina o di un evento sulla stessa pagina, si pone il problema di evitare gli invii multipli: questo compito è assolto da un’altra nuova opzione che si chiama “opzioni di attivazione del tag” e che presenta le seguenti scelte: illimitata (il tag viene sparato sempre), una volta per evento (il tag viene sparato solo una volta all’interno dello stesso evento GTM), una volta per pagina (il tag viene sparato solo una volta sulla pagina corrente).
Quest’ultima opzione ci viene in aiuto anche in altri casi particolari dove vogliamo evitare la duplicazione dell’invio di tag particolari (penso ad esempio ai contatori) nel caso in cui la configurazione corrente consenta di farlo; prima era necessario scrivere e duplicare parecchie regole ed eccezioni, adesso possiamo demandare questo lavoro direttamente al Google Tag Manager.


Aug 12 2015

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

La trasformazione del report AdSense

autore: Marco Cilia categoria: report tag: ,

Stando a quanto dichiarato qualche giorno fa dall’account ufficiale Google+ di Analytics, presto vedremo comparire nei nostri Google Analytics una nuova sezione all’interno del gruppo di report “comportamento”: si tratta dei report “publisher”. In sostanza i report AdSense vengono assorbiti dentro a questa nuova sezione, e per chi usa solo questa piattaforma non cambia nulla se non il nome dei report. Tuttavia, ci tiene a precisare Google, dentro a quei report possono finire – previo collegamento da fare tramite il pannello di amministrazione – anche le performance di Ad Exchange Seller
Purtroppo al momento vedo in un mio account i nuovi report, ma se provo ad iniziare la procedura di collegamento mi viene fuori sempre un errore di risorse non disponibili, per cui non riesco a dare dettagli aggiuntivi rispetto a quanto dice Google nel suo post.


Aug 02 2015

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

Non ti funzionano più i filtri IP? colpa del garante :)

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

Una delle azioni che praticamente tutti si sono prodigati a mettere in atto, per trasformare il cookie di Google Analytics da profilazione terza parte a tecnico secondo le indicazioni del garante, è stata quella di anonimizzare l’invio dell’indirizzo IP completo ai server di Google. Io stesso sulle prime ho risposto a chi mi chiedeva quali fossero le conseguenze con un laconico “perdi un po’ di precisione nei report geografici, ma niente altro”.

Al fine di salvaguardare l’impegno preso Google invece procede ad eliminare l’ultimo ottetto degli indirizzi IP ricevuti insieme ai dati di GA prima possibile, in modo da ridurre praticamente a zero le possibilità di registrarlo da qualche parte. Con “prima possibile” purtroppo si intende PRIMA dell’elaborazione, quindi anche prima dell’applicazione dei filtri.

La cosa (“in nessun momento viene scritto su disco l’indirizzo IP completo“) è chiarita in modo limpido in questa pagina dell’help:

Ad esempio, l’indirizzo IP 12.214.31.144 potrebbe essere modificato in 12.214.31.0. Se l’indirizzo IP è un indirizzo IPv6, gli ultimi 80 bit dei 128 vengono impostati su zero. Solo al termine di questo processo di anonimizzazione la richiesta viene scritta su disco per l’elaborazione. Se viene utilizzato il metodo di anonimizzazione IP, in nessun momento viene scritto su disco l’indirizzo IP completo, in quanto tutta l’anonimizzazione avviene nella memoria quasi istantaneamente dopo che la richiesta è stata ricevuta.

Se quello fosse proprio l’indirizzo IP dei dipendenti di un’azienda che prima dell’anonimizzazione era filtrato da un normale filtro IP, di colpo il 144 non viene più trovato (è sostituito da 0) e il filtro smette di funzionare.

La soluzione “cambio 144 con 0 nel filtro” sarebbe praticabile, ma escluderebbe anche altri 255 indirizzi IP validi. Al momento vedo alcune altre soluzioni percorribili, ma quelle più solide comportano un discreto sviluppo per comprendere anche i casi più difficili (configurazioni di rete particolarmente complesse in aziende medio-grandi). Ovviamente il TagManager ci può venire in aiuto, ma è basato su javascript e javascript non conosce l’indirizzo IP del client dove gira, quindi serve comunque uno sviluppo più o meno complesso, sempre a seconda della complessità in gioco.
Per tutto il resto, prendetevela col garante 😀


Jul 15 2015

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

L’unico sensato – ma ancora da venire – modo di bloccare i ghost referrals

autore: Marco Cilia categoria: generale tag: , , ,

Questo post è il complementare dello scorso “L’unico vero – ma insensato – modo per bloccare i ghost referrals” e ne riprende naturalmente il titolo 🙂

Si diceva che se Google dovesse fare un sistema di blocco preventivo dei ghost referrals dovrebbe studiare un sistema simile a quello descritto nel post, almeno a detta del sottoscritto. Si diceva nei commenti che forse un altro modo potrebbe essere un “segnala come spam” simile a quello di Gmail, ma che la cosa potrebbe avere problemi di workflow di approvazione.

Com’è, come non è, oggi thesempost.com ci informa che Adam Singer, Analytics advocate a Google, ha detto chiaramente durante il Mozcon che Google sta lavorando per risolvere il problema alla radice. Non ci sarà quindi da rivolgersi a terze parti ma soprattutto Singer – secondo l’articolo – ha detto che Google sta lavorando al problema in modo che la soluzione sia scalabile, ovvero che possa risolvere il problema adesso e per sempre, anche se gli spammer cambiassero i loro pattern di invio dei dati fasulli. Sembrerebbe quindi un qualcosa più simile ai filtri antispam di Gmail, ma ovviamente senza prima vederlo in azione non possiamo sbilanciarci troppo.

La creazione di un sistema definitivo spiegherebbe anche la relativa latitanza da parte di Google negli ultimi mesi durante i quali il problema è balzato alle cronache. Meglio tardi che mai, no? 🙂


Jun 30 2015

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

L’unico vero – ma insensato – modo per bloccare i ghost referrals

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

Sul fenomeno dei cosiddetti ghost referrals hanno scritto più o meno tutti, ma come direbbe il buon Corrado Guzzanti interpretando uno dei suoi personaggi più riusciti (Quelo) “la risposta che cerchi è dentro di te. Solo che è SBAGLIATA!” 🙂

I ghost referrals sono delle visite che vengono registrate dai vostri Google Analytics, ma che non sono originate da veri e propri visitatori sul vostro sito. “sono bot?” no, non sono nemmeno bot, o meglio non nel senso classico con cui siamo abituati a pensare a un agente automatico che NAVIGA il sito. La gente ha difficoltà a comprendere ciò che non riesce a visualizzare, e in questo caso ciò che non riesce a visualizzare è che da qualche tempo si possono inviare dati a Google Analytics anche SENZA l’ausilio del tipico codice javascript, attraverso una cosa chiamata Measurement Protocol.

Intendiamoci, è una cosa che si è sempre potuta fare, bastava copiarsi una richiesta HTTP dell’immagine _utm.gif che veniva usata – prima di Universal Analytics – per inviare i dati ai server Google e che conteneva nei parametri tutte le informazioni necessarie al calcolo delle visite. Con il measurement protocol la cosa è stata standardizzata e ufficializzata, dando peraltro l’avvio a tutta una serie di nuove possibilità di tracking veramente incredibili (tracciare la macchinetta del caffé?)
Quello che accade è che un qualche server da qualche parte del mondo viene istruito per comporre ed effettuare centinaia di chiamate fasulle a tutte le property del mondo. Che sia un fenomeno distribuito e completamente automatizzato se ne è accorto il mio amico Enrico Pavan creando una property di un sito inesistente che ha iniziato a tracciare visite da ghost referrer, ed è confermata da alcune opinioni secondo cui le property che terminano con numeri diversi da 1 (tipo UA-XXXXXXXX-2 e oltre) non sono soggette al problema. Ora, perché non potete semplicemente fare un filtro? perché gli spammer vincono sempre, sono troppi e fanno grossi danni con poco sforzo: voi passate 3 ore a configurare 80 filtri? domani qualche spammer cambierà una lettera nel pattern delle informazioni che invia e passerà i filtri. Quindi, tanto per essere chiari:

  • potete usare la “lista esclusione referral” che trovate nella configurazione della property? no, per il motivo sopra ma SOPRATTUTTO perché essa serve a trasformare in dirette (e quindi a non sovrascrivere la sorgente di traffico) le visite da alcuni domini. Quindi peggiorereste il problema
  • potete filtrare uno a uno i domini referrer? se proprio volete farlo, il buon vecchio Simo Ahava ha creato un tool per voi, lo spam insertion tool che vi evita gran parte del lavoro. Ma tanto poi lo dovrete mantenere nel tempo…
  • potete fare un filtro di inclusione che includa solo le visite al vostro dominio/hostname? tra tutte le alternative è forse quella che può mitigare meglio il problema, ma poiché anche l’hostname può essere inviato come parametro del measurement protocol, alcuni spammer particolarmente ostinati potrebbero aggiungere della logica per controllare l’UA su ogni host e bypassare il problema

e quindi? quindi l’unica soluzione secondo me valida dal punto di vista tecnico, ancorché completamente insensata, l’ho letta sul blog di Himanshu Sharma, Optimizesmart e consiste in un complicato metodo di codifica/decodifica di tutte le hit inviate. Per la precisione:

  1. Si decide una stringa di sicurezza, ad esempio “dhffjsrr12353fdf4253kc“, per mantenere il suo esempio
  2. Si antepone la stringa di sicurezza a tutte le chiamate a GA. Per farlo si modifica il codice di GA ad esempio così
    ga('send', 'pageview','dhffjsrr12353fdf4253kc' + location.pathname); o si usa un TagManager. ATTENZIONE che l’esempio riportato tronca tutte le query interne, quindi ad esempio la pagina /ricerca.html?key=asd viene tracciata solo come /ricerca.html. Dovrete ingegnarvi con un po’ di javascript per gestire tutti i casi.
  3. Si crea un filtro di inclusione di tipo custom con “includi – URI della richiesta – corrisponde a espressione regolare – ^/dhffjsrr12353fdf4253kc
  4. Si crea un filtro cerca e sostituisci per evitare di avere nei report degli URL orrendi. quindi filtro custom – cerca e sostituisci – URI della richiesta – cerca ^/dhffjsrr12353fdf4253kc/ – sostituisci con /. Nell’ordine dei filtri questo deve stare sotto al precedente, altrimenti non funziona nulla

Come vedete è una soluzione radicale, che va aggiustata e testata per bene prima di essere portata in produzione, e che a me sinceramente fa anche abbastanza orrore, concettualmente, perché costringe tutti a un lavoro grande e potenzialmente pericoloso per i dati. Ma è anche vero che se dovessi pensare a un metodo radicale per Google di evitare a tutti noi i ghost referrals senza uccidere il measurement protocol non mi viene in mente qualcosa di tanto diverso. Magari la chiave di sicurezza potrebbe essere generata direttamente da GA, e così il filtro di inclusione e replace, e il codice di monitoraggio potrebbe già essere fornito funzionante, ma la sostanza del problema non cambia di molto.


Jun 25 2015

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

Lavora sempre al meglio. E possibilmente migliora ancora!

autore: Marco Cilia categoria: generale

bandiera grecaSono appena tornato da dieci giorni di vacanza in Grecia, posti magnifici, cibo ottimo, relax, mare e cultura.
Perché ve ne parlo qui? perché c’entrano Google Analytics e il digital marketing. Seguitemi:

Appena esaurita la prima carica del MacBook Air estraggo l’alimentatore solo per scoprire con orrore che il mio cavo terminale finisce con una spina a tre denti (tipo L italiana, con messa a terra) mentre in Grecia usano prese con Europlug (due fori) o comunque Schucko. Figure su Wikipedia.
Chiedo al ragazzo dell’hotel in cui alloggio se ha un adattatore, e me ne procura uno, ma il Mac non si ricarica. “Che computer hai?” mi dice. “MacBook Air” rispondo. “Gimme five! anche io. Ti presto il mio alimentatore”.
Ovviamente lui aveva il modello vecchio (connettore MagSafe) e io quello nuovo (MagSafe 2 – grazie Apple!) quindi al mattino sono punto e a capo, col computer morto. “Ti presto il mio, che lavoro fai?” “mi occupo di digital marketing” “fantastico! sai che ho appena rifatto il sito? magari puoi darmi qualche consiglio!”. Mi sembra ovviamente il minimo, data la sua estrema gentilezza, e quindi iniziamo a parlare dopo che gli ho precisato che in particolare mi occupo di Digital Analytics.

“ah si! ho Google Analytics, te lo faccio vedere, dimmi se secondo te è a posto, perché io ho dei dubbi”. E inizia a mostrarmi il pannello spiegandomi i problemi: i dati del sito vecchio non ce li ha più, gli hanno fatto aprire un account nuovo “perché era meglio” (in realtà la vecchia agenzia lo ha tagliato fuori dai vecchi dati). Il sito ha un booking engine esterno, niente cross domain tracking. Il profilo non ha nemmeno un goal configurato, gli dico che almeno almeno dovrebbe avere la thankyou post prenotazione e l’invio della form dei contatti.
“ma questa Agenzia è partner certificato?” gli chiedo; non perché questo sia una garanzia assoluta, ma insomma un minimo… “si si” mi assicura, eppure io sull’elenco dei partner non la trovo. “guarda la firma nelle mail”, che ovviamente riporta il logo Google Analytics Qualified Individual.

Insomma, dopo due in ogni caso piacevoli sessioni da mezz’ora (si, perché anche dopo aver switchato i cavi terminali non andava – alla fine era proprio morto l’alimentatore) sono costretto a sentenziare “mi dispiace, cambia agenzia. In questo campo non mi sembrano proprio a loro agio”. La morale che ne ho tratto è questa: lavora sempre al meglio delle tue possibilità, non approfittarti di nessuno, non mentire, ammetti i tuoi limiti, non fare (male) cose che non sai fare bene. Sii onesto e cerca sempre sempre di migliorare, perché anche se lavori per il cliente microscopico nel più remoto angolo del paese, prima o poi alla lunga i nodi vengono sempre al pettine 🙂


Jun 14 2015

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

TagManager vendor template

autore: Marco Cilia categoria: tagmanager tag: ,

Uno dei due ingegneri a capo del Google Tag Manager – Brian Kuhn – ha da poco annunciato una novità molto importante: il prodotto ora introduce uno standard aperto per la creazione dei template dei tag, e soprattutto demanda ai singoli vendor la loro creazione tramite un processo di iscrizione – submit, testing&verifica e approvazione: il tag template program.

Se avete mai fatto delle installazioni un po’ corpose avrete usato quasi sicuramente tag di Analytics e AdWords: per essi ci sono dei comodissimi template che rendono il lavoro veloce, facile e praticamente a prova di errore. Se avete aggiunto dei tag diversi (Criteo fino a qualche tempo fa, ma anche solo un conversion pixel di Facebook al quale passare la revenue di un acquisto) avrete dovuto giocare con i tag HTML custom, con il rischio di perdere tempo nel capire come mai il tag non funzionava o peggio il contenitore non validava. Una volta ho perso più di mezz’ora su un tag HTML custom perché mancava un apostrofo su migliaia di caratteri.

Questo da ora in poi potrebbe ridursi, perché ogni strumento di marketing che richiede tag ha la possibilità di iscriversi al programma e di creare in autonomia i suoi template, che dopo essere stati validati da Google saranno resi disponibili agli utenti di tutto il mondo. La prima infornata di questi nuovi tag comprende:

  • Affiliate Window
  • Ve Interactive
  • Neustar
  • Eularian
  • Mouseflow
  • Nudge
  • SearchForce
  • TradeDoubler
  • Google Consumer Surveys

Il Tag Manager vuole diventare uno strumento sempre più facile da gestire e alla portata di tutti, e questa mossa sono certo che vada nella direzione giusta


Jun 06 2015

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

Perché non parlo della cookielaw?

autore: Marco Cilia categoria: cookie tag:

Vi sarete accorti che non ho scritto nulla sulla cosiddetta cookielaw, e per chi mi segue sui social network, che mi sono tenuto a distanza da quasi tutte le conversazioni. E’ stata una scelta deliberata, quando ho capito mesi fa che le cose non sarebbero andate affatto lisce come qualcuno sperava. Qualcuno si aspettava un post almeno a proposito dei cookie di Analytics, ma nemmeno su quelli ci sono certezze.

Per lavoro, so di questa norma da più di un anno, quando ancora era in discussione. Io e l’azienda dove lavoro abbiamo tentato di fornire materiale e risposte per provare a chiarire i punti critici del provvedimento quando ancora non era una legge. Nonostante tutto, è uscita come tutti la conosciamo. La prima cosa che ho capito quando abbiamo iniziato a lavorarci è stata questa: l’interpretazione legale è imprescindibile, e quindi qualsiasi cosa avessi detto o scritto, sarebbe stata sbagliata, semplicemente perché – ed è assurdo, me ne rendo conto – ognuno in quella norma ci legge cose diverse.

Ho finora lavorato con 4 legali diversi, e non c’è una installazione uguale ad un’altra. Ho letto i post di molte persone sui social e sui blog, e ognuno dice tante cose giuste e tante cose enormemente sbagliate, ma poiché tutto si basa su interpretazione, hanno ragione tutti.

Il più grande demerito di questa legge è quello di aver trasformato per sempre i concetti alla base dei cookie. Una cosa universalmente nota (oserei dire binaria) come “cookie di prima parte e cookie di terza parte” (cookie salvati nello stesso dominio che si visita = prima parte, salvati su altri domini = terza parte), un concetto cristallino e inoppugnabile, è diventato un problema insormontabile una volta trasformato in legalese “cookie DELLA prima parte e cookie DELLA terza parte” (cookie creati dal gestore del sito o creati da “altri”): i casi si moltiplicano e si complicano, perché ad esempio un “pezzo di sito” fatto e hostato da un partner diverso dal gestore è una terza parte? quindi i loro cookie tecnici sono di terza parte? e se quel pezzo di sito c’è un pulsante di Facebook, è una terza parte che crea cookie su una terza parte? se invece vale “chi ha deciso di mettere quel pulsante” e sto usando un template già pronto? insomma le complicazioni di questo modo di chiamare le cose sono infinite.

Fine della digressione e del rant, non credo ci saranno ulteriori update in materia su queste pagine.