Configurar eventos en Google Analytics 4 parece sencillo hasta que empiezas a mirar los datos de verdad.
Al principio todo encaja: creas un evento, lo ves aparecer en DebugView, lo marcas como evento clave si corresponde y das por hecho que la medición está resuelta. El problema llega después, cuando empiezas a detectar cosas raras: formularios que cuentan dos veces, eventos que aparecen en tiempo real pero no en los informes, parámetros que llegan a GA4 pero luego no puedes utilizar en una exploración, compras duplicadas o nombres distintos para acciones que, en realidad, deberían medirse de la misma manera.
Et c'est là le piège.
Muchos errores al configurar eventos en GA4 no provocan que Analytics “deje de funcionar”. La mayoría son bastante más traicioneros: GA4 sigue recogiendo datos, los informes se llenan y todo parece normal. Simplemente, los datos están mal.
Ese tipo de fallo es mucho más peligroso que un evento que directamente no se registra.
Si un formulario no envía ningún evento, sabes que existe un problema. Si cada formulario envía dos eventos generate_lead, puedes pasar meses tomando decisiones sobre una tasa de conversión inflada sin darte cuenta.
C'est pourquoi, quand nous parlons de configurar eventos en GA4, el objetivo no debería ser únicamente conseguir que “el evento salte”. Hay que comprobar cuatro cosas diferentes:
que se dispara cuando debe, que no se dispara cuando no debe, que envía la información correcta y que después podremos utilizar esa información para analizar el negocio.
En esta guía vamos a trabajar precisamente sobre esa idea. No vamos a explicar GA4 desde cero ni a hacer una lista genérica de eventos. Vamos a centrarnos en los errores que aparecen cuando empiezas a construir una medición real con Google Analytics 4 y Google Tag Manager, cómo identificarlos y qué conviene revisar antes de confiar en los datos.
Google distingue actualmente entre eventos recopilados automáticamente, eventos de medición mejorada, eventos recomendados y eventos personalizados. Además, recomienda utilizar eventos personalizados únicamente cuando ninguna de las opciones anteriores representa correctamente la interacción que queremos medir. Esa jerarquía es importante porque utilizar los nombres y parámetros recomendados permite aprovechar dimensiones, métricas e integraciones ya previstas dentro de Analytics.
Hay una razón bastante sencilla: GA4 es flexible. Y esa flexibilidad es precisamente una de sus ventajas.
Podemos definir qué interacciones queremos medir, añadir parámetros, utilizar Google Tag Manager, trabajar con dataLayer, crear dimensiones personalizadas, convertir determinadas acciones en eventos clave y diseñar una arquitectura prácticamente adaptada a cualquier web.
El problema es que GA4 también nos deja hacer bastantes cosas mal.
No existe una ventana que aparezca diciendo:
“Este evento funciona, pero lo has planteado de una forma que dentro de seis meses va a convertir tus informes en un pequeño infierno.”
Si envías un evento llamado:
formulario_enviado
GA4 puede recogerlo.
Si otro compañero crea:
form_submit
également.
Y si alguien utiliza después:
lead_form_sent
également.
Técnicamente, los tres pueden funcionar perfectamente.
Analíticamente, acabamos de empezar a construir un problema.
Quand on trouve problemas con eventos de GA4, es muy fácil culpar a la herramienta.
“Analytics no está midiendo bien.”
“GTM está duplicando datos.”
“DebugView hace cosas raras.”
En bastantes casos, sin embargo, GA4 simplemente está recogiendo exactamente lo que le estamos enviando.
Si una etiqueta se dispara dos veces, GA4 registra dos eventos.
Si enviamos el valor de un formulario vacío, Analytics recibe un parámetro vacío.
Si utilizamos tres nombres diferentes para una misma acción, GA4 registra tres eventos diferentes.
No interpreta nuestra intención.
Cette nuance est fondamentale.
Google Analytics es un sistema de medición, no un compañero de trabajo que mira nuestra implementación y piensa: “seguramente quería decir otra cosa”.
Por eso, antes de preguntarnos:
“¿Cómo creo este evento?”
conviene preguntarse:
“¿Qué quiero medir exactamente y para qué voy a utilizar ese dato?”
Esa segunda pregunta evita una cantidad sorprendente de errores.
Imagina una web de services con un formulario de contacto. Queremos medir cuántos usuarios solicitan información. Una implementación rápida podría consistir en crear un evento cada vez que alguien pulsa el botón:
Envoyer le formulaire
Parece lógico. Pero realmente no estamos midiendo formularios enviados. Estamos midiendo clics en un botón.
Puede ocurrir que el usuario pulse el botón con campos obligatorios vacíos.
Puede existir un error de validación.
Puede fallar la petición al servidor.
Puede hacer doble clic.
Puede incluso existir algún script que bloquee el envío.
Y aun así nuestro evento puede dispararse.
El informe termina diciendo que hemos recibido 120 leads cuando quizá solo llegaron 97 formularios correctamente.
Eso no es un error de GA4. Es un error en la definición del evento. En lugar de medir la intención de enviar el formulario, deberíamos intentar medir la confirmación de que el envío ha terminado correctamente, siempre que técnicamente podamos acceder a ese estado.
Este tipo de decisiones son las que separan una implementación que “recoge cosas” de una medición realmente útil.
GA4 utiliza eventos para representar interacciones o sucesos en una web o aplicación. Un evento puede registrar desde una visita a una página hasta un clic, una búsqueda, un inicio de sesión o una compra.
Después podemos añadir parámetros de evento para proporcionar contexto.
Par exemple:
generate_lead
puede indicarnos que alguien ha enviado una solicitud.
Pero quizá también queramos saber:
form_name = presupuesto
form_location = contacto_footer
service = diseño_web
Ahí es donde entran los parámetros.
Google define precisamente los parámetros como información adicional que permite describir con mayor detalle la interacción recogida por un evento. El problema aparece cuando empezamos a crear eventos nuevos cada vez que queremos guardar una diferencia. Por ejemplo:
lead_diseno_web
lead_seo
lead_ads
lead_mantenimiento
En muchos casos sería más limpio utilizar:
generate_lead
y añadir:
service = diseno_web
o
service = seo
Así mantenemos un evento coherente y trasladamos el detalle al parámetro. Esta diferencia puede parecer pequeña mientras estás configurando tres eventos. Cuando tienes 80, deja de ser pequeña.
Una buena forma de plantearlo es esta:
El evento responde a “¿qué ha ocurrido?”
El parámetro responde a “¿cómo, dónde o con qué características ha ocurrido?”
exemple:
L'événement: generate_lead
Que s'est-il passé?
Se ha generado un lead.
Paramètres:
form_name = contacto
service = seo
page_location = /servicios/seo/
lead_type = presupuesto
Ahora tenemos una estructura mucho más útil. Podemos contar todos los leads conjuntamente y, cuando necesitemos detalle, analizarlos por servicio, formulario o ubicación.
Google recomienda además utilizar los parámetros prescritos en sus eventos recomendados porque pueden alimentar dimensiones y métricas predefinidas y aprovechar capacidades actuales o futuras de Analytics.
Este es uno de los errores que más confusión genera al configurar eventos en GA4.
Creas un parámetro.
Lo ves perfectamente en DebugView.
Parece que todo funciona.
Después vas a crear una exploración y buscas ese parámetro.
Cela n'apparaît pas.
Y empiezas a pensar que GA4 lo ha perdido.
En realidad, hay una diferencia entre recoger un parámetro y disponer de una dimensión o métrica con la que analizarlo.
Google explica que los parámetros son los datos que se recopilan, mientras que las dimensiones y métricas son las estructuras que permiten analizarlos dentro de Analytics.
Cuando utilizamos determinados parámetros personalizados y queremos analizarlos en informes, puede ser necesario crear una dimensión personalizada con alcance de evento. Par exemple:
L'événement:
generate_lead
parámetro:
service = seo
GA4 puede estar recibiendo correctamente service.
Pero si queremos utilizar “Servicio” como dimensión en exploraciones o determinados informes, tendremos que registrar ese parámetro como dimensión personalizada cuando no exista ya una dimensión predefinida equivalente. Google recomienda precisamente no crear una dimensión personalizada si ya existe una dimensión estándar que cubra esa información.
Aquí aparece otra regla útil:
Antes de inventar una dimensión, comprueba si GA4 ya tiene una.
No tiene sentido ocupar espacio en la configuración personalizada para recrear datos que Analytics ya entiende de forma nativa.
Un evento GA4 mal configurado no es simplemente un problema técnico. Puede cambiar una decisión de negocio.
Imagina una campaña de Google Ads que genera aparentemente 200 conversiones. Si 40 proceden de un evento duplicado, el coste por lead parece bastante mejor de lo que realmente es.
Quizá decidimos aumentar presupuesto.
Quizá reducimos inversión en otra campaña que, en realidad, estaba consiguiendo leads más baratos.
Quizá concluimos que una landing convierte mejor cuando únicamente está enviando el evento dos veces.
Ahí es donde una implementación analítica deja de ser un asunto exclusivamente técnico. La medición condiciona:
qué campañas mantenemos,
qué páginas modificamos,
qué fuentes de tráfico valoramos,
qué productos potenciamos,
qué presupuestos aumentamos,
y, en general, qué creemos que funciona.
Por eso la pregunta adecuada no es:
“¿Está entrando el evento?”
mais:
“¿Puedo confiar en lo que este evento representa?”
Son preguntas muy diferentes.
Antes de crear cualquier evento, deberíamos poder responder:
¿Qué acción estamos intentando representar?
No qué botón estamos mirando, sino qué comportamiento queremos medir.
¿Existe ya un evento automático, de medición mejorada o recomendado que represente esta acción?
Google recomienda recurrir a eventos personalizados cuando los eventos existentes no encajan con el caso de uso.
¿Necesitamos un evento nuevo o únicamente un parámetro?
Esta pregunta evita convertir cada variante de una acción en otro evento.
¿Qué información necesitaremos después para analizarlo?
Si sabemos que querremos separar leads por servicio, quizá necesitamos preparar desde el principio un parámetro service.
¿Cómo vamos a validar que el evento representa una acción real?
No basta con comprobar que se dispara. Tenemos que probar casos correctos, incorrectos y situaciones límite.
Esta última parte suele olvidarse.
Probamos el formulario funcionando.
Parfait.
Pero también deberíamos probar:
un formulario con error,
un clic doble,
volver atrás,
recharger,
enviar desde móvil,
aceptar o rechazar determinadas categorías de consentimiento cuando esto afecte a la implementación,
y cualquier otro comportamiento que razonablemente pueda cambiar el disparo.
Ahí aparecen muchos de los errores de eventos en GA4 que nunca detectamos durante una prueba rápida.
Quieres medir | événement | Paramètre |
|---|---|---|
Se envía un formulario | générer_lead | form_name |
Se compra un producto | achat | transaction_id, value |
Se realiza una búsqueda | recherche | terme de recherche |
Se inicia sesión | vous connecter | méthode |
Se selecciona contenido | sélectionner_contenu | Tipo o identificación del contenido |
Aquí empieza la parte realmente delicada. Cuando un evento no llega a GA4, el fallo suele ser evidente. Lo ves, lo detectas y lo corriges. Lo peligroso son los eventos GA4 mal configurados que sí llegan, porque generan datos aparentemente válidos. El informe se llena, la gráfica sube, las conversiones aparecen… y nadie sospecha que la medición está torcida.
Por eso, en esta sección no vamos a centrarnos en errores “visibles”, sino en los que pueden alterar la lectura del negocio sin que Analytics lance ninguna alarma.
C'est probablement l'un des errores más frecuentes al configurar eventos en GA4. Y también uno de los más caros. Un evento duplicado significa que una misma acción real del usuario termina registrándose dos o más veces.
Imagina que un usuario envía un formulario una única vez. En el informe aparece:
generate_lead = 2
GA4 no sabe que esos dos eventos corresponden a una sola persona realizando una sola acción. Para Analytics han ocurrido dos eventos. El dato queda inflado desde el origen.
Las causas son variadas.
Una de las más habituales es medir la misma acción desde dos sistemas diferentes.
Por ejemplo, tienes configurado un evento en Google Tag Manager y, al mismo tiempo, un Plugin WordPress envía automáticamente otro evento a GA4.
El usuario hace clic una vez.
GTM envía:
generate_lead
El plugin envía:
generate_lead
Resultado: dos eventos.
También ocurre cuando activamos funciones automáticas de GA4 y después intentamos medir manualmente exactamente lo mismo.
La medición mejorada puede recopilar determinados eventos automáticamente, como desplazamientos, búsquedas internas, clics salientes o descargas de archivos, dependiendo de la configuración. Si implementamos esos mismos eventos manualmente sin comprobar antes qué está recogiendo Analytics, podemos terminar duplicando información.
Otro escenario clásico aparece con los formularios.
Supongamos que creamos un evento:
generate_lead
cuando se pulsa el botón de enviar. Y después otro:
generate_lead
cuando aparece el mensaje de confirmación.
Si el formulario se envía correctamente, se disparan los dos. Desde nuestro punto de vista sigue existiendo un único lead. Desde el punto de vista de GA4 hay dos eventos idénticos.
En ecommerce el problema es todavía más serio. Un evento purchase duplicado puede alterar ingresos, número de compras, ROAS y cualquier análisis relacionado con ventas.
Google utiliza el parámetro transaction_id precisamente para identificar una transacción concreta. Una implementación correcta de ecommerce debería enviar identificadores únicos y consistentes para cada compra.
Aquí hay una prueba muy útil. Si una misma transacción puede volver a enviar el evento purchase simplemente porque el usuario recarga la página de gracias, tenemos un problema.
El evento debería representar:
“Esta compra ha ocurrido.”
No:
“El usuario ha visitado otra vez la URL donde mostramos que la compra ocurrió.”
La diferencia es pequeña en la implementación y enorme en los datos.
El primer lugar donde miraría es Debugview. Realiza una única acción de prueba.
Un clic.
Un formulario.
Una compra de prueba.
Una reproducción.
Y observa cuántas veces aparece el evento. Si haces una sola acción y ves:
generate_lead
generate_lead
ya tienes una pista bastante clara.
Después tocaría revisar GTM en modo Preview para comprobar qué etiquetas se están disparando. Si vemos dos etiquetas diferentes enviando el mismo evento, podemos localizar el origen. También conviene revisar:
plugins,
scripts añadidos directamente al código,
Google Tag Manager,
integraciones de terceros,
configuración de GA4,
y cualquier plataforma que pueda enviar datos mediante Measurement Protocol.
GA4 es bastante permisivo con los nombres. Eso puede ser una ventaja durante las primeras semanas de implementación. Y una pesadilla seis meses después.
Imagina que distintas personas han configurado estos eventos:
form_submit
formulario_enviado
lead_form
contact_form
generate_lead
Todos pretenden representar prácticamente la misma acción. Ahora imagina intentar construir un informe de leads.
¿Qué evento utilizas? ¿Los cinco? ¿Solo algunos? ¿Hay diferencias reales entre ellos o son simplemente convenciones distintas?
c'est l'un de ces errores al crear eventos en GA4 que no rompe nada técnicamente, pero degrada muchísimo la calidad del análisis.
Google mantiene una lista de événements recommandés con nombres y parámetros definidos para acciones comunes. Por ejemplo:
login
sign_up
search
generate_lead
purchase
add_to_cart
begin_checkout
Cuando el evento recomendado representa correctamente la acción, normalmente merece la pena utilizarlo en lugar de inventar otro nombre. No porque Google prohíba crear uno personalizado, sino porque seguir la estructura estándar facilita la interoperabilidad con informes, dimensiones y futuras funcionalidades de Analytics.
Si una persona solicita información comercial, utilizar:
generate_lead
es normalmente más coherente que:
cliente_contacta_por_formulario
Aunque el segundo sea comprensible. En analítica buscamos nombres que sean: consistentes, reutilizables, documentables, y fáciles de interpretar por cualquier persona que llegue al proyecto después.
Este es otro error frecuente.
Supongamos que tenemos cuatro formularios:
formulaire de contact,
presupuesto SEO,
presupuesto web,
auditoría.
Podríamos crear:
contact_form_submit
seo_form_submit
web_form_submit
audit_form_submit
Ça marche.
Pero estamos utilizando el nombre del evento para almacenar una característica del evento. Puede ser más limpio utilizar:
generate_lead
y añadir:
form_name = seo
form_name = web
form_name = auditoria
Así mantenemos una lógica estable.
Que s'est-il passé?
generate_lead
Où?
form_name
¿Qué servicio?
service
¿Qué página?
page_location
La arquitectura queda mucho más escalable.
Aquí conviene introducir un matiz. No siempre debemos reducir absolutamente todo a cinco eventos universales.
Si dos acciones representan comportamientos realmente diferentes para el negocio, pueden merecer eventos diferentes. Por ejemplo:
generate_lead
y
sign_up
no significan necesariamente lo mismo.
Un usuario que solicita presupuesto es un lead.
Un usuario que crea una cuenta está registrándose.
Fusionarlos únicamente porque “los dos son formularios” empeora el modelo.
Por eso la pregunta nunca debería ser:
“¿Puedo meterlo todo en el mismo evento?”
Mais:
“¿Estas acciones representan realmente el mismo comportamiento?”
Este error es especialmente frustrante porque todo parece funcionar perfectamente.
Creas un evento:
generate_lead
avec des paramètres:
form_name
service
lead_type
user_type
En DebugView aparecen todos. Perfecto.
Días después quieres construir un informe por service. No encuentras la dimensión. Y empiezas a pensar que Analytics no ha recogido el dato. En realidad, puede estar llegando correctamente.
Le problème est que un parámetro personalizado no se convierte automáticamente en una dimensión personalizada disponible en todos los informes.
Cuando necesitamos utilizar determinados parámetros personalizados para análisis, normalmente debemos registrar una dimensión personalizada con el ámbito adecuado.
Google diferencia claramente entre recoger parámetros y crear dimensiones o métricas personalizadas para poder utilizarlos en informes y exploraciones.
También existe el extremo opuesto. Registrar cada parámetro imaginable como dimensión personalizada. No es una buena idea.
GA4 tiene límites de dimensiones y métricas personalizadas según el tipo de propiedad, y además una arquitectura llena de dimensiones inútiles termina siendo difícil de mantener.
Antes de registrar una dimensión deberíamos preguntarnos:
¿Voy a utilizar realmente este dato para analizar algo?
Si la respuesta es “probablemente nunca”, quizá no merece la pena ocupar un espacio personalizado.
También debemos comprobar si GA4 ya proporciona una dimensión estándar equivalente. Por ejemplo, crear:
custom_page_url
cuando ya disponemos de page_location
sería bastante difícil de justificar.
Hay otro problema menos evidente. El parámetro existe. Pero unas veces llega:
service = seo
otras:
service = SEO
otras:
service = posicionamiento
et autres :
service = posicionamiento_web
Desde el punto de vista humano entendemos perfectamente que todos hablan del mismo servicio. GA4 no. Para Analytics son valores diferentes.
En una exploración podríamos encontrarnos cuatro filas:
Le SEO
seo
placement
posicionamiento_web
Esto no es un error técnico. Es un error de normalización. Por eso los valores dinámicos también deben documentarse.
No basta con decidir:
“Vamos a enviar el servicio.”
Hay que decidir:
“¿Qué valores concretos puede tener service y cómo se escribirán?”
Par exemple:
seo
diseno_web
google_ads
mantenimiento
Sin tildes, sin espacios y con una convención consistente.
Implementación problemática | Mejor planteamiento |
|---|---|
lead_seo | generate_lead + service=seo |
lead_web | generate_lead + service=diseno_web |
lead_ads | generate_lead + service=google_ads |
form_footer | generate_lead + form_location=footer |
boton_contacto_home | Evento según acción + page_location o parámetro de ubicación |
No se trata de reducir eventos por reducir. Se trata de separar correctamente la acción del contexto.
Este error es muy común porque durante años utilizamos el término conversión y ahora GA4 trabaja con les évènements clés dentro de Analytics.
Un evento es algo que ocurre.
Un evento clave es un evento que hemos decidido considerar especialmente importante para medir el éxito del negocio.
No todas las acciones deberían convertirse en eventos clave.
Pongamos un ejemplo. Podemos medir:
scroll
file_download
view_search_results
generate_lead
purchase
Todos son eventos. Pero para un negocio de servicios quizá tenga sentido marcar como evento clave:
generate_lead
y quizá alguna acción adicional realmente estratégica.
Marquer scroll como evento clave simplemente porque podemos hacerlo no aporta demasiado.
Cuando prácticamente cualquier acción se trata como evento clave, la métrica pierde significado.
Imagina un informe donde “conversiones” incluyen:
téléchargements,
rouleaux,
clics en teléfono,
visualizaciones de vídeo,
formes,
visitas a páginas concretas.
La cifra puede ser enorme. Pero ¿qué significa realmente? Poco.
Un evento clave debería responder a una pregunta de negocio concreta:
¿Esta acción representa un resultado que realmente valoramos?
En ecommerce es evidente con purchase.
En generación de leads puede ser generate_lead.
En una plataforma SaaS podría ser sign_up, una prueba gratuita o una acción posterior más significativa.
La selección debería depender del modelo de negocio, no de cuántos eventos tenemos disponibles.
También ocurre lo contrario. Tenemos perfectamente configurado:
generate_lead
pero nunca lo marcamos como evento clave.
Analytics recoge el evento, pero después determinadas métricas e integraciones no lo tratan como una acción principal de negocio. Esto puede generar confusión especialmente cuando GA4 se utiliza junto con Google Ads.
Por eso, después de verificar que el evento funciona correctamente, tenemos que decidir conscientemente:
¿Este evento representa un resultado clave o simplemente comportamiento?
Este error merece un apartado propio porque parece inocente. Necesitas medir un registro. Creas:
registro_usuario
Perfecto. Excepto que GA4 ya tiene:
sign_up
Necesitas medir una búsqueda. Creas:
busqueda_web
Pero existe:
search
Necesitas medir una solicitud de contacto. Creas:
contacto_cliente
Y quizá generate_lead representa perfectamente la acción.
Google recomienda utilizar los eventos recomendados y sus parámetros cuando encajan con el comportamiento que estamos midiendo, y recurrir a eventos personalizados cuando no existe una alternativa adecuada.
Porque GA4 no solo ve nombres. Los eventos recomendados forman parte de un modelo semántico definido por Google. Por ejemplo, en ecommerce existe una estructura específica alrededor de:
view_item
add_to_cart
begin_checkout
purchase
avec des paramètres tels que :
currency
value
items
transaction_id
Si decidimos sustituir purchase par:
venta_finalizada
podemos enviar el evento.
Pero estamos alejándonos innecesariamente de la estructura que Analytics entiende mejor.
Cuando la acción que queremos medir no está representada por ningún evento automático, de medición mejorada o recomendado.
Imagina una plataforma donde los usuarios pueden:
create_project
No existe necesariamente un evento recomendado que represente exactamente esa acción. Ahí un evento personalizado puede tener todo el sentido.
La clave es que sea una décision consciente, no simplemente el resultado de desconocer que ya existía otro evento.
Cuando la medición pasa por Google Tag Manager, el margen de error aumenta porque ya no interviene una sola pieza. Tenemos el evento que queremos medir, la etiqueta que lo envía, el activador que decide cuándo debe dispararse y, muchas veces, variables o información procedente del dataLayer.
La ventaja es enorme: podemos construir una medición muy flexible sin tocar directamente cada parte del código. La desventaja es que un contenedor mal planteado puede enviar datos perfectamente válidos… en el momento equivocado.
Google indica que, para trabajar con GA4 desde Tag Manager, primero debe existir una etiqueta de Google correctamente configurada y, a partir de ahí, pueden enviarse los eventos correspondientes. También recuerda que esa configuración puede encargarse de eventos automáticos y de medición mejorada, algo que conviene revisar antes de implementar manualmente acciones similares.
Un activador responde a una pregunta muy concreta:
¿Cuándo debe ejecutarse esta etiqueta?
Si la respuesta está mal planteada, el evento también lo estará.
Uno de los ejemplos más habituales es medir un clic utilizando un activador demasiado genérico. Queremos saber cuándo alguien pulsa el botón de solicitar presupuesto, pero configuramos una condición que se cumple para todos los botones de la página.
Resultado: el evento funciona. El problema es que funciona demasiado.
Imagina una etiqueta:
generate_lead
con un activador basado únicamente en:
Click Classes contiene button
Si esa clase se reutiliza en el menú, en un CTA, en el formulario y en otros componentes, podemos terminar registrando leads donde únicamente hubo navegación.
El activador debería estar ligado a una característica lo bastante específica como para identificar la acción que realmente queremos medir: un ID, una clase exclusiva, una URL de destino concreta o, todavía mejor, un evento enviado al dataLayer cuando la acción ha finalizado correctamente.
Aquí vuelve a aparecer la diferencia entre medir una interfaz y medir un resultado.
Para un formulario, por ejemplo, detectar el clic en “Enviar” puede ser más frágil que escuchar una confirmación real de envío. Si el formulario es AJAX, la página ni siquiera tiene por qué recargarse, así que basarnos únicamente en una URL de agradecimiento tampoco será siempre suficiente.
El disparador correcto depende del funcionamiento real de la web.
Un autre des errores de Google Tag Manager con GA4 más frecuentes consiste en tener una etiqueta perfectamente configurada, pero permitir que su activador se cumpla varias veces durante una misma acción.
Supongamos que una web abre un modal después de enviar correctamente un formulario y que hemos configurado el evento utilizando la aparición de ese elemento.
El usuario envía el formulario.
Aparece el modal.
generate_lead
Correct.
Pero por alguna razón el componente se vuelve a renderizar dos veces.
GTM puede interpretar ambos cambios como nuevos cumplimientos de la condición y enviar:
generate_leadgenerate_lead
Aunque el usuario solo haya enviado un formulario.
Algo parecido puede ocurrir en webs construidas con JavaScript, aplicaciones de una sola página o componentes dinámicos. La interfaz cambia varias veces, pero conceptualmente el usuario solo ha realizado una acción.
Por eso comprobar simplemente que “la etiqueta se dispara” no basta. Tenemos que verificar también cuántas veces se dispara y en qué secuencia.
El modo Preview de Tag Manager es especialmente útil para esto, porque permite observar qué eventos internos están ocurriendo y qué etiquetas se activan en cada uno.
Una prueba que hacemos con demasiada poca frecuencia es repetir la acción varias veces de formas diferentes: enviar correctamente, provocar un error, volver atrás, cerrar el modal, abrirlo otra vez o navegar sin recargar la página.
Es precisamente ahí donde aparecen las duplicidades.
También podemos encontrarnos con una implementación correcta en GTM y otra implementación igualmente correcta fuera de GTM.
Y juntas dejan de ser correctas.
Par exemple:
generate_lead mediante un plugin.generate_lead al detectar la confirmación.Tres sistemas observando la misma acción.
Ninguno está técnicamente roto.
Pero el resultado está triplicado.
Antes de crear una nueva etiqueta conviene saber qué capas de medición existen ya en la web. En proyectos heredados es especialmente importante revisar el código, plugins, GTM e integraciones de terceros antes de añadir nada.
Quand on trouve eventos duplicados en GA4, nuestra primera pregunta debería ser:
¿Quién está enviando este evento?
No:
¿Dónde puedo añadir otro disparador para arreglarlo?
El dataLayer es una de las herramientas más potentes de Google Tag Manager porque permite que la web comunique información estructurada al contenedor.
En lugar de intentar “leer” lo que aparece visualmente en una página, podemos enviar algo parecido a:
dataLayer.push({
event: 'generate_lead',
form_name: 'presupuesto',
service: 'seo'
});
GTM escucha el evento generate_lead, recoge los valores y los envía a GA4.
Conceptualmente es una implementación mucho más sólida que intentar deducir qué ha ocurrido mirando clases CSS o textos de botones.
Le problème survient lorsque dataLayer no es consistente.
Imagina que unas páginas envían:
service: 'seo'
et autres :
servicio: 'seo'
O que unas utilizan:
form_name
et autres :
formName
Para una persona son variaciones pequeñas.
Para Tag Manager son variables diferentes.
La etiqueta puede terminar enviando parámetros vacíos, undefined o valores distintos según la página.
Y muchas veces no veremos un error visible. Simplemente encontraremos después informes llenos de valores (not set).
Otro problema frecuente aparece cuando el valor existe, pero todavía no estaba disponible cuando GTM intentó leerlo.
Por ejemplo, una variable del dataLayer se rellena después de que la etiqueta haya sido disparada.
La secuencia sería:
Trop tard.
GA4 ya recibió el evento.
Por eso, cuando dependemos de información dinámica, conviene que los datos y el evento que activa la etiqueta se envíen de forma coordinada.
Es mucho más sólido:
dataLayer.push({
event: 'form_success',
form_name: 'contacto',
service: 'diseno_web'
});
que enviar primero el evento y confiar en que las variables aparezcan después.
Google distingue igualmente entre parámetros de configuración y parámetros de evento: estos últimos son precisamente los que permiten enviar información adicional asociada a una interacción concreta.
Cuando una implementación crece, existe la tentación de enviar prácticamente toda la información disponible “por si algún día hace falta”.
No siempre es buena idea.
Un dataLayer debería tener una estructura comprensible, consistente y documentada. Si cada desarrollador utiliza nombres diferentes o añade datos sin una lógica común, la medición se vuelve difícil de mantener.
Además, debemos ser especialmente prudentes con datos personales. Que técnicamente podamos capturar algo no significa que debamos enviarlo a Analytics.
El objetivo no es tener el dataLayer más grande posible.
El objetivo es que contenga la información necesaria para una medición útil y bien gobernada.
Aquí añadiría una pequeña comprobación práctica.
Antes de publicar cualquier evento nuevo en GTM, haría como mínimo cuatro pruebas:
Caso correcto: realizamos exactamente la acción que queremos medir y comprobamos que aparece una vez.
Caso incorrecto: intentamos completar la acción de forma inválida y verificamos que el evento no se registra.
Répétition: repetimos la acción para comprobar que cada ejecución genera exactamente el número esperado de eventos.
Navegación alternativa: probamos desde otra página, dispositivo o ruta cuando exista la posibilidad de que cambie la lógica.
Después revisaría tres niveles:
Tag Manager Preview → ¿se ha disparado la etiqueta correcta?
Vue de débogage GA4 → ¿ha llegado el evento?
Paramètres → ¿han llegado también los valores correctos?
Ese orden ayuda bastante a localizar el fallo.
Si la etiqueta no aparece en Preview, normalmente el problema está antes de GA4.
Si aparece en Preview pero no en DebugView, debemos revisar el envío o la configuración.
Si llega a DebugView pero los parámetros están vacíos, probablemente tengamos que mirar variables o dataLayer.
Problème | Primer lugar que revisar |
|---|---|
La etiqueta no se dispara | Activador en GTM |
Se dispara dos veces | Preview y condiciones del activador |
Evento llega sin parámetros | Variables y dataLayer |
Evento llega a GA4 pero con nombre incorrecto | Configuración de la etiqueta |
Evento duplicado | GTM, plugins y otras implementaciones |
Valores aparecen como (not set) | Parámetros y dimensiones personalizadas |
Que un evento aparezca en Debugview no significa que vaya a verse de inmediato en los informes estándar. DebugView sirve para comprobar en tiempo real que GA4 está recibiendo el evento y sus parámetros, mientras que los informes pueden tardar entre Heures 24 et 48 en procesar los datos.
Por eso, si acabas de crear un evento y lo ves correctamente en DebugView, no conviene asumir que hay un error solo porque todavía no aparezca en los informes.
Si después de ese tiempo sigue sin verse, entonces sí conviene revisar cuatro cosas: que estés mirando la propiedad y el rango de fechas correctos, que no haya filtros activos, que el evento esté realmente marcado como evento clave si esperas verlo como conversión y que los parámetros personalizados que quieras analizar estén registrados correctamente como dimensiones personalizadas cuando sea necesario.
También puede influir el tráfico de prueba. Si trabajas con modo debug o filtros de desarrollador, es posible que veas el evento en DebugView pero que esas pruebas no terminen mezclándose con los datos normales de los informes.
La idea importante es esta:
DebugView confirma que el evento llega; los informes confirman cómo queda procesado y disponible para análisis.
Antes de dar por terminado un evento en GA4, conviene comprobar algo más que el simple hecho de que aparezca en DebugView. Un evento bien configurado debe cumplir tres condiciones: dispararse cuando corresponde, hacerlo una sola vez y enviar la información correcta.
Ese pequeño control evita muchos de los problemas que después terminan contaminando informes, eventos clave o campañas de Google Ads.
El primer paso es probar el evento en Google Tag Manager Preview o con las herramientas de depuración que utilicemos.
No basta con realizar la acción correcta. También conviene probar qué ocurre cuando el usuario no completa la acción.
Por ejemplo, si estamos midiendo un formulario, deberíamos comprobar:
Si generate_lead aparece cuando el formulario falla, no estamos midiendo un lead, estamos midiendo una intención.
Después hay que abrir el evento en DebugView y comprobar que los parámetros llegan como esperamos.
Si tenemos:
generate_lead
avec:
form_name = presupuestoservice = seo
deberíamos verificar que esos valores son consistentes y que no aparecen variantes como:
SEOseo_webposicionamiento
si todas representan exactamente lo mismo.
Este control parece pequeño, pero evita terminar con informes fragmentados por simples diferencias de nomenclatura.
También es buen momento para confirmar que estamos utilizando un evento recomendado por GA4 cuando existe uno adecuado y que los parámetros que queremos analizar posteriormente están correctamente planteados.
La última prueba es bastante sencilla: realiza una acción y cuenta cuántos eventos aparecen.
Una acción real debería generar el número de eventos esperado.
Si envías un formulario una vez y aparecen dos generate_lead, hay que revisar GTM, plugins, scripts o integraciones que puedan estar enviando la misma información.
También conviene comparar el comportamiento entre distintas páginas o dispositivos. Un evento puede funcionar perfectamente en escritorio y fallar en móvil porque el botón utiliza otra clase, porque cambia la estructura del formulario o porque el proceso de confirmación es diferente.
En definitiva, antes de publicar deberíamos poder responder con seguridad a estas preguntas:
¿Se dispara cuando debe? ¿No se dispara cuando no debe? ¿Aparece una sola vez? ¿Los parámetros son correctos?
Si las cuatro respuestas son sí, ya tenemos una base bastante fiable.
Cuando detectas un evento mal configurado en GA4, lo importante es corregir la causa y no limitarte a maquillar el resultado en los informes.
Si el problema está en el activador, corrige el activador. Si el evento está duplicado, localiza de dónde salen las dos señales. Si el parámetro llega mal, arregla su valor antes de enviarlo. Cuanto más cerca del origen solucionemos el error, más limpia quedará la medición.
También conviene hacer los cambios con cuidado. Renombrar un evento, por ejemplo, no modifica el histórico: los datos antiguos seguirán utilizando el nombre anterior. Por eso, si hacemos un cambio relevante, merece la pena dejar anotada la fecha para no interpretar después una ruptura artificial en los informes.
Y, si trabajamos con Google Tag Manager, cualquier modificación debería probarse primero en modo Preview antes de publicar. Cambiar una cosa cada vez hace mucho más fácil comprobar si realmente hemos solucionado el problema.
Règle pratique : corrige en origen, prueba antes de publicar y documenta los cambios importantes.
Las causas más habituales están en el propio disparo: el activador de Google Tag Manager no se cumple, la etiqueta no se ejecuta, el consentimiento bloquea Analytics o el evento se está enviando con una configuración incorrecta.
El mejor orden para comprobarlo es sencillo: primero GTM Preview, después DebugView y, por último, los informes. Así sabrás en qué punto exacto deja de funcionar.
Porque DebugView muestra la información prácticamente en tiempo real, mientras que los informes estándar de GA4 necesitan tiempo de procesamiento.
Si acabas de configurar el evento y lo ves correctamente en DebugView, espera antes de modificar nada. Si después sigue sin aparecer, revisa filtros, rango de fechas, propiedad y configuración del evento.
Haz una única acción y observa cuántas veces aparece el evento en DebugView o en Google Tag Manager Preview.
Si envías un formulario una vez y aparecen dos eventos generate_lead, hay que comprobar si la misma acción se está midiendo desde GTM, un plugin, código propio u otra integración al mismo tiempo.
No. Antes de crear un evento personalizado conviene comprobar si GA4 ya dispone de un evento automático, de medición mejorada o recomendado que represente esa acción.
Utilizar eventos recomendados cuando existen ayuda a mantener una estructura más coherente y evita terminar con nombres diferentes para acciones equivalentes.
Un événement registra una interacción o acción. Un événement clé es un evento que consideramos especialmente importante para los objetivos del negocio.
Par exemple, un scroll puede ser un evento útil para analizar comportamiento, mientras que generate_lead podría configurarse como evento clave si representa una solicitud comercial.
El error está en convertir prácticamente todo en evento clave, porque entonces esa clasificación deja de aportar información realmente útil.
Porque recibir un parámetro y poder analizarlo como dimensión no siempre es lo mismo.
Si has creado un parámetro personalizado, puede ser necesario registrarlo también como dimensión personalizada para utilizarlo en determinados informes o exploraciones. Antes de hacerlo, comprueba que GA4 no tenga ya una dimensión estándar equivalente.
Siempre que sea técnicamente posible, es preferible medir el resultado real.
Un clic en “Enviar” no significa necesariamente que el formulario se haya enviado correctamente. Puede existir un error de validación, un fallo técnico o incluso un doble clic.
Si quieres medir leads, intenta registrar la confirmación del envío, no simplemente la intención del usuario de enviarlo.
Cambiar ahora un evento no reescribe automáticamente lo que ya se recogió anteriormente.
Si renombramos lead_form como generate_lead, por ejemplo, los datos antiguos seguirán existiendo bajo el nombre anterior. Por eso conviene documentar cualquier cambio importante con su fecha y tenerlo en cuenta al analizar periodos largos.
Non.
GA4 puede recoger eventos automáticamente y también existen otras formas de implementación. Sin embargo, Google Tag Manager ofrece mucho más control cuando necesitamos medir acciones personalizadas, trabajar con variables dinámicas o gestionar varias etiquetas desde un mismo lugar.
El problema no es utilizar GTM, sino hacerlo sin una estructura clara de nombres, activadores y parámetros.
No existe un número ideal.
La pregunta importante es si cada evento responde a una necesidad real de análisis. Medir decenas de clics únicamente “por si algún día hacen falta” suele generar más ruido que información útil.
Una buena implementación no es la que recoge más datos, sino la que permite responder con confianza a las preguntas importantes del negocio.
Les errores al configurar eventos en GA4 no siempre provocan que Analytics deje de medir. De hecho, los más peligrosos son justo los contrarios: aquellos en los que los datos siguen llegando, pero representan mal lo que está ocurriendo.
Un evento duplicado, un activador demasiado amplio, un parámetro inconsistente o una acción mal definida pueden alterar informes, eventos clave y decisiones de negocio sin que aparezca ningún aviso evidente.
Por eso, configurar eventos en GA4 no debería consistir únicamente en conseguir que “el evento aparezca”. Hay que comprobar que se dispara en el momento correcto, una sola vez, con los parámetros adecuados y con una estructura que tenga sentido cuando llegue el momento de analizar los datos.
La mejor forma de trabajar es bastante sencilla: medir solo lo que realmente aporta información, utilizar eventos recomendados cuando encajan, validar siempre antes de publicar y mantener una nomenclatura coherente.
GA4 y Google Tag Manager ofrecen muchísimo margen para personalizar la medición. Esa flexibilidad es una ventaja, pero también obliga a trabajar con cierta disciplina. Cuanto mejor esté planteada la implementación desde el principio, menos tiempo tendremos que dedicar después a averiguar por qué las conversiones se han duplicado misteriosamente o por qué un informe no coincide con la realidad.
Porque, al final, medir más no significa medir mejor.
La analítica solo es útil cuando puedes confiar en los datos que estás utilizando para tomar decisiones.
Entrées connexes
