Por qué se rompe el cross-domain tracking y arruina tus conversiones (y cómo verificarlo)

"Mi sitio principal y mi dominio separado de registro o checkout intercambian usuarios constantemente, pero los números de GA4 simplemente no cuadran." Este es un problema muy común para servicios que abarcan varios dominios. Incluso cuando el tracking de cada página se ve correcto, si la identidad del usuario se corta justo al cruzar de dominio, tus reportes y la optimización de pujas empiezan a fallar silenciosamente.

¿Te suena alguno de estos síntomas?

• Tu propio dominio aparece como fuente de tráfico en el reporte de referencias (un self-referral)
• Es un solo usuario, pero la sesión se divide en dos en el momento en que cruza de dominio
• Los conteos de usuarios y sesiones salen inflados, más altos de lo que deberían
• Las conversiones de registro o checkout no se atribuyen a la campaña que trajo al visitante

Esta guía organiza cómo se rompe el cross-domain tracking de GA4, cómo verificarlo usando el parámetro linker _gl y DebugView, los puntos ciegos que suelen pasarse por alto, y cómo pensar en la verificación en producción.

Qué es realmente el cross-domain tracking

GA4 distingue a los usuarios mediante un identificador llamado client_id, que normalmente se guarda en la cookie de cada dominio. Aquí está la trampa: las cookies no se comparten entre dominios. Entonces, cuando un usuario pasa de site.com a checkout.otrositio.com, el dominio de destino vuelve a contar a la misma persona como un usuario totalmente nuevo.

El cross-domain tracking evita esto. Cuando configuras tus dominios, GA4 agrega automáticamente un parámetro linker — _gl= — a la URL al navegar por un enlace, transportando el client_id de un dominio a otro. Sin esa configuración, el traspaso nunca ocurre.

Estado	Qué ocurre	Síntoma típico
Configurado (saludable)	_gl= se agrega a la URL; el client_id se transporta	Continúa como el mismo usuario, la misma sesión
Sin configurar (roto)	El client_id no se transporta; se reasigna en el destino	Fragmentación de sesión, self-referral, conteos inflados
Sin exclusión de referencias	Las pasarelas de pago, etc., se registran como fuente de tráfico	El self-referral rompe la atribución

El punto clave: "el tag se dispara en cada dominio" y "la misma persona es reconocida entre dominios" son dos cosas distintas. La mayoría de las verificaciones se quedan en lo primero. Confirmar que el tag de GA4 en sí se dispara está cubierto en cómo verificar que tu tag de GA4 funciona, pero este artículo trata lo que viene después: si el traspaso realmente ocurre.

Subdominios vs. cross-domain: una confusión frecuente

Antes de entrar en las causas, vale la pena aclarar un punto que confunde a muchos equipos: los subdominios y el cross-domain no son lo mismo, y GA4 los maneja de forma diferente.

Si el recorrido del usuario se mantiene dentro de subdominios del mismo dominio principal —por ejemplo, www.tusitio.com a blog.tusitio.com a shop.tusitio.com— GA4 lo maneja automáticamente. La cookie _ga se establece en el dominio principal (.tusitio.com), por lo que es accesible desde todos los subdominios sin ninguna configuración adicional.

El cross-domain tracking solo es necesario cuando los usuarios se mueven entre dominios completamente distintos —por ejemplo, tusitio.com a checkout.otrodominio.com. Estos tienen "cookie jars" separados, y ahí es donde entra el parámetro linker _gl.

Escenario	¿Se necesita configuración?
www.tusitio.com → blog.tusitio.com	No — GA4 maneja los subdominios automáticamente
tusitio.com → checkout.otrodominio.com	Sí — se debe configurar el cross-domain tracking
tusitio.com → payment.stripe.com (terceros)	Solo exclusión de referencias (no puedes instalar tu tag en un dominio que no es tuyo)

Error común: configurar el cross-domain tracking entre tus propios subdominios cuando no es necesario. Esto puede en realidad introducir parámetros _gl innecesarios e incluso causar problemas. Si ambas páginas comparten el mismo dominio principal, basta con asegurarte de que el mismo tag de GA4 esté instalado en ambas; no se requiere ninguna configuración de dominio.

