Pubblicato il 14 Ott 2021 - Aggiornato il 14 Nov 2021

Perché usare il server-side tagging con GTM?

Web Analytics

Il mondo dei tracciamenti è sempre più in rapida evoluzione. Cambiano le regolamentazioni per la protezione dei dati, le piattaforme si adattano e con essi gli utilizzatori.

Sia il singolo imprenditore che il professionista devono dunque aggiornarsi continuamente per attenersi alle regole ed evitare multe salate ma al tempo stesso continuare a sfruttare tutte le potenzialità di queste piattaforme.

Vista la recente notizia (fine settembre) di Google che ha annunciato l’uscita del Server Side Tagging di Google Tag Manager dalla versione Beta voglio parlarvi di questa opportunità con Luca Sanità, content curator del blog Data Enthusiast, alla quale ho fatto alcune domande per approfondire un ambito ancora poco chiaro.

E voi siete pronti a cambiare il vostro punto di vista?

Che cos’è il Server-Side Tag in Google Tag Manager?

Per capire il contesto del tracciamento lato server tramite GTM, ci dobbiamo collegare ad alcuni temi ormai noti tra noi professionisti del settore, ossia le limitazioni ai cookie di terza parte che in questi anni non solo Apple, ma a ruota i principali Browsers, stanno portando avanti.

Le limitazioni che avvengono client-side, ossia proprio nel browser utilizzato dall’utente, non sono le stesse che si riscontrano con un tracciamento server-side. Per capirci, quando abbiamo il classico contenitore di GTM installato, ogni tag implementato fa delle chiamate a server esterni, come Google Analytics, Facebook etc., e queste chiamate avvengono tramite il browser dell’utente.

Per il corretto funzionamento dei tag, vengono inoltre creati dei cookie che, per la maggior parte dei casi, sono di terza parte. Con le continue limitazioni che avvengono nei Browsers, molti dati, utili alla digital analytics, non vengono passati ai tool che utilizziamo tutti giorni come Analytics o Facebook.

Nel contesto server-side in GTM, le cose cambiano perché le informazioni non passano semplicemente dal browser dell’utente ai tool di terza parte, bensì si aggiunge un nuovo elemento che è il Contenitore Server che viene ospitato su un server che, una volta impostato, ci permette di lavorare in un contesto di prima parte. 

Come funziona il Server-side tracking?

Il funzionamento è semplice dal punto di vista teorico, perché l’idea di fondo è quella di spostare le richieste HTTP sul server che ospita il nuovo contenitore, gestirle meglio in questo luogo, solo successivamente inviare i dati ai diversi fornitori di servizi.

Tuttavia è bene tenere a mente che, questa tipologia di tracciamento, funziona con due contenitori. Eh sì! Non pensiamo di dover archiviare il contenitore client-side. Fondamentalmente ci troveremo a dover gestire il classico contenitore che abbiamo sempre utilizzato e il nuovo contenitore server-side.

A questo, si aggiunge un nuovo elemento chiamato Client che è lo strumento chiave di tutto il sistema, perché è il collegamento che gestisce concretamente le richieste HTTP in ingresso e le definisce in modo che possano essere utilizzate dai tag per completare la richiesta nel server e quindi inviare i dati ai fornitori di servizi.

Attenzione però: quando parliamo di client-side non stiamo dicendo la stessa cosa di quando mi riferisco ai “Client”.

Parliamo di contenitore lato client o lato web quando facciamo riferimento al contenitore che lavora tramite il browser dell’utente.

Quando parlo dei “Client” mi riferisco a questo nuovo elemento, fondamentale per far lavorare correttamente il tracciamento lato server.

Quali sono i vantaggi e gli svantaggi principali?

I vantaggi sono diversi perché trasferendo la gestione principale dal browser dell’utente al server, che ospita il nuovo contenitore, anzitutto abbiamo un miglioramento delle performance del sito. Nel contenitore client-side, per far funzionare tutto correttamente, ogni tag va ad aggiungere delle librerie JavaScript con un ovvio impatto sul caricamento delle pagine.

Nel contenitore server-side invece, posso far caricare meno script gestendo poi l’invio delle diverse informazioni ai tool di terza parte. Controllo della qualità del dato: possiamo gestire le informazioni che inviamo ai diversi fornitori di servizi decidendo cosa inviare e cosa no. Maggiore sicurezza lato PII (Personally Identifiable Information): le credenziali utilizzate dagli utenti che navigano sul nostro sito web hanno un livello aggiuntivo di protezione perché la gestione delle informazioni passa, non più tramite browser, ma tramite server. 

