Select Page

SERVER-SIDE TRACKING

La nuova frontiera del tracciamento dati… senza perderne nessuno

FREE TRIAL 15 GIORNI

PROVALO SUBITO

SCENARIO

Cosa sta accadendo

I Marketer stanno impazzendo!
Gli effetti della “rivoluzione dei Cookies” si stanno iniziando a vedere: limiti ai Cookies di terze parti,
limitazioni ai Browser  come Safari e Firefox , e tutti i problemi legati al blocco ITP (Intelligent Tracking Prevention), la Consent Mode di Google, iOS14, iOS15 e GDPR, ed abbiamo appena iniziato…..

Google ha dichiarato che dal 2023 il proprio browser Chrome, utilizzato dalla maggioranza degli utenti, non supporterà più i cookie di terze parti, già esclusi nelle impostazioni di default di altri browser come Safari e Mozilla, di fatto annunciando la fine di un modo molto diffuso di fare Digital Advertising, ritenuto insicuro e poco rispettoso della privacy degli utenti.

Il fenomeno è quindi legato interamente alle richieste dei consumatori di maggiore trasparenza e chiarezza sull’utilizzo dei propri dati sul web, ma scuote il mondo dell’ADV online, che attualmente si trova in grande difficoltà, con importante calo delle “performance” delle campagne.

PRODOTTO

Dal client side al server side

Tag Manager attiva dei Tag tramite i quali questi effettua “richieste/chiamate” dei servizi che risiedono in server esterni (Google Analytics, Google Ads, Facebook, etc).
Tutte queste richieste sono create e gestite dal browser stesso, ma per far sì che questo accada è necessario che ogni singolo Tag aggiunga nelle pagine del sito una serie di librerie JavaScript che gli permettono di eseguire le diverse chiamate ai servizi esterni (che corrispondono ai Tag).

Funzionamento del TAG CLIENT-SIDE di GTM

GTM Client Side è ad oggi il classico metodo di tagging utilizzato; questi utilizza il browser dell’utente come client, inviando direttamente da qui le chiamate a piattaforme esterne di analisi tipo Google Analytics o ADS  come Google Ads, Meta Ads, ecc.
I tracciamenti e codici JavaScript vengono inclusi tramite tag manager direttamente nella pagina web e da qui inviano dati ai diversi strumenti esterni come sopra citato.

Ogni Tag presente nel sito internet funziona con uno script installato su GTM il quale script invia delle richieste ai server esterni che gestiscono i  vari Tag; la piattaforma esterna del Tag risponderà alle richieste provenienti dal sito installando nel browser dell’utente dei Cookie di prima o terza parte per tracciare i comportamenti dell’utente.

Tutte queste operazioni vengono gestite da GTM Web Container.
Cosa può accadere in questi casi?

  • potrebbero verificarsi delle anomalie negli script installati nei browser
  • vengono attivati dei blocchi delle richieste da parte dei browser (adBlock, Ghostery,etc.)
  • sussiste una problematica per quanto riguarda la gestione cookies

Funzionamento del TAG SERVER-SIDE di GTM

Con l’arrivo del Tag Server-Side la logica di funzionamento di GTM cambia radicalmente.

Dal flusso riportato nell’immagine vediamo che c’è un nuovo tipo specifico contenitore di GTM: il Server Container.

Le limitazioni che avvengono nel client-side, non esisteranno in un tracciamento Server-Side. Utilizzando Server-Side all’interno di Google Tag Manager viene aggiunto un passaggio rispetto al “classico” tracciamento dati. I tracciamenti vengono effettuati attraverso un processo esterno, implementato su un Server Container proprietario.

Il Server-Side Tag consente un controllo completo sui dati delle navigazioni degli utenti. I tracciamenti sono incorporati in un Server creato e gestito dal proprietario del sito o dell’App interessata; questo strumento incrementa la sicurezza del sito web e ne protegge la privacy.

Funzionamento

Cosa cambia con il server-side?

Il lancio di GTM Server Side è stato favorito dai recenti cambiamenti sui Cookies di terze parti; all’interno di Google Tag manager, con la configurazione classica (Client Side), ogni singolo tag effettua delle chiamate a Server esterni (come ad esempio Google Analytics, Facebook ecc.).
Per un corretto funzionamento dei tag vengono creati cookies, solitamente di terze parti

Ma a causa delle possibili alterazioni all’interno dei Browsers, molti dati non vengono comunicati ai tool che utilizziamo.

Le limitazioni che avvengono nel client-side, non esisteranno in un tracciamento Server-Side.

Utilizzando Server-Side all’interno di Google Tag Manager viene aggiunto un passaggio rispetto al “classico” tracciamento dati; i tracciamenti vengono effettuati attraverso un processo esterno, implementato su un Server Container proprietario.

