Cross domain GA4: guía práctica paso a paso con snippets

¿Qué es el cross-domain en GA4 y por qué importa?

El cross domain GA4 (seguimiento entre dominios) es un conjunto de ajustes para que Google Analytics 4 reconozca como el mismo usuario y la misma sesión a una persona que navega desde un dominio a otro dentro de un mismo recorrido (por ejemplo, de www.ejemplo.es a checkout-ejemplo.com).

Sin esta configuración, GA4 suele iniciar un usuario/sesión nuevos al cambiar de dominio porque, por defecto, las cookies de medición (por ejemplo _ga) se crean con un ámbito de cookie limitado al dominio actual. El resultado típico es:

Inflado de usuarios y sesiones, pérdida de atribución (cambios de fuente/medio), aparición de referencias internas no deseadas y dificultades para reconstruir embudos que cruzan dominios (registro, pago, reservas, subdominios con apps, etc.).

En GA4, la medición multidominio se basa en añadir información de enlace a las URLs cuando se navega hacia dominios permitidos. Esa información suele viajar mediante el parámetro _gl. En el dominio de destino, GA4 lee ese parámetro, lo valida y lo utiliza para reconciliar identificadores y mantener continuidad del usuario/sesión siempre que el navegador permita almacenamiento y que la configuración sea consistente.

Documento oficial de referencia: Configurar la medición multidominio en GA4.

¿Cuándo necesitas activar el seguimiento entre dominios?

El cross-domain suele ser necesario cuando el recorrido real del usuario se reparte entre dos o más dominios diferentes que forman parte del mismo producto/embudo y se desea medirlo como una sola experiencia. En entornos habituales, el cambio de dominio se produce por decisiones técnicas (PSP de pago, motor de reservas, plataforma de tickets) o por arquitectura (apps en otro dominio, micrositios operativos).

• Checkout o pago en dominio externo (dominio de un proveedor, dominio independiente por legacy o por internacionalización).
• Reservas en un motor de terceros que opera en dominio separado.
• Login/área privada servida desde otro dominio por restricciones técnicas o de seguridad.
• Flujos con redirecciones entre dominios (SSO, pasarelas, confirmación de pedido, verificación de identidad).
• Landings en un dominio distinto que continúan en el dominio principal (o al revés).

En cambio, si el recorrido ocurre entre subdominios del mismo dominio registrable (por ejemplo, www.ejemplo.es y app.ejemplo.es), suele ser suficiente con una configuración correcta de cookies first-party y etiquetado consistente; en muchos casos no hace falta medición multidominio porque la cookie puede ser válida a nivel de dominio (según el atributo Domain y la implementación). Aun así, puede ser recomendable si se observan referencias internas o reinicios de sesión al saltar entre subdominios por configuraciones de cookies o por apps embebidas.

También puede no ser necesario cuando el “segundo dominio” no forma parte del embudo (por ejemplo, enlaces a redes sociales, medios, documentación externa) o cuando se pretende que esa navegación sea tratada como salida/entrada independiente.

Requisitos previos y conceptos clave

Antes de configurar cross-domain conviene alinear tres capas: medición (GA4), implementación (gtag/GTM) y comportamiento del sitio (redirecciones, enlazado, iframes, consentimiento). En la práctica, la mayoría de problemas se explican por inconsistencias entre etiquetas, bloqueos de almacenamiento o pérdida del parámetro _gl durante redirecciones.

Requisitos técnicos habituales:

1) El mismo flujo de medición (mismo ID de medición o al menos una estrategia consistente) en los dominios implicados, evitando duplicidades. 2) Enlaces navegables (A→B) que permitan añadir/propagar parámetros (no solo formularios post o saltos por JS que “limpian” la URL). 3) Capacidad de almacenar cookies (siempre condicionada por navegador y consentimiento). 4) Exclusión de referencias bien planteada para que los dominios propios no aparezcan como referers.

Entender dominios y subdominios

