Rastreio de mesma origem no Shopify: limitações do checkout e soluções

O método de mesma origem encaminha os pedidos de rastreio do lado do servidor através do domínio do seu website, em vez de um subdomínio de rastreio separado.

Define quando dois URL pertencem à mesma origem web. Uma origem é composta por três componentes: esquema (https:// ou http://), nome do anfitrião (p. ex., shop.example.com) e porta (por exemplo, 443 para HTTPS).

O caminho do URL é um componente separado do URL e não determina a sua origem. Por exemplo, estes URL têm a mesma origem, embora o segundo inclua um caminho:

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

No entanto, partilhar uma origem ao nível do URL não garante que todos os ambientes de navegador ou plataformas permitam um pedido para esse endpoint. Um exemplo é o checkout do Shopify, que abordamos em detalhe neste guia.

O rastreio do checkout do Shopify é executado num ambiente mais restrito do que a loja. Consoante a implementação do checkout, os scripts podem ser executados com restrições nos pedidos de rede, nas API do navegador e nas interações com outras origens.

Estas restrições aplicam-se à sua implementação de rastreio na sandbox do checkout e afetam também o funcionamento das soluções de rastreio.

Entre as restrições mais comuns que qualquer especialista em rastreio poderá notar está o facto de, por predefinição, não ser possível ver os eventos do checkout no GTM Preview ao testar a configuração. Isto acontece porque o snippet do contentor GTM é carregado na sandbox do checkout e o GTM Preview simplesmente não sabe onde procurar o contentor. Para ativar a depuração do GTM no checkout, o código de rastreio tem de ser carregado na página principal (parent) para a sua própria sessão do navegador. A extensão Chrome Stape GTM Helper permite fazê-lo em poucos cliques.

A limitação do GTM Preview é apenas um exemplo de como o ambiente do checkout do Shopify difere das páginas da loja. Nos bastidores, as restrições da sandbox afetam também a forma como os navegadores gerem a comunicação entre domínios, o que tem impacto no rastreio com domínios de mesma origem.

Um endpoint de mesma origem é uma abordagem útil para o rastreio na loja, mas apresenta limitações durante o checkout do Shopify.

Quando um pixel do checkout do Shopify tenta enviar um pedido para o endpoint de mesma origem (p. ex., um evento GA4 no formato https://shop.stapedesk.com/metrics/g/collect), a consola do navegador pode apresentar um erro semelhante ao da captura de ecrã abaixo:

No nosso teste, o pedido falhou com um RestrictedUrlError, o que indica que o pixel do checkout tentou efetuar o pedido XHR/fetch para o mesmo domínio onde a loja está a ser executada, mas o pedido foi rejeitado pelo runtime de pixels do Shopify antes de o navegador o enviar.

O que diz a documentação do Shopify?

Este erro foi reportado na Shopify Community, mas, de momento, a documentação do Shopify não documenta diretamente a regra exata que bloqueia os pedidos de mesma origem no checkout.

No entanto, o Shopify disponibiliza informação sobre a arquitetura subjacente que pode explicar porque isto acontece. De acordo com a página do Shopify sobre web pixels, o Shopify carrega os Web Pixels num ambiente isolado (sandbox) no navegador do visitante, tal como referido anteriormente.

Isto significa que um pixel do checkout não é executado com as mesmas capacidades que outros scripts adicionados diretamente ao tema do Shopify. O pixel é executado no runtime controlado do Shopify, que aplica restrições às API do navegador e aos pedidos de rede.

Por isso, os pedidos efetuados por um Web Pixel são avaliados de acordo com as regras do ambiente sandbox onde o pixel é executado, e não apenas com base no URL de destino (o URL que recebe o pedido).

O ponto-chave é que «mesmo domínio» nem sempre significa «mesmo contexto de execução». Um URL que é de mesma origem do ponto de vista da loja do comerciante pode, ainda assim, ser restringido quando acedido a partir da sandbox de Web Pixels do Shopify.

O teste seguinte mostra que a sandbox de Web Pixels do Shopify não bloqueia simplesmente todos os pedidos para o domínio da loja. A restrição aplica-se especificamente a pedidos HTTP programáticos, como fetch() e XMLHttpRequest.

Durante o teste, os eventos do checkout foram acionados em duas configurações numa loja Shopify: endpoint de mesma origem e subdomínio de rastreio. Uma comparação dos tipos de pedido mostra o comportamento:

Isto poderá explicar porque é que as abordagens de rastreio baseadas em pixels de imagem (os seus page_views, que são maioritariamente pedidos GET) podem funcionar, enquanto as implementações de rastreio do lado do servidor que utilizam fetch() para um endpoint de mesma origem podem falhar.

Parece que os pedidos GET e beacon simplesmente não passam pelo wrapper próprio do Shopify para XHR e fetch e, como tal, poderão ser limitados sem aviso a qualquer momento no futuro, partindo do princípio de que se trata de um descuido. Isto é, naturalmente, uma especulação.

Um service worker é um ficheiro JavaScript executado separadamente da página principal do navegador. É normalmente utilizado em funcionalidades como suporte offline, cache e interceção de pedidos de rede.

No contexto do rastreio do checkout do Shopify, pode intercetar pedidos de rede e ajudar a processá-los mesmo quando o comportamento da página é interrompido. É a solução que o Google Analytics 4 utiliza para ajudar a reduzir a perda de pedidos de rastreio.

No entanto, como não controla explicitamente que evento será enviado através do worker e este não é o caso de utilização para o qual o GA4 os introduziu, não deve depender deles para o rastreio de eventos do checkout do Shopify. Poderá captar alguns eventos de checkout/purchase, é certo, e pode parecer que tudo está a funcionar, mas isso é pura sorte – faça mais testes.

Mesmo que os pedidos de mesma origem não fossem bloqueados na sandbox de eventos personalizados do Shopify, os seus benefícios práticos seriam limitados devido ao ambiente sandbox do Shopify (sim, outra vez).

A abordagem de mesma origem é vantajosa sobretudo porque permite definir os cookies com o seu tempo de vida previsto no ITP e em ambientes semelhantes. Mas, na sandbox do checkout, os cookies não são incluídos nos seus pedidos de rastreio; da mesma forma, defini-los através das respostas também não resultará. É por isso que a nossa Data Tag inclui a opção Send Common Cookies, que adiciona os cookies ao payload do pedido.

Como o iframe da sandbox é configurado sem allow-same-origin, o navegador atribui-lhe uma origem opaca, pelo que aparece sempre como null. Isto acontece mesmo quando o iframe é servido a partir do próprio domínio da loja e independentemente de o pedido definir explicitamente ‘credentials: include’ ou ‘mode: cors’. Consequentemente, o navegador considera estes pedidos como cross-site ao gerir os cookies. Em termos simples, o navegador trata os cookies associados como cookies de terceiros.

Simo Ahava descreveu em detalhe este problema de cookies no checkout do Shopify já em 2024.

Para lojas Shopify com rastreio do lado do servidor configurado, a abordagem recomendada é híbrida:

• abordagem de mesma origem na loja;
• encaminhamento padrão por subdomínio para o checkout.

Na loja, o rastreio de mesma origem proporciona os benefícios esperados (melhor encaminhamento de pedidos first-party, melhor gestão de cookies e maior resiliência do rastreio), uma vez que os pedidos de rastreio são enviados a partir do mesmo contexto de domínio que o website.

No entanto, o checkout do Shopify tem restrições que impedem a abordagem de mesma origem de funcionar da mesma forma que na loja. Por isso, o encaminhamento padrão por subdomínio é mais adequado. Encaminhar os pedidos de rastreio através de um subdomínio de rastreio dedicado permite evitar esta restrição específica, fazendo com que estes pedidos cheguem ao endpoint de rastreio.

A configuração de mesma origem para a loja Shopify pode ser feita com diferentes fornecedores de DNS e de infraestrutura. A configuração exata depende do fornecedor que utiliza.

Por exemplo, a Cloudflare disponibiliza uma integração Orange-to-Orange (O2O) que permite encaminhar o tráfego tanto através da zona Cloudflare do comerciante como da infraestrutura Cloudflare do Shopify. Isto proporciona um controlo adicional sobre a gestão do tráfego, mantendo ao mesmo tempo o seu domínio como ponto de entrada.

Outros fornecedores poderão oferecer soluções semelhantes através de proxy inverso, CDN ou funcionalidades de nome de anfitrião personalizado, mas os passos de configuração e as funcionalidades suportadas podem variar consoante a plataforma.

Para o checkout do Shopify, utilize uma configuração padrão de subdomínio.

Ao contrário de uma configuração de mesma origem, a configuração do subdomínio requer a adição de registos DNS para ligar o subdomínio ao seu fornecedor de rastreio do lado do servidor.

Depois de configurar os domínios de rastreio da loja e do checkout, tem de configurar o GTM para enviar os dados de eventos para o seu contentor do lado do servidor.

No seu contentor web do GTM, adicione e configure o modelo Data Tag. Esta tag envia os dados de eventos juntamente com os parâmetros configurados para o seu contentor de servidor do GTM.

No contentor de servidor do GTM, instale e configure o Data Client. O Data Client recebe e analisa os pedidos da Data Tag. Desta forma, os dados de eventos recebidos ficam disponíveis para as tags do GTM de servidor.

Esta opção envia os valores dos cookies do navegador mais utilizados juntamente com os dados do evento. São importantes para a atribuição, a identificação de utilizadores e o rastreio de conversões, em particular quando os eventos do checkout do Shopify são executados num ambiente isolado com acesso restrito aos dados da loja.

Ative esta opção em cada Data Tag que deva ser acionada na página do checkout.

A lógica de seleção do domínio é gerida no contentor web do GTM, uma vez que esta decisão tem de ser tomada antes de o pedido ser enviado. Em seguida, o contentor de servidor recebe os pedidos do endpoint selecionado e continua a processá-los através dos clients e das tags configurados.

Para definir a lógica, utilize a variável RegEx Table.

3.1 Para a configurar, aceda à secção Variables do GTM web → clique em New → selecione RegEx Table como configuração da variável.

3.2 Selecione uma Input Variable para a variável.

A condição específica dependerá do fluxo do seu website Shopify. No nosso caso, as páginas de checkout e de agradecimento (thank-you) estão alojadas no mesmo domínio, mas o Page Path é diferente.

Se precisar de mais detalhes sobre como encontrar a Input Variable para o seu website Shopify, clique no elemento expansível abaixo:

Especifique a Input Variable (no nosso caso, Page Path).

3.3 Introduza o padrão e o resultado pretendido.

Introduza o Pattern através de expressões regulares.

Para o nosso fluxo, a seguinte regex funciona:

Corresponde a qualquer cadeia de caracteres que comece por /checkouts, independentemente do que vem a seguir.

Como Output, especifique o subdomínio que deve ser utilizado para o rastreio no ambiente sandbox.

Se um valor for utilizado em várias entidades do GTM, defina-o uma única vez como variável constante e reutilize essa variável sempre que necessário.

Assinale a caixa Set Default Value e adicione uma variável com o seu domínio de mesma origem como Default Value.

Eis um exemplo de configuração da variável:

Guarde as alterações.

Substitua nas suas tags quaisquer valores de URL de mesma origem definidos diretamente no código (hardcoded), ou variáveis que contenham o URL de mesma origem, pela variável RegEx Table.

A variável devolverá automaticamente o domínio correto com base no contexto da página atual, para que os pedidos dos ambientes da loja e do checkout sejam encaminhados através do endpoint adequado.

Segue-se um exemplo. Reveja as tags no seu contentor web do GTM e atualize-as quando necessário.

Verifique se a configuração de rastreio funciona corretamente tanto no ambiente da loja como no do checkout.

Para ver os detalhes da depuração, clique no elemento expansível correspondente abaixo:

O rastreio do checkout do Shopify é um desafio, em particular no contexto do rastreio do lado do servidor. A abordagem de mesma origem oferece todos os benefícios nas páginas da loja, mas o ambiente do checkout tem restrições de sandbox que impedem essa mesma abordagem de funcionar corretamente.

A melhor solução, por agora, é adaptar a sua arquitetura de rastreio ao ambiente do Shopify: manter a configuração de mesma origem onde acrescenta valor e utilizar uma abordagem padrão por subdomínio para os eventos do checkout. Com a configuração correta do GTM e um processo de testes adequado, pode manter um rastreio preciso ao longo de todo o percurso do utilizador.

Acompanhe as novidades da Stape. Trabalhamos continuamente para melhorar as soluções de rastreio do lado do servidor e acompanhar as mudanças no ecossistema Shopify. Sabemos como um rastreio preciso é importante para o seu negócio, e procuramos melhores formas de superar estes desafios e partilhar consigo as nossas descobertas mais recentes!