Causa 1: "Configure your domains" no está configurado

La causa más frecuente. En el panel de administración de GA4, en "Data Streams → Configure tag settings → Configure your domains," debes registrar todos los dominios entre los que se mueven los usuarios. Si el dominio de destino no está en la lista, GA4 no agregará el parámetro linker y el client_id no se transportará.

Qué revisar: si todos los dominios relevantes están registrados, sin ninguna omisión. Presta atención a las variantes de subdominio (www vs. sin www, shop., etc.).

Error común: asumir que "puse el mismo ID de medición en ambos dominios, así que ya estoy cubierto." Instalar el tag y configurar tus dominios son dos tareas distintas. El tag puede estar presente, pero sin la configuración de dominios el traspaso simplemente no ocurrirá.

Causa 2: _gl= no se está agregando a la URL

Si el traspaso realmente está funcionando se puede ver en la URL tras la navegación. Justo después de que un enlace te lleva de site.com a checkout.otrositio.com, si la barra de direcciones muestra una cadena larga que empieza con _gl=, el traspaso está funcionando. Si está ausente, algo se está rompiendo en el camino.

Qué revisar: haz clic de verdad en el enlace cross-domain y verifica si _gl= aparece en la URL de destino. Si no aparece, sospecha de la Causa 1 (un dominio faltante) o de la forma en que está implementado el enlace (ver abajo).

Error común: si navegas reescribiendo window.location en JavaScript, o pasas por un envío de formulario o una redirección, el _gl puede perderse en lugar de agregarse y conservarse. "Un enlace <a> normal lo transporta, pero pasando por un botón no" es un patrón clásico.

Causa 3: la exclusión de referencias (self-referral) no está configurada

Cuando pasas por una pasarela de pago, un carrito o un formulario externo, ese dominio puede quedar registrado en GA4 como fuente de tráfico (referencia). Entonces checkout.otrositio.com o la pasarela de pago —en lugar de tu campaña de adquisición real— se trata como "la última fuente antes de la conversión," y la atribución se rompe. Esto es un self-referral.

Configurar correctamente el cross-domain tracking resuelve la mayor parte, pero cuando pasas por un dominio que no es tuyo (como una pasarela de pago), además necesitas agregar ese dominio a la lista de "referencias no deseadas / exclusión de referencias" de GA4. Para entender cómo se transportan los click IDs de anuncios, consulta cómo funcionan el gclid y los click IDs.

Error común: ver tu propio dominio o un dominio de pago listado en el reporte de referencias y celebrar "estamos recibiendo tráfico." Puede que no sea adquisición nueva; puede ser una señal de que el mismo usuario se está perdiendo y volviendo a contar, inflando los números.

Causa 4: el consentimiento de cookies (CMP) bloquea el destino

Aun cuando el parámetro _gl llega correctamente a la URL de destino, el traspaso puede seguir fallando silenciosamente si el estado de consentimiento de cookies del usuario impide que GA4 escriba una cookie en el dominio de destino. Esto es cada vez más común con Consent Mode v2 y una aplicación más estricta de los CMP (Consent Management Platform).

Así es como se rompe: un visitante acepta las cookies en site.com y navega a checkout.otrositio.com. El parámetro _gl se transporta, pero el banner de consentimiento en checkout.otrositio.com aún no ha sido aceptado, o usa un CMP distinto que no comparte el estado de consentimiento. GA4 en el destino ve "sin consentimiento" y o bien se dispara en modo cookieless, o directamente no se dispara. Resultado: el client_id proveniente de _gl se ignora, y la sesión se divide.

Qué revisar: si tu CMP comparte el estado de consentimiento entre tus dominios. Muchos CMP soportan el intercambio de consentimiento entre dominios, pero debe configurarse explícitamente. También verifica que el parámetro analytics_storage de Consent Mode esté otorgado ("granted") en todos los dominios antes de asumir que el traspaso funciona.

Error común: probar el cross-domain tracking en tu propia máquina, donde ya aceptaste las cookies en ambos dominios, y concluir "funciona." Los visitantes reales que llegan al destino por primera vez se enfrentan al banner de consentimiento, y si el consentimiento no se otorga o no se transporta, el traspaso se pierde, incluso con un _gl perfectamente formado en la URL.