Dominio suele referirse al dominio registrable (eTLD+1), por ejemplo ejemplo.es. Un subdominio es una rama como tienda.ejemplo.es o app.ejemplo.es. El seguimiento entre subdominios puede funcionar con cookies de primer nivel si se configura el alcance de cookie para cubrir el dominio principal, pero esa posibilidad depende de cómo se sirve el sitio, de restricciones del navegador y de que no existan implementaciones que “fijen” el dominio de cookie al host exacto.

El cross-domain es necesario cuando hay dominios distintos (por ejemplo, ejemplo.es y ejemplo-payments.com) porque una cookie creada en un dominio no se envía al otro. Para salvar esa barrera, GA4 usa decoración de enlaces: el dominio origen añade información a la URL (parámetro _gl) y el dominio destino la interpreta para continuar el usuario/sesión.

Aspectos que suelen complicar el escenario:

Redirecciones 301/302 múltiples, normalizaciones de URL (quita parámetros), acortadores, enlaces generados por JS y pasos en iframes. Cada uno puede alterar o perder el _gl si no se gestiona con cuidado.

Cookies y client_id: _ga y _gl

GA4 identifica navegadores principalmente con un identificador almacenado en cookie first-party. El más conocido es el client_id, que se guarda típicamente en la cookie _ga (y, según implementación, en otras cookies auxiliares). Cuando la medición multidominio está activa, GA4 añade el parámetro _gl a los enlaces hacia dominios permitidos.

_ga es una cookie establecida por el script de medición en el dominio actual. Su contenido incluye un identificador que GA4 usa para reconocer el navegador. Al cambiar de dominio, esa cookie no viaja. Por eso se transfiere información mediante _gl.

_gl es un parámetro de URL que encapsula datos necesarios para enlazar sesiones/usuarios entre dominios. En el destino, GA4 lo lee y, si procede, establece las cookies correspondientes en el dominio de destino para que el identificador quede persistido allí. Si el parámetro se pierde por el camino, GA4 no puede asociar el salto y lo tratará como nueva sesión/usuario o como un tráfico con referencia inesperada.

Advertencia: el cross-domain no “salta” restricciones de privacidad. Si el usuario no consiente almacenamiento (dependiendo del modo de consentimiento), o el navegador bloquea almacenamiento, la continuidad de usuario se verá limitada. En esos casos, la medición puede degradarse a modelos agregados o pings sin almacenamiento (según configuración), pero no se garantiza continuidad individual.

Métodos de implementación (GA4 nativo vs GTM)

La medición multidominio puede configurarse de forma nativa en GA4 (recomendable cuando se usa el tag de Google y ajustes centralizados) o mediante Google Tag Manager (GTM) (habitual si el despliegue de etiquetas depende de contenedores, condiciones, entornos o reglas avanzadas).

Ambos métodos comparten el objetivo: declarar una lista de dominios sobre los que se debe aplicar la decoración automática de enlaces. En la práctica, la decisión depende del nivel de control requerido, del número de propiedades/entornos, de si existe tagging híbrido (gtag + GTM) y de si hay que evitar colisiones entre configuraciones.

Método	Cuándo encaja	Ventajas	Riesgos típicos
A) GA4 nativo (Flujos de datos)	Implementación simple, misma medición en todos los dominios, pocos cambios por release.	Centralizado en GA4, menos dependencias de contenedor, coherencia por flujo.	Confusión si coexiste con GTM/gtag con reglas distintas; cambios no versionados como un contenedor.
B) GTM (etiquetas GA4/Google tag)	Setups complejos, varios entornos, triggers por rutas, necesidad de control por versión.	Versionado, debug del contenedor, reglas avanzadas y posibilidad de coexistir con más etiquetas.	Doble etiquetado y duplicidades; mala coordinación entre “Google tag” y etiquetas GA4; disparos múltiples.

Método A — Configuración desde GA4 (flujos de datos)

En GA4, la configuración multidominio se gestiona desde el flujo de datos web. En términos operativos, se trata de definir dominios a medir para que GA4 aplique automáticamente la decoración de enlaces cuando detecta navegación hacia esos dominios.

