Seguimiento de mismo origen en Shopify: limitaciones del checkout y soluciones

El método de mismo origen enruta las solicitudes de seguimiento del lado del servidor a través del dominio de su sitio web en lugar de un subdominio de seguimiento independiente.

Define cuándo dos URL pertenecen al mismo origen web. Un origen consta de tres componentes: esquema (https:// o http://), nombre de host (p. ej., shop.example.com) y puerto (por ejemplo, 443 para HTTPS).

La ruta de la URL es un componente independiente de la URL y no determina su origen. Por ejemplo, estas URL tienen el mismo origen, aunque la segunda incluye una ruta:

• https://shop.example.com/
• https://shop.example.com/metrics

Sin embargo, compartir un origen a nivel de URL no garantiza que todos los entornos de navegador o plataformas permitan una solicitud a ese endpoint. Un ejemplo es el checkout de Shopify, que analizamos en detalle en esta guía.

El seguimiento del checkout de Shopify se ejecuta en un entorno más restringido que la tienda. Según la implementación del checkout, los scripts pueden ejecutarse con restricciones en las solicitudes de red, las API del navegador y las interacciones con otros orígenes.

Estas restricciones se aplican a su implementación de seguimiento en el sandbox del checkout y también afectan al funcionamiento de las soluciones de seguimiento.

Entre las restricciones más habituales que cualquier especialista en seguimiento puede notar está que, de forma predeterminada, no es posible ver los eventos del checkout en GTM Preview al probar la configuración. Esto ocurre porque el fragmento del contenedor de GTM se carga dentro del sandbox del checkout, y GTM Preview simplemente no sabe dónde buscar el contenedor. Para habilitar la depuración de GTM en el checkout, el código de seguimiento debe cargarse en la página principal durante su propia sesión del navegador. La extensión de Chrome Stape GTM Helper le permite hacerlo en unos pocos clics.

La limitación de GTM Preview es solo un ejemplo de cómo el entorno del checkout de Shopify se diferencia de las páginas de la tienda. En segundo plano, las restricciones del sandbox también afectan a la forma en que los navegadores gestionan la comunicación entre dominios, lo que repercute en el seguimiento mediante dominios de mismo origen.

Un endpoint de mismo origen es un enfoque útil para el seguimiento en la tienda, pero presenta limitaciones durante el checkout de Shopify.

Cuando un píxel del checkout de Shopify intenta enviar una solicitud al endpoint de mismo origen (p. ej., un evento de GA4 con el formato https://shop.stapedesk.com/metrics/g/collect), la consola del navegador puede mostrar un error similar al de la captura de pantalla siguiente:

En nuestra prueba, la solicitud falló con un RestrictedUrlError, lo que indica que el píxel del checkout intentó realizar la solicitud XHR/fetch al mismo dominio en el que se ejecuta la tienda, pero el runtime de píxeles de Shopify rechazó la solicitud antes de que el navegador la enviara.

¿Qué dice la documentación de Shopify?

Este error se ha notificado en la Shopify Community, pero, por el momento, la documentación de Shopify no documenta directamente la regla exacta que bloquea las solicitudes de mismo origen en el checkout.

No obstante, Shopify ofrece información sobre la arquitectura subyacente que puede explicar por qué ocurre. Según la página de Shopify sobre los web pixels, Shopify carga los Web Pixels dentro de un entorno aislado (sandbox) en el navegador del visitante, como se ha mencionado antes.

Esto significa que un píxel del checkout no se ejecuta con las mismas capacidades que otros scripts añadidos directamente al tema de Shopify. El píxel se ejecuta dentro del runtime controlado de Shopify, que aplica restricciones a las API del navegador y a las solicitudes de red.

Por ello, las solicitudes realizadas por un Web Pixel se evalúan según las reglas del entorno sandbox en el que se ejecuta el píxel, y no solo en función de la URL de destino (la URL que recibe la solicitud).

La clave es que «mismo dominio» no siempre significa «mismo contexto de ejecución». Una URL que es de mismo origen desde la perspectiva de la tienda del comerciante puede seguir estando restringida cuando se accede a ella desde el sandbox de Web Pixel de Shopify.

La siguiente prueba muestra que el sandbox de Web Pixel de Shopify no bloquea simplemente todas las solicitudes al dominio de la tienda. La restricción se aplica específicamente a las solicitudes HTTP programáticas, como fetch() y XMLHttpRequest.

Durante la prueba, los eventos del checkout se activaron en dos configuraciones de una tienda Shopify: endpoint de mismo origen y subdominio de seguimiento. La comparación de los tipos de solicitud muestra el comportamiento:

Esto podría explicar por qué los enfoques de seguimiento basados en píxeles de imagen (sus page_views, que en su mayoría son solicitudes GET) pueden funcionar, mientras que las implementaciones de seguimiento del lado del servidor que usan fetch() hacia un endpoint de mismo origen pueden fallar.

Parece que las solicitudes GET y beacon simplemente no pasan por el wrapper propio de Shopify para XHR y fetch, por lo que podrían limitarse sin aviso en cualquier momento en el futuro, suponiendo que se trate de un descuido. Esto, por supuesto, es una especulación.

Un service worker es un archivo JavaScript que se ejecuta de forma independiente de la página principal del navegador. Se usa habitualmente para funciones como el soporte sin conexión, el almacenamiento en caché y la interceptación de solicitudes de red.

En el contexto del seguimiento del checkout de Shopify, puede interceptar solicitudes de red y ayudar a gestionarlas incluso cuando el comportamiento de la página se interrumpe. Es la solución que utiliza Google Analytics 4 para ayudar a reducir la pérdida de solicitudes de seguimiento.

Sin embargo, como usted no controla explícitamente qué evento se enviará a través del worker y este no es el caso de uso para el que GA4 los introdujo, no se debe confiar en ellos para el seguimiento de eventos del checkout de Shopify. Puede capturar algunos eventos de checkout/purchase, por supuesto, y puede parecer que todo funciona, pero es pura suerte: haga más pruebas.

Incluso si las solicitudes de mismo origen no se bloquearan en el sandbox de eventos personalizados de Shopify, sus beneficios prácticos serían limitados debido al entorno sandbox de Shopify (sí, otra vez).

El enfoque de mismo origen es beneficioso, sobre todo, porque permite establecer las cookies con su duración prevista en ITP y entornos similares. Pero en el sandbox del checkout, las cookies no se incluyen en sus solicitudes de seguimiento y, del mismo modo, tampoco funcionará establecerlas mediante las respuestas. Por eso nuestro Data Tag incluye la opción Send Common Cookies, que añade las cookies a la carga útil (payload) de la solicitud.

Como el iframe del sandbox se configura sin allow-same-origin, el navegador le asigna un origen opaco, por lo que siempre aparece como null. Esto ocurre incluso cuando el iframe se sirve desde el propio dominio de la tienda e independientemente de si la solicitud establece explícitamente ‘credentials: include’ o ‘mode: cors’. Como resultado, el navegador considera estas solicitudes como cross-site al gestionar las cookies. En términos sencillos, el navegador trata las cookies asociadas como cookies de terceros.

Simo Ahava ya describió en detalle este problema de cookies en el checkout de Shopify en 2024.

Para las tiendas Shopify que tienen configurado el seguimiento del lado del servidor, se recomienda utilizar un enfoque híbrido:

• enfoque de mismo origen en la tienda;
• enrutamiento estándar mediante subdominio para el checkout.

En la tienda, el seguimiento de mismo origen ofrece los beneficios esperados (mejor enrutamiento de solicitudes first-party, gestión de cookies y resiliencia del seguimiento), ya que las solicitudes de seguimiento se envían desde el mismo contexto de dominio que el sitio web.

Sin embargo, el checkout de Shopify tiene restricciones que impiden que el enfoque de mismo origen funcione igual que en la tienda. Por tanto, el enrutamiento estándar mediante subdominio es más adecuado. Enrutar las solicitudes de seguimiento a través de un subdominio de seguimiento dedicado permite evitar esta restricción concreta, de modo que estas solicitudes lleguen al endpoint de seguimiento.

La configuración de mismo origen para la tienda de Shopify puede realizarse con distintos proveedores de DNS e infraestructura. La configuración exacta depende del proveedor que utilice.

Por ejemplo, Cloudflare ofrece una integración Orange-to-Orange (O2O) que permite enrutar el tráfico tanto a través de la zona de Cloudflare del comerciante como de la infraestructura de Cloudflare de Shopify. Esto proporciona un control adicional sobre la gestión del tráfico y, al mismo tiempo, mantiene su dominio como punto de entrada.

Otros proveedores pueden ofrecer soluciones similares mediante proxy inverso, CDN o funciones de nombre de host personalizado, pero los pasos de configuración y las funciones compatibles pueden variar según la plataforma.

Para el checkout de Shopify, utilice una configuración estándar de subdominio.

A diferencia de una configuración de mismo origen, la configuración del subdominio requiere añadir registros DNS para conectar el subdominio con su proveedor de seguimiento del lado del servidor.

Una vez configurados los dominios de seguimiento de la tienda y del checkout, debe configurar GTM para enviar los datos de eventos a su contenedor del lado del servidor.

En su contenedor web de GTM, añada y configure la plantilla Data Tag. Esta etiqueta envía los datos de eventos junto con los parámetros configurados a su contenedor de servidor de GTM.

En el contenedor de servidor de GTM, instale y configure Data Client. Data Client recibe y analiza las solicitudes de Data Tag. De este modo, los datos de eventos entrantes quedan disponibles para las etiquetas del servidor de GTM.

Esta opción envía los valores de las cookies del navegador más utilizadas junto con los datos del evento. Son importantes para la atribución, la identificación de usuarios y el seguimiento de conversiones, especialmente cuando los eventos del checkout de Shopify se ejecutan en un entorno aislado con acceso restringido a los datos de la tienda.

Active esta opción en cada Data Tag que deba activarse en la página del checkout.

La lógica de selección del dominio se gestiona en el contenedor web de GTM, ya que esta decisión debe tomarse antes de enviar la solicitud. Después, el contenedor de servidor recibe las solicitudes del endpoint seleccionado y continúa procesándolas con los clientes y las etiquetas configurados.

Para definir la lógica, utilice la variable RegEx Table.

3.1 Para configurarla, vaya a la sección Variables del GTM web → haga clic en New → seleccione RegEx Table como configuración de la variable.

3.2 Seleccione una Input Variable para la variable.

La condición concreta dependerá del flujo de su sitio web de Shopify. En nuestro caso, las páginas de checkout y de agradecimiento (thank-you) están alojadas en el mismo dominio, pero el Page Path es distinto.

Si necesita más detalles sobre cómo encontrar la Input Variable para su sitio web de Shopify, haga clic en el elemento desplegable siguiente:

Especifique la Input Variable (en nuestro caso, Page Path).

3.3 Introduzca el patrón y el resultado necesario.

Introduzca el Pattern mediante expresiones regulares.

Para nuestro flujo, funciona la siguiente regex:

Coincide con cualquier cadena que empiece por /checkouts, independientemente de lo que venga después.

Como Output, especifique el subdominio que debe utilizarse para el seguimiento en el entorno sandbox.

Marque la casilla Set Default Value y añada como Default Value una variable que contenga su dominio de mismo origen.

Este es un ejemplo de configuración de la variable:

Guarde los cambios.

Sustituya en sus etiquetas cualquier valor de URL de mismo origen escrito directamente en el código (hardcoded), o las variables que contengan la URL de mismo origen, por la variable RegEx Table.

La variable devolverá automáticamente el dominio correcto según el contexto de la página actual, de modo que las solicitudes de los entornos de la tienda y del checkout se enruten a través del endpoint adecuado.

A continuación se muestra un ejemplo. Revise las etiquetas de su contenedor web de GTM y actualícelas cuando sea necesario.

Verifique que la configuración de seguimiento funciona correctamente tanto en el entorno de la tienda como en el del checkout.

Para ver los detalles de depuración, haga clic en el elemento desplegable correspondiente:

El seguimiento del checkout de Shopify supone un reto, en particular en el contexto del seguimiento del lado del servidor. El enfoque de mismo origen ofrece todos sus beneficios en las páginas de la tienda, pero el entorno del checkout tiene restricciones de sandbox que impiden que ese mismo enfoque funcione correctamente.

La mejor solución, por ahora, es adaptar su arquitectura de seguimiento al entorno de Shopify: mantener la configuración de mismo origen donde aporte valor y utilizar el enfoque estándar de subdominio para los eventos del checkout. Con una configuración correcta de GTM y un proceso de pruebas adecuado, puede mantener un seguimiento preciso en todo el recorrido del usuario.

Esté atento a las novedades de Stape. Trabajamos constantemente para mejorar las soluciones de seguimiento del lado del servidor y adaptarnos a los cambios del ecosistema de Shopify. Sabemos lo importante que es un seguimiento preciso para su negocio, y buscamos mejores formas de superar estos retos y compartir con usted nuestros últimos hallazgos.