Google Analytics in 30 secondi

A seconda del tipo di menu che avete scelto per il vostro Analytics potreste avere o meno il report “Landing Pages”; se non lo avete, niente paura, lo potete sempre tirare fuori dalla Libreria dei report e incastrarlo dove vi pare nel menu.

E’ un report piuttosto utile, introdotto successivamente al rilascio di GA4 e di chiara memoria “universalosa”: è un report con scope sessione, con metriche di sessione, utile a capire dove atterrano le visite e quanta revenue viene generata a partire dai diversi touchpoint di atterraggio degli utenti, in alcuni casi potendo suddividere facilmente gli intenti di acquisto (atterro su listing o pagine prodotto) da quelli un po’ più alti (atterro in home, o su pagine editoriali)…

Nel caso in cui il vostro tracking comprenda più domini – e abbiate fatto bene il cross-domain-tracking ovviamente – potrebbe essere utile aggiungere la dimensione secondaria “hostname” al report, magari per distinguere uno stesso url di pagina che è uguale su due domini diversi. Senza la dimensione secondaria infatti, i dati delle due pagine sarebbero fusi insieme.

Se avete già provato a fare questa operazione, però, potreste aver notato qualcosa di strano, e in particolare potreste aver notato url di pagine su hostname dove queste pagine… non esistono. Come se GA4 mischiasse male le pagine e i domini.

