Cómo crear eventos personalizados en GA4 con GTM

Un evento personalizado en GA4 es cualquier interacción que se define y se envía de forma explícita porque el modelo de medición automático no la captura: un clic en un botón concreto, el envío de un formulario, un vídeo reproducido o un paso del checkout. Google Analytics 4 funciona sobre un modelo basado en eventos, y Google Tag Manager es la capa que decide qué se mide, cuándo y con qué detalle, sin tener que reprogramar la web en cada cambio.

La diferencia entre una cuenta de analítica que informa decisiones y otra que solo acumula datos rara vez está en la herramienta: está en si los eventos se han diseñado para responder preguntas de negocio concretas o se han activado sin criterio. Esta guía recorre el flujo completo para crear eventos personalizados en GA4 con GTM —del dataLayer a la validación en DebugView— con foco en lo que casi ningún tutorial cubre: cómo estructurar los datos y nombrar los eventos para que después se puedan analizar de verdad.

Resumen

Crear eventos personalizados en GA4 con Google Tag Manager consiste en enviar la interacción a una capa de datos (dataLayer), capturarla con un activador de evento personalizado y dispararla hacia GA4 con una etiqueta de evento y sus parámetros. El éxito de la medición depende de tres palancas en paralelo: un dataLayer bien estructurado que exponga los datos como parámetros reutilizables, una nomenclatura gobernada que respete los límites de GA4 y sea consistente en todo el sitio, y una validación rigurosa en modo previsualización antes de publicar. Lo que distingue una implementación profesional no es la cantidad de eventos, sino que cada uno se traduzca en una métrica accionable y en una decisión.

Qué es un evento personalizado en GA4 con GTM y cuándo hace falta

Un evento personalizado es el que se define manualmente cuando los eventos automáticos y recomendados de GA4 no cubren una interacción relevante para el negocio. GA4 ya recoge por su cuenta páginas vistas, scroll del 90%, clics salientes o descargas mediante la medición mejorada, pero no sabe qué es «pedir cita», «descargar la ficha técnica» o «llegar al paso de pago» en una web concreta. Ahí es donde entra el evento personalizado: se declara qué interacción importa y qué información viaja con ella.

Google Tag Manager es el contenedor que orquesta ese envío sin depender del equipo de desarrollo para cada ajuste. En lugar de insertar código de seguimiento repartido por la plantilla, se centraliza la lógica en etiquetas, activadores y variables que se publican con versionado y control de cambios. Para que este sistema funcione con solidez conviene partir de tener GA4 correctamente configurado desde el principio: propiedad, flujo de datos y medición mejorada revisados antes de añadir eventos propios encima.

La regla práctica para decidir cuándo hace falta un evento personalizado es sencilla: si una interacción cambia una decisión de negocio —presupuesto, prioridad de una página, optimización de un formulario— y GA4 no la registra sola, merece un evento. Si no cambia ninguna decisión, medirla solo añade ruido.

El flujo completo: dataLayer, activador y etiqueta GA4

Crear un evento personalizado en GA4 con GTM sigue siempre la misma secuencia de cuatro pasos: enviar la interacción al dataLayer, capturarla con un activador, dispararla con una etiqueta de evento de GA4 y verificarla antes de publicar. Entender esta cadena evita el error más común, que es mezclar responsabilidades entre la web, GTM y GA4.

El punto de partida es empujar la interacción a la capa de datos desde la web. Es una instrucción de JavaScript que anuncia «ha pasado esto, con estos detalles»:

window.dataLayer = window.dataLayer || [];
dataLayer.push({
  'event': 'lead_formulario',
  'form_id': 'contacto-home',
  'form_destino': 'presupuesto'
});

A partir de ahí, el trabajo ocurre dentro de Google Tag Manager y GA4. Cada pieza tiene una función única y no debe asumir la del resto:

Para leer form_id o form_destino dentro de GTM se crean variables de capa de datos con ese mismo nombre, y se asignan como parámetros en la etiqueta de GA4. Así, el dato que viajó en el push se convierte en un parámetro de evento consultable en los informes. Esta separación —la web declara, GTM interpreta, GA4 almacena— es la que permite escalar a decenas de eventos sin que la implementación se vuelva frágil.

