Cuando una empresa empieza a medir con GA4, normalmente el primer objetivo es entender cuántas personas visitan el sitio, de qué canales vienen y qué acciones realizan.
Pero cuando el negocio tiene un proceso de conversión que no ocurre dentro del mismo dominio, la medición se vuelve más delicada.
Esto pasa mucho en hoteles, motores de reserva, pasarelas de pago, plataformas externas, CRMs, sistemas de citas, formularios embebidos o cualquier flujo donde el usuario inicia en un sitio web y termina convirtiendo en otro dominio o subdominio.
Ahí aparece uno de los temas más importantes y menos entendidos de la analítica digital: el cross-domain tracking.
No basta con saber que el usuario entró al sitio. Necesitamos saber si ese mismo usuario llegó después al motor de reservas, si continuó el proceso, si terminó comprando y si esa conversión puede atribuirse al canal correcto.
Porque si la medición se rompe en el salto de dominio, el negocio puede estar generando reservas, leads o ventas, pero GA4 y Google Ads no van a contar la historia completa.
Qué es el cross-domain tracking
El cross-domain tracking, o medición multidominio, es la configuración que permite que GA4 entienda el recorrido de un usuario cuando navega entre más de un dominio relacionado.
Google lo define como una configuración útil cuando necesitas medir una experiencia de usuario que ocurre en varios dominios, por ejemplo, un sitio principal y un carrito de compra en otro dominio.
Dicho de forma práctica, sirve para que GA4 no piense que son dos usuarios o dos sesiones diferentes cuando una persona pasa de:
https://www.hotel.com
a:
https://booking.hotel.com
o de:
https://www.hotel.com
a:
https://booking.motor-reserva.com/hotel
o a una URL de motor externo como Roiback, Easy-Rez u otra plataforma de reservas.
Para el usuario, todo es parte del mismo proceso.
Para GA4, si no está configurado correctamente, puede parecer que el usuario abandonó un sitio y comenzó una sesión nueva en otro o simplemente jamás inicio una sesión.
Ahí empieza el problema.
Por qué el cross-domain es tan importante en hoteles y motores de reserva
En hotelería, muchas conversiones no ocurren directamente dentro del sitio oficial.
El usuario normalmente hace este recorrido:
Entra al sitio oficial
↓
Consulta habitaciones o promociones
↓
Da clic en Reservar
↓
Sale al motor de reservas
↓
Selecciona fechas
↓
Elige habitación o tarifa
↓
Completa datos
↓
Confirma la reserva
Ese flujo puede pasar por diferentes dominios, subdominios o redirecciones.
Por ejemplo:
- www.hotel.com
- booking.hotel.com
- reservations.motor.com
- booking.easy-rez.com
- motor.roiback.com
El problema es que GA4 y Google Ads necesitan conservar el contexto de la sesión. Necesitan saber que la persona que llegó por Google Ads, SEO, Meta Ads, email o metabuscador es la misma persona que terminó reservando.
Si ese contexto se pierde, la reserva puede quedar mal atribuida o sin atribución alguna.
Y cuando la atribución falla, los reportes dejan de representar la realidad.
Problema 1: GA4 divide la sesión en dos
Este es uno de los errores más comunes.
El usuario entra al sitio oficial desde un anunció por Google Ads. Después da clic en reservar y pasa al motor externo. Si el cross-domain no está bien configurado, GA4 puede crear una nueva sesión cuando el usuario llega al motor.
El resultado es que el recorrido se parte.
En vez de ver algo como:
google / cpc → sitio oficial → motor → reserva
GA4 puede interpretar:
google / cpc → sitio oficial
y después:
motor / referral → reserva
Esto hace que el canal original pierda crédito.
Solución
La solución empieza configurando la medición entre dominios en GA4.
Para hacerlo correctamente, se deben declarar los dominios que forman parte del recorrido dentro de la configuración de la etiqueta de Google (Por ejemplo GTM) o del flujo web de GA4. Google necesita que la medición de varios dominios usen la misma etiqueta de Google o estén configurados en los ajustes correspondientes.
Pero no basta con agregar dominios de memoria.
Primero hay que mapear el flujo real:
Dominio principal:
https://www.hotel.com
Subdominio de booking:
https://booking.hotel.com
Motor externo:
https://booking.easy-rez.com/hotel
o
https://reservas.roiback.com/hotel
Después se prueban los clics reales hacia el motor para confirmar si GA4 está agregando el parámetro de enlace correspondiente y si la sesión se conserva.
Problema 2: el motor de reservas aparece como fuente de conversión
Este error es muy común en proyectos hoteleros.
El hotel revisa GA4 y ve que las reservas vienen de:
booking.easy-rez.com / referral
o:
motor.roiback.com / referral
o cualquier dominio asociado al motor de reservas.
El problema es que ese dominio no fue el canal que convenció al usuario. Solo fue el entorno donde se cerró la venta.
La fuente real pudo haber sido Google Ads, SEO, Meta Ads, email marketing, metabuscador o tráfico directo.
Solución
Aquí se deben revisar dos capas.
Primero, el cross-domain tracking. Si GA4 está cortando la sesión, el motor puede aparecer como referral.
Segundo, la lista de referidos no deseados. En GA4 se puede configurar una lista de dominios que no deben iniciar una nueva sesión como referidos cuando forman parte del mismo recorrido de conversión.
Esto debe hacerse con cuidado. No se trata de excluir todo lo que parezca externo, sino de excluir únicamente dominios que realmente forman parte del flujo propio de conversión.
En motores como Roiback o Easy-Rez, este ajuste suele ser necesario cuando el motor participa como intermediario técnico y no como canal de adquisición.
Problema 3: los parámetros de campaña se pierden al pasar al motor
Otro problema frecuente ocurre cuando el usuario llega al sitio con parámetros como:
?utm_source=google&utm_medium=cpc&utm_campaign=hotel-cancun
o con identificadores publicitarios como:
gclid
gbraid
wbraid
Pero al dar clic en reservar, el motor carga una URL limpia, sin parámetros.
Para el usuario no pasa nada.
Para la medición, puede ser grave.
Si el motor o una redirección intermedia elimina parámetros, Google Ads y GA4 pueden tener más dificultad para relacionar la conversión con la campaña original.
Solución
Primero se debe probar el flujo con una URL parametrizada.
Ejemplo:
https://www.hotel.com/?utm_source=test&utm_medium=test&utm_campaign=crossdomain
Después se da clic en el botón de reservar y se revisa si los parámetros o el linker de GA4 sobreviven en el paso al motor.
También hay que revisar si el botón de reserva es un enlace normal, un formulario, un script, una redirección intermedia o una apertura en nueva pestaña.
En muchos casos el problema no está en GA4, sino en cómo el sitio construye la URL de salida hacia el motor.
Cuando el motor elimina parámetros o no permite conservar ciertos identificadores, puede ser necesario levantar un ticket con el proveedor para solicitar soporte específico de tracking, paso de parámetros, integración de GTM o activación de eventos en página de confirmación.
Problema 4: Conversion Linker no está configurado o no dispara donde debe
Cuando se trabaja con Google Ads, no basta con tener GA4.
Google Ads necesita conservar información del clic publicitario para poder atribuir conversiones correctamente. Para eso, en implementaciones con Google Tag Manager, se usa la etiqueta Conversion Linker.
Google recomienda que Conversion Linker se dispare en todas las páginas en la mayoría de los casos, para asegurar que esté activo en las páginas donde pueden aterrizar los usuarios después de hacer clic en un anuncio.
Solución
Hay que validar que Conversion Linker esté activo:
- en el sitio principal,
- en las landing pages,
- en el subdominio si aplica,
- y en el motor de reservas cuando el motor permite GTM o etiquetas de Google.
Si la conversión ocurre dentro del motor, pero Conversion Linker solo está instalado en el sitio principal, la medición puede quedar incompleta.
También hay que confirmar que la etiqueta no esté limitada por un trigger incorrecto, por consentimiento, por errores del contenedor o por bloqueos del motor.
Problema 5: el motor tiene GTM, pero no entrega datos suficientes
En algunos proyectos, el proveedor del motor permite agregar Google Tag Manager. Eso es un gran avance, pero no significa que todo esté resuelto.
GTM es solo el contenedor.
Lo importante es saber qué información está disponible dentro del motor.
Por ejemplo, para medir una reserva real se necesita algo más que saber que el usuario llegó a una página final. Idealmente, necesitamos datos como:
- transaction_id
- value
- currency
- hotel_name
- room_type
- check_in
- check_out
- nights
- guests
- rate_plan
Si el motor no expone esos datos en el dataLayer o en variables accesibles, la medición queda limitada.
Solución
Hay que inspeccionar el dataLayer del motor.
En una prueba de reserva, revisamos si existe un evento de confirmación y qué datos entrega. Si no existe, o si los datos están incompletos, se debe levantar ticket con el equipo del motor.
En el ticket se debe pedir de forma específica:
- activación o validación de GTM en todas las páginas necesarias,
- disparo de evento en confirmación de reserva,
- verificación de dataLayer con ID de reserva, valor y moneda,
- compatibilidad con GA4 ecommerce,
- posibilidad de enviar evento purchase,
- y conservación de parámetros o linker entre sitio y motor.
Mientras más claro sea el ticket, más probable es que el proveedor pueda resolverlo sin idas y vueltas innecesarias.
Problema 6: la conversión se mide como clic y no como reserva
Este error parece pequeño, pero puede afectar toda la estrategia.
A veces se marca como conversión el clic en el botón “Reservar”.
Eso puede servir como microconversión, pero no debe tratarse como venta.
Un clic al motor solo indica intención. La reserva confirmada indica negocio.
Solución
Separar eventos por nivel de intención.
Por ejemplo:
click_booking_button
sirve para medir cuántos usuarios intentan entrar al motor.
search_availability
sirve para medir búsqueda de fechas.
begin_checkout
sirve para medir inicio del proceso de compra.
purchase
debe usarse solo cuando la reserva está confirmada.
Google recomienda configurar eventos personalizados o recomendados en GA4 para medir interacciones relevantes, pero la clave está en definir qué evento representa una acción de negocio real.
En Google Ads, la conversión principal debería ser la reserva confirmada, no el clic en el motor.
Problema 7: el evento purchase se dispara duplicado
Este problema también es frecuente.
Puede ocurrir cuando:
GA4 está instalado directo y también vía GTM.
El motor tiene una integración nativa y además se configuró una etiqueta manual.
La página de confirmación se recarga.
El evento no usa ID único de transacción.
Google Ads recibe la conversión desde GA4 y también desde una etiqueta directa sin control.
Solución
Primero se auditan todas las fuentes de medición.
Hay que revisar:
- si existe gtag directo,
- si existe GTM,
- si Roiback o Easy-Rez tienen integración nativa,
- si hay scripts duplicados,
- si la página de confirmación recarga,
- y si el evento incluye transaction_id.
Para GA4 ecommerce, el evento de compra debería incluir un identificador único de transacción, valor y moneda cuando sea posible.
Sin transaction_id, es más difícil detectar duplicidades y validar reservas contra el motor.
Herramientas que usamos para validar cross-domain tracking
Una implementación de cross-domain no debe validarse “a ojo”.
En Iniciativa M usamos diferentes herramientas para confirmar qué está pasando realmente.
Google Tag Assistant
Sirve para revisar si la etiqueta de Google, GA4, Google Ads o GTM están presentes y si se disparan correctamente durante el flujo.
Vista previa de Google Tag Manager
GTM Preview permite ver qué etiquetas disparan, cuáles no, qué activadores se cumplen y qué variables están disponibles.
Esto es esencial para detectar si un evento se dispara en el momento correcto.
DebugView de GA4
DebugView permite ver eventos y propiedades de usuario en tiempo real para validar una implementación. Google indica que DebugView muestra eventos y propiedades que Analytics recoge de un usuario en tiempo real, lo que ayuda a solucionar problemas durante la instalación.
Revisión de parámetros en URL
Se valida si UTMs, linker, gclid, gbraid o wbraid permanecen durante el flujo o si se pierden por redirecciones.
Consola del navegador
Permite revisar errores de JavaScript, bloqueos, dataLayer, scripts y comportamiento del botón de reserva.
Network del navegador
Ayuda a confirmar qué solicitudes se envían a Google Analytics o Google Ads, qué parámetros viajan y si los hits se generan correctamente.
Pruebas con URLs parametrizadas
Creamos URLs de prueba con UTMs para validar si la atribución se conserva desde el sitio hasta el motor.
Por ejemplo:
https://www.hotel.com/?utm_source=test&utm_medium=test&utm_campaign=cross_domain_test
Después recorremos el flujo completo hasta la confirmación o hasta donde sea posible validar.
Checklist para detectar problemas de cross-domain
Este checklist ayuda a identificar dónde se puede estar rompiendo la medición:
| Pregunta | Qué puede indicar |
| ¿El motor aparece como referral en GA4? | Problema de cross-domain o referidos |
| ¿Google Ads tiene clics pero no conversiones? | Pérdida de gclid/gbraid/wbraid o conversión mal instalada |
| ¿El evento purchase no tiene valor? | Falta de dataLayer o ecommerce incompleto |
| ¿Las reservas se duplican? | Etiquetas repetidas o falta de transaction_id |
| ¿El botón abre otra pestaña? | Hay que revisar parámetros y linker |
| ¿Hay redirecciones intermedias? | Posible pérdida de parámetros |
| ¿El motor permite GTM? | Validar contenedor y páginas donde dispara |
| ¿El evento final ocurre en confirmación? | Evitar medir clics como ventas |
| ¿La sesión se conserva entre dominios? | Validar con DebugView y Tag Assistant |
| ¿El proveedor respondió el ticket? | Dar seguimiento con evidencia técnica |
Cómo trabajamos estos casos en Iniciativa M
En Iniciativa M no vemos el cross-domain como una configuración aislada. Somos expertos en revisar, configurar y auditar mediciones donde el usuario no convierte en una sola página, sino en un recorrido completo.
Lo vemos como una arquitectura de medición.
Primero entendemos el flujo real del usuario.
Después mapeamos dominios, subdominios, redirecciones y botones.
Luego revisamos GA4, GTM, Google Ads, Conversion Linker, eventos, dataLayer, UTMs y cookies.
Después hacemos pruebas con herramientas de depuración.
Si encontramos una limitación dentro del motor, levantamos tickets técnicos claros con el proveedor.
Y damos seguimiento hasta validar si el ajuste se resolvió.
Nuestro objetivo no es solo que “dispare una etiqueta”.
Nuestro objetivo es que GA4 y Google Ads puedan entender el recorrido completo del usuario y atribuir correctamente la conversión.
Porque una reserva, una compra o un lead no deberían perderse en el camino solo porque el usuario cambió de dominio.