Il Server-Side Tag consente un controllo completo sui dati delle navigazioni degli utenti; i tracciamenti sono incorporati in un Server creato e gestito dal proprietario del sito; questo strumento incrementa la sicurezza del sito web e ne protegge la privacy.
Affinché il Server Side Tracking funzioni, oltre a GTM Server Side, occorre un server esterno che gestisca le chiamate; il server potrà essere scelto tra una di queste 2 tipologie:

  1. Google Cloud (necessario per creare e gestire il server)
  2. Altro server configurato dal cliente o da sistemista esterno

Le specifiche del server sono consultabili a questo link.

Cambia così radicalmente la natura dei tag, che vengono creati all’interno del nuovo container sfruttando la tecnologia sandboxed JavaScript; è un sistema più chiuso e protetto rispetto al linguaggio JavaScript normale, alcune funzionalità sono state rimosse e altre richiedono dei permessi per attivarsi.

Cos'è la codifica lato server?

Con la codifica lato server, Google Tag Manager ha introdotto un nuovo tipo di contenitore Server, che risiede in un ambiente Server Cloud.

 

Lo scopo di questa configurazione è creare un endpoint in un ambiente server di proprietà; questo avrà la funzione di proxy tra gli hit inviati da browser e dispositivi e gli endpoint effettivi su cui vengono raccolti gli hit stessi.
Il contenitore stesso funziona come un endpoint API HTTP, a cui qualsiasi browser, dispositivo o altre origini che supportano il protocollo HTTP, possono inviare richieste.

 

Idealmente, questo endpoint viene mappato con un sottodominio personalizzato nella stessa gerarchia di domini del sito Web che invia le richieste; in questo modo si presuppone che le richieste avvengano in un contesto di prima parte, il che ha un impatto significativo sul modo in cui i cookie possono essere letti e scritti.

Vantaggi chiave

Ecco alcuni dei principali vantaggi dell’utilizzo della codifica lato server.

MIGLIORI PERFORMANCE

Il primo vantaggio evidente è il miglioramento delle performance del sito. Togliendo l’inserimento di codice JavaScript sul sito si vanno ad alleggerire le pagine visitate, migliorando in modo significativo la user experience.
Eseguendo la logica di creazione e invio di hit all’endpoint del fornitore nel tuo ambiente lato server, puoi ridurre drasticamente la quantità di JavaScript (soprattutto di terze parti) eseguiti nel browser dell’utente.
Potendo configurare il contenitore del server per mappare qualsiasi richiesta HTTP in entrata nel formato richiesto dal fornitore, è possibile ridurre l’intero carico di pixel e JavaScript di terze parti a un singolo flusso di eventi diretto nel contenitore del server.

CONTROLLO DEI DATI

Il Server-Side Tag permette di minimizzare i problemi data leak o la perdita di informazioni, rendendo i dati raccolti più affidabili e di qualità. Sarà anche possibile gestire e arricchire le informazioni prima di inviarle alla piattaforma.
Nel Client, puoi modificare la risposta HTTP dal contenitore server al browser o al dispositivo. Questa è una cosa piuttosto interessante se si considera l’Intelligent Tracking Prevention di Apple , ad esempio. Puoi convertire i cookie scritti con JavaScript, e quindi soggetti a un limite di scadenza di 7 giorni, in cookie HTTP scritti con Set-Cookie, estendendone così la durata temporale.

Estensione dei Cookies
Agendo su un contesto di prima parte sarà possibile ridurre le limitazioni sui cookie degli utenti iOS.
Non ci sono perdite di dati con i cookie di terze parti, non ci sono sorprese con i parametri URL iniettati e il servizio di terze parti non ha alcuna connessione con il browser dell’utente per impostazione predefinita. Comunicheranno solo con il cloud server.

Bypass degli "ad-blockers"

Come nel caso dei cookies, il contesto di prima parte ci permette di ridurre alcune limitazioni causate dagli ad-blockers; solitamente hanno un impatto negativo sulle richieste inviate da e per Google Analytics.

SICUREZZA DEI CONTENUTI

Un altro vantaggio della riduzione del numero di endpoint HTTP con cui comunica il browser riguarda la Content Security Policy (CSP) del sito.
Un CSP è ciò che il sito utilizzerebbe per limitare il traffico HTTP da e verso il browser dell’utente.
Riducendo il numero di endpoint HTTP con cui il browser deve comunicare (poiché li hai sostituiti con il tuo endpoint di tagging lato server), stai anche rendendo il CSP più robusto.

ELUSIONE DEL BLOCCO DEI CONTENUTI

Una delle prime reazioni istintive che molti hanno probabilmente al tagging lato server ha a che fare con il blocco dei contenuti e le protezioni di tracciamento del browser in generale.
Un approccio tipico per i browser rispettosi della privacy consiste nel limitare o bloccare completamente le comunicazioni tra il browser ed i tracker noti . L’elenco dei tracker conosciuti è generalmente basato su un blocklist come Disconnect.Me , ma potrebbe anche essere algoritmico e sul dispositivo, come con Intelligent Tracking Prevention.

GESTIONE DEL CONSENSO ALL'AMMINISTRATORE

La gestione del consenso è un argomento importante; molti siti implementano strumenti di gestione del consenso lato client, che richiedono il consenso dell’utente per quanto riguarda i dati da raccogliere.

