Depuración de GA4 Measurement Protocol: por qué 2xx no demuestra nada

GA4 Measurement Protocol devuelve un estado 2xx para casi cualquier cosa que le envíes: un evento válido, un evento con un nombre mal escrito, un evento sin client_id, un secreto inventado. Por eso, el código de estado no sirve para depurar. Para depurar llamadas de GA4 Measurement Protocol, envía el mismo cuerpo al servidor de validación en /debug/mp/collect, lee los validationMessages que devuelve, corrige lo que indique y solo entonces confirma que llega a DebugView o Realtime.

Ese último paso importa más de lo que la gente espera. ¿Por qué? El servidor de validación no comprueba tu secreto de API, así que una carga útil puede pasar la validación, recibir un 204 del endpoint real y aun así no llegar nunca a tu propiedad. He visto a un equipo perder una semana exactamente por eso antes de que a alguien se le ocurriera copiar el secreto otra vez.

Si estás conectando eventos del lado del servidor para hacer seguimiento de campañas, la guía fundamental sobre seguimiento integral de UTM explica qué debe incluir el enlace antes de todo esto. Esta publicación trata sobre el momento en que envías el evento y no aparece nada.

Por qué Measurement Protocol responde 2xx a todo

La referencia del protocolo de Google es clara al respecto: el endpoint devuelve un código de estado 2xx si recibe la solicitud HTTP y no devuelve un error si la carga útil está mal formada o los datos no se procesan. La recopilación funciona en modo "enviar y olvidar" (fire-and-forget). Tu servidor nunca espera al procesamiento.

Lo comprobamos nosotros mismos. Un POST a /mp/collect con el cuerpo {"garbage":true}, un ID de medición falso y un secreto inventado devolvió HTTP 204 con un cuerpo vacío. Igual que un evento perfecto.

La lógica de reintento basada en códigos de estado detecta fallos de red. Nada más. No puede decirte que GA4 descartó tus eventos. Para eso necesitas el segundo endpoint.

Cómo usar el servidor de validación en /debug/mp/collect

El servidor de validación de Measurement Protocol está en el mismo host. Misma cadena de consulta, mismo cuerpo:

curl -s -X POST \
  "https://www.google-analytics.com/debug/mp/collect?measurement_id=G-XXXXXXXXXX&api_secret=YOUR_SECRET" \
  -H "Content-Type: application/json" \
  -d '{"events":[{"name":"session_start","params":{"firebase_x":1}}]}'

Responde con 200 y un cuerpo JSON en lugar de uno vacío. Esa carga útil de prueba tiene tres problemas, y el servidor informa el primero que encuentra:

{
  "validationMessages": [
    {
      "fieldPath": "client_id",
      "description": "Measurement requires a client_id.",
      "validationCode": "VALUE_REQUIRED"
    }
  ]
}

Añade un client_id y pasará a NAME_RESERVED para session_start; cambia el nombre del evento y el siguiente será el prefijo firebase_. Cada mensaje incluye un fieldPath, una descripción para personas y un código. Los códigos que documenta Google incluyen VALUE_INVALID, VALUE_REQUIRED, NAME_INVALID, NAME_RESERVED, VALUE_OUT_OF_BOUNDS, EXCEEDED_MAX_ENTITIES y NAME_DUPLICATED.

Un arreglo vacío, "validationMessages": [ ], significa que la estructura está bien. No se almacena nada de lo enviado a /debug/mp/collect. Úsalo tanto como quieras durante el desarrollo; recuerda únicamente que una llamada de depuración nunca prueba que los datos hayan llegado.

Lo que el servidor de validación no comprueba

La mayoría de los tutoriales omiten esta parte. La página de validación de eventos de Google afirma claramente que el servidor de validación no valida el api_secret. En nuestra prueba del 22 de septiembre de 2026 tampoco comprobó el ID de medición: G-FAKE123 con el secreto nonsense devolvió un arreglo validationMessages vacío.

Un secreto incorrecto pasa. También uno revocado, uno de otra fuente de datos o un error tipográfico en G-. El api_secret de Measurement Protocol es la razón más común que veo para "carga útil válida, sin datos", y solo puedes confirmarlo viendo que llega un evento.

La segunda carencia es el modo de validación. De forma predeterminada, el servidor se ejecuta en modo RELAXED, y en ese modo permitió dos cosas que los propios límites de Google prohíben: un evento con 26 parámetros y un valor de parámetro de 120 caracteres. Añade "validation_behavior": "ENFORCE_RECOMMENDATIONS" al cuerpo de depuración y ambos fallarán, con EXCEEDED_MAX_ENTITIES y VALUE_TOO_LONG. Siempre validaría en modo estricto, aunque producción siga en modo relajado. Es la diferencia entre un verificador y un sello de aprobación automático.

Ver eventos de servidor en GA4 DebugView y Realtime

Una vez que la carga útil se valida, envíala al endpoint real y observa cómo llega. Hay dos vistas que sirven para eventos de servidor, y los informes estándar no son una de ellas, ya que pueden tener un retraso de 24 a 48 horas.

DebugView necesita una activación por evento. La guía de verificación de Google solicita "debug_mode": 1 (o true) en los parámetros del evento, además de un engagement_time_msec positivo. Solo aparecen los eventos que llevan la marca, por lo que un lote donde a un evento le falta parecerá medio vacío. Abre Administrar, luego DebugView, y espera un minuto.

Realtime no necesita nada adicional. Desplázate hasta la tarjeta "Recuento de eventos por nombre del evento" y busca tu evento. Google señala que session_id y engagement_time_msec son importantes para que la actividad del usuario aparezca en Realtime, así que si un evento se valida pero Realtime permanece vacío, comprueba primero esos dos valores.

