Come ci aveva già preannunciato qui Andrea subito dopo la SuperWeek 2020, qualcosa di grosso bolliva in casa Google Tag Manager. Brian Kuhn e Scott Herman avevano sganciato una bomba capace di sconvolgere Google Tag Manager per come lo conosciamo: il Server-Side Tagging.

Qualche mese dopo, il 12 agosto 2020, ecco che viene effettuato il rilascio. Si tratta solo di una versione beta, per ora, ma Google Tag Manager sembra aver fatto il primo passo per la sua trasformazione da strumento Client per eccellenza a Server-Side.

Niente paura, questo non vuol dire che il Google Tag Manager che siamo abituati a utilizzare non ci sarà più. Il nuovo GTM convivrà con la sua versione più classica per il momento (ma non solo) visto che rispondono a esigenze diverse.

Non pensate però di poter ignorare l’aggiornamento. Esattamente come nel caso di App+Web, si tratta di un piccolo passo verso quello che potrebbe essere il futuro del tracking e degli analytics. Meglio farsi trovare preparati.

In questo articolo non ci soffermeremo troppo sulle basi di Google Tag Manager e ci concentreremo su cosa cambia con il passaggio al Server-Side. Per chi avesse bisogno di un ripasso, però, abbiamo l’articolo che fa al caso vostro proprio qui.

GTM Client-Side

Togliamo subito dal nostro sentiero gli ostacoli e soffermiamoci qualche riga sulla differenza tra Client-Side e Server-Side. Questa differenza è fondamentale per comprendere la rivoluzione in atto in casa GTM.

Finora, Google Tag Manager è sempre stato uno strumento Client-Side, ovvero che “vive” sul dispositivo dell’utente. Questo significa che ogni volta che una persona visita un sito che utilizza GTM, anche tutto il relativo container viene caricato sul dispositivo, con possibili impatti sulla performance.

Il funzionamento del Google Tag Manager “classico” è abbastanza semplice e Google ci aiuta con questa immagine:

Google Tag Manager è caricato sul device dell’utente (assieme al resto del sito). Tag Manager spara dei tag che “parlano” direttamente con i tool esterni che risiedono in server esterni. Si crea, quindi, una sorta di catena: GTM comunica con le altre piattaforme (Google Analytics, Google Ads, Facebook, AdRoll) e ognuno di loro comunica con il proprio server (Google Analytics con il server Google Analytics e così via).

Per fare in modo che il browser comunichi con questi server è necessario che ogni tag aggiunga delle librerie JavaScript sul sito in maniera tale da permettere le chiamate tra browser e servizi esterni.

Come potete immaginare, le conseguenze sono tre:

  • Molti tag significa minori prestazioni.
  • Ad un certo punto, nella catena, smettiamo di avere controllo diretto sui dati raccolti.
  • Permettiamo ai servizi esterni di agire direttamente sul nostro sito.

GTM Server-Side

E ora cosa cambia? E ora cambia un po’ tutto. Con l’introduzione del Server-Side, cambia lo schema di raccolta dati. Ancora con l’immagine di Google:

Come potete vedere la prima differenza è che si aggiunge un elemento, il Server Container. Il server container è il ponte tra browser e servizi esterni. GTM comunica con il Server Container per informarlo su quale evento è stato attivato. In questo caso, nel nuovo GTM e nell’immagine, a recepire l’evento sarà il Client. Ora è il nostro service container, una volta ricevuto l’evento, ad attivare i tag Server-Side che comunicano direttamente con le piattaforme esterne.

Sì, ma in pratica cosa cambia?

GTM lato server nasce con l’intento di alleggerire la parte client (ovvero quella che sta sul browser degli utenti) e trasferire queste operazioni sul server.