Cómo estructurar el dataLayer para eventos analizables

Un dataLayer bien estructurado es el que expone cada dato relevante como un parámetro independiente y estable, no el que concatena información en el nombre del evento. La diferencia es la que separa un dato que se puede segmentar en GA4 de uno que hay que limpiar a mano cada mes. Este es, en la práctica, el factor que más determina si la analítica sirve para decidir.

El principio rector es que el nombre del evento describe la acción y los parámetros describen el contexto. Un antipatrón habitual es crear eventos como clic_boton_azul_home o video_producto_35_reproducido: meten en el nombre lo que debería ser un parámetro, multiplican nombres de evento y hacen imposible comparar «todos los vídeos» o «todos los CTA» entre sí. La versión analizable es un evento video_play con parámetros video_titulo, video_porcentaje y pagina.

Tres criterios convierten un dataLayer en analizable: enviar los valores en un formato consistente (mismas unidades, misma capitalización, sin acentos ni espacios en las claves), incluir solo los parámetros que responden a una pregunta real, y mantener el mismo esquema de nombres en toda la web. Cuando estos parámetros se van a usar para segmentar informes, hay que registrarlos además como dimensiones o métricas personalizadas en la propiedad de GA4; de lo contrario se recogen, pero no aparecen en las exploraciones. Definir este esquema antes de tocar GTM es exactamente el tipo de trabajo que estructura el servicio de analítica de datos de Advanze cuando una empresa necesita que su medición sostenga decisiones y no solo llene paneles.

Casos reales de eventos personalizados que sí mueven decisiones

Los eventos personalizados que aportan valor son los que responden a una pregunta de negocio concreta, no los que miden por medir. Cuatro casos cubren la mayoría de necesidades de una web de servicios o de comercio electrónico, y todos siguen el mismo patrón de dataLayer → activador → etiqueta.

En comercio electrónico, estos eventos se estructuran siguiendo el esquema de ecommerce de GA4, con un array items y parámetros como value y currency, de forma que el mismo dato alimenta los informes de monetización y, si se desea, la activación de campañas en Google Ads y Meta con audiencias basadas en comportamiento real. El hilo conductor es siempre el mismo: un evento existe porque hay una decisión esperando al otro lado del dato.

Nomenclatura y gobierno: la taxonomía que evita datos inservibles

La nomenclatura de eventos es la primera decisión técnica que condiciona todo el análisis posterior, y la que más se descuida. GA4 impone límites concretos —hasta 500 nombres de evento distintos por propiedad, 25 parámetros por evento y nombres sensibles a mayúsculas— y los ignora en silencio: no avisa cuando se superan, simplemente deja de registrar. Un esquema de nombres improvisado se traduce, meses después, en datos que no se pueden comparar ni recuperar.

Un buen sistema de nombres es consistente y predecible. Conviene fijar una convención única (por ejemplo snake_case, en minúsculas, verbo + objeto: lead_formulario, descarga_ficha, video_play) y documentar cada evento con su propósito, sus parámetros y la pregunta de negocio que responde. Ese documento —un simple plan de medición— es lo que permite que dos personas distintas nombren igual la misma interacción y que la propiedad no se llene de duplicados semánticos.

El gobierno también implica decidir qué eventos se marcan como key events (los antiguos «conversiones»), cuáles se registran como dimensiones personalizadas y cuáles se quedan como señal secundaria. Sin esa jerarquía, GA4 trata por igual un clic accesorio y un lead cualificado, y los informes pierden capacidad de discriminar lo que importa. Establecer esta taxonomía antes de implementar cuesta una tarde; reconstruirla después de un año de datos sucios cuesta mucho más.

Cómo validar los eventos en Preview y DebugView

Ningún evento debe publicarse sin verificar antes que llega con el nombre y los parámetros correctos. La validación se hace en dos capas complementarias: el modo previsualización (Preview) de Google Tag Manager confirma que la etiqueta se dispara con el activador previsto, y DebugView dentro de GA4 confirma que el evento y sus parámetros aterrizan realmente en la propiedad. Saltarse este paso es la causa más frecuente de eventos duplicados, mal nombrados o que nunca llegan.