Consideraciones importantes antes de tocar ajustes:

Consistencia del etiquetado: los dominios deben estar etiquetados de forma compatible. Si un dominio usa un ID de medición distinto en otra propiedad, se mezclarán recorridos o se partirán. Si se pretende analizar el recorrido completo en una sola propiedad, el tagging debe apuntar al mismo destino de medición.

Evitar el doble control: si existe configuración de linker también en GTM/gtag, conviene definir un único punto de control para no generar comportamientos inesperados. El síntoma típico de mala convivencia es ver el parámetro _gl duplicado, reescrituras extrañas o cambios de session_id.

Además, la lista de dominios debe alinearse con la realidad técnica. Si el pago se hace en pagos.proveedor.com pero el enlace real va a secure.proveedor.com o hay saltos intermedios, los dominios relevantes deben incluir los destinos efectivos, o el decorado no se aplicará en el salto que importa.

Método B — Implementación vía Google Tag Manager (GTM)

En GTM, el control suele aplicarse desde la configuración de la etiqueta (Google tag / GA4 Configuration, según la plantilla disponible) o desde parámetros de configuración que habilitan la decoración de enlaces hacia dominios definidos.

La ventaja operativa es el versionado y la posibilidad de desplegar por entorno (staging/producción) con trazabilidad. También encaja bien cuando el cross-domain depende de condiciones (por ejemplo, solo aplicar en rutas de checkout) o cuando se gestiona una arquitectura con varios contenedores y reglas específicas.

Aspectos críticos en GTM:

1) Disparo único de la etiqueta base por página. Si la etiqueta se dispara dos veces, pueden generarse identificadores nuevos o eventos duplicados. 2) Coherencia de dominios: la lista declarada debe cubrir todos los saltos reales. 3) Coordinación con Consent Mode: si el contenedor bloquea tags hasta consentimiento, los enlaces pueden no decorarse al inicio de la sesión, afectando a la continuidad al saltar de dominio.

Referencia oficial de GTM (documentación general): Ayuda de Google Tag Manager.

Snippets y regex útiles (copiar/pegar)

Los siguientes ejemplos son genéricos y usan identificadores de placeholder. Deben adaptarse a cada implementación y probarse en un entorno controlado antes de desplegar en producción.

<script>
  // Ejemplo hipotético con gtag (no usar IDs reales en este snippet)
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}

  gtag('consent', 'default', {
    ad_storage: 'denied',
    analytics_storage: 'denied'
  });

  gtag('js', new Date());

  gtag('config', 'G-XXXXXXXXXX', {
    linker: {
      domains: ['ejemplo.es', 'checkout-ejemplo.com', 'reservas-ejemplo.net']
    }
  });
</script>

Regex útil cuando se necesita validar hosts permitidos en reglas (por ejemplo, en lógica de GTM o en utilidades internas). El objetivo es cubrir www y subdominios esperados sin abrir demasiado la puerta a coincidencias accidentales.

// Ejemplo hipotético (JavaScript) para permitir varios dominios y subdominios
// Coincide con ejemplo.es y cualquier subdominio de ejemplo.es
const allowlist = /(^|\.)ejemplo\.es$/;

// Coincide con checkout-ejemplo.com exactamente o subdominios
const allowlistCheckout = /(^|\.)checkout-ejemplo\.com$/;

// Uso hipotético
allowlist.test(location.hostname);
allowlistCheckout.test(location.hostname);

Ejemplo de evento hipotético vía dataLayer (sin datos personales) para marcar un paso de funnel que ayuda a validar continuidad cross-domain en DebugView o en exploraciones. El ejemplo evita identificadores directos y usa campos categóricos.

<script>
  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({
    event: 'funnel_step',
    funnel_name: 'checkout',
    step_name: 'payment_redirect',
    step_index: 3,
    user_state: 'logged_out',
    consent_state: 'analytics_denied'
  });
</script>

