Giovani Ortolani Barbosa
AutoreA settembre 2024, Google ha introdotto l’uso dei Service Worker in Google Tag Manager (GTM) per migliorare le prestazioni e l’affidabilità delle misurazioni:
| “Google Tag Manager può utilizzare un Service Worker per migliorare le prestazioni e l’affidabilità delle misurazioni. Per garantire il corretto caricamento del Service Worker, consultare le linee guida sulla Politica di sicurezza dei contenuti.” |
In seguito, a marzo 2025, Google ha annunciato l’espansione di questa funzionalità:
| “Ora Google tag utilizza i Service Worker, quando disponibili, per inviare dati a Tag Manager lato server, migliorando le prestazioni e l’affidabilità delle misurazioni.” |
Questo articolo illustra come GTM e gtag gestiscono i Service Worker, cosa sono i Service Worker, come avviene la comunicazione tra essi e perché le richieste di analisi dei dati potrebbero non comparire nella scheda Network di DevTools.
I Service Worker sono script in background che vengono eseguiti separatamente dal thread principale di un sito web. Consentono operazioni come caching, supporto offline e richieste di rete in background, senza bloccare l’interfaccia utente.
Nel contesto di GTM e gtag, i Service Worker vengono utilizzati per delegare l’invio dei dati di misurazione dalla pagina web (ad esempio, hit di GA4 o Ads), rendendo il tracciamento più rapido e affidabile, anche durante eventi di chiusura della pagina o su reti lente. Si noti che, in questo contesto, i Service Worker non memorizzano gli eventi per inviarli in un secondo momento.
Possono essere registrati due tipi di Service Worker, a seconda della configurazione:
googletagmanager.com. Utilizzato principalmente dai prodotti Ads (Google Ads e Floodlight) per le richieste di form-data e user-data.Entrambe le versioni seguono un modello di comunicazione simile che coinvolge diverse entità del browser.
Quando gtag o GTM vengono eseguiti, viene creato un iframe invisibile (src=”about:blank”), che a sua volta carica un altro iframe, sw_iframe.html. Questo secondo iframe è responsabile dell’installazione dello script del Service Worker (sw.js).
Questi elementi comunicano tramite postMessage() API del browser (per inviare le informazioni) e il listener dei messaggi per riceverle, formando il seguente flusso:
gtag/GTM ↔ iframe (about:blank) ↔ iframe (sw_iframe.html) ↔ sw.js (Service Worker)Questo ponte permette a gtag o GTM, in esecuzione sulla pagina principale, di passare i dati degli eventi al Service Worker, il quale decide poi come e quando inviarli.
Se si ispeziona la pagina web tramite la scheda Elements di DevTools, sarà possibile visualizzare gli iframe.
Dimostrazione reale dei messaggi scambiati tra l’iframe e il Service Worker:
Questo Service Worker viene utilizzato per le richieste GA4 inviate a un contenitore GTM lato server.
Lo script gtag (G-{Measurement ID} ecc.) è responsabile dell’inoltro degli eventi al Service Worker.
Verifichi se un evento deve essere inviato tramite il Service Worker in base a diverse condizioni:
analytics.google.com/g/collect o www.google-analytics.com/g/collect (ad esempio, quando è configurato il parametro server_container_url). beforeunload). Durante l’unload, richieste come l’evento user_engagement ignorano il Service Worker.- Più nello specifico, viene controllato che lo User Agent del browser NON contenga nessuna delle seguenti stringhe: "; wv" O "FBAN" O "FBAV" O (("GSA" O "GoogleApp") E ("iPhone" O "iPad"))
2). - Questo controllo viene eseguito tramite il metodo .delegate(),che può essere osservato qui.
Se tutte le condizioni sono soddisfatte, l’evento viene inviato tramite il Service Worker. In caso contrario, viene inviato direttamente dalla pagina principale utilizzando fetch, XHR, sendBeacon, o Image (in questo ordine).
Inoltre, se le prime due condizioni sono soddisfatte, il parametro richsstsse viene aggiunto all’URL dell’evento (per saperne di più). Questo parametro permette al browser di elaborare la risposta, ad esempio inviando richieste indicate dal sGTM per la sincronizzazione dei cookie di terze parti.
Questo Service Worker sembra gestire eventi per i prodotti Google Ads e Floodlight.
Alcune richieste passano attraverso di esso, come:
https://www.google.com/ccm/form-data/{Conversion ID}/... e https://www.google.com/pagead/form-data/{Conversion ID}/...)https://www.google.com/ccm/form-data/{Conversion ID}/...).Lo script gtag dei prodotti Ads caricato nella pagina (AW-{Conversion ID}, DC-{Floodlight Config ID}, ecc.) è responsabile dell’inoltro degli eventi al Service Worker.
Le condizioni per l’utilizzo di questo Service Worker sono simili:
send_user_data_hit è uno dei seguenti:- user_data_web: utilizzato dall’evento Auto-captured User-data
- user_data_lead: utilizzato dall’evento Google Ads User-Provided Event
beforeunload). 2). - Questo controllo viene eseguito tramite il metodo .delegate() , che può essere osservato qui.
Se una di queste condizioni non è soddisfatta, l’evento viene inviato normalmente dalla pagina principale.
Sia gtag che GTM includono un metodo chiamato .delegate, che esegue il controllo finale prima di decidere se inviare l’evento tramite un Service Worker o dalla pagina principale.
La logica è la seguente:
k.delegate = function (a, b, c) {
this.getState() !== 2
? (this.H.C( // Path 1: Not Ready - Sends event from main page.
this.C,
{
state: this.getState(),
hg: this.initTime,
ng: Math.round(Ab()) - this.initTime
},
void 0,
a.commandType
),
c({ // Call the failure callback
failureType: this.C
}))
: this.N.wo(a, b, c); // Path 2: Ready - Sends events from Service Worker.
};
Ogni volta che lo stato è pari a 2, la richiesta viene inviata tramite il Service Worker; altrimenti, viene inviata dalla pagina principale.
Il Service Worker e la pagina principale scambiano messaggi di heartbeat a intervalli regolari (attualmente ogni 5 secondi) per mantenere aggiornato questo state . La variabile state rappresenta la prontezza del Service Worker:
| Stato | Significato |
|---|---|
| 0 | Stato iniziale all’inizializzazione della pagina |
| 1 | Tentativo di stabilire la comunicazione tra la pagina principale e il Service Worker |
| 2 | Service Worker pronto e handshake con la pagina principale riuscito |
| 3 | Riprova dopo errore |
| 4 | Errore fatale/fallimento/canale di comunicazione chiuso |
È possibile controllare l’utilizzo dei Service Worker in diversi modi.
Filtri le richieste verso sw.js o sw_iframe.html.
Nota:
Service Worker caricato dal dominio first-party del sGTM.
Service Worker caricato dal dominio googletagmanager.com.
Apra DevTools → vada alla scheda Applicazione → Service Worker → faccia clic su “Visualizza tutte le registrazioni” e cerchi il suo dominio.
Se utilizza prodotti Ads di Google: vedrà il Service Worker servito da googletagmanager.com.
Le richieste gestite da un Service Worker mostrano un’icona a forma di ingranaggio accanto all’URL. Queste rappresentano gli hit inviati dal processo in background, anziché dalla pagina principale.
Se gli eventi GA4 o Ads non compaiono nella scheda Network della pagina principale, è probabile che vengano inviati dal Service Worker. Tuttavia, continueranno a essere visibili nella finestra GTM Preview Mode, dove è possibile ispezionarli.
È possibile visualizzare fino a due Service Worker: uno per il dominio sGTM e uno per il dominio di Google. Ognuno gestisce tipi di eventi differenti, come descritto in precedenza.
L’integrazione graduale dei Service Worker in GTM e gtag da parte di Google rappresenta un passaggio verso un metodo più robusto di invio e gestione degli eventi. Delegando la consegna degli eventi agli script in background, Google migliora prestazioni, affidabilità e accuratezza della raccolta dei dati, soprattutto in casi limite come rimbalzi rapidi o connessioni instabili. Tuttavia, questo significa anche che alcune richieste non appariranno nella tradizionale scheda Network.
Per gli specialisti di analisi di dati digitali, questo significa:
Dal momento che questa funzionalità continua a evolversi, comprendere come gtag e GTM sfruttano i Service Worker sarà fondamentale per un debug accurato e per garantire l’affidabilità dei dati.
Commenti