La taxonomía de eventos en GA4 no es una cuestión de estilo: es el límite técnico que decide si marketing y desarrollo miden lo mismo cuando hablan de una venta, un lead o una matrícula. Cuantos más equipos tocan el data layer, antes aparecen dos eventos que nombran la misma acción de forma distinta —compra, purchase, venta_completada— y un informe que no cuadra entre departamentos.
El problema no es exclusivo del ecommerce ni del SaaS: una academia online, una consultora industrial o un despacho que mide formularios de contacto chocan con las mismas reglas de nomenclatura. Esta pieza repasa esos límites y cómo organizarlos por sector sin que cada departamento invente su propio diccionario.
La taxonomía de eventos en GA4 es el conjunto de reglas que fija cómo se nombran los eventos y sus parámetros: nombres de hasta 40 caracteres, 25 parámetros por evento y un máximo de 50 dimensiones personalizadas en una propiedad estándar. Sin esas reglas escritas, cada equipo registra la misma acción con un nombre distinto.
La taxonomía de eventos en GA4 ordena tu medición
Una taxonomía de eventos es el documento —casi siempre una hoja de cálculo compartida— que fija qué evento se dispara en cada acción, con qué nombre exacto y con qué parámetros. GA4 no obliga a tenerla, pero sí impone los límites dentro de los que tiene que funcionar: nombres de evento y de parámetro de hasta 40 caracteres, solo letras, números y guion bajo, y empezando siempre por una letra, según detalla la documentación oficial de límites de recopilación de eventos. Por evento se admiten 25 parámetros como máximo, y cada valor no puede superar los 100 caracteres.
Esos números parecen generosos hasta que varios equipos registran acciones parecidas sin coordinarse. Un departamento comercial llama lead_enviado a lo que el de producto llama formulario_completado, y el informe de generación de leads queda partido en dos eventos que nadie suma. La taxonomía no añade datos nuevos: ordena los que ya se envían para compararlos entre campañas y sectores del mismo negocio, algo parecido a lo que falla con la medición mejorada de GA4 cuando se activa sin revisar qué evento ya cubre lo mismo.
Nomenclatura de eventos: la regla que todos rompen
La regla más incumplida no es compleja: un mismo verbo para una misma acción, siempre en el mismo orden y en minúsculas. GA4 trata las mayúsculas como caracteres distintos al agrupar, así que «Purchase» y «purchase» generan dos filas distintas y nadie las suma sin darse cuenta. Ponerlo por escrito suele exigir más una decisión de gobierno de datos que de analítica pura, y ahí entra una consultoría digital que se sienta con marketing y desarrollo a la vez.
snake_case frente a mayúsculas y espacios sueltos
Google recomienda snake_case —palabras en minúscula separadas por guion bajo— para todos los eventos y parámetros, la misma convención que usan sus propios eventos recomendados como generate_lead o begin_checkout. No es una preferencia estética: el nombre debe empezar por una letra y solo admite caracteres alfanuméricos y guion bajo, así que un espacio o un guion medio puede impedir que el evento se registre.
En la práctica, la convención se rompe antes en los parámetros que en los eventos: marketing manda categoria_producto y desarrollo, dos sprints después, manda categoriaProducto para el mismo dato. GA4 los trata como dos parámetros distintos y ninguno de los dos se rellena en todos los eventos, así que el informe que los cruza sale con huecos que parecen errores de medición y en realidad son errores de nomenclatura.
Un evento recomendado es uno de los que Google predefine con nombre y parámetros fijos —purchase, generate_lead, sign_up—; un evento personalizado es cualquier otro que el equipo inventa cuando ninguno de los predefinidos describe la acción.
Parámetros por evento y sus límites reales
El límite de 25 parámetros por evento suena amplio hasta que se cuenta lo que hace falta para describir un pedido completo: artículo, categoría, precio, divisa, cupón, método de envío, canal de origen, campaña e identificador interno del cliente ya son nueve, antes de añadir nada propio de un sector concreto. Se agotan rápido en comercio electrónico y quedan de sobra en un formulario de contacto, así que no hay una plantilla única: hay que repartir el presupuesto de parámetros según lo que cada evento necesita de verdad.
Veinticinco parámetros no cubren un pedido completo
Un evento de compra con variantes de producto —talla, color, grabado— se queda corto en 25 parámetros si cada artículo manda sus atributos sueltos en vez de ir anidado en el parámetro items, pensado precisamente para eso. La solución no es pedir más límite a Google: es mover a items lo que varía por producto y dejar los 25 parámetros de evento para la acción completa —cupón, método de pago, si es primera compra—. Conviene que quien programa el data layer y quien pide los parámetros sea el mismo equipo de sistemas, porque las propiedades de usuario tienen su propio tope de 25 y tampoco sirven de válvula de escape.
¿Te ayudamos con esto?
Cuéntanos tu caso
Si esto te afecta, escríbenos en dos líneas y te respondemos por email con una valoración concreta.
Eventos recomendados según el sector del negocio
Google no deja la taxonomía completamente en manos del cliente: publica una lista de eventos recomendados por tipo de negocio, con nombre y parámetros ya fijados, para que no haga falta inventar compra_realizada cuando ya existe purchase con la misma función y encima alimenta directamente los informes estándar de GA4. El catálogo cambia según el sector, y mezclar el de uno con las necesidades de otro deja huecos en los informes que vienen de serie.
- Comercio electrónico: view_item, add_to_cart, purchase.
- Generación de leads B2B: generate_lead, qualify_lead, close_convert_lead.
- Educación y empleo: tutorial_complete, generate_lead, sign_up.
- Reservas de servicios locales: view_item, add_to_cart, purchase, igual que en ecommerce pero pensado para franjas horarias.
Comercio electrónico y leads usan el mismo verbo con distinto cierre
Una tienda online cierra la venta con purchase en el instante en que el usuario paga, así que ese evento ya lleva ingresos, artículos y moneda. Un negocio B2B que capta leads no vende en la web: cierra con generate_lead al enviarse el formulario, y la venta real llega semanas después, en el CRM. Tratar un lead como una venta —marcarlo como conversión de valor fijo en el momento del formulario— infla el informe de ingresos con cifras que todavía no existen. El ecommerce necesita view_item, add_to_cart y purchase encadenados; el B2B necesita generate_lead seguido, ya en el CRM, de qualify_lead y close_convert_lead.
GA4 360 amplía el margen de maniobra
Cuando la taxonomía crece porque el negocio opera en varios sectores o países a la vez, los límites estándar se quedan cortos antes que la nomenclatura. GA4 360, la versión de pago, no cambia las reglas de nombrado pero sí multiplica el número de dimensiones y métricas personalizadas que se pueden registrar, además del tope de muestreo ya conocido en GA4 360, según recoge la documentación oficial sobre dimensiones y métricas personalizadas:
| Límite | GA4 estándar | GA4 360 |
|---|---|---|
| Dimensiones personalizadas de evento | 50 | 125 |
| Dimensiones personalizadas de usuario | 25 | 100 |
| Dimensiones personalizadas de producto | 10 | 25 |
| Métricas personalizadas | 50 | 125 |
| Métricas calculadas | 5 | 50 |
Compensa pagar GA4 360 solo por los límites a partir de cierto tamaño
Pasar a GA4 360 cuesta decenas de miles de euros al año, así que multiplicar por dos o tres los límites de dimensiones no justifica el gasto si el problema real es que nadie ha puesto por escrito la taxonomía. Compensa cuando la propiedad estándar ya está en el tope por motivos legítimos: una cadena con variantes de producto por tienda, un marketplace con atributos distintos por categoría o un grupo con marcas que necesitan sus propias dimensiones sin pisarse. Antes de pedir presupuesto, conviene auditar cuántas dimensiones siguen alimentando algún informe: es habitual encontrar la mitad abandonadas, y una auditoría de analítica web detecta en un día las dimensiones muertas, lo que a veces resuelve el problema sin pagar nada.
Preguntas frecuentes sobre taxonomía de eventos en GA4
¿Cuántos caracteres admite el nombre de un evento en GA4?
Hasta 40 caracteres, igual que los nombres de parámetro, y solo letras, números y guion bajo, empezando siempre por una letra. Los valores de los parámetros tienen un tope distinto: 100 caracteres cada uno. Superar el límite no bloquea el envío, pero GA4 trunca o descarta el dato, así que el evento llega incompleto sin avisar.
¿Qué pasa si se superan los 25 parámetros por evento?
GA4 solo procesa los primeros 25 parámetros que recibe en ese evento y descarta el resto sin mostrar ningún error. Por eso conviene mover a un parámetro tipo lista, como items, los datos que varían por producto en lugar de mandarlos sueltos: libera espacio para los que describen la acción completa.
¿Debo usar snake_case o camelCase para nombrar eventos?
snake_case, en minúsculas y con guion bajo, porque es la convención que usan los propios eventos recomendados de Google —purchase, generate_lead— y la que mejor evita duplicados por mayúsculas. Mezclar convenciones entre equipos es la causa más frecuente de eventos que parecen distintos y en realidad miden lo mismo.
¿Compensa crear eventos personalizados en vez de usar los recomendados?
Solo cuando ningún evento recomendado describe la acción. Los recomendados alimentan informes estándar de GA4 sin configuración adicional; un evento personalizado hay que registrarlo a mano como evento clave y no aparece en esos informes por defecto, así que se pierde parte del valor de usar GA4 en primer lugar.
Fuente: Ayuda de Google Analytics — Límites de recopilación de eventos [GA4]