Causa 5: Safari ITP y las restricciones de privacidad de los navegadores

El ITP (Intelligent Tracking Prevention) de Safari impone un límite de expiración de 7 días a las cookies propias establecidas vía JavaScript, incluyendo la cookie _ga de GA4. Si un usuario no regresa dentro de 7 días, su client_id desaparece, y es contado como usuario nuevo en su siguiente visita. Para el cross-domain tracking, el impacto se agrava.

Aun cuando _gl logra transportar el client_id con éxito al dominio de destino, Safari puede haber expirado ya la cookie original. Y del lado del destino, la cookie recién escrita también estará sujeta al mismo límite de 7 días. El resultado: los recorridos de usuario de varias sesiones que cruzan dominios son especialmente frágiles en Safari, que representa entre el 25% y el 35% del tráfico web en muchos mercados (y más aún en móvil).

Otros navegadores están siguiendo el mismo camino. La Protección de Seguimiento Mejorada de Firefox y el bloqueo integrado de Brave pueden interferir de forma similar, aunque mediante mecanismos distintos.

Qué revisar: si tu cross-domain tracking se sostiene específicamente en Safari. Prueba el recorrido completo en una ventana privada de Safari (donde el ITP es más estricto) y compara el comportamiento del client_id con Chrome.

Error común: probar solo en Chrome, donde las restricciones de cookies son mínimas, y asumir que los resultados aplican en todas partes. Los usuarios de Safari —que a menudo representan una gran parte del tráfico móvil— pueden estar fragmentando tus sesiones e inflando tus conteos de usuarios silenciosamente, sin ningún error visible en tus reportes.

Cómo verificar: revisa tres cosas en conjunto

Si el cross-domain tracking está vivo se reduce a estas tres verificaciones, usadas en conjunto.

1. _gl= en la URL de destino: haz clic en el enlace cross-domain y comprueba si el parámetro linker aparece en la URL de destino.
2. client_id en DebugView: en el DebugView de GA4, opera ambos dominios en secuencia y confirma que se use el mismo client_id. Si se reasigna, el traspaso falló.
3. Reporte de referencias: revisa si tu propio dominio o el dominio de pago aparecen como fuente de tráfico en el reporte de fuente/medio. Si es así, está ocurriendo un self-referral.

Solo cuando las tres coinciden puedes afirmar que "la misma persona está siendo rastreada entre dominios." Para separar esto de si la conversión en sí se registró, consulta también por qué se dispara una conversión pero no se registra. Si el problema más amplio son cero conversiones en Google Ads, revisa Sin conversiones en Google Ads: guía de diagnóstico paso a paso para el flujo de diagnóstico completo.

Lo que revisar desde tu propia máquina no te puede decir

Las tres verificaciones anteriores son útiles, pero verificar una sola vez desde tu propia máquina tiene dos límites estructurales.

1. Tu entorno no es el entorno de tus visitantes. El estado de sesión, las extensiones del navegador, la configuración de cookies, la exclusión de la IP de oficina y factores similares hacen que _gl pueda verse presente en tu máquina, pero que el traspaso falle bajo condiciones reales de visitante (otro navegador, protección de seguimiento, estado de consentimiento).
2. Los recorridos que involucran un clic en un anuncio son difíciles de reproducir. Para confirmar de verdad "cuando alguien llega vía un anuncio y cruza de dominio, ¿sigue atribuyéndose a la campaña de adquisición?" necesitarías hacer clic en un anuncio en vivo para recrear el recorrido, lo cual conlleva el riesgo de una violación de política publicitaria por autoclic.

Concluir "el _gl está presente, así que está bien" desde tu propia máquina tiende a pasar por alto el problema de que el traspaso falle en el recorrido real que hacen tus visitantes.

Checklist de verificación

