Guía de tracking de eventos en GA4

Implementar tracking en GA4 sin un measurement plan produce datos que parecen completos, pero no son fiables. Los eventos disparan, los dashboards muestran números y, aun así, la organización sigue sin saber lo que realmente necesita porque nadie definió de antemano qué preguntas debía poder responder la analítica.

GA4 es un sistema orientado a eventos, no a sesiones como Universal Analytics. Esa flexibilidad amplía el espacio de diseño, pero también hace mucho más importante la taxonomía. Si nombres, parámetros y propósito de los eventos no se gobiernan desde el principio, en pocos meses la propiedad se llena de señales inconsistentes y casi imposibles de recuperar sin reimplementación.

Diseño de una taxonomía de eventos en GA4

Una taxonomía de eventos en GA4 define el conjunto completo de eventos que debería disparar una propiedad, qué significa cada uno, qué parámetros lleva y qué pregunta de negocio responde. Sin esa definición, cada desarrollador nombra eventos a su manera, los parámetros aparecen de forma oportunista y el esquema cambia en silencio con el tiempo.

GA4 organiza su modelo en cuatro categorías. Automatically collected events, como session_start, first_visit y user_engagement. Enhanced measurement events, como scroll, outbound click, site search, video engagement y file download. Recommended events, donde Google fija nombres y parámetros para verticales concretos. Y custom events, creados para interacciones específicas del negocio que no encajan en las otras categorías.

La regla de diseño es simple: usar recommended event names siempre que la interacción encaje, porque desbloquean reporting nativo en GA4 y una alineación más limpia con BigQuery. Solo conviene apartarse de ese modelo cuando la interacción realmente no encaja y la desviación queda documentada.

Para cada evento conviene documentar nombre, condición exacta de disparo, parámetros con tipos y ejemplos, pregunta de negocio a la que responde y equipo responsable de la definición.

Custom dimensions y modelo de datos

Los parámetros de un evento no aparecen automáticamente en los informes de GA4. Un parámetro enviado con todos los eventos sigue siendo invisible en los reportes estándar hasta que se registra como custom dimension. Este es un punto de confusión muy común en migraciones desde Universal Analytics.

GA4 distingue entre dimensiones event-scoped y user-scoped. Las primeras describen valores propios de un evento concreto. Las segundas describen al usuario a lo largo de su historial de sesiones, por ejemplo un subscription_tier.

Las propiedades gratuitas de GA4 tienen límites relativamente bajos para custom dimensions. Por eso el measurement plan debería incluir un presupuesto deliberado de qué parámetros merece la pena registrar, de modo que las prioridades altas no queden bloqueadas por decisiones marginales.

Server-side tagging: cuándo se vuelve necesario y cómo cambia la arquitectura

El client-side tagging de GA4, normalmente a través de Google Tag Manager en navegador, sigue siendo el modelo por defecto para la mayoría de propiedades. El server-side tagging introduce una arquitectura distinta: un tagging server recibe eventos del navegador, los procesa y los reenvía a GA4 y a otros destinos.

El server-side tagging empieza a tener sentido cuando los requisitos de first-party data y cumplimiento hacen inaceptable el tracking puramente en cliente, cuando los ad blockers recortan la recogida de datos de manera material, cuando la resolución de identidad cross-domain o cross-device debe controlarse en servidor o cuando hace falta enriquecer eventos antes de enviarlos a GA4.

Ese cambio arquitectónico añade coste e impacto operativo. Requiere infraestructura, despliegue y mantenimiento continuado. Por eso conviene evaluar explícitamente si la mejora de calidad de datos justifica el overhead en la escala actual de la propiedad.

Consent mode, modelos de atribución e integración con BigQuery

Consent Mode V2 conecta GA4 y Google Ads con la señal de consentimiento de la plataforma de gestión de consentimiento del sitio. Cuando un usuario rechaza analytics consent, GA4 deja de disparar eventos para esa sesión y, si el modelado está activo, utiliza behavioural modelling para estimar el comportamiento faltante. Una configuración incompleta puede generar pérdida de personalización publicitaria y exposición de cumplimiento en propiedades afectadas.

GA4 utiliza data-driven attribution por defecto, pero ese modelo necesita suficiente volumen de conversiones para estabilizarse. Por debajo del umbral operativo, la propiedad cae a last-click. Si no se define esto con claridad, el equipo acaba aceptando un fallback sin entender sus implicaciones.

La exportación a BigQuery entrega el dato a nivel de evento con todos sus parámetros y evita el sampling típico de la interfaz estándar. Para cohortes, funnels, análisis multitoque o unión con CRM y revenue data, BigQuery es una pieza central, no un lujo.

La práctica de crecimiento y analítica de Logic Grid Studio cubre measurement plan, implementación, consent mode y BigQuery como un proyecto estructurado. No es un servicio de colocar etiquetas, sino de construir una base de medición confiable.