Come GTM e gtag utilizzano i Service Worker (e perché i suoi eventi non compaiono in DevTools)
Scritto da
Giovani Ortolani Barbosa
⚠️ Questo articolo si basa su un’ampia attività di debug e sperimentazione con Google Tag Manager (GTM) e il Google tag (gtag). Sebbene ogni dettaglio riportato sia accurato al momento della pubblicazione, segnaliamo che le implementazioni di Google possono evolversi, rendendo alcune informazioni qui contenute obsolete.
A 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.
Cosa sono i Service Worker?
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.
Come GTM e gtag utilizzano i Service Worker
Possono essere registrati due tipi di Service Worker, a seconda della configurazione:
- 1.Service Worker dal dominio first-party del GTM lato server (sGTM). Utilizzato per le richieste GA4 inviate ai contenitori lato server.
- 2.Service Worker dal dominio
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.
Flusso di comunicazione
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:
- Service Worker dal dominio first-party del GTM lato server (sGTM)
- Service Worker dal dominio googletagmanager.com
1. Service Worker caricato dal dominio first-party del sGTM
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:
- L’evento non viene inviato direttamente a
analytics.google.com/g/collectowww.google-analytics.com/g/collect(ad esempio, quando è configurato il parametroserver_container_url).
- La pagina non è in fase di scaricamento (evento
beforeunload). Durante l’unload, richieste come l’eventouser_engagementignorano il Service Worker.
- Il browser non si trova in un ambiente limitato (ad esempio WebView, Google App su iOS, o i browser in-app di Facebook e Messenger).
- 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"))
- Il Service Worker è attivo e pronto (stato
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.
2. Service Worker loaded from googletagmanager.com domain
Questo Service Worker sembra gestire eventi per i prodotti Google Ads e Floodlight.
Alcune richieste passano attraverso di esso, come:
- Evento Google Ads User-Provided (richieste a
https://www.google.com/ccm/form-data/{Conversion ID}/...ehttps://www.google.com/pagead/form-data/{Conversion ID}/...) - Evento Auto-captured User-data (richieste solo a
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:
- Il tag è configurato per inviare dati utente e il parametro interno
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
- La pagina non è in fase di scaricamento (evento
beforeunload).
- Il Service Worker è attivo e pronto (stato
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.
The .delegate method
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 |
Come verificare se i Service Worker vengono utilizzati
È possibile controllare l’utilizzo dei Service Worker in diversi modi.
1. Scheda Network di DevTools
Filtri le richieste verso sw.js o sw_iframe.html.
Nota:
sw.js appare solo durante la registrazione iniziale. Non comparirà al successivo caricamento della pagina (a meno che non si deregistri manualmente il Service Worker).
Service Worker caricato dal dominio first-party del sGTM.
Service Worker caricato dal dominio googletagmanager.com.
2. Scheda Application di DevTools
Apra DevTools → vada alla scheda Applicazione → Service Worker → faccia clic su “Visualizza tutte le registrazioni” e cerchi il suo dominio.
- Se utilizza GA4 per inviare dati a sGTM: vedrà il Service Worker servito dal dominio first-party del suo sGTM.
Se utilizza prodotti Ads di Google: vedrà il Service Worker servito da googletagmanager.com.
3. Scheda Network di DevTools
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.
Perché alcuni eventi non compaiono nella scheda Network
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.
- 1.Segua i passaggi descritti qui sopra.
- 2.Dopo aver individuato il Service Worker desiderato, faccia clic su Ispeziona per aprire la sua finestra DevTools dedicata.
- 3.Acceda alla scheda Network del Service Worker, dove appariranno le richieste GA4 o Ads mancanti.
È 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.
Conclusione
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:
- Non presupporre che gli hit mancanti nella scheda Network indichino problemi di tracciamento.
- Controllare l’attività dei Service Worker prima di procedere alla risoluzione dei problemi.
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.
Per configurazioni o problemi di debug più complessi, puoi rivolgerti a un consulente Google Tag Manager.
Vuoi passare al lato server?
Prova gratis
Commenti