Cómo GTM y gtag usan Service Workers para Analytics
En septiembre de 2024, Google introdujo el uso de Service Workers en Google Tag Manager (GTM) para mejorar el rendimiento y la fiabilidad de la medición:
| “Google Tag Manager puede usar un Service Worker para mejorar el rendimiento y la fiabilidad de la medición. Para asegurarse de que el Service Worker se carga correctamente, consulte las directrices de Content Security Policy.” |
Después, en marzo de 2025, Google anunció una ampliación de esta función:
| “Google tag ahora usa Service Workers, cuando están disponibles, para enviar datos a Tag Manager del lado del servidor, lo que mejora el rendimiento y la fiabilidad de la medición.” |
Este artículo explica cómo GTM y gtag gestionan Service Workers, qué es un Service Worker, cómo se produce la comunicación entre ellos y por qué sus solicitudes de Analytics pueden no aparecer en la pestaña Network de DevTools.
Qué son los Service Workers
Los Service Workers son scripts en segundo plano que se ejecutan por separado del hilo principal de un sitio web. Permiten operaciones como caché, soporte offline y solicitudes de red en segundo plano, sin bloquear la interfaz de usuario.
En el contexto de GTM y gtag, los Service Workers se usan para mover fuera de la página web la tarea de enviar datos de medición, por ejemplo hits de GA4 o Ads. Esto hace que el seguimiento sea más rápido y fiable, incluso durante eventos de descarga de página o en redes lentas. En este contexto, no almacenan los eventos para enviarlos más tarde.
Cómo GTM y gtag usan Service Workers
Se pueden registrar dos tipos de Service Workers, según su configuración:
1. Service Worker desde su dominio first-party de server-side GTM (sGTM)
Se usa para solicitudes de GA4 enviadas a contenedores del lado del servidor.
2. Service Worker desde el dominio googletagmanager.com
Lo usan sobre todo los productos de Ads, como Google Ads y Floodlight, para solicitudes de form-data y user-data.
Ambas versiones siguen un modelo de comunicación parecido, con varias entidades del navegador.
Flujo de comunicación
Cuando gtag o GTM se ejecuta, crea un iframe invisible (src=”about:blank”). Este iframe carga otro iframe, sw_iframe.html. El segundo iframe se encarga de instalar el script del Service Worker (sw.js).
Estos elementos se comunican mediante la API postMessage() del navegador para enviar información y el message listener para recibirla. El flujo queda así:
gtag/GTM ↔ iframe (about:blank) ↔ iframe (sw_iframe.html) ↔ sw.js (Service Worker)Este puente permite que gtag o GTM, ejecutado en la página principal, pase datos de eventos al Service Worker. Después, el Service Worker decide cómo y cuándo enviarlos.
Si inspecciona la página del sitio con la pestaña Elements de DevTools, verá los iframes.
Demostración real de los mensajes intercambiados entre el iframe y el Service Worker:
- Service Worker desde el dominio first-party de server-side GTM (sGTM).
- Service Worker desde el dominio
googletagmanager.com.
1. Service Worker cargado desde el dominio first-party de sGTM
Este Service Worker se usa para solicitudes de GA4 que se envían a un contenedor server-side GTM.
El script de GA4 gtag (G-{Measurement ID}, etc.) se encarga de reenviar los eventos al Service Worker.
Comprueba si un evento debe enviarse mediante el Service Worker según varias condiciones:
- El evento no se envía directamente a
analytics.google.com/g/collectowww.google-analytics.com/g/collect, por ejemplo con el parámetroserver_container_urlconfigurado. - La página no se está descargando, es decir, no está en el evento
beforeunload. Durante la descarga, solicitudes como el eventouser_engagementno pasan por el Service Worker. - El navegador no está en un entorno restringido, como WebView, Google App en iOS o los navegadores integrados de Facebook y Messenger.
- Más concretamente, comprueba que el Browser User Agent NO contenga ninguna de estas cadenas: "; wv" O "FBAN" O "FBAV" O (("GSA" O "GoogleApp") Y ("iPhone" O "iPad")).
- El Service Worker está activo y listo, con estado
2.
- Esta comprobación la realiza el método .delegate(), que se puede ver aquí.
Si se cumplen todas las condiciones, el evento se envía mediante el Service Worker. Si no, se envía directamente desde la página principal usando fetch, XHR, sendBeacon o Image, en ese orden.
Además, si se cumplen las dos primeras condiciones, se añade el parámetro richsstsse a la URL del evento. Este parámetro permite que el navegador procese la respuesta, por ejemplo para enviar solicitudes indicadas por sGTM para la sincronización de cookies de terceros.
2. Service Worker cargado desde el dominio googletagmanager.com
Este Service Worker parece gestionar eventos de productos de Google Ads y Floodlight.
Algunas solicitudes pasan por él, por ejemplo:
- Google Ads User-Provided Event, con solicitudes a
https://www.google.com/ccm/form-data/{Conversion ID}/...yhttps://www.google.com/pagead/form-data/{Conversion ID}/.... - Auto-captured User-data Event, con solicitudes solo a
https://www.google.com/ccm/form-data/{Conversion ID}/....
El script gtag del producto Ads cargado en la página, por ejemplo AW-{Conversion ID} o DC-{Floodlight Config ID}, se encarga de reenviar los eventos al Service Worker.
Las condiciones para usar este Service Worker son parecidas:
- El tag está configurado para enviar datos de usuario y el parámetro interno
send_user_data_hittiene uno de estos valores:
- user_data_web: usado por Auto-captured User-data Event.
- user_data_lead: usado por Google Ads User-Provided Event.
- La página no se está descargando, es decir, no está en el evento
beforeunload. - El Service Worker está activo y listo, con estado
2.
Esta comprobación la realiza el método .delegate(), que se puede ver aquí.
Si alguna de estas condiciones no se cumple, el hit se envía desde la página principal como de costumbre.
El método .delegate
Tanto gtag como GTM incluyen un método llamado .delegate, que realiza la comprobación final antes de decidir si el evento se envía mediante un Service Worker o desde la página principal.
La lógica es clara:
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.
};
Cuando el state es 2, la solicitud se envía mediante el Service Worker. En cualquier otro caso, se envía desde la página principal.
El Service Worker y la página principal intercambian mensajes heartbeat cada cierto tiempo, actualmente cada 5 segundos, para mantener actualizado este state. La variable state representa si el Service Worker está listo:
| Estado | Significado |
|---|---|
| 0 | Estado inicial durante la inicialización de la página. |
| 1 | Intento de establecer comunicación entre la página principal y el Service Worker. |
| 2 | El Service Worker está listo y el handshake con la página principal se realizó correctamente. |
| 3 | Reintento después de un error. |
| 4 | Error fatal, fallo o canal de comunicación cerrado. |
Cómo comprobar si se están usando Service Workers
Puede comprobar el uso de Service Workers de varias maneras.
1. Pestaña Network de DevTools
Filtre las solicitudes por sw.js o sw_iframe.html.
Nota:
Service Worker cargado desde el dominio first-party de sGTM.
Service Worker cargado desde el dominio googletagmanager.com.
2. Pestaña Application de DevTools
Abra DevTools → vaya a la pestaña Application → Service Workers → haga clic en See all registrations y busque su dominio.
- Si usa GA4 para enviar datos a sGTM, verá que el Service Worker se sirve desde su dominio first-party de sGTM.
Si usa cualquier producto de Ads de Google, verá que el Service Worker se sirve desde googletagmanager.com.
3. Pestaña Network de DevTools
Las solicitudes gestionadas por un Service Worker muestran un icono de engranaje junto a la URL. Representan hits enviados desde el proceso en segundo plano y no desde la página principal.
Por qué no ve algunos eventos en la pestaña Network
Si sus eventos de GA4 o Ads no aparecen en la pestaña Network de la página principal, probablemente se envían mediante el Service Worker. Aun así, aparecerán en la ventana de Google Tag Manager's preview and debug mode y podrá inspeccionarlos allí.
- Siga los pasos explicados aquí.
- Después de encontrar el Service Worker que necesita, haga clic en Inspect para abrir su propia ventana de DevTools.
- Vaya a su pestaña Network. Allí aparecerán las solicitudes de GA4 o Ads que faltaban.
Puede ver hasta dos Service Workers: uno para su dominio de sGTM y otro para el dominio de Google. Cada uno gestiona distintos tipos de eventos, como se explicó arriba.
Conclusión
La integración gradual de Service Workers por parte de Google en GTM y gtag marca un cambio hacia una forma más resistente de entregar y gestionar eventos. Al mover el envío de eventos a scripts en segundo plano, Google mejora el rendimiento, la fiabilidad y la precisión de captura de datos, sobre todo en casos límite como rebotes rápidos o conexiones inestables. A la vez, esto significa que algunas solicitudes no aparecerán en la pestaña Network tradicional.
Para especialistas en analítica digital, esto significa:
- No asuma que los hits que faltan en la pestaña Network indican problemas de seguimiento.
- Compruebe la actividad de Service Worker antes de solucionar problemas.
A medida que esta función siga cambiando, será importante entender cómo gtag y GTM usan Service Workers para depurar con precisión y mantener datos fiables.
Comentarios