Quando passiamo al tagging lato server, potremmo avere un solo flusso di eventi dal browser al server. Questo singolo flusso può essere suddiviso in moltissime richieste di pubblicità, marketing e analisi nel contenitore Server.
I modelli in esecuzione nel contenitore Server non saranno in grado di sfruttare le API di consenso lato client per cui sarà necessario creare il meccanismo di interpretazione e analisi del consenso dell’utente manualmente nel contenitore stesso.

GTMSS

TUTORIAL

Il contenitore Server stesso ricorda visivamente qualsiasi contenitore di Google Tag Manager.

La differenza principale è il nuovo tipo di asset del cliente che puoi vedere nel menu a sinistra.

Quando si utilizza il termine richiesta HTTP in entrata , ci riferiamo alla richiesta HTTP inviata da un dispositivo o browser al contenitore Server. Quando si utilizza il termine richiesta HTTP in uscita , ci riferiamo invece alla richiesta HTTP creata e inviata dai tag che si attivano nel contenitore.

Tag

In riferimento ai tag attualmente disponibili, ci sono i modelli nativi Universal Analytics, GA4, Google ADS e poco più, tutti configurati per assimilare i dati inviati dai rispettivi “client”; Il tag di richiesta HTTP ti consente di creare una richiesta HTTP in uscita verso qualsiasi destinazione.

Inoltre possiamo trovare tag personalizzati da creare “ad hoc”; quasi tutti i servizi che accettano richieste HTTP possono essere configurati in un modello di tag personalizzato nel contenitore Server.

Trigger

Il contenitore Server contiene i seguenti trigger: “Visualizzazione pagina”, “Evento Personalizzato” e “Personalizzato”.

Un contenitore Server non è inoltre correlato alle etichette lato client come “caricamento pagina” o “carico contenitore”. È sempre in esecuzione – non viene ripristinato quando la pagina viene aggiornata. Quindi non ci sono trigger relativi al ciclo di vita di un contenitore Server, anche se ciò non significa che, prima o poi, non ci saranno.

Questi possono essere usati per analizzare le informazioni sulla richiesta in arrivo e per recuperare i metadati sull’evento che si è attivato e sul contenitore stesso.

Nella configurazione del Cloud Server si consiglia vivamente di eseguire il mapping di un dominio (di terzo livello) personalizzato all’endpoint del contenitore del server.

Il motivo principale è che in questo modo sarà possibile incorporare l’endpoint di raccolta dati lato server dei nomi di dominio proprietario; ad esempio, noi usiamo “gtm.groweb.it” come host del contenitore Server.

Questo diventa significativo se si considerano cose come la prevenzione del rilevamento intelligente (ITP).

Potremmo voler utilizzare i cookie nelle richieste in arrivo, ma se il contenitore del Server è ospitato su un dominio diverso da quello in cui vengono inviate le richieste (come il nostro sito), questi cookie saranno considerati cookie di terze parti e quindi trascurati da molti browser.

Inoltre a seguito degli ultimi aggiornamenti relativi all’ITP, è consigliabile mappare il dominio come un sottodominio appena verificato; in questo modo verrà chiesto di utilizzare i record DNS A/AAAA anziché il CNAME.

Allo stesso modo, avere l’endpoint nello spazio dei nomi di dominio di prima parte significa che sarà possibile impostare i cookie proprietari con le intestazioni di Set-Cookie e quindi evitare che Safari e Firefox li facciano scadere entro 7 giorni.

Il contenitore Server, proprio come un contenitore Web, ha la propria modalità Anteprima e Debug.

Quando si fa clic sul pulsante “anteprima” nell’interfaccia utente, si apre una nuova scheda con l’interfaccia di anteprima.

Proprio come con un contenitore web, la scheda anteprima mostra solo gli hit che provengono dal browser e deve essere la stessa istanza del browser che ha avviato la modalità anteprima.

Nella navigazione a sinistra, troviamo tutte le richieste HTTP in entrata.

Selezionando una richiesta , tutte le schede in modalità anteprima si comporteranno come se avessimo selezionato riepilogo; in altre parole, potremo vedere quante volte un tag è stato attivato per la richiesta, ma non possiamo esaminare le variabili o i dati dell’evento.

Per questo motivo, ogni volta che facciamo il debug, dovremmo scegliere l’oggetto dei dati dell’evento (ad esempio “page_view”) se disponibile.

GTMSS

PREZZI

MENSILI

*TRAFFICO DI DEBUG NON VERRÀ CONTEGGIATO

€ 15/ mese per ogni 1.000.000 di richieste aggiuntive PER PIANO GOLD – (tutti i prezzi sono IVA esclusa)

ANNUALI

*TRAFFICO DI DEBUG NON VERRÀ CONTEGGIATO

€ 15/ mese per ogni 1.000.000 di richieste aggiuntive PER PIANO GOLD – (tutti i prezzi sono IVA esclusa)

Contattaci

Privacy