Seguimiento server-side de GA4 a través de la capa de redirección

El etiquetado del lado del cliente de GA4 vía gtag.js o GTM es la base de atribución a la que la mayoría de los equipos recurren por defecto. Funciona bien en condiciones ideales: un usuario de Chrome de escritorio en una conexión rápida, sin bloqueador de anuncios, una sesión de Safari que no ha activado el tope de cookies de 24 horas establecidas por scripts del ITP. Las condiciones ideales cubren quizás el 65-75% del tráfico de la UE en 2026.

El resto de él - usuarios de uBlock Origin, el bloqueo integrado de Brave, la Intelligent Tracking Prevention de Safari en iOS, la creciente cohorte de bloqueadores a nivel de red como NextDNS y Pi-hole - envía eventos que o se pierden antes de llegar a www.google-analytics.com o llegan sin un identificador de cliente usable porque la cookie _ga fue eliminada. La brecha típica en audiencias de gran peso UE es del 25-35% de eventos de conversión. Para algunas industrias - fintech, herramientas de privacidad, herramientas para desarrolladores - es mayor porque la demografía del usuario se correlaciona con la adopción de bloqueadores de anuncios.

El Measurement Protocol de GA4 es el camino server-side que esquiva todo eso. Tu servidor habla con el endpoint de recopilación de Google directamente. El estado del navegador es irrelevante. Este artículo cubre la configuración exacta: credenciales, forma del payload, unión del client_id, validación y el patrón de deduplicación para equipos que ejecutan gtag junto al camino server-side.

La arquitectura subyacente de reenvío de conversiones - por qué gana el server-side y cómo funciona el fan-out a múltiples plataformas - se cubre en la visión general del seguimiento de conversiones server-side. La versión Meta CAPI de este tutorial está en reenviando conversiones a Meta CAPI; el patrón de configuración tiene la misma forma, con parámetros específicos de GA4 aquí.

TL;DR#

• gtag.js de GA4 pierde 25-35% de eventos de conversión en tráfico típico UE por bloqueadores de anuncios (uBlock, Brave) e ITP (topes de vida de cookies de Safari); Measurement Protocol esquiva todo eso porque la petición se origina en tu servidor.
• Necesitas dos credenciales: el Measurement ID (G-XXXXXXXX) de tu flujo de datos, y un API secret generado en Admin → Flujos de datos → API secrets de Measurement Protocol. Ambos se pegan en la configuración del workspace de Elido en menos de dos minutos.
• El client_id es lo que vincula un evento server-side de vuelta a una sesión GA4; Elido establece una cookie UUID de primera parte en la redirección del enlace corto y la incluye en cada reenvío de conversión, por lo que no tienes que leer la cookie _ga del navegador.
• La validación lleva unos diez minutos: el DebugView de GA4 muestra eventos de Measurement Protocol llegando en unos diez segundos; los informes estándar se rellenan retroactivamente en 24-48 horas.

Las dos credenciales que necesitas#

El Measurement Protocol de GA4 requiere dos piezas de información, ambas de la consola de Admin de GA4.

Measurement ID. El identificador del flujo de datos, formateado como G-XXXXXXXX. Encuéntralo en Admin → Flujos de datos → tu flujo web → el panel de detalles del flujo. Este es el mismo ID que pasas a gtag('config', 'G-XXXXXXXX') en tu configuración del lado del cliente - no es un secreto; aparece en el código fuente de tu página.

API secret. Esta es la credencial que autoriza las escrituras server-side al endpoint de recopilación. Navega a Admin → Flujos de datos → tu flujo web → API secrets de Measurement Protocol → Crear. El secreto es una cadena alfanumérica corta. Trátalo como una clave de cuenta de servicio: almacénalo como un secreto del workspace, rótalo con otras credenciales de servicio, no lo subas al código fuente.

En Elido, estos se pegan en Configuración del Workspace bajo Integraciones → GA4. Una vez guardado, Elido valida el par contra el endpoint de depuración de GA4 y confirma la conectividad. La validación es inmediata; un 4xx en este paso significa que el Measurement ID o el API secret están mal.

La forma del evento#

La referencia del Measurement Protocol de GA4 (consultada el 2026-05-12) especifica el formato de la petición. El endpoint es:

POST https://www.google-analytics.com/mp/collect?measurement_id=G-XXXXXXXX&api_secret=<secret>

El cuerpo lleva un client_id, un user_id opcional y un array events. Aquí está el payload para un evento de compra:

{
  "client_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "user_id": "user-shop-12847",
  "events": [
    {
      "name": "purchase",
      "params": {
        "transaction_id": "ord_98231",
        "value": 89.5,
        "currency": "EUR",
        "engagement_time_msec": 1,
        "items": [
          {
            "item_id": "sku-spring-jeans-32-blue",
            "item_name": "Spring Jeans 32 Blue",
            "quantity": 1,
            "price": 89.5
          }
        ]
      }
    }
  ]
}

Algunas cosas en este payload que es fácil equivocar:

event_name debe estar en snake_case en minúsculas. La referencia de eventos de GA4 (consultada el 2026-05-12) lista los nombres de eventos recomendados: purchase, sign_up, generate_lead, add_to_cart. Enviar Purchase (P mayúscula) producirá un evento separado en los informes de GA4 en lugar de fusionarse con tus eventos purchase disparados por gtag. La plataforma no te avisa; el evento simplemente aterriza como un evento personalizado con un nombre extraño.

engagement_time_msec debe estar presente y establecido a un entero positivo. Sin él, GA4 cuenta el evento pero no acredita la implicación de la sesión, y algunos modelos de atribución excluyen eventos sin tiempo de implicación. Establecer 1 es suficiente para satisfacer el requisito.

event_params está limitado a 25 parámetros por evento. El Measurement Protocol rechazará payloads que excedan este límite. El rechazo es silencioso por defecto - la petición devuelve 204 sin cuerpo independientemente de si el evento fue aceptado. Usa el endpoint de depuración (cubierto en la sección de validación) para detectar desbordes.

user_id es opcional pero valioso. Si tienes un identificador de usuario persistente del lado del servidor - un ID de cliente en tu tabla de pedidos, un ID de suscriptor en tu CRM - envíalo. GA4 lo usa para atribución entre dispositivos, y mejora la coincidencia entre eventos server-side y del lado del cliente.

Unión de client_id: por qué importa y cómo lo maneja Elido#

El client_id es el campo que GA4 usa para vincular un evento server-side a una sesión del navegador. Cuando gtag.js se ejecuta en una página, lee la cookie _ga y usa su UUID como client_id para todos los eventos que dispara. Si tu evento server-side lleva el mismo client_id, GA4 puede unir esos eventos en el mismo recorrido de usuario y sesión.

El reto es conseguir ese UUID en el lado del servidor. La cookie _ga es una cookie de primera parte en tu dominio, por lo que tu servidor puede leerla en el momento del checkout e incluirla en el payload de conversión. Pero esto solo funciona si el navegador del usuario tiene _ga establecida, que es exactamente la población que pierdes por ITP y bloqueadores de anuncios.

Elido resuelve esto en la capa de redirección. Cuando un usuario hace clic en un enlace corto, el manejador de borde de Elido genera un UUID y lo establece como una cookie _elido_cid de primera parte en la respuesta de redirección - antes de que el usuario llegue a tu sitio. El UUID también se añade a la URL de destino como ?elido_click=<uuid> (configurable por workspace). El flujo:

Tu landing page o gestor de etiquetas lee elido_click de la URL y lo escribe en los atributos personalizados del pedido. En el momento de la conversión, tu webhook de pedido lleva el UUID. Elido lo busca, construye el payload del Measurement Protocol con client_id establecido a ese UUID, y reenvía a GA4.

Esto es más fiable que leer _ga del navegador porque el UUID se captura en el momento del clic, antes de que la sesión del navegador del usuario determine si las cookies son aceptadas. Incluso si ITP elimina la cookie _ga en 24 horas, la cookie _elido_cid de Elido persiste como una cookie de primera parte bajo tu dominio de enlace corto - y el atributo del pedido persiste en tu base de datos independientemente.

La guía de envío de eventos de GA4 (consultada el 2026-05-12) describe cómo funciona client_id a través de los caminos cliente y servidor.

Elido reenvía: el curl real#