Para depuración rápida en consola, un fragmento hipotético para localizar el parámetro _gl en la URL y comprobar si se conserva durante redirecciones y saltos (la lectura es local, no envía datos).

// Ejemplo hipotético para consola del navegador
const url = new URL(window.location.href);
const gl = url.searchParams.get('_gl');
console.log('Parametro _gl:', gl ? gl.slice(0, 24) + '…' : null);

// También puede interesar ver si existe la cookie _ga
console.log('Cookies incluyen _ga:', document.cookie.includes('_ga='));

Paso a paso: checklist operativo

Este flujo operativo está orientado a asegurar continuidad de usuario/sesión y evitar referencias internas. Debe aplicarse con acceso a GA4, a la implementación (GTM/gtag) y a un entorno de pruebas donde se pueda inspeccionar URLs y cookies.

Configuración rápida: pasos principales

1. Inventariar dominios y saltos reales: listar dominio origen, dominio destino y cualquier dominio intermedio por redirecciones (incluyendo hosts “secure”, pasarelas y dominios de confirmación).
2. Validar que el etiquetado apunta al mismo destino de medición en todos los dominios que deban formar un único recorrido (misma propiedad/flujo o estrategia definida). Revisar duplicidades: gtag directo + GTM, o dos contenedores.
3. Elegir un único punto de control para la lista de dominios de cross-domain: o bien GA4 (Flujos de datos) o bien GTM/gtag. Mantener un solo mecanismo reduce conflictos.
4. Configurar la lista de dominios (permitidos) y publicar el cambio. Incluir los hosts efectivos que aparecen en los enlaces y en las redirecciones.
5. Configurar exclusión de referencias cuando proceda, para que los dominios propios implicados en el recorrido no aparezcan como referral. Esta parte es sensible: una exclusión mal planteada puede ocultar referencias reales no deseadas o enmascarar problemas de etiquetado.
6. Probar un recorrido completo desde un navegador limpio (ventana de incógnito o perfil nuevo) para reducir interferencias de cookies anteriores y extensiones.

Comprobaciones inmediatas: _ga, _gl y DebugView

La verificación práctica combina tres señales: (1) presencia y persistencia de _gl al navegar entre dominios, (2) establecimiento de cookie _ga en el dominio de destino, (3) continuidad de sesión/usuario en herramientas de depuración.

Comprobaciones útiles en el navegador:

_gl en enlaces: al hacer clic en un enlace hacia el dominio destino, la URL resultante debería incluir el parámetro _gl=… (en el primer aterrizaje del dominio destino). Si no aparece, la decoración no se está aplicando o el enlace no es decorable (por ejemplo, navegación que no pasa por un enlace estándar).

_gl no debe “desaparecer” antes de llegar: si hay redirecciones, revisar en la pestaña Network si el parámetro se mantiene o si algún salto lo elimina. Un “limpiador de parámetros” o una canonicalización agresiva suelen ser responsables.

Cookie _ga en destino: tras aterrizar en el dominio B, comprobar en Application/Storage del navegador si existe _ga y si su valor se establece de forma estable al continuar navegando. Si no se crea, puede haber bloqueo de almacenamiento, falta de consentimiento o fallos de ejecución del tag.

Para depuración en GA4, DebugView permite observar eventos con detalle cuando el navegador está en modo depuración. La documentación oficial ayuda a entender el flujo de depuración y las señales: DebugView en Google Analytics.

Integración con Consent Mode y efecto en lead nurturing

Cuando hay un marco de consentimiento, el comportamiento de la medición multidominio depende de si está permitido almacenar cookies de analítica. Con Consent Mode, GA4 puede operar con estados de consentimiento que afectan al almacenamiento (analytics_storage) y, en escenarios publicitarios, a almacenamiento de anuncios (ad_storage).

En un recorrido cross-domain, el punto crítico es que la continuidad basada en client_id depende de poder establecer y leer cookies en ambos dominios. Si el estado de consentimiento impide almacenamiento, la transferencia por _gl puede no consolidarse en el dominio de destino. El resultado práctico suele ser:

Pérdida de continuidad entre dominios para usuarios no consentidos, más fragmentación en sesiones/usuarios y menor capacidad de unir pasos del embudo a nivel individual. Aun así, GA4 puede seguir recibiendo señales modeladas o agregadas (según configuración y producto), pero no debe asumirse una equivalencia con el seguimiento basado en cookies.

En contextos donde se utiliza analítica para procesos de lead nurturing (por ejemplo, segmentación por comportamiento, scoring, automatización con CRM), conviene tratar el dato como:

1) Event-based: priorizar eventos y propiedades de evento que describan etapas (páginas clave, envíos de formularios, pasos de checkout) sobre identificadores persistentes. 2) Robusto ante pérdida de identidad: diseñar audiencias y flujos que toleren sesiones fragmentadas. 3) Compatible con privacidad: evitar depender de identificadores personales. Cuando exista integración con CRM, esta debe basarse en un intercambio controlado y conforme a normativa, y no en capturas indirectas del client_id sin base legal.

Documentación oficial sobre Consent Mode: Consent Mode (Tag Platform) en Developers.

Advertencia operativa: si el decorado de enlaces depende de que el tag ejecute antes del clic, y el tag está bloqueado por consentimiento, puede suceder que no se añada _gl al enlace en la primera interacción. En ese caso, el cross-domain funcionará de forma inconsistente: usuarios consentidos tendrán continuidad; no consentidos, no. Esto debe considerarse en el análisis de embudos.

Casos de uso y ejemplos prácticos

Los siguientes escenarios describen patrones reales. Los dominios y detalles son ejemplos hipotéticos para ilustrar decisiones de configuración, verificación y troubleshooting.

Checkout en dominio externo

Escenario hipotético: www.ejemplo.es (catálogo) redirige a checkout-ejemplo.com para finalizar compra. El salto ocurre desde un botón “Pagar” que apunta a una URL del proveedor, y hay al menos una redirección intermedia hacia un host “secure”.

Puntos de control:

Decoración del enlace: el clic hacia checkout debería aterrizar con _gl. Si el botón genera el enlace en tiempo real (JS), conviene confirmar que el enlace final es un <a href> navegable y que no hay una navegación que “reconstruya” la URL sin parámetros.

Dominios intermedios: si el primer host que recibe el clic es secure.checkout-ejemplo.com, debe estar incluido en la allowlist (o al menos debe coincidir con la regla de dominios según se configure). Si la decoración se aplica solo hacia checkout-ejemplo.com pero el destino real es otro host, se perderá el _gl.

Exclusión de referencias: el dominio de checkout puede aparecer como referencia al volver a la confirmación en el dominio principal. Si esa vuelta forma parte del mismo recorrido, conviene excluir referencias internas para evitar atribución como referral propio, pero evitando ocultar referers legítimos de terceros.

Validación en GA4: en exploraciones de ruta (Path exploration) y en DebugView, observar si el salto al checkout mantiene el mismo usuario (cuando es posible) y si la sesión no se reinicia sin necesidad. Si la sesión se reinicia, revisar cookies y Consent Mode.

Login en subdominio

Escenario hipotético: www.ejemplo.es lleva a cuenta.ejemplo.es para autenticación, y luego vuelve a www o continúa en app.ejemplo.es.

En subdominios, el primer diagnóstico no debería empezar por cross-domain, sino por alcance de cookies y consistencia de implementación:

Etiquetado consistente: mismo ID de medición y misma lógica de disparo. Un patrón común es que la web use GTM y el subdominio use gtag directo, generando configuraciones diferentes (consentimiento, linker, parámetros). Eso puede fragmentar sesiones incluso sin cambio de dominio registrable.

Cookie domain: si el subdominio crea cookies con ámbito limitado al host, se observarán reinicios al pasar de www a cuenta. Ajustes de cookie (según la herramienta y el modo de despliegue) deben permitir que la cookie sea válida para el dominio principal cuando sea apropiado.