Posso estendere la durata del cookie per gli utenti che usano sistemi iOS in quanto il server diventa un contesto di prima parte. Riduzione dell’impatto degli ad-blockers che, non raramente, vanno ad impattare anche sulle richieste inviate da e verso Google Analytics. Come al solito non è tutto oro quello che luccica e quindi, ai pro, seguono anche diversi contro.

Gli svantaggi principali di questa soluzione riguardano il know-how nell’implementazione dell’istanza server su Google Cloud Platform oppure su AWS. Non tutti hanno questa expertise e spesso l’effort aumenta perché è necessario fare riferimento al reparto IT al quale bisogna spiegare le necessità e i motivi di implementare questa soluzione.

Ci sono dei costi di mantenimento del server che varia a seconda dei volumi di traffico e della scalabilità del servizio (parliamo di delta che possono andare dai  50€ ai 200€/mese ma che possono anche salire. Una guida dei costi la si può trovare qui).

Se è vero che prima ti ho detto che si riduce l’esposizione delle credenziali degli utenti sul browser, adottando una soluzione di tracciamento server-side, il rovescio della medaglia è che, quello che succede sul server è meno controllabile e più opaco. 

Rischio spam e bolletta salata: un altro rischio è quello che ci possano hackerare le richieste inviate dal client al server impattando i costi finali (è pur vero che nella GCP, nella sezione Billing > Budget&Alerts, è possibile inserire degli alert per il monitoraggio dei costi, però è importante essere consci della problematica).

Come si implementa e quali potrebbero essere i costi aggiuntivi?

Se ti devo riassumere gli step principali dell’implementazione, posso dirti che questi sono i passaggi principali da seguire:

• creazione del contenitore GTM lato server direttamente da Tag Manager;
• verifica e mapping del dominio personalizzato lato server: ad inizio implementazione viene fornito un dominio, che ospita il contenitore server, che appartiene a Google (lo riconosci perché ha il nome appspot.com). Sarà necessario creare un sottodominio di tracking legato al proprio dominio (es.: se il mio sito è www.miosito.it il sottodominio potrà essere gtm.miosito.it oppure data.miosito.it)
• creare i Client per processare le richieste in ingresso
• aggiornare il settings di GTM per inviare i dati al contenitore server-side
• verificare e testare le richieste in ingresso 
• inviare i primi dati dal contenitore lato server ai fornitori di terza parte 
• se si utilizza la Google Cloud Platform, fare l’upgrade all’ambiente App Engine Flexible
• pubblicare il contenitore, monitorare i costi e aumentare nel tempo il tracking con lo scopo di far girare in parallelo il tracciamento lato client e lato server

In merito ai costi, diciamo che, oltre a quanto detto sopra, bisogna considerare l’effort da dedicare alla soluzione. Non si può pensare, che il tracciamento lato server sia un qualcosa di pre-confezionato che si mette in piedi e poi lo si lascia andare (in realtà non può essere così neanche per il tracciamento lato client).

Si deve pensare di dedicare le risorse giuste per manutenerlo, analizzare i dati e le differenze tra le informazioni raccolte lato client e lato server. Questo è un costo/investimento difficile da quantificare ma necessario da considerare.

In quali casi si dovrebbe implementare?

Come abbiamo discusso, si capisce che la soluzione non è così difficile da implementare, ma allo stesso tempo nemmeno semplicissima. Inoltre, richiede la pianificazione delle giuste risorse nel tempo. Ti direi che è una soluzione che, a partire da realtà di medie dimensioni, deve essere seriamente presa in considerazione.

Ci sono una serie di vantaggi che devono essere visti in un’ottica di medio-lungo periodo: prima si mette mano sull’implementazione e prima ci possiamo rendere conto delle potenzialità e saremo in grado di padroneggiare lo strumento per offrire delle soluzioni, in azienda o al cliente che seguiamo, al futuro cookie-less.

Inoltre, dobbiamo assolutamente sfruttare queste novità per vedere con i nostri occhi la differenza del dato raccolto attraverso un’architettura di tracciamento lato client e lato server e l’impatto che si ha sui tool di web analytics e su quelli di gestione delle campagne.