Cuando POST /v1/conversions llega con un click_id, Elido ensambla el payload del Measurement Protocol y lo reenvía. Para llamar al endpoint directamente - esquivando Elido y probando el lado MP de GA4 del cableado - el curl es:

curl -X POST \
  "https://www.google-analytics.com/mp/collect?measurement_id=G-XXXXXXXX&api_secret=YOUR_SECRET" \
  -H "Content-Type: application/json" \
  -d '{
    "client_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
    "user_id": "user-shop-12847",
    "events": [
      {
        "name": "purchase",
        "params": {
          "transaction_id": "ord_98231",
          "value": 89.50,
          "currency": "EUR",
          "engagement_time_msec": 1
        }
      }
    ]
  }'

GA4 devuelve 204 tanto para eventos válidos como inválidos. No puedes distinguir un evento mal formado de una ingesta exitosa solo por el código de estado HTTP. Para ver si el evento realmente aterrizó, usa el endpoint de depuración durante el desarrollo:

POST https://www.google-analytics.com/debug/mp/collect?measurement_id=G-XXXXXXXX&api_secret=YOUR_SECRET

El endpoint de depuración devuelve un cuerpo JSON que lista errores de validación para cada evento. Un evento con un nombre de parámetro incorrecto, un payload que excede los 25 parámetros o un client_id mal formado aparecerá aquí.

Al usar Elido, la misma visibilidad de validación está disponible vía GET /v1/conversions/{id} - el registro de conversión muestra el estado del reenvío a GA4 y cualquier respuesta de error del endpoint de depuración durante el modo de prueba.

Validación: DebugView#

El DebugView de GA4 es el bucle de retroalimentación más rápido durante la configuración. Para activarlo para eventos server-side, añade "debug_mode": 1 al objeto params del evento. Los eventos con esta bandera aparecen en DebugView en aproximadamente diez segundos; no cuentan para los datos de informes de producción.

En DebugView (Admin de GA4 → DebugView), cada evento muestra su nombre, los parámetros que llevaba, y si se rechazaron parámetros. La vista agrupa eventos por client_id, por lo que puedes rastrear la sesión completa desde el clic hasta la conversión.

Qué verificar antes de eliminar debug_mode:

• El nombre del evento aparece exactamente como se espera en el flujo de eventos de DebugView (purchase, no Purchase o ecommerce_purchase).
• El parámetro transaction_id es visible y coincide con el formato de tu ID de pedido.
• El client_id es una cadena en formato UUID - no vacía, no una cadena de respaldo "unknown".
• La currency es el código ISO 4217 correcto (EUR, no eur, no Euro).

Los informes estándar de GA4 tardan 24-48 horas en reflejar los datos de conversión server-side. No evalúes la precisión de los informes en el día uno. DebugView confirma la forma del evento; los informes confirman atribución y totales.

Errores comunes#

client_id faltante. Los eventos sin un client_id son descartados silenciosamente por Measurement Protocol. Este es el modo de fallo único más común. La pérdida es invisible - la petición devuelve 204, DebugView no muestra nada, la conversión nunca aparece. Verifica que el campo client_id siempre esté poblado antes de que la petición se dispare. En la configuración de Elido, un client_id faltante significa que el parámetro elido_click no fue escrito en el pedido en el momento de la conversión - comprueba la etiqueta de la landing page o el manejador del webhook.

Formato de nombre de evento incorrecto. Purchase crea un evento personalizado llamado Purchase junto a cualquier evento purchase existente de gtag. Tu conteo total de compras en los informes de GA4 se divide en dos nombres de eventos. El arreglo es hacer cumplir snake_case en minúsculas en todos los nombres de eventos enviados al endpoint del Measurement Protocol. La referencia de eventos de GA4 (enlazada arriba) lista los nombres canónicos para eventos de ecommerce.

Exceder 25 event_params. El Measurement Protocol rechaza silenciosamente payloads con más de 25 parámetros por evento. Los equipos que reenvían metadatos completos de pedidos (todos los artículos de línea, todos los atributos personalizados) a menudo alcanzan este límite sin darse cuenta. Usa el endpoint de depuración para detectar desbordes en desarrollo. En producción, elimina los parámetros no esenciales y mantén los payloads de eventos ligeros.