SSO y redirecciones: muchos logins usan múltiples redirects y parámetros de estado. Revisar que ningún mecanismo “limpie” query strings de forma agresiva cuando se vuelve al sitio.

Si tras asegurar lo anterior aún aparecen referencias internas o reinicios, la medición multidominio puede utilizarse como medida adicional, pero conviene justificarla por datos observados (no por suposición).

Reservas o pasarelas de pago en dominio separado

Escenario hipotético: la web principal hotel-ejemplo.es integra un motor de reservas en booking-partner.com. El usuario navega por disponibilidad, selección de fechas, y vuelve a una URL de confirmación en el dominio principal.

Casos particulares que suelen aparecer:

Iframe: si el motor está embebido en un iframe, la navegación puede ocurrir dentro del iframe sin cambios de URL del top window. En ese caso, la medición debe definirse con cuidado: GA4 en el top domain no “ve” automáticamente la navegación interna del iframe como páginas distintas, y el cross-domain basado en link decoration puede no aplicar si no hay navegación top-level.

Dominio de tercero: si el motor es de un proveedor, hay que alinear responsabilidades. Para que el cross-domain funcione, el dominio de tercero debe estar etiquetado de forma compatible y permitir decoración/lectura de parámetros. No siempre es posible si el proveedor no da control sobre su implementación.

Retorno a confirmación: si el retorno elimina parámetros por reglas de seguridad o por canonicalización, se puede romper continuidad. Conviene acordar con el proveedor un retorno que preserve query strings relevantes o, como mínimo, no destruya el _gl si se usa.

En estos entornos, la verificación se apoya más en pruebas de extremo a extremo y en inspección de redirecciones que en ajustes teóricos.

Herramientas y comandos para diagnósticos rápidos

Cuando el cross-domain falla, la causa suele estar en uno de estos puntos: decoración no aplicada, _gl perdido, etiqueta no ejecuta, cookie no se establece, duplicidades de tags o exclusión de referencias mal planteada. El diagnóstico rápido busca localizar en cuál de esas capas ocurre el corte.

Tag Assistant, GA Debug y DebugView

Tag Assistant (y el modo de previsualización de GTM) ayuda a validar si la etiqueta se dispara en cada dominio, con qué configuración y en qué orden. Además, permite detectar duplicidades de tags y problemas de carga.

DebugView en GA4 permite observar eventos casi en tiempo real con detalle de parámetros cuando el dispositivo está en modo debug. Es útil para comprobar si, al cambiar de dominio, los eventos siguen llegando en el mismo flujo y si aparecen señales de reinicio (por ejemplo, cambios bruscos en identificadores o nuevos inicios de sesión).

GA Debug (extensión/flags de depuración) puede ayudar a ver logs, aunque el enfoque actual suele basarse en Tag Assistant + DevTools + DebugView. La clave es correlacionar: clic → URL decorada → landing en dominio destino → eventos entrantes.

Cómo inspeccionar _gl y _ga en DevTools

En Chrome DevTools (o herramientas equivalentes), las comprobaciones más directas se hacen en:

Application/Storage: revisar cookies del dominio actual y comprobar presencia de _ga tras cargar la página. Si no aparece, revisar consentimiento, bloqueos, CSP o que la etiqueta realmente se ejecute.

Network: filtrar por solicitudes relacionadas con medición (según el modo de implementación). La intención no es interpretar cada request, sino ver si hay actividad tras el cambio de dominio y si la secuencia se mantiene.

Preservar log (Preserve log): activarlo antes del clic permite ver la cadena de redirecciones y comprobar si la URL aterriza con _gl y cuándo se pierde.

Lecturas rápidas en consola (sin exponer datos) ya quedan cubiertas en el snippet anterior para detectar _gl y la existencia de _ga. En entornos controlados, también es útil copiar la URL final del primer aterrizaje en el dominio destino y confirmar que incluye _gl sin doble codificación.

Errores comunes y cómo solucionarlos