In effetti è proprio quello che fa, ma questa volta con un motivo che adesso illustriamo. Come abbiamo detto il report delle landing pages ha scope SESSIONE, ma la dimensione hostname invece ha scope EVENTO (si può verificare a seconda di come si sveglia Google: alcuni giorni è scritto direttamente nel menu a tendina della dimensione secondaria, altri giorni ci sono scritte le dimensioni con scope SESSION e USER, e quindi per esclusione le altre sono EVENT, oppure ci si rivolge a una fonte esterna ma solida: https://data.ga4spy.com/?parameter=hostname ). Sappiamo che è sempre male incrociare metriche e dimensioni con scope diversi, se non si sta attenti; o come direbbe il buon Egon Spengler: “MAI incrociare i flussi”

Quello che succede è che una riga singola, ipotizziamo la landing page /pippo con una sola sessione, quando viene accostata alla dimensione con scope evento “hostname” si moltiplica mostrando TUTTE le pagine di quella sessione, per cui avremo /pippo su hostname disney.it e /pippo su hostname gardaland.it, ANCHE SE LA PAGINA PIPPO NON ESISTE in quel dominio. Infatti il report ci sta dicendo “una sessione che è atterrata su pippo, è stata sul dominio disney e sul dominio gardaland (ma sempre su /pippo era atterrata)”, non ci sta dicendo “quelle pagine sono su quei domini” come invece faceva GA3 (che non incrociava i due scope e quindi mostrava solo le landing e i domini delle landing). Il conteggio delle sessioni infatti, per fortuna, rimane 1 anche se la somma delle due righe sarebbe 2.

E’ uno dei chiaroscuri di avere un sistema flessibile ad eventi, dove c’è libertà di incrocio ma dove è sempre necessario tenere alta l’attenzione perché gli errori possibili sono più alti di un sistema tutto sommato “chiuso” come GA3.

Più libertà = più attenzione.

Come tutti dovrebbero sapere, o forse no dato che ormai GA4 non lo guarda più nessuno 😛 , verso fine giugno Google ha introdotto una modifica a come GA4 legge i dati del consenso, nello specifico come legge il nuovo parametro ad_user_data nel consent mode v2. Di fatto, poiché ad_user_data è attualmente mappato automaticamente allo stato di advertising_storage, se un utente rifiuta i cookie di marketing rifiuta anche ad_user_data.

Quindi se un utente arriva da una campagna Google Ads con l’autotagging ed è presente il parametro gclid nella URL della landing page, questo viene registrato da GA4 nei report (e infatti lo troviamo cercandolo tra le url) ma poi ci sono due casi:

1. l’utente aveva accettato ad_user_data: GA4 prende quel gclid, interroga le API di Google Ads, e si fa dire tutto lo scibile su quel click: quale keyword, quale campagna, gruppo di annunci, il costo, eccetera… questa sessione avrà source/medium google/cpc e campagna corrispondente a quanto avete impostato su Google Ads
2. l’utente NON AVEVA accettato ad_user_data: GA4 non ha il permesso di usare quel gclid e lo lascia lì, senza parlare con Google Ads. questa sessione avrà source/medium google/cpc (perché comunque la presenza del gclid è inequivocabile, e non comporta “problemi di privacy”) e campagna (not set) oppure (organic)

Ora, praticamente tutto il web ripete il mantra di aggiungere i parametri UTM in parallelo al gclid, suggerendo anche script automatici da far girare per automatizzare la cosa e dormire più tranquilli, e per carità va benissimo, non ci sono tante altre strade. Ma in giro avete letto qualcuno che parla dell’effetto collaterale di questa cosa? Io no, pochi, e nessuno con i dettagli. Per cui, eccomi qua 🙂

Allora, l’obiettivo dell’inserimento degli UTM dovrebbe essere quello di comunicare a GA4 quale è la campagna originaria in Google Ads che ha portato quella sessione/conversione/revenue, ripristinando la corretta lettura del report Google Ads e il calcolo dei ROI che altrimenti erano basati solo su un sottoinsieme parziale dei dati, quelli di chi aveva accettato ad_user_data, no? beh, questa cosa semplicemente… non funziona.

Prendiamo come al solito un esempio reale per capire meglio. Dati del 1 maggio di un GA qualsiasi, confrontiamo il report Acquisizione traffico settato su dimensione sorgente/mezzo e dim. secondaria campagna con il report Google Ads: pressoché perfetti

Stessa cosa, ma con dati del 30 luglio, dopo la modifica di Google: mancano quasi 500 sessioni su 1600, e il report Google Ads è sottostimato in sessioni, risultati, e calcolo del ROI delle campagne.

Ultimo, dati del 30 settembre, molte settimane dopo l’implementazione degli UTM in parallelo al gclid: sono spariti (organic) e (not set), ma i numeri ancora non tornano

Quale dei due report ha ragione? oh, vi assicuro che ha ragione il report sorgente/mezzo, senza dubbio: quello è il livello “giusto” di sessioni con quella pressione adv, è coerente con G ADS, è coerente con lo storico e con i numeri che c’erano prima del problema, è coerente con lo speso. E quindi il report Google Ads interno a GA4 resta inutile.

“Poco male! me lo personalizzo! mi faccio un explore!”. Si, puoi provarci, oppure continui a leggere e ti fidi del buon vecchio goanalytics che ci ha già sbattuto la testa prima di te 🙂

NON PUOI PERSONALIZZARE il report Google Ads, o meglio non ha senso perché il problema non è tanto nelle metriche, quanto nelle dimensioni: il report è filtrato a monte con questa condizione

E poiché abbiamo detto che per le sessioni che rifiutano ad_user_data GA4 “non parla” nemmeno con Google Ads, quelle sessioni non entrano in quella condizione. E se personalizzi il report puoi solo filtrare con dimensioni derivanti da Google Ads.

Puoi creare un nuovo report, quello si, e usare la dimensione “session campaign” e il filtro “session source/medium = google/cpc”, ma potrai metterci solo metriche generiche. In questo modo ripristini la “nuova versione” del report Google Ads, quella inutile per capirci, ma non quella con i ROI che c’era originariamente, cioè quella più utile e che stiamo cercando disperatamente.

E negli explore? In teoria negli explore puoi fare circa tutto, quindi anche mettere insieme il report “giusto”, ma in realtà non puoi lo stesso, sempre per incompatibilità delle dimensioni. Ecco la prova sui dati del 30 settembre per la campagna IT_2020_Search_Prospect_Brand

Usando la dimensione “session campaign” viene 694 come il report source/medium ma solo 182 sessioni (comunque 40 meno del report GADS) hanno come source platform Google Ads (qui c’è anche un evidente problema con i numeri e le somme, ma non importa adesso: sono le dimensioni che contano). Inoltre le metriche di Advertising come “Google Ads cost” o “Google Ads cost per click” sono compatibili solo e soltanto con dimensioni di tipo “session Google Ads qualcosa“, e quindi ‘sto report non si può proprio fare, nada, niet, zero! Che frustrazione 🙁

Ci si riferisce al “salto dello squalo” come al punto di svolta (che vira in negativo) della carriera o della storia di qualcosa, sulla scia della famosa (o famigerata) prima puntata della quinta serie di Happy Days in cui Fonzie sugli sci d’acqua salta, appunto, sopra uno squalo.

Ora, è ovvio che il titolo è volutamente pompato, d’altronde sono mesi che non scrivo e in qualche modo devo farvi tornare :D, però nelle ultime settimane sono successe due cose troppo grosse e troppo vicine tra loro per non far storcere il naso anche ai fan di più vecchia data come il sottoscritto. A cosa mi riferisco?

Primo, di minore entità per le persone “normali” ma di grande impatto per i grossi brand che ancora utilizzano Universal Analytics (e si, ce ne sono ancora, e si, ne hanno il diritto perché pagano, e nemmeno poco). Come sanno anche i sassi il 6 marzo è entrato in vigore il DMA, e alcune feature di Universal Analytics sono state deprecate anzitempo, diversamente da quanto in precedenza comunicato. Qui le parole chiave sono “deprecate anzitempo”, “diversamente” e “precedentemente comunicato”.

Si perché uno si aspetta che certe comunicazioni di impatto piuttosto grande vengano fatte con largo anticipo, specie ai clienti paganti, in modo che si preparino per bene. E invece no: nell’elenco delle deprecazioni, vi agevolo il link per comodità, troviamo (tra le altre) cose come “scomparsa dei report demografici e sugli interessi” (capisco, sono basati su dati Google, ci sta), “import dei dati SalesForce” (paura che si importino dati personali? può essere), “fine dell’export intra-day su BigQuery” (ma perché?), “deprecazione degli identificativi ad click come gclid e dclid” (beh si in effettWAIT! COSA?? COSA HAI DETTO?)

E quindi, dal 6 marzo il gclid è come se non esistesse, e Google consiglia di mettere gli UTM sulle campagne GADS e Doubleclick. Certo, come se anche le più scafate agenzie media worldwide fossero tutte in grado di sapere che bisogna smanettare con Ads Script per avere il nome della campagna, che di default non esiste come ValueTrack… come se pochi giorni di tempo fossero sufficienti a modificare tutto. Esatto, perché stiamo parlando esattamente di QUANDO Google l’ha detto? Se siano girate email non lo so, ma siccome due o tre casi direttamente o indirettamente li ho visti e un paio di forward di mail di personale Google li ho letti, diciamo che non l’hanno detto con mesi di anticipo. Ma restiamo sull’ufficiale, la famosa pagina della transizione. Ecco qua INTERNET ARCHIVE interrogato all’uopo:

il 23 febbraio la pagina ufficiale della transizione non menziona la scomparsa del GCLID, il 5 marzo si. Non ci sono snapshot di mezzo, quindi col beneficio del dubbio diciamo che l’hanno detto con non più di 14 giorni di anticipo. No anzi, l’hanno pubblicato. Poi sta a noi fare refresh di quella pagina una volta al giorno, ovviamente.

Secondo, lo spostamento del report Google Ads nella sezione ADVERTISING di Google Analytics 4, di per sé nulla di male se non che:

1. nella sezione advertising non posso creare e modificare report, quindi mi prendo quel che c’è. E quel che c’è è MOLTO MENO di quel che c’era nel report “vecchio” nella sezione dei report. Nel “nuovo” report ci trovo solo Conversioni, Costo, Costo per Conversione, Click, CPC, Revenue e ROAS. Sessioni? no. Eventi? nemmeno. Engagement/Bounce? non pervenuti.
2. I report della sezione advertising seguono l’impostazione di attribuzione che c’è nell’admin, quindi DATA DRIVEN o LAST CLICK (data driven di default). Se non lo so, rischio di non capire quel che leggo. E qualcuno potrebbe anche cambiare il setting da un giorno all’altro.
3. Google ha CAMBIATO il vecchio report, eliminando le metriche di preclick. Il “nuovo vecchio” report ha le informazioni sul post click e basta. SE siete fortunati il vecchio report ve lo eravate salvati come una copia nella libreria dei report, e quello non lo toccano (o almeno, su alcuni clienti s’è salvato). Mi riferisco al report con queste colonne

   

4. Se provo a ricreare un report mischiando metriche di pre e post click… non posso. Non è permesso! nella costruzione del report standard semplicemente NON CI SONO le metriche di GADS. Posso sempre fare un explorer, certo, ma non è la stessa cosa. Ma soprattutto PERCHÉ? perché limitare così la possibilità di vedere i dati delle campagne?

In buona sostanza abbiamo un Google che toglie, toglie funzionalità dal giorno alla notte e toglie possibilità, senza vedere dall’altra parte un Google che da qualcosa in cambio, almeno per ora. Magari poi quando spengono le macchine su cui gira Universal e le aggiungono ai datacenter di GA4 ci stupiscono, ma per adesso speriamo nel cliffhanger di fine stagione.

Nonostante ormai non sia più così assiduo nella scrittura come un tempo, mi arrivano continuamente attestati di stima per quel che ho fatto – e faccio, ma meno di prima – qui sopra. Ieri sono andato a conoscere il nuovo referente interno di un cliente molto importante, e lui mi dice “ti conosco di fama, ti ho anche citato in una mia presentazione anni fa. Quando ho iniziato questo lavoro il mio capo di allora mi disse ‘tu leggi ogni mattina quel che scrive goanalytics.info, e vedrai che vai liscio’ “.

E niente, per poco mi metto a piangere. Non lo so se me lo merito, ma ce l’ho messa tutta e a volte mi sembra che si, forse un pochino… 🙂

Quindi Grazie! forse non ve l’ho mai detto. E se si, forse non abbastanza!

Una delle cose divertenti di Google Analytics 4 (mhhhh, una delle TANTE cose divertenti…) è che ormai abbiamo capito che non possiamo mai dire “Su Universal è sempre stato così, quindi per coerenza lo sarà anche qui”, no?

Ecco, parliamo un attimo di come funzionavano revenue e resi su Universal Analytics: tracciavi una transazione, che aveva una revenue associata. ID transazione -> Revenue. Tracciavi un reso, che aveva una revenue associata (diciamo per comodità la stessa revenue, reso totale). ID transazione -> Refund Amount. Notate la metrica diversa?

Poi se volevi le revenue nette potevi creare una custom metric e fare {{Revenue}} – {{Refund Amount}}, o affiancare le due colonne in un report tabellare e vedere quanto reso sul totale incassato.

E su GA4? OVVIAMENTE su GA4 è diverso: Su GA4 tracci una transazione con l’evento purchase e hai una revenue, quindi ID Transazione -> Purchase Revenue. Poi tracci un reso con un evento refund, però hai ugualmente una revenue, cioè ID Transazione -> Purchase Revenue. Vediamo un caso reale:

I più attenti di voi noteranno che riporta “2” nelle transactions. L’ho lasciato apposta, ci arriviamo tra poco, per ora fate finta di non averlo visto. Quindi la transazione 5007088 ha revenue 149 euro, giusto?

No, sbagliato! Adesso aggiungo la dimensione data

Tra l’altro si nota che se prendessi solo il 20 settembre e questa fosse la mia unica transazione, per quel giorno avrei revenue negativa! “Marco, ma non si è sempre detto che non si mandano transazioni con valori negativi per rettificare le revenue?” certo, è uno dei mantra massimi di Universal insieme a “MAI usare gli utm su link interni” (che infatti non si sente tanto bene nemmeno lui 😀 ). In effetti però quel valore negativo non è una TRANSAZIONE con revenue negativa, ma il risultato dell’evento refund cui abbiamo passato un valore positivo. Guardiamo infatti la revenue di un certo periodo con un explore, usando la stessa metrica che vedete nel report Monetization

Questo ecommerce ha guadagnato 71k? NO! Se infatti divido per eventi la figura è ben diversa

Ne ha incassati 93,5 ma nel frattempo ha avuto quasi 22k di resi. che è ben diverso, se stiamo valutando ad esempio l’efficacia di una campagna e non la qualità del prodotto.

Quindi occhio, perché nei report standard, anzi ogni volta che usate la metrica Purchase revenue / Total Revenue, fareste meglio a controllare che succede filtrando solo per evento “purchase” o filtrando via “refund”. Potreste avere delle gioie 🙂

Da qualche tempo su GA4 è possibile avere (“ri-avere” per i nostalgici del “si stava meglio con GA3 😀 ) il report con la progressione e i drop del funnel di checkout, e anzi non solo del checkout: possiamo in realtà creare qualsiasi funnel con qualsiasi pagina, evento, o combinazione di pagine ed eventi, e incastonarlo nel menu principale, ad esempio dentro a Monetizzazione, sempre per compiacere i nostalgici. Come?

Facile, con un explorer che trasformeremo in un report standard.

1. Apriamo la sezione Explore e creiamo un nuovo report, ovviamente di tipologia Funnel (Esplorazione della canalizzazione se usate l’interfaccia italiana – ma non dovreste proprio 😉 )
2. Configuriamo il nostro report innanzitutto decidendo quanti e quali sono gli step. Qui come detto potete usare qualsiasi cosa abbiate nel vostro Analytics: eventi, eventi con parametri particolari, pagine, eventi custom o eventi predefiniti, tutto
3. Tralasciamo pure le metriche, tanto in un report di tipo funnel ci saranno sempre e solo gli “Utenti Attivi”
4. Selezioniamo le dimensioni applicabili. Attenzione perché le dimensioni che scegliamo qui (e l’ordine in cui le mettiamo) si rifletterà tale e quale nel report standard. Quindi la prima dimensione che scegliamo sarà la dimensione predefinita del report, la seconda sarà la prima del menu a tendina, la terza la seconda del menu a tendina e così via
5. Modifichiamo il report fino a quando non lo troviamo soddisfacente. Attenzione anche qui! se dopo avremo bisogno di modificare il report standard, dovremo per forza distruggerlo e ripartire dall’explore, quindi cerchiamo di essere ben sicuri in questo passaggio
6. Salviamo con nome il report nella libreria attraverso un pulsante che esiste solo nei report di tipo Funnel, il pulsante “salva come report nella Libreria” in alto a destra

7. Apriamo la Libreria, editiamo una Collection (per Esempio Ciclo di vita) o creiamo una Collection nuova, e andiamo a incastrare dove vogliamo il nostro report appena salvato
8. Voilà, il report del Funnel è adesso un report standard, visibile da tutti al pari degli altri

Come detto, pongo l’accento su due temi importanti: uno è che il funnel è “libero”, non necessariamente legato al comportamento ecommerce o di checkout come era su GA3: posso fare un funnel di tutti quelli che atterrano da cpc, e che dopo vedono un certo listing, e aggiungono al carrello un prodotto di una certa categoria, eccetera… ovviamente più sono specifico e meno utenti avrò nella mia canalizzazione, ma avete capito. L’altro tema è che una volta incardinato nel menu, il report (questo report, almeno) non è editabile. Va distrutto e ricreato partendo dall’explore in caso ci sia bisogno di modifiche. Un piccolo prezzo da pagare in cambio di una feature molto potente, tutto sommato.

Lo so, lo so…

Mi aspettavate, me lo avete chiesto (grazie, vi ricordate ancora di me 🙂 ) e quindi eccomi qua. Oggi, stanotte, domani – o forse chi lo sa, invece magri ancora per qualche giorno funzionerà, ma insomma, ci siamo – oggi ufficialmente muore Google Universal Analytics, già Google Analytics asincrono, già Google Analytics, e ancora prima Urchin. Diciamo che oggi smetterà di funzionare la mia property più vecchia, quella che ho aperto nel dicembre 2005

Poi dopo 3 anni, nel 2008, ho avviato questo blog e abbiamo iniziato a conoscerci. (Si, dai, “e ora tutto questo andrà perduto, come lacrime nella pioggia“, come sei banale! vi sento, cosa credete? 😀 ).

Non c’è molto che possa aggiungere all’ottimo post di Simo che sono sicuro avete già letto tutti. Anche io come lui devo la mia carriera in larga parte a Google Analytics, e anche io come lui sono stupito dal livello di “non ascolto” di Google. Magari, al suo livello di influenza, non avrei aspettato così tanto per scriverlo, se voleva scuotere qualche animo per davvero a Mountain View. Ma a parte questo, potremo dire sicuramente un paio di cose su Universal Analytics:

• se oggi la digital analytics è un mercato maturo, pieno di professionisti, e un’attività imprescindibile per un brand moderno che faccia marketing lo dobbiamo a lui. Non possiamo sapere SE sarebbe arrivato un tool simile, ne se avrebbe avuto la sua portata (culturale) e la sua scala (tecnica), ma quasi certamente non sarebbe stato la perfetta macchina da marketing che GA è stato per l’ecosistema Google
• Di contro, se oggi la digital analytics è anche spesso “solo” il setup di Google Analytics lo dobbiamo a lui, alla sua facilità, alla sua versatilità e malleabilità; potevi adattare Universal a quasi qualsiasi cosa, tutto sommato velocemente, avevi sempre risposte veloci e precise, e questo alla lunga ha smesso di far pensare per davvero molte persone, ha impedito loro di porsi le giuste domande, o ha fatto credere a molte persone che fare un report (essere in grado di fare un report) fosse sufficiente a rispondere a ogni domanda

Di fatto, sono in realtà due aspetti “culturali” e molto poco tecnici, e sono frutto delle due facce di una stessa medaglia.

Cosa ci riserva il futuro non lo sappiamo. Di sicuro GA4 ha tanta strada da fare prima di arrivare anche solo ad ambire di poter avere la stessa portata culturale. Tecnicamente ce la può anche fare in poco tempo – con un po’ di impegno da parte di Google, chiaro – ma culturalmente ci vorrà del tempo. E come dice Simo, la rivoluzione culturale l’abbiamo fatta tutti insieme, Google, i partner, le agenzie e la community. E’ impensabile farne un’altra senza uno di questi componenti, ma invece ce n’è un gran bisogno altrimenti GA4 sarà “solo” l’evoluzione tecnologica apparentemente complicata di un grande tool sottoutilizzato dai più. E invece l’industry ha bisogno di molto di più, molto molto di più.

(e magari, chissà, ora che ho tolto la polvere dal pannello di WordPress sia mai che… 🙂 )

L’altro giorno mi sono trovato un po’ spiazzato da una frase che suonava alla lontana come “su GA4 non c’è il report Google Ads”. Che però è una cosa piuttosto imprecisa: è vero che GA4 non c’è una sezione dedicata nel menu di navigazione. È vero che su GA4 non ci sono tutti i report dedicati a Google Ads cui eravamo abituati prima. Ma è altrettanto vero che il report Google Ads è vivo e vegeto, esiste ed è fruibile. Solo, è un po’ nascosto. Dove lo trovate, quindi?

Se avete collegato Google Ads e Google Analytics 4, navigate fino alla schermata Ciclo di vita -> Acquisizione -> Panoramica dell’acquisizione, dove tra i widget troverete anche “Sessioni per Campagna Google Ads della sessione”. Da quel widget potrete vedere le prime 7 campagne per sessioni, ma usando il link “visualizza le campagne Google Ads” arriverete al report dedicato, questo:

A parte che mancano le impressions, somiglia molto al report “tutte le campagne” della sezione Google Ads di GA3. Inoltre cambiando la dimensione principale del report si può riprodurre i report campagne, ad set, keyword, query di ricerca, rete pubblicitaria; molti report in un solo report. Per le impressions al momento non si può fare niente, nel senso che anche provando ad editare il report la metrica non è disponibile. Quel che invece potete fare è incardinarlo nella struttura del menu, in modo da renderlo a portata di clic per tutti gli utenti della property, come ho fatto io:

Fate così:

1. Quando siete nel report Google Ads cliccate l’icona a forma di penna in alto a destra, per entrare in modalità MODIFICA
2. Non toccate niente (o personalizzate quel che volete, se lo ritenete necessario) e premete il tasto blu “Salva…” in alto a destra selezionando “salva come nuovo rapporto”
3. Date un nome al rapporto, ad esempio con grande fantasia “Campagne Google Ads” 🙂
4. Tornate al report, in modo da vedere il menu principale, e scegliete “Libreria” in basso a sinistra, vicino all’icona dell’amministrazione
5. Premete “Modifica raccolta” in corrispondenza della raccolta “Ciclo di vita”, e così facendo vedrete il menu esploso e modificabile.
6. A questo punto cercate il report “Campagne Google Ads” (o come lo avete chiamato) e trascinatelo sotto ad Acquisizione Traffico
7. in basso a sinistra fate “Salva…” e poi “Salva le modifiche alla raccolta corrente”

Et voilà, ora il menu ha il suo report Google Ads, per tutti gli utenti che hanno accesso alla property

AH! fermi tutti! Non si era detto che GA4 anonimizza gli IP per default? che non manda niente negli Stati Uniti? MA ALLORA CI PRENDE IN GIRO??

Beh, no, niente affatto. Vediamo un po’ come gira la macchina.

Innanzitutto da dove è che filtro gli IP? dal pannello di AMMINISTRAZIONE, poi DATA STREAMS, poi seleziono lo stream appropriato, poi CONFIGURE TAG SETTING (poi “show all” altrimenti non si vede la voce) e quindi finalmente DEFINE INTERNAL TRAFFIC. Vi ritroverete davanti a una schermata così

Potete inserire varie condizioni come al solito e salvare la regola. Di fatto, quel che accade è che il traffico da quel/quegli indirizzi IP verrà marcato con un parametro “traffic_type” = internal e lo potrete filtrare tramite l’apposito menu.

OK, ma come fa, dato che gli IP ASSOLUTAMENTE non ci arrivano alla macchina di analisi? beh, la cosa è abbastanza interessante: come i più attenti di voi avranno notato, le chiamate al file javascript di analytics (il gtag.js) non sono tutte uguali come accadeva con le vecchie versioni, ma sono parametrizzate. Ad esempio per questo blog viene chiamato https://www.googletagmanager.com/gtag/js?id=G-CPT24FYWZ1

All’interno del file ci sono varie regole e settaggi aggiuntivi, che sono diversi da file a file e dipendono dalle impostazioni che avete nei pannelli. Quando voi salvate un’impostazione tipo questa degli indirizzi IP, di fatto modificate il file che viene scaricato dagli utenti.

All’interno del file quindi c’è una regola che semplicemente dice “se l’indirizzo IP corrisponde a uno di quelli listati, aggiungi il parametro traffic_type=internal”. L’indirizzo IP non viene inviato (o insomma, viene inviato almeno al primo server collettore che per l’Europa è region1.analytics.google.com) ma il traffico può essere filtrato come ai vecchi tempi perché c’è un parametro nella hit – già in partenza, senza quindi dover aspettare che l’IP arrivi ai server – che “marchia” adeguatamente la stessa.

La stessa cosa avviene quando impostate la creazione di un evento dall’interfaccia. La regola viene scritta nel file gtag della vostra property e l’evento viene creato NEL BROWSER e inviato, non viene creato in fase di analisi. Brillante, no? 🙂

Questo blog esiste dal 2008, alcuni di voi lo seguono da allora. Nel corso del tempo abbiamo visto di tutto – come si suol dire – e ne abbiamo sentite di tutti i colori. Un tempo mi dilettavo in previsioni sul futuro dello strumento e vi ho sempre raccontato con dovizia di particolari ogni nuova feature. Se sono stato accomodante con Google? probabilmente si, ma perché sono sempre stato convinto della bontà del prodotto. Ma se cercate bene, troverete anche spunti molto critici, non sono mai stato uno cui piace la piaggeria… 🙂

Ora, su alcune cose in questi anni mi sono sentito di poter dire a voi e ai clienti che “ci metto la mano sul fuoco”, perché in oltre 17 anni di uso dello strumento, Google ci aveva abituato bene; diciamo che era un meccanismo ben oliato e “prevedibile”. Ultimamente invece mi sono trovato già due volte a dire “questa cosa ho sempre detto che non sarebbe mai stata possibile, e invece…”: una su tutte è l’uso dell’identità Google per deduplicare gli utenti cross-device, prerogativa di GA4.

L’altra è la CLAMOROSA SMENTITA del mio mantra “ma no, Google non ha mai forzato nessuno a passare di versione, infatti se vuoi usare il codice di urchin.js è ancora lì. Semplicemente sviluppano feature solo per le nuove versioni così sei incentivato a passare, coi tuoi tempi naturalmente”.

Lo saprete ormai tutti perché non si parla d’altro, invece dal 1 Luglio 2023 Universal SMETTERA’ di raccogliere dati, e funzionerà solo Google Analytics 4. E già questa di per sé è una rottura clamorosa rispetto al passato, uno switch epocale che non sarà esente da traumi. Ma per non farsi mancare niente, avremo accesso ai report Universal per “almeno ancora 6 mesi”, dopodiché anche quelli spariranno. Come se “scaricarsi i report” fosse la soluzione… (si, mi scarico i report mensili dal 2005 al 2023, che sai mai che un CEO voglia l’andamento annuale del sito da quando esiste? ma di quali metriche poi? le sessioni? per channel? per device? per entrambi? e le mie custom dimension utili a segmentare i dati? riscarico anche – di nuovo – tutto in base ad ogni CD?)

Ora, capisco molto bene i vantaggi di GA4, che è un tool completamente riscritto da zero, il cambio di logiche, e che nel lungo periodo saremo tutti più contenti e lavoreremo meglio. Davvero, tralasciando i peccati di gioventù del tool e il suo essere uscito sul mercato in condizioni non ancora ottimali, sapevo per certo che saremmo andati tutti lì, perché e con quali vantaggi. Non capisco però perché Google abbia BISOGNO di forzare la mano così a tutti. 15 mesi sembrano tanti, ma se avete lavorato con realtà di una certa caratura invece saprete che siamo già in ritardo. E’ un non-sense e secondo me è anche un boomerang niente male per Google. Quando metti fretta alle persone, a volte fanno scelte non ben ponderate, per comodità…

In ogni caso, credo che nei prossimi mesi avremo BEN BEN da fare, non sarà affatto una passeggiata.