Moneda procedente de la configuración de página, no del pedido. Si tu configuración de gtag tiene como predeterminado USD pero tus pedidos están en EUR, el evento server-side y el evento del lado del cliente llevan diferentes valores de moneda. GA4 los registra bajo el mismo nombre de evento pero no puede agregar los valores. Toma la moneda del registro del pedido en tu backend, no de una configuración gtag a nivel de página.

Deduplicación con gtag del lado del cliente#

Si ejecutas gtag.js del lado del cliente y Measurement Protocol del lado del servidor simultáneamente, necesitas deduplicación. GA4 deduplica eventos usando client_id combinado con una ventana de marca de tiempo. El mecanismo es menos explícito que el campo event_id de Meta CAPI, pero el enfoque práctico es el mismo: llevar un transaction_id consistente en los eventos de compra a través de ambos caminos.

Para eventos de compra, establece transaction_id a tu ID de pedido. Tu gtag del lado del navegador dispara purchase con transaction_id: "ord_98231" cuando la página de confirmación carga; tu evento server-side del Measurement Protocol lleva el mismo transaction_id: "ord_98231". GA4 deduplica dentro de la misma ventana de sesión. Si la misma combinación client_id + transaction_id llega dos veces dentro de la ventana de deduplicación, la segunda se ignora.

Para eventos upstream - generate_lead, sign_up, add_to_cart - no hay un ID de pedido que usar. El click ID funciona aquí: establece event_id al UUID elido_click. Tanto el píxel del lado del navegador como el reenvío server-side referencian el mismo valor. Esta es la misma disciplina descrita en el tutorial de seguimiento UTM de extremo a extremo, que cubre la configuración más amplia de etiquetado de campañas que hace que este ID esté disponible a lo largo del embudo.

La ventana de deduplicación en GA4 no está documentada públicamente con la precisión que Meta publica para CAPI. En la práctica, los eventos con client_id + transaction_id coincidentes que llegan dentro de la misma ventana de sesión se deduplican. Ejecutar ambos caminos simultáneamente es la configuración más segura - proporciona cobertura de respaldo para la audiencia con alta presencia de bloqueadores de anuncios al tiempo que le da al algoritmo una señal más limpia del camino del servidor.

Dónde encaja esto en el pipeline de atribución#

Measurement Protocol cierra la brecha de señal de GA4 de la misma manera que CAPI cierra la brecha de señal de Meta. Los mecanismos son diferentes - GA4 usa client_id y transaction_id donde Meta usa event_id y claves de coincidencia - pero la arquitectura es idéntica: un evento server-side que no depende del estado del navegador.

Para el panorama completo de a qué plataformas reenviar y cómo funciona el fan-out a escala, la visión general del seguimiento de conversiones server-side cubre GA4, Meta CAPI y TikTok Events lado a lado. Para campañas donde el etiquetado UTM es el paso upstream, rastreando campañas UTM de extremo a extremo es la lectura prerrequisito.

La superficie de producto para esta configuración: funciones de seguimiento de conversiones documenta la API completa /v1/conversions, incluido el fan-out multi-plataforma, eventos de reembolso y semántica de reintentos. Soluciones para marketers muestra cómo el pipeline de conversión encaja en un flujo de trabajo de campaña junto a plantillas UTM y enrutamiento de smart links.

La configuración en sí - credenciales en la configuración del workspace, paso del gestor de etiquetas para elido_click en la landing page, fontanería del webhook de pedido - lleva medio día para la mayoría de los equipos. El paso de validación de DebugView añade otros treinta minutos. La salida son datos de conversión de GA4 que reflejan lo que tus campañas están impulsando realmente, no el 65-75% de ello que sobrevive al camino del lado del navegador.

Fuentes

• Google Analytics 4: Visión general del Measurement Protocol. developers.google.com/analytics/devguides/collection/protocol/ga4 (consultado el 2026-05-12)
• Measurement Protocol de GA4: Referencia de eventos. developers.google.com/analytics/devguides/collection/protocol/ga4/reference/events (consultado el 2026-05-12)
• Measurement Protocol de GA4: Envío de eventos. developers.google.com/analytics/devguides/collection/protocol/ga4/sending-events (consultado el 2026-05-12)