In pratica questi sono alcuni dei miglioramenti:

  • Vivendo su un server, il container può ricevere dati da fonti diverse. Non solo siti web, ma anche app, dispositivi internet of things e molto altro.
  • Grazie al nuovo modello, si eviterà quel proliferare incontrollato di pixel e script che popolano i container GTM classici, migliorandone le performance. Tutti i file JavaScript di terza parte verranno sostituiti da uno stream di eventi consolidato.
  • Server-side vuole dire controllo assoluto sui dati: con il nuovo GTM saprai sempre quali dati sono inviati e a quale piattaforma. Prima di passare le informazioni possiamo modificarle secondo le nostre esigenze.
  • Server-Side è anche maggiore sicurezza perché gli script dei vendor non vengono più caricati a livello di browser e device. Ma non solo, anche le credenziali degli utenti non vengono più esposte sul browser, come purtroppo capita normalmente, rendendo più difficile il furto dei dati.

Non solo aspetti positivi, però, con il passaggio al Server-Side, andiamo anche incontro a rischi e complicazioni:

  • Il primo problema è sicuramente legato alle difficoltà di implementazione, soprattutto per quanto riguarda l’apertura dell’istanza server su Google Cloud Platform.
  • Un altro aspetto delicato è quello dei costi. Su questo meglio fare chiarezza, non sarà GTM a diventare a pagamento. Ciò che dovremmo pagare saranno i costi di gestione del server, per il momento della Google Cloud Platform, che potrebbero ammontare ad almeno 100 euro al mese.
  • Altro grande problema per i clienti (non i client) è che la data collection con il Server-Side si fa decisamente più opaca. Tutto si gioca sull’invio di un segnale al server in cui è ospitato GTM. Il dietro le quinte non si può scoprire e la fiducia giocherà un ruolo centrale nel processo.
  • Un ultimo problema è relativo ai sistemi di ad-blocking che potrebbero essere aggirati in maniera non intenzionale, ma creando qualche problemino all’utente.

Come cambia GTM?

Come ci si potrebbe aspettare, qualche aspetto dell’interfaccia e delle funzionalità di Google Tag Manager verrà modificato. Vediamo qui in breve cosa c’è di nuovo (per avere una visione chiara dal punto di vista operativo di ogni aspetto e cambiamento di Google Tag Manager Server-Side, il consiglio come sempre è di fare riferimento al blog di Simo Ahava e al suo articolo qui):

  • Come già scritto, avremo un nuovo container, quello server, appunto. Da usare assieme (il container server da solo non basta) al container web. Sarà proprio questo container che dovremo collegare alla Google Cloud Platform.
  • I tag nativi disponibili per il momento sono solo per Google Analytics: Universal Analytics e App+Web ma, considerando che qualsiasi servizio che accetta le richieste HTTP può esser configurato per diventare un tag, ci aspettiamo di vedere nascere un bel po’ di custom template nei prossimi mesi.

  • Per quanto riguarda i trigger, ne troviamo di un solo tipo: custom trigger. Questo perché il container server non sarà legato a trigger creati ad hoc come quello di visualizzazione pagina o di click. I tag saranno sparati solo se il Client li avrà istruiti a farlo.
  • Il Client entra nella lista degli elementi di GTM assieme a tag e variabili, pronto a fare da ponte tra sito e terze parti. Il suo obiettivo sarà duplice: registrare le richieste HTTP entranti e definirle in maniera tale che possano essere utilizzate dai tag per completare la richiesta nel server.

Confusi? Proviamo a chiarire con un esempio. Se volessimo tracciare un click su una determinata area del sito per inviare i dati al nostro Google Analytics, dovremmo seguire questi passaggi:

  1.  Inserire nel nostro sito uno snippet gtag.js che invii un evento dal nome “click” al container server.
  2. Creare un Client Universal Analytics che sia capace di ricevere l’evento.
  3. Creare un trigger legato al Client che scatti quando il nome dell’evento è “click”.
  4. Creare un tag Universal Analytics che invii il dato a GA.

Un passaggio in più ma molto più controllo dei dati.

 

Insomma, la rivoluzione sembra essere iniziata e noi siamo qui per darti tutti gli strumenti per tirare fuori il meglio da questo aggiornamento. Cosa ne pensi? Credi che lo userai con i tuoi clienti o per il tuo sito?