Cómo migrar a GA4 sin perder datos ni conversiones

Si en tus informes han empezado a aparecer discrepancias (ventas que “no cuadran”, leads que bajan, campañas que parecen peor de lo que son), la causa más frecuente es simple: la migración a GA4 se hizo como una instalación, no como un proyecto de medición. Y GA4, al ser event-based, exige una lógica distinta: nombres coherentes, parámetros bien definidos, deduplicación, consentimiento y controles de calidad.

En esta guía (actualizada a 6 de febrero de 2026) tienes un proceso práctico para migrar a GA4 con GTM evitando los dos dolores típicos: pérdida de conversiones (por mala definición o consentimiento) y datos inutilizables (por eventos duplicados, parámetros inconsistentes o ecommerce incompleto). Si además quieres que tu medición sea útil para SEO moderno (incluyendo resultados con IA y análisis por intención), verás cómo estructurar eventos para que luego puedas analizar bien en exploraciones, BigQuery o tus dashboards.

Si necesitas apoyo técnico para implementarlo o auditarlo, puedes ver nuestros servicios de analítica y automatización o el método de trabajo en SEOAGIL.

1) Qué vas a migrar (mapa de medición y objetivos)

El error #1 en una migración GA4 es empezar creando etiquetas en GTM sin saber qué se pretende medir. En GA4, cada decisión se traduce en eventos, parámetros y conversiones. Si no hay un mapa, acabarás con eventos que no sirven (o peor: que engañan), conversiones mal disparadas y comparativas imposibles.

Tu “migración” debe arrancar con un mapa de medición que responda a 4 preguntas:

• Qué objetivos de negocio quieres medir (leads, ventas, demos, llamadas, suscripciones).
• Qué acciones del usuario indican progreso (microconversiones): envío de formulario, clic en WhatsApp, scroll significativo, uso del buscador interno, añadir al carrito, inicio de checkout.
• Qué fuente de verdad valida cada conversión (CRM, backoffice, pasarela de pago, logs, email de confirmación, etc.).
• Qué equipo es owner de cada pieza (marketing, dev, eCommerce, data) y cómo se gestiona el cambio (versionado en GTM + changelog).

Recomendación práctica: crea una tabla (Google Sheet o Notion) con estas columnas mínimas:

• Evento GA4 (nombre en snake_case, por ejemplo generate_lead o purchase).
• Trigger (GTM) (qué lo dispara exactamente).
• Parámetros (ej.: form_id, lead_type, value, currency).
• Condiciones anti-duplicado (por ejemplo, solo una vez por sesión o usando transaction_id).
• Conversión (sí/no) en GA4.
• Validación (cómo comprobarlo).

Mini-caso típico (lead B2B): si marcas “envío de formulario” como conversión pero el trigger es “clic en botón enviar”, contarás intentos fallidos, errores de validación y envíos duplicados. La definición correcta suele ser: evento disparado en la confirmación real (thank-you o callback JS del submit OK). Esto por sí solo puede “recuperar” conversiones reales y limpiar el ratio de conversión.

Por último, decide qué harás con el histórico. No inventes equivalencias: UA y GA4 no son comparables 1:1. Lo sensato es:

• Exportar/reportar histórico UA donde lo tengas guardado (si procede) y dejarlo como referencia.
• Arrancar GA4 con una definición estable y documentada para comparar “a partir de” una fecha.
• Si tu equipo usa BI, prepara una capa de normalización (nombres, canales, campañas) en BigQuery o en tu pipeline.

2) Implementación en GTM: eventos, conversiones y ecommerce

Con el mapa de medición listo, implementas en GTM con un objetivo claro: medir lo necesario, una sola vez, con parámetros consistentes. En 2026, la implementación más robusta suele combinar:

• GA4 Configuration (o Google tag vía GTM) para la base.
• GA4 Event tags para eventos clave (no para “todo”).
• Data Layer (especialmente para ecommerce) como fuente fiable.
• Consent Mode bien configurado para evitar inframedición o pérdida total en entornos con consentimiento estricto.

Eventos y conversiones: prioriza 6–12 eventos realmente útiles antes de añadir más. En GA4, menos puede ser más si está bien hecho. Para cada evento, define:

• Nombre estable (sin cambios por capricho). Evita espacios y mayúsculas.
• Parámetros con valores controlados (catálogos de valores, no texto libre sin límite).
• Disparo basado en confirmación real (no en intención), y con reglas para evitar dobles envíos.

Configuración GA4 + GTM para campañas: revisa que no rompes el etiquetado:

• UTMs consistentes (source/medium/campaign) y naming estándar.
• Auto-tagging en Google Ads si aplica, y verificación de aterrizajes sin redirecciones que borren parámetros.
• Cross-domain si tienes checkout en otro dominio o subdominio.

Ecommerce (GA4): si vendes online, aquí es donde se “pierden” conversiones con más frecuencia. Tu implementación debe basarse en dataLayer y eventos recomendados (por ejemplo, view_item, add_to_cart, begin_checkout, add_shipping_info, add_payment_info, purchase). Lo crítico en purchase:

• transaction_id único y estable (anti-duplicación).
• value y currency correctos.
• items[] completo (id, name, price, quantity) para que los informes de producto y embudo tengan sentido.

Consent Mode: no es un “extra legal”; afecta directamente a cómo se modelan y atribuyen conversiones. Implementa una solución de consentimiento que:

• Inicialice el estado por defecto (denied) cuando corresponde.
• Actualice el consentimiento cuando el usuario acepta/rechaza.
• Evite disparos de etiquetas no consentidas.

Si tu web necesita mejoras de rendimiento o limpieza de etiquetas para que la medición sea estable (por ejemplo, demasiados píxeles y scripts), revisa nuestras recomendaciones para optimización técnica de webs orientadas a rendimiento y tracking. Una base técnica mala produce datos malos.

Checklist rápido de implementación en GTM:

• Una sola “fuente” para cada evento (evitar duplicar por GA4 auto events + custom + plugins).
• Variables GTM nombradas y versionadas.
• Triggers específicos (no “All Pages” para eventos).
• Publicación con notas de versión.

3) Validación y control de calidad (DebugView + BigQuery)

La migración no termina cuando publicas el contenedor de GTM. Termina cuando confirmas que los datos son completos, deduplicados y accionables. Para eso necesitas QA en tres niveles: navegador, GA4 UI y datos crudos.

Nivel 1: validación en el navegador. Antes de mirar GA4, confirma que:

• El dataLayer contiene lo esperado (especialmente ecommerce).
• Los eventos se disparan una vez (navegación, recargas, SPA).
• No hay eventos “fantasma” por doble implementación (por ejemplo, un plugin que envía purchase y tu GTM también).

Nivel 2: GA4 DebugView y Realtime. DebugView te permite ver los eventos casi en directo en modo depuración. Úsalo para comprobar:

• Que el nombre del evento es correcto.
• Que los parámetros llegan y con formato correcto.
• Que las conversiones se marcan como esperas (ojo: algunas configuraciones tardan en reflejarse).

Nivel 3: BigQuery (calidad y auditoría). Si tu propiedad GA4 está vinculada a BigQuery, podrás hacer controles que la interfaz no facilita. Sin inventar cifras ni prometer “mágicamente más ventas”, BigQuery te ayuda a encontrar problemas reales:

• Duplicados de purchase por transaction_id repetida.
• Caídas anómalas de eventos clave por navegador/país (posibles temas de consentimiento o bloqueos).
• Parámetros nulos (por ejemplo, currency o value faltantes).

Un control práctico de QA (muy habitual en ecommerce) es revisar diariamente:

• Conteo de purchase en GA4 vs pedidos en backend.
• Suma de ingresos en GA4 vs sistema de pagos (teniendo en cuenta devoluciones/IVA si no están alineados).
• Distribución por canal: si “Direct” se dispara de golpe, suele haber problema de UTMs, redirecciones o cross-domain.

Errores comunes que detecta QA (y cómo evitarlos):

