40 caracteres que arruinan GA4: taxonomía de eventos para técnicos
La taxonomía de eventos es la lista gobernada de nombres y parámetros que usarás en GA4 para medir comportamiento y conversiones. La regla práctica es simple: usa un evento recomendado de GA4 cuando tu acción encaje en uno; si no existe, crea un evento personalizado en snake_case, de menos de 40 caracteres, y guarda el contexto en parámetros, nunca en el nombre del evento.
En resumen:
- Solo los eventos recomendados y personalizados requieren intervención activa, mientras que los automáticos y de medición optimizada no necesitan configuración adicional.
- Es crucial respetar las reglas de nombrado en snake_case, limitar los nombres a 40 caracteres y empezar por una letra para evitar errores y colisiones en GA4.
- La distinción entre evento y parámetro debe basarse en si la variación modifica la acción o solo la describe, priorizando el uso de parámetros para detalles adicionales.
- La gobernanza, con un responsable que revise y actualice trimestralmente la taxonomía, evita la proliferación de nombres redundantes o desactualizados.
- Integrar herramientas automáticas y documentar en una tabla compartida ayuda a mantener una taxonomía activa y coherente en múltiples sitios o equipos.
Tabla de contenidos
- Las cuatro categorías de eventos en GA4: qué son y qué requieren
- Reglas técnicas obligatorias y checklist de naming para GA4
- Evento o parámetro: cómo decidirlo con ejemplos
- Del dataLayer a GA4: implementación y validación paso a paso
- Gobernanza: quién mantiene la taxonomía y con qué frecuencia
- Plantilla de registro maestro para tu taxonomía
- Prefijos, verbos y por qué el contexto no va en el nombre
- Lo que la mayoría se equivoca al diseñar su taxonomía
- Cómo LG DataOne facilita el mantenimiento de tu taxonomía
- Fuentes
- Preguntas frecuentes
Las cuatro categorías de eventos en GA4: qué son y qué requieren
GA4 organiza toda la medición en cuatro categorías, y solo dos de ellas exigen trabajo de configuración por tu parte. Confundir estas categorías es la razón por la que muchos equipos duplican eventos que la plataforma ya captura sola.
- Eventos automáticos: GA4 los recopila sin ninguna instrumentación, como
first_visitosession_start. - Eventos de medición optimizada: se activan al habilitar una casilla en la configuración del flujo de datos, por ejemplo
scrollofile_download. - Eventos recomendados: GA4 los define con nombre y parámetros fijos (
add_to_cart,purchase,generate_lead), pero tú decides cuándo dispararlos. - Eventos personalizados: los diseñas desde cero cuando ninguna categoría anterior cubre la acción que necesitas medir.
Solo las dos últimas categorías requieren intervención real: decidir el disparador, mapear los parámetros y validar que llegan bien a GA4. Los eventos automáticos y los de medición optimizada quedan fuera de tu taxonomía documentada, aunque conviene anotarlos para que el equipo sepa que ya existen y no los reconstruya.
Usar un evento recomendado en lugar de inventar uno propio desbloquea informes predefinidos de GA4 y mejora la compatibilidad con futuras actualizaciones de la plataforma, según indica la documentación oficial de eventos recomendados. Esa es la primera decisión de diseño, antes de escribir una sola línea de código.
Reglas técnicas obligatorias y checklist de naming para GA4
GA4 impone restricciones formales que no son negociables, y saltárselas provoca errores silenciosos que solo detectas semanas después, cuando el informe no cuadra. Las reglas obligatorias son:
- El nombre debe usar snake_case (palabras en minúscula separadas por guion bajo), nunca camelCase ni espacios.
- No puede superar los 40 caracteres.
- Debe empezar por una letra, nunca por un número o un guion bajo.
- No admite espacios ni caracteres especiales como
%,#o/. - GA4 distingue mayúsculas de minúsculas:
Purchaseypurchaseson dos eventos distintos para la plataforma.
Superar el límite de 40 caracteres provoca truncamiento automático, y ahí es donde aparecen las colisiones: dos eventos con nombres largos y parecidos pueden acabar truncados al mismo texto, mezclando sus datos sin que nadie lo note hasta la auditoría.
Consejo profesional: Antes de publicar cualquier evento nuevo, pégalo en un contador de caracteres y pregúntate en voz alta cómo lo leerías a un compañero. Si suena raro o ambiguo, el nombre está mal diseñado, no solo mal escrito.
Checklist rápida antes de aprobar un nombre: que empiece por letra, que esté en snake_case, que no pase de 40 caracteres, que no repita un nombre ya usado con mayúsculas distintas y que no incluya información que debería ir en un parámetro.
Evento o parámetro: cómo decidirlo con ejemplos
La pregunta que define una buena taxonomía de eventos es esta: ¿la variación que quiero medir cambia la acción del usuario, o solo describe esa acción? Si cambia la acción, es un evento nuevo. Si solo la describe, es un parámetro.
- Un clic en «añadir al carrito» es siempre el mismo evento (
add_to_cart), sin importar si el producto es una camiseta o unas botas; el producto va en el parámetroitem_name. - Un envío de formulario es un evento (
generate_leadoform_submit); el tipo de formulario (contacto, newsletter, presupuesto) va en un parámetro comoform_type. - Una reproducción de vídeo es un evento (
video_start); el título del vídeo y el porcentaje visto son parámetros, no eventos distintos por cada vídeo.
El anti‑patrón más habitual es crear add_to_cart_camiseta y add_to_cart_botas en lugar de un único evento con parámetro. Esta práctica infla el número de nombres distintos y agota antes de tiempo el límite de 500 eventos por propiedad estándar que permite GA4, como advierte la guía de eventos personalizados de Advanze. Mantener pocos eventos con parámetros ricos facilita además cualquier análisis posterior, porque puedes segmentar sin multiplicar consultas.
Del dataLayer a GA4: implementación y validación paso a paso
Tutorial 2 de LG DataOne: gestión de DataLayers. Vídeo de apoyo para comprender cómo organizar el seguimiento de eventos y datos en la plataforma.
La cadena técnica correcta tiene tres eslabones: el sitio envía datos al dataLayer, Google Tag Manager los captura con un activador, y una etiqueta de tipo «Google Analytics: evento de GA4» los reenvía a tu propiedad, según describe la documentación de Tag Manager. Romper este orden, o saltarte un paso, es la causa más frecuente de eventos que «no llegan».
Para que el dataLayer sea reutilizable, conviene estructurarlo como un objeto consistente en cada página, con las mismas claves aunque cambie el contenido:
- Usa siempre la misma clave para el nombre de evento (
event) y para los parámetros que se repiten entre páginas, comopage_typeouser_status. - Agrupa los datos de producto o transacción en un objeto anidado (
ecommerce) en vez de aplanarlos en variables sueltas. - Evita nombres de variable distintos para el mismo dato en páginas diferentes; eso obliga a duplicar variables en GTM.
En Google Tag Manager, define variables de capa de datos con nombres idénticos a las claves del dataLayer y activadores de tipo «evento personalizado» que escuchen el nombre exacto del evento. Reutilizar la misma variable en varias etiquetas, en lugar de crear una por etiqueta, reduce la duplicidad y facilita el mantenimiento cuando cambias un parámetro.
La validación nunca es opcional. El proceso mínimo antes de publicar cualquier cambio combina dos capas: GTM Preview, donde compruebas que el activador dispara y la etiqueta envía los parámetros esperados, y GA4 DebugView, donde confirmas que el evento llega con el nombre y los valores correctos a la propiedad real. Contar con esta validación en dos capas, junto con una checklist técnica previa a publicar, reduce errores comunes y evita rehacer instrumentación semanas después, según señala Advanze en su guía de eventos personalizados.
Gobernanza: quién mantiene la taxonomía y con qué frecuencia
Una taxonomía de eventos no es un documento que se cierra al terminar la implementación. Sin un responsable claro, la nomenclatura se degrada en pocos meses: alguien crea un evento parecido a otro que ya existía porque nadie revisó el registro antes de publicar.
- Asigna un propietario de la taxonomía (normalmente en el equipo de analítica) que apruebe cualquier evento nuevo antes de que llegue a producción.
- Fija una revisión trimestral mínima para detectar eventos huérfanos, duplicados o que ya no se disparan.
- Registra cada cambio con fecha, versión y motivo en el mismo documento que usa el equipo de implementación, no en un correo suelto.
- Diferencia entre cambios menores (ajustar un parámetro) y cambios mayores (renombrar un evento), porque estos últimos rompen comparativas históricas si no se documentan.
Una taxonomía saludable es iterativa y necesita ese responsable fijo; sin gobernanza, la calidad de los datos se degrada con el tiempo aunque la implementación inicial fuera impecable, tal como recoge el análisis de arquitectura de eventos y parámetros de Pablo Moratinos.
Consejo profesional: Guarda la guía de naming como una hoja viva, no como un PDF. Un documento que nadie puede editar rápido es un documento que nadie actualiza, y una taxonomía sin actualizar es peor que no tener taxonomía.
Herramientas especializadas pueden apoyar esta gobernanza con auditorías automáticas que detectan eventos duplicados, nombres fuera de norma o parámetros que dejaron de recibir datos, sin depender de una revisión manual exhaustiva cada trimestre.
Plantilla de registro maestro para tu taxonomía
Documentar cada evento en una tabla compartida es lo que separa una taxonomía viva de una lista de nombres olvidada en un documento antiguo. La estructura mínima necesita cuatro columnas, y conviene ampliarla con estado y fecha de última revisión.
| Evento | Parámetros clave | Responsable | Estado |
|---|---|---|---|
| add_to_cart | item_name, price, quantity | Equipo CRO | Activo |
| generate_lead | form_type, page_location | Marketing | Activo |
| video_progress_75 | video_title, video_duration | Contenido | En revisión |
Sincroniza esta tabla con el repositorio o el contenedor de GTM donde vives la implementación, para que cualquier cambio de nombre se refleje primero en el registro y después en producción, nunca al revés. Documentar la taxonomía con versión y registro de cambios en una hoja de cálculo compartida es, según la guía de taxonomía de Minders, la práctica más efectiva para equipos distribuidos que trabajan sobre la misma propiedad de GA4.
Prefijos, verbos y por qué el contexto no va en el nombre
Agrupar eventos por prefijo es la convención que más tiempo ahorra cuando la taxonomía crece. Prefijos como content_, video_ o checkout_ permiten filtrar informes por familia de eventos sin depender de memorizar cada nombre suelto, una práctica que recoge la guía de reglas de naming de TaggingDocs.
El patrón más estable dentro de cada familia es verbo_objeto: video_start, form_submit, checkout_complete. Este orden deja claro qué acción ocurrió y sobre qué elemento, y resulta más fácil de leer en un informe que un nombre invertido o ambiguo como submit_the_contact_form.
El error que más nombres distintos genera es cargar el contexto dentro del propio nombre del evento en lugar de moverlo a un parámetro. Escribir add_to_cart_categoria_ropa en vez de add_to_cart con un parámetro item_category no solo rompe el patrón verbo_objeto: dispara el conteo de eventos distintos mucho antes de agotar el volumen real de acciones que mides. GA4 admite hasta 500 nombres de evento distintos en una propiedad estándar, así que cada variante innecesaria consume ese margen sin motivo.
La regla que resume esta sección: el nombre del evento responde a «¿qué acción ocurrió?», y el parámetro responde a «¿con qué detalles?». Si te encuentras escribiendo un nombre largo para describir una variación, esa variación probablemente pertenece a un parámetro.
Lo que la mayoría se equivoca al diseñar su taxonomía
La mayoría de guías sobre taxonomía de eventos se centran en la sintaxis (snake_case, límites de caracteres) y olvidan que el problema real casi nunca es técnico. El problema real es organizativo: nadie es responsable de decir que no a un evento redundante antes de que llegue a producción.
Lo que sorprende, después de ver decenas de implementaciones, es que las propiedades de GA4 mejor estructuradas no son las que tienen más eventos personalizados, sino las que tienen menos. Equipos que priorizan eventos recomendados y parámetros ricos por encima de crear un evento por cada matiz acaban con taxonomías de 40 o 50 nombres que cubren todo el negocio, frente a propiedades con 300 eventos donde la mitad son variantes del mismo hecho.
La checklist técnica importa, pero no es lo que falla primero. Lo que falla primero es la falta de gobernanza: nadie revisa, nadie versiona, nadie dice «este evento ya existe con otro nombre». Si tu equipo solo puede invertir tiempo en una cosa esta semana, que sea nombrar un propietario de la taxonomía, no pulir la sintaxis de un evento aislado.
— Juan
Cómo LG DataOne facilita el mantenimiento de tu taxonomía
Mantener una taxonomía limpia a mano, evento por evento, es exactamente el tipo de trabajo manual y repetitivo que consume horas de un equipo de analítica cada mes, que se puede optimizar con automatización en software personalizado.
Si tu equipo ya gestiona GA4 y GTM en varios sitios o clientes, LG DataOne centraliza esas auditorías en un único panel en lugar de revisar propiedad por propiedad a mano. También conecta esa base de datos limpia con pruebas A/B y mejoras de conversión, para que la taxonomía que acabas de ordenar sirva directamente para decidir qué optimizar. Puedes empezar con la prueba gratuita de 14 días y comprobar sobre tu propia propiedad qué eventos están mal nombrados antes de que sigan contaminando tus informes.
Recursos para ampliar esta guía: artículo relacionado y funcionalidad de LG DataOne.
Fuentes
Preguntas frecuentes
¿Qué es exactamente una taxonomía de eventos en GA4?
Es el conjunto documentado de nombres de evento y parámetros que usa una organización en GA4, con reglas de naming, propietario y registro de cambios, para que la medición sea consistente entre equipos.
¿Cuántos caracteres puede tener el nombre de un evento en GA4?
El límite es de 40 caracteres; superarlo provoca truncamiento automático y puede generar colisiones entre eventos con nombres parecidos.
¿Cuándo debo usar un evento recomendado en lugar de uno personalizado?
Siempre que la acción encaje en la definición de un evento recomendado de GA4, como add_to_cart o purchase, porque desbloquea informes predefinidos y evita reconstruir esa lógica manualmente.
¿Cuántos eventos distintos permite GA4 por propiedad?
Una propiedad estándar admite hasta 500 nombres de evento distintos y 25 parámetros por evento, un límite que se agota rápido si se carga contexto en el nombre en lugar de usar parámetros.
¿Cómo se valida un evento antes de publicarlo en producción?
Se comprueba primero en GTM Preview, verificando que el activador y la etiqueta funcionan, y después en GA4 DebugView, confirmando que el evento llega con el nombre y los parámetros correctos a la propiedad real.