Insomma, sappiamo che il nostro è un settore in continua evoluzione e, se vogliamo cavalcare l’onda e non semplicemente farci travolgere, dobbiamo iniziare a metterci mano da subito.

Qual è il futuro dei classici tag, trigger e variabili di GTM?

Generalmente, l’implementazione lato server di GTM non modifica in maniera eccessiva l’utilizzo di tag, trigger e variabili. Questi restano gli strumenti cardine del sistema per implementare qualsiasi architettura di tracciamento. La novità più grande, però, riguarda l’entrata in scena dei Client. Questa è la parte fondamentale perché permette una serie di cose:

• rende disponibili i dati per i tag e le variabili per poi inviare il tutto a Google Analytics o altri fornitori di servizi;
• permette di inviare il dato direttamente a certi fornitori senza dover creare alcun tag (anche se questa è una scelta non raccomandata); 
• si possono ripulire i dati prima di inviare il tutto a certi tool (lato PII ma anche per non inviare certe informazioni non necessarie)
• si possono arricchire i dati raccolti, comunicando con il CRM per inviare un dato più completo. Insomma il Client ha, per così dire, la stessa importanza che il Data Layer ha nell’implementazione del tracciamento con il contenitore classico di GTM.

Per concludere ti dico che le possibilità sono tante. Lo strumento non è ancora al 100% delle sue potenzialità ma prima ci si mette le mani e prima lo si inizierà a padroneggiare. Per concludere, è bene tenere a mente una serie di questioni:

• il setup di GTM client-side non verrà eliminato- le conoscenze che ognuno di noi si è fatto su GTM come lo abbiamo utilizzato fino ad oggi non diventeranno obsolete, anzi!
• il data layer non diventa inutile
• con l’implementazione server-side non abbiamo tra le mani uno strumento che aggira le varie GDPR e altre legislazioni dedicate alla privacy, anzi ci permette di gestire meglio le informazioni che passano dal nostro sito web prima di essere inviate ai fornitori di terze parti.

Quindi, consigli di partire da oggi con una implementazione 100% server-side?

Giusta domanda, ma la risposta è no. Bisogna partire step-by-step misurando ogni implementazione lato server e comparandola con quella che tracciamo lato web. In questo modo possiamo osservare le differenze sui dati raccolti.

Inoltre, un altro motivo per non passare alla sola implementazione lato server è che non tutti i fornitori che utilizziamo sono pronti e hanno gli strumenti per migrare ad un tracciamento server. Ci vorrà tempo e sicuramente ognuno offrirà i giusti strumenti (tag, template etc.) ma al momento la lista è ancora stringata.

Diciamo che il consiglio è lo stesso che ancora oggi si da sull’implementazione di GA4, ossia far girare in parallelo il tracking di Universal Analytics e Google Analytics 4. Allo stesso modo, oggi il consiglio è: partire il prima possibile, ma in un’ottica di tracciamento parallelo per conoscere lo strumento, padroneggiarlo, e misurare le differenze tra i due ambienti.

Se poi vuoi entrare più nel dettaglio sul tema, ho scritto una guida approfondita a riguardo che trovi qui.

Conclusioni

L’essere umano non è subito propenso alle novità, soprattutto quando si tratta di tecnologia. Il cervello è neofobico ed ha paura di intraprendere nuove strade. Ha bisogno infatti di qualcosa o di qualcuno che lo spinga al cambiamento.

In questo caso saranno le limitazioni ai cookie di terza parte e il valore che hanno per il nostro business che ci condurranno ad una scelta ben precisa.

E tu hai già fatto questa scelta?

Tag: Interviste ad esperti del web

Luca Sanità

Web Analytics Lead

Dopo qualche anno nel Retail, la passione del mondo digitale, unita alla passione nell'interpretazione dei numeri, mi ha portato ad avvicinarmi al mondo magico della web analytics. La curiosità ha fatto il resto, dandomi l'energia costante di scoprire le novità del settore fino ad aprire un mio blog (Data Enthusiast) dove condividere quello che imparo tutti i giorni. Nella vita quotidiana, le altre passioni sono lo sport, i viaggi e la musica classica, alle quali cerco di dedicare il giusto tempo per aiutarmi a ricaricare le batterie a fine giornata!