¿Tus eventos llegan correctamente a GA4? ¿Alguna vez has intentado validar eventos en GA4? Cuando trabajas con Google Analytics 4 (GA4), una de las mejores formas de comprobar que los eventos se están enviando correctamente es inspeccionar las solicitudes HTTP que se hacen desde el navegador.
Para ello, puedes usar las DevTools (herramientas de desarrollo) de Chrome o cualquier navegador moderno.
¿Cómo ver las peticiones que hace GA4?
- Abre tu sitio web y pulsa F12 o clic derecho > Inspeccionar para abrir las herramientas de desarrollo.
- Ve a la pestaña Network (o Red).
- Marca la casilla Preserve log o Mantener registro para conservar las solicitudes al cambiar de página o recargar y tener toda la secuencia.
- En el cuadro de filtro, escribe collect? para ver únicamente las peticiones de GA4.
- Te saldrá todas las peticiones de GA4 en esa página y posteriores si navegas al haber mantenido el registro.
- Si picas sobre alguna y vas a la ventana de encabezados o headers podrás ver el método de envío y estado.
- Si vas a la pestaña de Payload o Carga útil veras los parámetros asociados a la petición.
Ahora que sabemos como ver las solicitudes nos toca entender qué significan sus métodos y códigos de respuesta.
¿Qué es el Request Method o Método de solicitud?
El método de solicitud HTTP indica qué tipo de operación está realizando el navegador al comunicarse con el servidor. En el caso de GA4, lo más habitual es:
POST
- GA4 utiliza principalmente el método POST para enviar los datos de eventos al endpoint https://www.google-analytics.com/g/collect.
- POST permite incluir los datos en el cuerpo de la solicitud, lo cual es más seguro, limpio y flexible que enviarlos en la URL como en un GET. Además, permite payloads más grandes, lo que es fundamental para eventos complejos con muchos parámetros.
GET (ocasional)
- En algunos casos específicos, especialmente en implementaciones básicas o con ciertos parámetros de configuración, GA4 puede usar GET.
- Es menos común, pero no indica necesariamente un problema.
¿Qué es el Status Code?
El código de estado HTTP es la respuesta del servidor. Informa de si la solicitud se ha procesado correctamente, si hay que redirigir, o si ha fallado por algún motivo.
En GA4 te vas a encontrar principalmente con estos códigos:
302 Found
Indica que el servidor ha recibido la solicitud, la ha aceptado, y está redirigiendo temporalmente al navegador a otra ubicación. Es parte normal del funcionamiento de GA4.
Google utiliza estas redirecciones para hacer balanceo de carga, enviar las peticiones al servidor regional más cercano o aplicar lógica interna.
¿Debes preocuparte? No. Ver un POST con código 302 tras enviar un evento a /g/collect es completamente normal.
200 OK
Significa que la solicitud se ha procesado correctamente y el servidor devuelve una respuesta satisfactoria. Es menos común en GA4, pero puede aparecer en algunos entornos de prueba o en ciertos endpoints del Measurement Protocol.
¿Debes preocuparte? No. Es una respuesta válida.
204 No Content
Indica que la solicitud ha sido aceptada y procesada correctamente, pero el servidor no devuelve contenido. Puede verse al usar el Measurement Protocol directamente o en ciertos entornos de desarrollo.
¿Debes preocuparte? No, especialmente si estás en un entorno de pruebas o usando herramientas como GA Debugger.
400 Bad Request
Esto sí es un error. Significa que el servidor no ha podido interpretar la solicitud porque contiene errores: datos mal formateados, campos requeridos que faltan, IDs incorrectos, etc.
¿Debes preocuparte? Sí. Revisa el payload y asegúrate de que estás enviando los parámetros correctos:
- Measurement ID (tid o G-XXXXXXXXXX)
- Client ID (cid)
403 Forbidden
El servidor ha denegado el acceso a la solicitud. Puede deberse a problemas con el dominio de origen, configuración de cookies, uso de bloqueadores o restricciones de seguridad.
¿Debes preocuparte? Sí. Aunque no es común en GA4, si aparece de forma persistente conviene revisar la configuración del entorno.
5xx (500, 502, 503…)
Estos códigos indican errores del servidor de Google. Normalmente son puntuales, debidos a mantenimiento o sobrecarga.
¿Debes preocuparte? Solo si se repiten constantemente. Si ocurre una vez y los eventos llegan igualmente a GA4, no es un problema.
¿Cuándo debes preocuparte y cuándo no?
Puedes estar tranquilo si:
- Las solicitudes usan el método POST (o GET en casos específicos)
- El código de estado es 302, 200 o 204
- El payload incluye campos clave como «en», «tid», «cid», «sid», etc.
- Los eventos aparecen correctamente en la vista en tiempo real de GA4
- No hay errores JavaScript en consola relacionados con gtag, GTM o analytics.js
Deberías revisar si:
- El servidor devuelve códigos 400, 403 o 5xx de forma continua
- No se están enviando solicitudes a /g/collect en ningún momento
- El payload está incompleto o contiene valores incorrectos como «undefined», «null», o vacíos
- Los eventos no se reflejan en GA4 ni en tiempo real ni tras varias horas
Consejos útiles para revisar la secuencia de eventos
1. Activa «Preserve log» o Mantener registro
Marca esta opción en la pestaña Network antes de interactuar con el sitio. Así evitarás perder las solicitudes anteriores al navegar o recargar.
2. Filtra por «collect» o «collect?» este último acota más.
Esto te permite centrarte solo en las solicitudes de GA4, sin el ruido de otras llamadas de red. También puedes filtrar por «google-analytics.com» para una vista más amplia.
3. Revisa el payload de cada evento
En cada solicitud, accede a la pestaña Payload o Carga útil y comprueba los datos enviados. Es la forma más rápida de saber si los parámetros son correctos y si se está enviando lo que esperas.
Ahí podras ver todos los parámetros que describen el evento que se está registrando. A continuación te dejo algunos campos clave que puedes encontrar en el payload:
uid(User ID):
Identificador del usuario autenticado, si se ha configurado explícitamente en la implementación.cid(Client ID):
Identificador único del visitante. Este ID es persistente por usuario y lo genera GA4 automáticamente. Se guarda típicamente en una cookie (_ga).en(Event Name):
El nombre del evento que se ha activado, por ejemplo:page_view,click,scroll,purchase, etc.tid(Measurement ID):
El ID de medición de tu propiedad GA4, con formatoG-XXXXXXXXXX.sid(Session ID):
ID de sesión actual, usado para agrupar eventos dentro de la misma visita.
Y muchos otros que te invito a explorar.
4. Verifica los Headers
Revisa que el Content-Type sea correcto y que no haya headers problemáticos que puedan causar bloqueos.
5. Usa el DebugView de GA4
Combina la inspección de Network con el DebugView de GA4 para tener una visión completa del flujo de datos.
En resumidas cuentas
GA4 puede parecer opaco al principio, pero si sabes leer lo que ocurre en la pestaña Network, tienes un control total sobre lo que está ocurriendo en tu implementación. A mi personalmente me ha ayudado a detectar errores más allá de la vista previa de Google Tag Manager.
- Ver un POST con código 302 es completamente normal y forma parte del comportamiento esperado
- En cambio, ver un 400, 403 o no ver solicitudes en absoluto sí debe activar tus alarmas
Con un poco de observación y la opción Preserve log activada, puedes entender la secuencia completa de eventos, identificar problemas y validar tu configuración sin esperar a que aparezcan los datos en los informes.
Tip adicional: Si trabajas frecuentemente con GA4, considera usar Analytics Debugger de David Vallejo que puede complementar perfectamente esta inspección manual en las DevTools.
Gracias por leerlo hasta el final 😉
Kiko Luque
Ingeniero en Informática y apasionado del mundo de la medición, la analítica y el CRO.