Una advertencia más de la misma guía: para fuentes web, indica que un evento válido usa un client_id que gtag.js ya ha utilizado. Los ID sintéticos siguen contabilizándose, cada uno como su propio usuario, pero nunca se unen a una sesión del navegador y, en un informe basado en sesiones, eso aparece como una larga cola de usuarios de un solo evento que no puedes explicar hasta saber de dónde vienen. Más información en la siguiente sección. Si faltan datos de campaña en lugar de eventos, los parámetros UTM no aparecen en GA4 explica el lado de DebugView de ese problema.

Errores comunes de carga útil y lo que dice el validador

La mayoría de los eventos defectuosos corresponden a unos pocos patrones. Estos son los resultados que devolvió el servidor de validación cuando enviamos cada uno el 22 de septiembre de 2026:

Dos filas merecen un comentario. El prefijo ga_ está reservado según la referencia, pero el validador aceptó ga_session_id en ambos modos cuando lo probamos, así que no tomes un arreglo vacío como autorización. Y el límite de 100 caracteres para valores suele afectar a las URL de destino completas: una página de destino con cinco etiquetas UTM suele ser más larga.

El propio client_id es el punto sutil. Cualquier cadena pasa la validación relajada, pero el modo estricto rechazó tanto c1 como elido-12-4711 con "It should be in . format". Si tus eventos deben vincularse a sesiones del navegador, envía el valor real de _ga; la guía de seguimiento de GA4 del lado del servidor explica esa vinculación en detalle.

Cómo lo aplican el reenviador de GA4 de Elido y el botón Probar conexión

Elido reenvía los clics de enlaces cortos a GA4 del lado del servidor. Pegas un ID de medición y un secreto de API de Measurement Protocol en la tarjeta de GA4 dentro de Integraciones, y desde entonces cada clic en ese espacio de trabajo se convierte en un evento link_click:

{
  "client_id": "elido-12-4711",
  "events": [
    {
      "name": "link_click",
      "params": {
        "workspace_id": 12,
        "link_id": 4711,
        "slug": "spring-26",
        "country": "DE",
        "device": "mobile",
        "destination": "https://shop.example/spring?utm_source=newsletter",
        "engagement_time_msec": 100
      }
    }
  ]
}

El client_id es elido-<workspace>-<link>, así que cada clic en un enlace se interpreta como el mismo usuario de GA4 y ninguno se une a una sesión del navegador. Es la contrapartida honesta de hacerlo sin una cookie: los totales y los desgloses por slug, país y dispositivo funcionan; los recuentos de usuarios y los embudos de sesión no. País y dispositivo son parámetros de evento simples. Regístralos primero como dimensiones personalizadas. Además, un destination de más de 100 caracteres se topa con el límite de la tabla anterior, así que construye tus informes con slug o link_id en su lugar.

El botón Probar conexión sigue el orden que recomienda este artículo:

Primero envía un link_click sintético, marcado con elido_test: true, a /debug/mp/collect. Si validationMessages no está vacío, la prueba falla y muestra literalmente las descripciones de Google. Si el arreglo está vacío, el mismo evento se envía de verdad a /mp/collect. Debajo del botón ves la respuesta del proveedor (estado HTTP, el endpoint de depuración con tu ID de medición pero nunca el secreto y el cuerpo de Google), además de una nota que indica que Measurement Protocol no verifica el secreto de API.

Así que verde significa "válido y Google lo recibió". No significa "tu propiedad lo tiene". El evento de prueba lleva debug_mode: 1 y elido_test: true, así que aparece en DebugView como link_click; Realtime también funciona. Si quieres eventos de clic en GA4 sin una etiqueta en cada página de destino, crea un espacio de trabajo y apunta primero la tarjeta de GA4 a una propiedad de prueba.

Un orden eficaz para depurar GA4 Measurement Protocol

Cuando los eventos de GA4 no aparezcan, sigue este orden y detente en el primer fallo:

1. Envía el cuerpo a /debug/mp/collect con validation_behavior establecido en ENFORCE_RECOMMENDATIONS. Corrige cada mensaje.
2. Copia otra vez el secreto de API desde Administrar, Fuentes de datos, tu fuente web, secretos de API de Measurement Protocol. Comprueba que procede de la misma fuente que el ID G-.
3. Envía un evento a /mp/collect con debug_mode: 1 y observa DebugView durante dos minutos.
4. Quita la marca y comprueba Realtime; después, da a los informes estándar uno o dos días.

El paso 2 es donde termina la mayor parte de mis propias depuraciones. La página de solución de problemas de Google comienza con las mismas tres preguntas: secreto correcto, todavía válido, copiado exactamente. Cuando por fin fluyen los números y aun así no coinciden con los recuentos de tus enlaces, clics de enlaces cortos frente a sesiones de GA4 explica la diferencia, y seguimiento de conversiones del lado del servidor cubre los eventos de conversión que suelen venir después. El mismo hábito de validar y luego verificar se aplica a los demás destinos de la página de seguimiento de conversiones.

Relacionado en el blog

• Seguimiento de GA4 del lado del servidor mediante redirecciones - credenciales, estructura de la carga útil y vinculación de client_id.
• Mixpanel frente a GA4 para analítica de enlaces - qué herramienta debe conservar tus datos de clics.
• Seguimiento de enlaces de Mixpanel - el mismo reenviador dirigido a Mixpanel, con su propia particularidad de devolver 200 para cualquier cosa.
• Los parámetros UTM no aparecen en GA4 - la versión de este problema de depuración centrada en datos de campaña.
• Seguimiento de conversiones del lado del servidor - GA4, Meta CAPI y TikTok en paralelo.