De todas las auditorías de analítica que hemos hecho, todavía no hemos encontrado una instalación de GA4 perfecta. Ni una. Lo habitual es encontrar eventos duplicados que inflan las métricas, un consent mode mal configurado que descarta la mitad de los datos, y conversiones sin definir — con lo que las campañas de paid optimizan a ciegas.
Y el problema es serio: todo el growth marketing se apoya en los datos. Si el tracking está roto, cada test A/B, cada decisión de presupuesto y cada dashboard construido encima está contaminado. En esta guía explicamos cómo implementar GA4 bien: el modelo de eventos, qué medir, cómo montarlo con Google Tag Manager y los errores que vemos repetirse en casi todas las cuentas.
Por qué la mayoría de instalaciones GA4 están rotas
Tres causas explican el 90% de los desastres que auditamos:
- Datos duplicados. La combinación clásica: el snippet de gtag.js pegado en la plantilla y GA4 disparándose también desde Google Tag Manager. Resultado: dos
page_viewpor página, conversiones dobles y ratios que no cuadran con el negocio. También pasa con plugins de CMS que “ya incluyen analytics” conviviendo con el tag manual. - Consent mode mal puesto (o ausente). Desde marzo de 2024, consent mode v2 es obligatorio para usar audiencias y remarketing de Google en el EEE. Lo vemos mal implementado constantemente: el banner de cookies bloquea GA4 por completo (pérdida total de datos de quienes rechazan), o al revés, dispara todo sin esperar el consentimiento (problema legal).
- Conversiones sin definir. GA4 no sabe qué es importante para tu negocio. Si nadie marca eventos como conversión (key events), Google Ads optimiza hacia clics, los informes no responden preguntas de negocio y “tener analytics” se queda en tener un contador de visitas.
La buena noticia: nada de esto es difícil de arreglar. Lo difícil es detectarlo, porque un tracking roto produce números igual de bonitos que uno sano.
El modelo de eventos de GA4: olvida las categorías de Universal Analytics
Si vienes de Universal Analytics, lo primero es desaprender. UA tenía tipos de hit distintos (pageviews, eventos con categoría/acción/etiqueta, transacciones). En GA4 todo es un evento con parámetros:
evento: sign_up
parámetros: { method: "google", plan: "free" }Esto tiene dos implicaciones prácticas:
- No metas la información en el nombre del evento.
click_boton_verde_homees un anti-patrón; lo correcto es un evento genérico (cta_click) con parámetros (location: "home",cta_text: "..."). Menos eventos, más parámetros. - Los parámetros personalizados no aparecen en informes por arte de magia. Hay que registrarlos como dimensiones o métricas personalizadas en la propiedad. Es el olvido más común: eventos ricos en parámetros que nadie puede consultar.
GA4 además trae eventos automáticos (page_view, session_start) y de medición mejorada (scroll, click saliente, file_download, video_start…). Revísalos antes de crear los tuyos: no midas a mano lo que ya viene de serie.
Qué medir: un plan de medición ligado al embudo
El error de base no suele ser técnico sino de diseño: medir sin plan. Nuestro punto de partida es siempre el mismo: un evento bien definido por cada etapa del embudo AARRR.
| Etapa | Evento ejemplo (SaaS B2B) | Parámetros clave |
|---|---|---|
| Adquisición | generate_lead / sign_up | method, canal (UTM) |
| Activación | onboarding_complete, primera acción de valor | steps_completed, time_to_value |
| Retención | feature_used recurrente | feature_name |
| Revenue | purchase / subscribe | value, currency, plan |
| Referral | invite_sent, share | method |
El plan de medición es un documento (una hoja de cálculo basta) con: nombre del evento, cuándo se dispara, parámetros, quién lo consume y para qué decisión. Si un evento no tiene respuesta a “¿qué decisión alimenta?”, no se implementa. Diez eventos documentados valen más que cien improvisados.
Implementación con Google Tag Manager
Nuestra recomendación por defecto: un solo punto de entrada (GTM) y un dataLayer bien poblado. Nada de gtag.js hardcodeado conviviendo con el contenedor.
- El dataLayer es el contrato entre desarrollo y marketing. El equipo de producto hace push de eventos con sus parámetros (
dataLayer.push({event: "sign_up", method: "google"})) y GTM los traduce a tags. Así el tracking sobrevive a rediseños: no depende de clases CSS ni de selectores frágiles. - Convenciones de nombres desde el día uno:
snake_casesiempre (GA4 distingue mayúsculas:sign_upySign_Upson dos eventos distintos), verbos en inglés consistentes con los eventos recomendados de Google (sign_up,purchase,generate_lead) y prefijos para lo custom si ayuda (sw_para eventos propios). Documentado en el plan de medición. - Entornos y versiones: GTM permite probar en preview, publicar con versiones y hacer rollback. Úsalo. Un cambio de tracking sin probar es un incidente de datos esperando fecha.
Conversiones y audiencias
Con los eventos fluyendo, quedan dos pasos que casi nadie da:
- Marca como conversión (key event) solo lo que es negocio: lead, registro, compra, demo solicitada. Marcar
scrollopage_viewcomo conversión destruye la utilidad del dato y confunde a Google Ads. Entre 3 y 5 conversiones bien elegidas es lo normal. - Construye audiencias sobre comportamiento: usuarios que activaron pero no pagaron, carritos abandonados, visitantes de pricing sin conversión. Exportadas a Google Ads, convierten tu analítica en músculo de remarketing y similar audiences. Es la parte de GA4 que paga la factura.
Consent mode v2 y la pérdida de datos
Con consent mode v2 bien implementado, cuando el usuario rechaza cookies GA4 envía pings anónimos (sin cookies) en lugar de no enviar nada. Con ellos, Google aplica modelado de comportamiento y conversiones: estima estadísticamente los datos de quienes rechazaron, a partir de los patrones de quienes aceptaron.
Lo que hay que asumir: vas a perder granularidad sí o sí. Con tasas de rechazo del 20-40% habituales en Europa, tus números absolutos son parcialmente modelados. Las implicaciones prácticas:
- Configura el consent mode en modo avanzado (pings anónimos) y no en básico (bloqueo total) si quieres que el modelado funcione.
- Trata GA4 como herramienta direccional: tendencias y comparativas fiables, cifras absolutas aproximadas.
- La fuente de verdad de negocio (ventas, leads) debe ser tu backend o CRM, nunca la herramienta de analítica.
Cuándo dar el siguiente paso: server-side y analítica de producto
GA4 client-side bien montado cubre mucho, pero tiene techo:
- Tracking server-side (GTM Server-Side): tiene sentido cuando los adblockers e ITP te comen una parte relevante de los datos y la inversión en paid justifica recuperarla, o cuando quieres enriquecer eventos con datos de backend y controlar qué se comparte con cada plataforma. Es infraestructura: requiere ingeniería, no solo configuración.
- Herramienta de analítica de producto (PostHog, Mixpanel, Amplitude): cuando las preguntas dejan de ser de marketing (“¿qué canal convierte?”) y pasan a ser de producto (“¿qué hacen los usuarios que retienen y no hacen los que se van?”). Cohortes flexibles, funnels ad hoc, session replay y feature flags — terreno donde GA4 no llega.
La combinación habitual en empresas con producto digital: GA4 para marketing y campañas + una herramienta de producto para comportamiento. Si estás en ese punto, es exactamente lo que montamos en nuestro servicio de data & analytics.
Checklist de auditoría GA4
Antes de dar el tracking por bueno:
- Un único punto de disparo (GTM o gtag, no ambos) y sin
page_viewduplicados en DebugView - Plan de medición documentado: eventos, parámetros, propietario y decisión que alimentan
- Convención de nombres consistente (
snake_case, eventos recomendados de Google donde existan) - Parámetros personalizados registrados como dimensiones/métricas personalizadas
- Conversiones (key events) definidas: solo eventos de negocio, entre 3 y 5
- Consent mode v2 en modo avanzado, verificado con el banner aceptando y rechazando
- Retención de datos subida de 2 a 14 meses (viene en 2 por defecto)
- Tráfico interno y de desarrollo filtrado
- Enlace con Google Ads y Search Console activo
- Verificación en DebugView y Realtime tras cada publicación de GTM
Errores comunes (y cómo evitarlos)
| Error | Consecuencia | Solución |
|---|---|---|
| gtag + GTM disparando a la vez | Eventos y conversiones duplicados | Un solo punto de entrada, verificar en DebugView |
| Consent mode básico o ausente | Pérdida del 20-40% de datos sin modelado | Consent mode v2 avanzado con tu CMP |
| Todo marcado como conversión | Google Ads optimiza hacia ruido | 3-5 key events de negocio reales |
| Información en el nombre del evento | Cientos de eventos inanalizables | Eventos genéricos + parámetros |
| Parámetros sin registrar | Datos enviados pero invisibles en informes | Dimensiones personalizadas en la propiedad |
| Retención de datos en 2 meses | Análisis históricos imposibles en Explore | Subirla a 14 meses el primer día |
| Tracking dependiente de selectores CSS | Se rompe con cada rediseño | dataLayer como contrato con desarrollo |
| Nadie verifica tras publicar | Semanas de datos rotos sin que nadie lo note | DebugView + revisión mensual del plan |
Conclusión
Implementar GA4 bien no es pegar un snippet: es diseñar un plan de medición ligado al embudo, ejecutarlo con disciplina de ingeniería (dataLayer, convenciones, versiones, verificación) y asumir honestamente los límites del dato con consentimiento. La diferencia entre hacerlo bien y hacerlo regular no se ve en la web — se ve tres meses después, cuando las decisiones tomadas con esos datos funcionan o no.
Y si algo hemos aprendido auditando cuentas: es mucho más barato montar el tracking bien una vez que decidir seis meses sobre datos rotos.
¿Sospechas que tu GA4 está midiendo mal? Lo auditamos y lo dejamos fino →