Los fallos de cross-domain suelen ser reproducibles. La resolución efectiva se basa en aislar el punto exacto donde se rompe la continuidad y en corregir una sola causa a la vez. En implementaciones complejas, los fallos pueden ser acumulativos (por ejemplo, pérdida de _gl + doble etiquetado + exclusión de referencias agresiva), así que conviene validar por capas.

Redirecciones que rompen el _gl

Una cadena de redirecciones puede eliminar parámetros de URL por:

Normalización del servidor (quita query strings), WAF o reglas de seguridad, middleware que reconstruye URLs, o integraciones que redirigen a una URL “limpia” por motivos estéticos.

Señales típicas:

En el clic se ve un enlace decorado, pero el primer aterrizaje final no tiene _gl. En Network se observa que el primer 302 sí llevaba parámetros, pero el último 301/302 devuelve una Location sin query string.

Correcciones habituales:

Preservar query strings en redirecciones (mantener parámetros), ajustar reglas que eliminan parámetros específicos, o cambiar el punto de enlace para que apunte a una URL que no redirige. Si el dominio destino está bajo control de un tercero, es necesario acordar con el proveedor la preservación de parámetros o el soporte explícito de medición multidominio.

Conflictos con otras secuencias de comandos

Existen conflictos cuando hay:

Doble etiquetado (gtag + GTM midiendo lo mismo), dos contenedores GTM activos en la misma página, o scripts que manipulan enlaces y eliminan parámetros (por ejemplo, tracking de afiliación, acortadores, librerías de routing).

Señales típicas:

Eventos duplicados, cambios inesperados en parámetros, presencia de _gl en algunos enlaces pero no en otros, o decoración que aparece y desaparece según el orden de carga.

Acciones correctivas:

Unificar el origen de la configuración (solo GA4 o solo GTM), asegurar un único disparo de la etiqueta base, revisar scripts que reescriben enlaces y, si es necesario, excluir del rewrite los dominios/URLs donde deba preservarse _gl. En Tag Assistant, la identificación de tags duplicados suele ser inmediata.

Problemas por exclusión de referencias mal configurada

La exclusión de referencias se usa para evitar que dominios propios aparezcan como referral en los informes cuando el usuario salta entre partes de un mismo ecosistema. Sin embargo, una exclusión mal planteada puede ocultar el síntoma real (cross-domain roto) o enmascarar referers legítimos.

Señales típicas:

Disminuye el volumen de referral “interno”, pero siguen existiendo reinicios de sesión o pérdida de atribución. También puede ocurrir que desaparezcan referers relevantes de terceros si se usa una regla demasiado amplia.

• Validar primero la continuidad técnica (decoración + cookies) y después ajustar exclusiones, no al revés.
• Excluir solo dominios propios necesarios para evitar autorreferencias, evitando patrones demasiado amplios.
• Revisar el efecto en adquisición en un periodo corto tras el cambio, comparando con anotaciones de despliegue y pruebas controladas.

Recursos y enlaces

Los recursos oficiales suelen ser el punto de partida para confirmar comportamiento esperado y matices por producto. Además de la guía de medición multidominio enlazada al inicio, resultan útiles los centros de ayuda de GA4, Tag Manager y la documentación de Consent Mode para entender limitaciones por almacenamiento y depuración.

Como verificación operativa, conviene mantener un procedimiento repetible para cada despliegue o cambio en checkout, reservas, SSO o rutas críticas, documentando dominios, redirecciones y resultados de pruebas.

1. Revisar la configuración efectiva (GA4 o GTM) y confirmar que la lista de dominios coincide con los hosts reales observados en redirecciones y destinos.
2. Ejecutar una prueba controlada en navegador limpio: clic origen → primer aterrizaje en destino, confirmando presencia de _gl y creación de _ga en el dominio destino.
3. Validar en DebugView que los eventos del recorrido aparecen como una secuencia coherente durante el salto de dominio, sin duplicidades por doble etiquetado.
4. Registrar el resultado (fecha, cambio aplicado, dominios implicados, observaciones de redirecciones) para facilitar troubleshooting cuando se modifique el checkout, el proveedor o el consentimiento.