En el modo previsualización de GTM se navega la web con el contenedor conectado (Tag Assistant) y se comprueba, en cada interacción, que la etiqueta correcta aparece en «Tags Fired», que el activador se ha evaluado como esperado y que las variables de capa de datos contienen los valores reales, no undefined. Es el momento de detectar que un activador dispara de más —por ejemplo, un clic que se cuenta dos veces— antes de que ensucie los datos históricos.

DebugView, en la sección de administración de GA4, muestra el flujo de eventos del dispositivo en depuración en tiempo casi real. Ahí se verifica que el event_name es exactamente el previsto, que los parámetros aparecen con sus valores y que se han registrado como key events o dimensiones cuando correspondía. Solo cuando ambas capas confirman el comportamiento se publica la versión del contenedor, siempre con un nombre de versión y una nota de qué se ha cambiado, para poder revertir si algo se tuerce.

De evento a métrica: key events, dimensiones y atribución

Un evento solo genera valor cuando se convierte en una métrica que alguien usa para decidir. Recoger la interacción es la mitad del trabajo; la otra mitad es traducirla en key events, dimensiones e informes que respondan a las preguntas del negocio. Esta es la fase donde una implementación técnica correcta se convierte —o no— en analítica útil.

El primer paso es marcar como key events las interacciones que representan valor real (lead enviado, compra, cita solicitada) y dejar el resto como eventos de apoyo. A partir de ahí, los parámetros registrados como dimensiones personalizadas permiten segmentar: qué formulario convierte mejor, qué vídeo precede a más leads, qué sección retiene la atención. La medición gana profundidad cuando se cruza con el resto del stack.

La atribución es donde los eventos personalizados demuestran su valor: al tener key events limpios y bien nombrados, se puede analizar qué canales y campañas intervienen en cada conversión, y entender por qué el last-click reparte mal el mérito entre canales. Esos mismos key events se pueden importar como conversiones a Google Ads, cerrando el círculo entre lo que se mide en la web y lo que se optimiza en las campañas.

Para que ese trabajo se traduzca en lectura diaria, el destino natural de los eventos es un panel donde el equipo consulte el dato sin exportar nada. Llevar los key events y sus dimensiones a un panel en Looker Studio convierte la implementación en una herramienta de gestión. A 6-12 meses, la ventaja competitiva no está en tener más eventos que nadie, sino en un modelo de medición gobernado: pocos eventos, bien nombrados, marcados con criterio y conectados a decisiones. Ese sistema es lo que hace que cada nueva campaña, cada rediseño y cada test parta de datos fiables en lugar de reconstruir la medición desde cero.

Errores comunes al crear eventos en GA4 con GTM

La mayoría de los problemas de medición no vienen de GA4 ni de GTM, sino de decisiones de implementación que se arrastran. Estos son los errores que con más frecuencia obligan a rehacer el trabajo.

• 1
  Meter contexto en el nombre del evento

  Nombres como clic_boton_home_azul multiplican eventos y consumen el límite de 500. El contexto va en parámetros, no en el nombre.

• 2
  Publicar sin validar en DebugView

  Un activador que dispara de más genera eventos duplicados que inflan las conversiones. La previsualización de GTM y DebugView lo detectan antes de publicar.

• 3
  No registrar los parámetros como dimensiones

  Los parámetros que no se registran como dimensiones personalizadas se recogen, pero no aparecen en las exploraciones. El dato existe y no se puede usar.

• 4
  Leer el DOM en vez del dataLayer

  Depender de selectores del DOM en lugar de un push hace la medición frágil: cualquier cambio de maquetación rompe el evento sin avisar.

• 5
  Medir todo sin marcar qué es key event

  Sin una jerarquía clara, GA4 trata igual un clic accesorio y un lead cualificado. Marcar los key events es lo que da capacidad de decidir a los informes.

• 6
  Ignorar el consentimiento

  Disparar eventos sin respetar el modo de consentimiento incumple la normativa y contamina los datos. La medición debe activarse según la elección del usuario.

Preguntas frecuentes