• ¿Están registrados todos los dominios entre los que se mueven los usuarios en "Configure your domains" de GA4?
• ¿Hay variantes de subdominio omitidas (www vs. sin www, etc.)?
• ¿Aparece _gl= en la URL después de una navegación cross-domain?
• ¿Se conserva _gl incluso a través de botones, formularios y redirecciones?
• En DebugView, ¿el client_id es idéntico en ambos dominios?
• ¿Aparecen tu propio dominio o el dominio de pago en el reporte de referencias?
• ¿Agregaste los dominios de terceros (pasarelas de pago, etc.) a la lista de exclusión de referencias?
• ¿Tu CMP comparte el estado de consentimiento entre todos los dominios, para que GA4 tenga permiso de escribir cookies en el destino?
• ¿Probaste el recorrido completo en Safari (donde el ITP limita las cookies a 7 días)?
• ¿Se sostiene el traspaso bajo condiciones reales de usuario en producción (no solo tu única prueba)?

Preguntas frecuentes

P. Si pongo el mismo tag de GA4 en ambos dominios, ¿eso ya es cross-domain tracking? R. No. Además de instalar el tag, debes registrar los dominios en "Configure your domains" de GA4. Instalación y configuración son tareas separadas.

P. ¿Qué hace el parámetro _gl? R. Es el parámetro linker de GA4. Se agrega automáticamente a la URL al navegar por un enlace cross-domain y transporta información identificadora, como el client_id, hacia el destino. Sin él, el destino vuelve a contar al visitante como usuario nuevo.

P. ¿Qué es un self-referral? R. Es cuando otro dominio propio, o un dominio de pago, queda registrado en GA4 como "fuente de tráfico (referencia)." Causado por una configuración de cross-domain faltante o una exclusión de referencias faltante, desplaza la atribución fuera de tu verdadera fuente de adquisición.

P. Uso una pasarela de pago externa. ¿Qué debo configurar? R. Registra los dominios que posees en "Configure your domains," y agrega el dominio de la pasarela de pago que no te pertenece a la lista de exclusión de referencias de GA4. Haz ambas cosas juntas.

P. ¿Necesito cross-domain tracking para subdominios? R. No. GA4 maneja automáticamente los subdominios del mismo dominio principal (por ejemplo, www.tusitio.com y shop.tusitio.com), porque la cookie se establece en el dominio principal. La configuración de cross-domain solo es necesaria cuando los usuarios se mueven entre dominios completamente distintos.

P. ¿Los banners de consentimiento de cookies pueden romper el cross-domain tracking? R. Sí. Si tu CMP no comparte el estado de consentimiento entre dominios, GA4 en el destino puede no tener permiso para escribir cookies, incluso si el parámetro _gl llegó correctamente. Asegúrate de que tu gestión de consentimiento esté configurada para compartir el consentimiento entre dominios.

P. ¿Safari afecta el cross-domain tracking de forma distinta? R. Sí. El ITP de Safari limita las cookies establecidas por JavaScript (incluida la cookie _ga de GA4) a 7 días de inactividad. Esto significa que los usuarios recurrentes de Safari suelen contarse como nuevos, y los recorridos cross-domain de varias sesiones son especialmente frágiles. Establecer las cookies del lado del servidor puede mitigar esto.

P. Mi conteo de usuarios es más alto de lo que debería; ¿el cross-domain es la causa? R. Puede serlo. Cuando el traspaso falla, el mismo usuario se reasigna como nuevo en el destino, inflando los conteos de usuarios y sesiones. Revisa en DebugView si el client_id se transporta correctamente.

Conclusión: no te quedes en el disparo del tag, verifica el traspaso

Verificar el cross-domain tracking implica más que comprobar que el tag se dispara en cada dominio. Lo que importa es lo que viene después: si la identidad se transporta entre dominios como el mismo usuario, y si el client_id se conserva en el recorrido real que hacen tus visitantes en producción. Para el panorama completo, consulta la guía completa del cross-domain tracking de conversiones de GA4.

ConversionOK ejecuta tu página en vivo en un navegador independiente y aislado, e intercepta los eventos y el client_id realmente enviados para verificarlos, sin necesidad de hacer clic en tu propio anuncio y sin interferencia de tu entorno de oficina. Empieza con una revisión estática gratuita para confirmar el punto de entrada de tu medición.