Configurar GA4 bien significa siete cosas que casi nadie hace al instalarlo: marcar como eventos clave solo las conversiones de negocio, activar el modo de consentimiento, filtrar el tráfico interno, excluir las pasarelas de pago de los referidos, configurar los dominios cruzados, unificar las UTM y subir la retención de datos. Sin ellas, GA4 cuenta visitas, pero no sirve para decidir.
Este artículo es para quien tiene GA4 instalado desde hace años y nunca lo ha revisado, para quien acaba de heredar la cuenta de una agencia anterior y para quien va a montar un panel y sospecha que los datos de abajo están mal. Cada error lleva cómo detectarlo en tu propiedad y cómo arreglarlo, con el nombre exacto de la pantalla.
Los siete son los puntos que revisamos en cada auditoría de medición, y cada uno se comprueba con la documentación de Google enlazada.
¿Cómo saber si tu GA4 está mal configurado?
Tu GA4 está mal configurado si responde que sí a alguna de estas preguntas: tiene más de tres eventos clave, el número de compras no cuadra con los pedidos de la tienda, aparece tu propio dominio o una pasarela de pago como fuente de tráfico, el canal «Unassigned» crece cada mes, o la retención de datos sigue en dos meses. Cada una es un síntoma de uno de los siete errores.
Cuando audito una propiedad, lo primero que abro no es un informe: es la pantalla de Administrar. Ahí está casi todo lo que falla, porque GA4 por defecto viene preparado para contar páginas vistas y nada más. Ninguno de los siete errores exige programar.
| Error | Dónde se ve el síntoma | Qué falsea |
|---|---|---|
| 1. Sin eventos de conversión, o conversiones de clic | Informes > Participación > Eventos clave | Cuántos leads o pedidos trae cada canal |
| 2. Sin modo de consentimiento | Herramientas del navegador, pestaña Red, parámetro gcs | La legalidad del dato y el total de conversiones |
| 3. Tráfico interno sin filtrar | Informes de usuarios por ciudad y páginas de administración | Visitas, tasa de rebote y conversiones de prueba |
| 4. Referidos de pasarela de pago | Adquisición de tráfico: paypal.com, redsys.es como fuente | A quién se atribuye cada compra |
| 5. Dominios cruzados sin configurar | Tu propio dominio como referencia; usuarios duplicados | El origen real de la sesión que convierte |
| 6. UTM inconsistentes | Canal «Unassigned» o «(other)» creciendo | El reparto entre email, redes y campañas |
| 7. Retención de datos por defecto | Administrar > Retención de datos: 2 meses | Cualquier comparación con el año anterior en exploraciones |
Es el repaso con el que empieza nuestro servicio de datos para decidir: la auditoría de medición cuesta 490 € y entrega la lista de errores con cómo arreglar cada uno. Si prefieres hacerlo tú, los siete apartados siguientes son el mismo guion.
¿Por qué GA4 no mide conversiones de negocio?
GA4 no mide conversiones de negocio porque, recién instalado, no tiene ningún evento clave, y cuando alguien marca alguno suele elegir los que GA4 recoge solo: click, form_start, form_submit o scroll. Son eventos de clic, no de negocio: form_submit se dispara con el buscador de la web y con la newsletter igual que con el formulario de presupuesto. El resultado es una propiedad con quince «conversiones» y ninguna que signifique un cliente.
GA4 llama «eventos clave» a los que cuentan como conversión en informes y atribución. Los de la medición mejorada (desplazamiento, clics salientes, envíos de formulario) se recogen sin configurar nada, y por eso son los primeros que alguien marca. Pero un form_submit no sabe qué formulario era ni si el envío llegó.
Cómo detectarlo: en Administrar > Visualización de datos > Eventos clave, cuenta cuántos hay y qué nombres tienen. Si hay más de tres, o si aparece cualquier nombre de la medición mejorada, el error está. Después compara el número de purchase de los últimos 30 días con los pedidos pagados de la tienda; una diferencia pequeña la explica el consentimiento rechazado, una grande la explica una etiqueta que no se dispara o se dispara dos veces.
Cómo arreglarlo: definir por escrito los eventos de negocio (para servicios, generate_lead con el parámetro del tipo de servicio; para tienda, purchase con value, currency, transaction_id e items), dispararlos desde Google Tag Manager en la página de gracias o en la respuesta del servidor, y marcar como eventos clave solo esos. Dos o tres eventos clave por propiedad es lo normal; los demás eventos siguen existiendo, pero no cuentan como conversión.
¿Qué pasa si GA4 no tiene modo de consentimiento?
Si GA4 no tiene modo de consentimiento, o mide a todo el mundo sin permiso, que es ilegal en la Unión Europea, o deja de medir a quien rechaza y pierde esas conversiones sin modelar. El modo de consentimiento es la forma en que la etiqueta de Google recibe lo que el usuario eligió en el banner: con consentimiento, cookies y medición normal; sin él, pings sin cookies que permiten modelar.
Google lo documenta en la página del Consent Mode: cuando analytics_storage está denegado, Analytics no lee ni escribe cookies propias y envía pings sin identificador con dimensiones gruesas, que Google usa para modelar el comportamiento y las conversiones de quien rechazó. Hay dos implementaciones: la básica bloquea las etiquetas hasta que hay consentimiento y no permite modelar; la avanzada carga las etiquetas antes del banner y envía los pings sin cookies.
Cómo detectarlo: abre la web en una ventana privada con las herramientas del navegador en la pestaña Red, filtra por collect y mira la petición a Google Analytics antes de tocar el banner. Si no hay parámetro gcs, no hay modo de consentimiento. Si pone G111 antes de aceptar, se está midiendo con cookies sin permiso. Lo correcto antes de responder al banner es G100 y ninguna cookie _ga en el navegador.
Cómo arreglarlo: en Google Tag Manager, una plantilla de la plataforma de consentimiento que uses, un activador de «Inicialización del consentimiento» que fije el estado por defecto en denegado para la Unión Europea, y las etiquetas de Google con la comprobación de consentimiento integrada. Lo desarrollo, con la parte legal y la tabla de comprobaciones, en Consent Mode v2.
¿Por qué el tráfico interno y las pasarelas de pago falsean GA4?
Falsean GA4 porque añaden sesiones que no son de clientes y porque cambian el origen de las que sí lo son. El tráfico interno (tu equipo, la agencia, el entorno de pruebas) infla visitas y genera conversiones de prueba. La pasarela de pago rompe la sesión de compra: el usuario sale a Redsys o PayPal, vuelve, y GA4 abre una sesión nueva cuya fuente es la pasarela, que se lleva el mérito del pedido.
El tráfico interno se filtra en dos pasos, y es habitual encontrar el primero hecho y el segundo no. Primero, en Administrar > Flujos de datos > tu flujo web > Configurar ajustes de etiquetas > Definir tráfico interno, se crea una regla por dirección IP que marca ese tráfico con traffic_type = internal. Segundo, en Administrar > Recogida y modificación de datos > Filtros de datos, el filtro «Internal Traffic» viene en estado «Prueba» y hay que pasarlo a «Activo». En prueba no excluye nada; solo etiqueta. Y el filtro no es retroactivo: lo que entró antes se queda.
Para detectarlo, en una exploración añade la dimensión «Nombre del filtro de prueba de datos» y mira cuánto tráfico lleva la etiqueta Internal Traffic. Si tu equipo trabaja con IP dinámica, la regla por IP no basta; se usa una cookie que la etiqueta lee o un perfil de navegador sin la etiqueta.
Las pasarelas se excluyen en Administrar > Flujos de datos > tu flujo web > Configurar ajustes de etiquetas > Enumerar referencias no deseadas. Ahí van los dominios de las pasarelas que uses (Redsys, PayPal, Stripe, la de tu banco). Para detectar el error, abre Adquisición de tráfico y busca esos dominios como fuente: si aparecen con compras atribuidas, cada una de esas compras tenía otro origen real que has perdido. Los modelos de atribución de GA4 reparten el crédito entre las fuentes que ven; si la última fuente es la pasarela, el reparto nace roto.
¿Qué rompe la atribución en GA4: dominios cruzados y UTM?
La atribución se rompe cuando GA4 pierde el hilo entre la visita y la conversión, y eso pasa por dos vías: el usuario cambia de dominio sin que las etiquetas se pasen el identificador, o llega con parámetros UTM que GA4 no sabe clasificar. En los dos casos la conversión existe, pero se asigna a «Directo», a «Unassigned» o a tu propio dominio, y el canal que la trajo no se lleva nada.
Los dominios cruzados hacen falta cuando parte del recorrido vive en otro dominio: el motor de reservas de un tercero, un formulario alojado fuera, un checkout en otra marca. Entre subdominios de la misma web no hace falta, porque la cookie se comparte. El síntoma es tu propio dominio, o el del tercero, como fuente de referencia en Adquisición de tráfico, y un número de usuarios que no cuadra porque cada dominio cuenta el suyo.
Se arregla en Administrar > Flujos de datos > tu flujo web > Configurar ajustes de etiquetas > Configurar tus dominios, añadiendo todos los dominios del recorrido. A partir de ahí la etiqueta añade el parámetro _gl a los enlaces entre ellos y el identificador viaja con el usuario. Para comprobarlo, haz clic en un enlace entre dominios y mira si la URL de destino lleva _gl=.
Las UTM fallan por inconsistencia, no por ausencia. GA4 distingue mayúsculas: Newsletter y newsletter son dos fuentes distintas. El canal se asigna por reglas sobre el medio: email va al canal Email, cpc a Búsqueda de pago, social a Social orgánico; un utm_medium=mailing o =boletin cae en «Unassigned». Y una UTM en un enlace interno de tu propia web reinicia la sesión y le cambia la fuente.
Cómo arreglarlo: una hoja de nomenclatura con tres columnas (fuente, medio, campaña), todo en minúsculas, con los medios que GA4 reconoce, y un único constructor de URLs que todo el equipo use. Para detectar el daño ya hecho, en Adquisición de tráfico filtra por canal «Unassigned» y mira qué fuentes y medios lo componen; esa lista es tu hoja de nomenclatura al revés.
¿Por qué la retención de datos por defecto te borra el histórico?
La retención de datos por defecto te borra el histórico porque GA4 guarda los datos de usuario y evento que usan las exploraciones durante dos meses si nadie cambia el ajuste; la alternativa en una propiedad estándar es catorce. Pasados esos meses, cualquier exploración o embudo sobre periodos anteriores devuelve nada. Los informes estándar, agregados, no se ven afectados; las preguntas interesantes casi nunca se responden con ellos.
Está en Administrar > Recogida y modificación de datos > Retención de datos. Cambiarlo a catorce meses lleva diez segundos y no es retroactivo: lo que ya ha expirado no vuelve. Por eso es el primer ajuste que toco en cualquier propiedad nueva.
Catorce meses siguen siendo pocos cuando quieres comparar con el año anterior en una exploración, y aquí entra la segunda mitad del arreglo: la exportación de GA4 a BigQuery. Es gratuita en la propiedad estándar, con un límite de un millón de eventos al día en la exportación diaria, y envía los eventos en bruto a un conjunto de datos tuyo, donde se quedan el tiempo que decidas. Los datos que no se exportan desde el primer día no se recuperan después.
Lo que llega a BigQuery está descrito en el esquema de exportación: una tabla por día, events_AAAAMMDD, con una fila por evento, los parámetros anidados en event_params, el identificador user_pseudo_id y las dimensiones de tráfico, dispositivo y geografía. Es la materia prima de cualquier panel serio, y la única copia de GA4 que no caduca.
¿En qué orden hay que arreglar GA4?
El orden es consentimiento, retención, eventos, filtros, referidos, dominios y UTM. El consentimiento va primero porque es la parte legal; la retención, porque es el único ajuste que pierde datos cada día que pasa; los eventos, porque sin ellos lo demás no tiene nada que atribuir. Los otros cuatro limpian el dato que ya se recoge. Una propiedad pequeña se arregla en una tarde; una tienda con varios dominios, en una semana.
- Modo de consentimiento comprobado con el parámetro
gcsantes y después de aceptar y de rechazar. - Retención de datos a catorce meses y exportación a BigQuery activada.
- Eventos de negocio definidos por escrito, disparados desde Tag Manager y marcados como eventos clave; nada de la medición mejorada entre ellos.
- Regla de tráfico interno y filtro en estado Activo.
- Pasarelas de pago en la lista de referencias no deseadas.
- Dominios del recorrido en Configurar tus dominios, con
_glcomprobado. - Hoja de nomenclatura UTM y un solo constructor de URLs.
Nada de esto exige medición desde el servidor. El tracking server-side resuelve otros problemas, como los bloqueadores y las conversiones con datos del CRM; explico cuándo compensa en server-side tracking. Antes de pagar por eso, arregla los siete puntos de arriba: son gratis.
Cuando GA4 está limpio, el siguiente paso es que alguien lo mire con una pregunta concreta cada semana, que es de lo que trata la guía de datos y dashboards para marketing. Un GA4 bien configurado y un panel que responde a las tres preguntas del lunes es, para una pyme, todo el sistema de medición que hace falta durante mucho tiempo.
Hay más sobre esto en la sección de datos para decidir del blog.
Preguntas frecuentes
¿Cuántos eventos clave debería tener en GA4?
Dos o tres: el pedido con su importe y el lead cualificado, o su equivalente en tu negocio. Si tienes más de cinco, o alguno de la medición mejorada como form_submit o click, la propiedad cuenta clics como conversiones y los informes de canal no sirven para repartir presupuesto.
¿Cómo sé si mi GA4 tiene el modo de consentimiento activado?
Abre la web en una ventana privada con la pestaña Red del navegador, filtra por collect y mira la petición a Google Analytics antes de tocar el banner. Si lleva el parámetro gcs=G100 y no hay cookie _ga, está bien; si no hay parámetro gcs o pone G111, no hay modo de consentimiento o está mal configurado.
¿Cambiar la retención de datos a 14 meses recupera lo que ya se perdió?
No. El ajuste no es retroactivo: lo que expiró con la retención de dos meses no vuelve. Por eso conviene cambiarlo el primer día y activar la exportación a BigQuery, que guarda los eventos en bruto el tiempo que decidas.
¿Hace falta tracking server-side para arreglar estos errores?
No. Los siete se arreglan en la pantalla de Administrar de GA4 y en Google Tag Manager, sin coste. El server-side resuelve otros problemas, como los bloqueadores de anuncios o enviar conversiones con datos del CRM, y tiene un coste de montaje y mantenimiento que una web pequeña rara vez amortiza.
—
Juan Martínez es el fundador de We Love SEO, en Zaragoza, ingeniero y data scientist. Monta paneles de datos para marketing con GA4, BigQuery, Power BI y Data Studio (antes Looker Studio). Más en el equipo.