• Duplicación por thank-you: el usuario recarga y cuenta otra compra. Solución: deduplicar por transaction_id y evitar disparos en cada pageview.
• Conversión mal definida: se marca “clic en teléfono” como conversión pero no se valida si hubo llamada real. Solución: separar micro (clic) de macro (lead confirmado) y, si puedes, integrar con CRM.
• Eventos con nombres cambiantes: hoy “lead_form”, mañana “form_lead”. Solución: convención fija + revisión por pull request interno o checklist de publicación.
• Consentimiento rompe medición: etiquetas bloqueadas sin alternativa de modelado/consent mode. Solución: implementar bien el modo de consentimiento y testear escenarios aceptar/rechazar.

Si quieres convertir este QA en un proceso recurrente (alertas, checks diarios, automatización en n8n), en SEOAGIL lo montamos como sistema: medición + control + reporting para que no “te enteres tarde”.

4) Conclusión: checklist final y errores a evitar

Una migración a GA4 sólida es un proyecto de negocio y datos, no una tarea de “poner una etiqueta”. Si haces bien el mapa de medición, implementas con GTM sin duplicidades y validas con QA real, tu GA4 se convierte en un activo: podrás optimizar campañas, CRO y SEO con confianza (incluyendo análisis por landing, intención y tipo de usuario).

Checklist final (lista para copiar):

• Mapa de medición documentado (eventos, parámetros, conversiones, owners).
• Convención de nombres aprobada y estable (eventos y parámetros).
• GTM versionado con notas, y entorno de pruebas si aplica.
• Eventos clave implementados con triggers de confirmación real.
• Deduplicación (purchase por transaction_id, leads por confirmación única).
• Ecommerce GA4 completo (items[], value, currency, transaction_id).
• Cross-domain y referrals indeseados revisados (checkout, pasarelas, subdominios).
• Consent Mode probado en 3 escenarios: aceptar / rechazar / sin interacción.
• DebugView validado para eventos + parámetros.
• Comparativa con backend/CRM (pedidos, leads) para detectar gaps.
• BigQuery (si está) con queries básicas de QA y deduplicación.
• Revisión de canales: Direct, Organic, Paid, Referral tras cambios.

Errores a evitar (los que más “hacen perder conversiones”):

• Marcar como conversión eventos de intención (clic) en lugar de éxito (confirmación).
• Dejar que múltiples fuentes envíen los mismos eventos (plugin + GTM + gtag hardcoded).
• Implementar ecommerce sin transaction_id o con IDs que cambian.
• Ignorar consent mode y descubrir semanas después que falta una parte del tráfico.
• No documentar: sin mapa, cualquier ajuste futuro rompe comparativas.

Si tu objetivo es que GA4 te sirva para crecer (y no para discutir por qué “no cuadra”), lo ideal es tratar la medición como producto: iteración, QA y automatización. Puedes ver cómo lo trabajamos en el método de SEOAGIL o solicitar una consultoría de implementación y auditoría GA4 para dejarlo estable.

Preguntas frecuentes

¿Se puede “migrar” el histórico de Universal Analytics a GA4?

No como una migración nativa 1:1 dentro de GA4. UA y GA4 tienen modelos distintos. Lo recomendable es mantener el histórico donde lo tengas almacenado (reportes/exports/BI) y empezar GA4 con una medición bien definida desde una fecha clara.

¿Qué conversiones debo configurar primero en GA4?

Empieza por las macroconversiones que impactan negocio (compra, envío de lead, demo reservada) y después añade microconversiones (clic en WhatsApp, scroll, interacción). Evita marcar como conversión cualquier evento “por si acaso”.

¿Cómo evito conversiones duplicadas en ecommerce?

Asegura que el evento purchase se dispare una sola vez por pedido y usa transaction_id único. Evita dispararlo en cada carga de la página de confirmación sin control (recargas, volver atrás, etc.).

¿GA4 con GTM o con instalación directa (gtag)?

Para la mayoría de equipos, GTM facilita control, versionado y QA. La clave no es la herramienta, sino la disciplina: mapa de medición, triggers correctos, deduplicación y validación.

¿Necesito BigQuery para validar una migración a GA4?

No es obligatorio, pero ayuda mucho en control de calidad (duplicados, parámetros nulos, análisis por segmentos y auditorías). Si no lo tienes, compensa con pruebas sistemáticas en DebugView + comparativas con CRM/backoffice.