"Meu site principal e meu domínio separado de cadastro ou checkout trocam usuários entre si, mas os números do GA4 simplesmente não batem." Esse é um ponto de tropeço muito comum para serviços que abrangem múltiplos domínios. Mesmo quando o rastreamento por página parece funcionar bem, se a identidade do usuário é cortada no momento em que ele cruza domínios, seus relatórios e sua otimização de lances vão silenciosamente para o buraco.
Alguma dessas situações soa familiar?
- Seu próprio domínio aparece como fonte de tráfego no relatório de referência (um self-referral)
- É um único usuário, mas a sessão se divide em duas no momento em que ele cruza domínios
- As contagens de usuários e sessões saem infladas — mais altas do que deveriam
- As conversões de cadastro ou checkout não se conectam à campanha que trouxe o visitante
Este guia organiza como o cross-domain tracking do GA4 quebra, como verificar isso usando o parâmetro linker _gl e o DebugView, os pontos cegos que costumam passar despercebidos, e como pensar sobre verificação em produção.
O que é o cross-domain tracking, de fato
O GA4 diferencia usuários com um identificador chamado client_id, normalmente armazenado no cookie daquele domínio. Aqui está a armadilha: cookies não são compartilhados entre domínios. Então, quando um usuário se move de site.com para checkout.outrosite.com, o destino conta a mesma pessoa como um usuário completamente novo.
O cross-domain tracking evita isso. Quando você configura seus domínios, o GA4 automaticamente adiciona um parâmetro linker — _gl= — na URL durante a navegação por link, carregando o client_id consigo. Sem essa configuração, essa transferência nunca acontece.
| Estado | O que acontece | Sintoma típico |
|---|---|---|
| Configurado (saudável) | _gl= é adicionado à URL; o client_id é transferido |
Continua como o mesmo usuário, mesma sessão |
| Não configurado (quebrado) | O client_id não é transferido; é reatribuído no destino | Fragmentação de sessão, self-referral, contagens infladas |
| Sem exclusão de referência | Gateways de pagamento etc. são registrados como fonte de tráfego | Self-referral quebra a atribuição |
O ponto-chave: "a tag dispara em cada domínio" e "a mesma pessoa é reconhecida entre domínios" são duas coisas diferentes. A maioria das verificações para na primeira. Confirmar se a própria tag do GA4 dispara é abordado em como verificar se sua tag do GA4 está funcionando, mas este artigo trata do que vem depois — se a transferência acontece.
Subdomínios vs. cross-domain: uma fonte comum de confusão
Antes de mergulhar nas causas, vale esclarecer um ponto que confunde muitas equipes: subdomínios e cross-domain não são a mesma coisa, e o GA4 os trata de forma diferente.
Se a jornada do seu usuário permanece dentro de subdomínios do mesmo domínio pai — por exemplo, de www.seusite.com para blog.seusite.com até shop.seusite.com — o GA4 lida com isso automaticamente. O cookie _ga é definido no domínio pai (.seusite.com), então fica acessível a todos os subdomínios sem qualquer configuração extra.
O cross-domain tracking só é necessário quando os usuários se movem entre domínios completamente diferentes — por exemplo, de seusite.com para checkout.outrodominio.com. Esses são cookie jars separados, e é aí que entra o parâmetro linker _gl.
| Cenário | Configuração necessária? |
|---|---|
www.seusite.com → blog.seusite.com |
Não — o GA4 lida com subdomínios automaticamente |
seusite.com → checkout.outrodominio.com |
Sim — o cross-domain tracking precisa ser configurado |
seusite.com → payment.stripe.com (terceiro) |
Apenas exclusão de referência (você não pode instalar sua tag em um domínio que não possui) |
Erro comum: configurar cross-domain tracking entre seus próprios subdomínios quando isso não é necessário. Isso pode até introduzir parâmetros
_gldesnecessários e causar problemas. Se ambas as páginas compartilham o mesmo domínio pai, basta garantir que a mesma tag do GA4 esteja instalada em ambas — nenhuma configuração de domínio é necessária.
Causa 1: "Configure your domains" não está definido
A causa mais comum. No painel do GA4, em "Fluxos de dados → Configurar definições de tag → Configure your domains", você deve registrar todos os domínios entre os quais os usuários transitam. Se o domínio de destino não estiver na lista, o GA4 não adicionará o parâmetro linker e o client_id não será transferido.
O que verificar: se todos os domínios relevantes estão registrados, sem lacunas. Fique atento a variantes de subdomínio (www vs sem www, shop. e assim por diante).
Erro comum: assumir que "coloquei o mesmo ID de medição nos dois domínios, então está coberto." Instalar a tag e configurar seus domínios são duas tarefas separadas. A tag pode estar presente, mas sem a configuração de domínio a transferência ainda não vai acontecer.
Causa 2: _gl= não está sendo adicionado à URL
Se a transferência está realmente funcionando é algo visível na URL após a navegação. Logo depois que um link te leva de site.com para checkout.outrosite.com, se a barra de endereço mostra uma longa string começando com _gl=, a transferência está funcionando. Se estiver ausente, algo está quebrando pelo caminho.
O que verificar: clique de verdade no link cross-domain e veja se _gl= aparece na URL de destino. Se não aparecer, suspeite da Causa 1 (um domínio faltando) ou da forma como o link foi implementado (abaixo).
Erro comum: se você navega reescrevendo
window.locationem JavaScript, ou passa por um envio de formulário ou redirecionamento, o_glpode ser descartado em vez de adicionado e preservado. "Um link<a>comum carrega o parâmetro, mas passar por um botão não" é um padrão clássico.
Causa 3: Exclusão de referência (self-referral) não está configurada
Quando você passa por um processador de pagamento, carrinho ou formulário externo, esse domínio pode ser registrado no GA4 como fonte de tráfego (referência). Aí checkout.outrosite.com ou o gateway de pagamento — em vez da sua real campanha de aquisição — é tratado como "a última fonte antes da conversão", e a atribuição quebra. Isso é um self-referral.
Configurar o cross-domain tracking corretamente resolve a maior parte disso, mas quando você passa por um domínio que você não possui (como um gateway de pagamento), você precisa adicionalmente adicionar esse domínio à lista de "referências indesejadas / exclusão de referência" do GA4. Para entender como os IDs de clique de anúncios são transferidos, veja como funcionam o gclid e os click IDs.
Erro comum: ver seu próprio domínio ou um domínio de pagamento listado no relatório de referência e comemorar "estamos recebendo tráfego." Isso pode não ser aquisição nova — pode ser um sinal de que o mesmo usuário está saindo e sendo recontado, inflando os números.
Causa 4: O consentimento de cookies (CMP) bloqueia o destino
Mesmo quando o parâmetro _gl chega corretamente na URL de destino, a transferência ainda pode falhar silenciosamente se o estado de consentimento de cookies do usuário impedir o GA4 de gravar um cookie no domínio de destino. Isso está cada vez mais comum com o Consent Mode v2 e a aplicação mais rigorosa de CMPs (Consent Management Platforms).
Veja como isso quebra: um visitante aceita cookies em site.com e navega para checkout.outrosite.com. O parâmetro _gl é transferido, mas o banner de consentimento em checkout.outrosite.com ainda não foi aceito — ou usa um CMP diferente que não compartilha o estado de consentimento. O GA4 no destino vê "sem consentimento" e ou dispara em modo cookieless ou não dispara de forma alguma. Resultado: o client_id vindo do _gl é ignorado, e a sessão se divide.
O que verificar: se seu CMP compartilha o estado de consentimento entre seus domínios. Muitos CMPs suportam compartilhamento de consentimento cross-domain, mas isso precisa ser configurado explicitamente. Verifique também se o parâmetro analytics_storage do Consent Mode está concedido ("granted") em todos os domínios antes de assumir que a transferência funciona.
Erro comum: testar o cross-domain tracking na sua própria máquina, onde você já aceitou cookies em ambos os domínios, e concluir que "está funcionando." Visitantes reais que chegam ao destino pela primeira vez enfrentam o banner de consentimento, e se o consentimento não for concedido ou transferido, a transferência falha — mesmo com um
_glperfeitamente formado na URL.
Causa 5: ITP do Safari e restrições de privacidade do navegador
O Intelligent Tracking Prevention (ITP) do Safari impõe um limite de expiração de 7 dias em cookies primários definidos via JavaScript — incluindo o cookie _ga do GA4. Se um usuário não retornar em 7 dias, seu client_id desaparece, e ele é contado como um novo usuário na próxima visita. Para o cross-domain tracking, o impacto se soma.
Mesmo quando o _gl consegue transferir o client_id com sucesso para o domínio de destino, o Safari pode já ter expirado o cookie original. E do lado do destino, o cookie recém-gravado também estará sujeito ao mesmo limite de 7 dias. O resultado: jornadas de múltiplas sessões que atravessam domínios são especialmente frágeis no Safari, que representa de 25% a 35% do tráfego web em muitos mercados (e mais no mobile).
Outros navegadores estão seguindo o mesmo caminho. O Enhanced Tracking Protection do Firefox e o bloqueio nativo do Brave podem interferir de forma semelhante, ainda que por mecanismos diferentes.
O que verificar: se o seu cross-domain tracking se mantém funcional especificamente no Safari. Teste a jornada completa em uma janela privada do Safari (onde o ITP é mais rigoroso) e compare o comportamento do client_id com o Chrome.
Erro comum: testar apenas no Chrome, onde as restrições de cookies são mínimas, e assumir que os resultados se aplicam em todo lugar. Usuários do Safari — muitas vezes uma grande parcela do tráfego mobile — podem estar silenciosamente fragmentando suas sessões e inflando suas contagens de usuários sem nenhum erro visível nos seus relatórios.
Como verificar: confira três coisas juntas
Se o cross-domain tracking está vivo se resume a estas três verificações, usadas em conjunto.
_gl=na URL de destino: clique no link cross-domain e veja se o parâmetro linker aparece na URL de destino.- client_id no DebugView: no DebugView do GA4, opere ambos os domínios em sequência e confirme se o mesmo
client_idé usado. Se ele for reatribuído, a transferência falhou. - Relatório de referência: verifique se seu próprio domínio ou o domínio de pagamento aparece como fonte de tráfego no relatório de origem/mídia. Se aparecer, um self-referral está acontecendo.
Só quando os três se alinham você pode dizer "a mesma pessoa está sendo rastreada entre domínios." Para separar isso de saber se a própria conversão foi registrada, veja também por que uma conversão dispara mas não é registrada. Se o problema mais amplo é zero conversões no Google Ads, veja Sem Conversões no Google Ads? Um Guia de Diagnóstico Passo a Passo para o fluxo de diagnóstico completo.
O que verificar na sua própria máquina não consegue te dizer
Todas as três verificações acima são úteis, mas verificar uma única vez na sua própria máquina tem duas limitações estruturais.
- Seu ambiente não é o ambiente dos seus visitantes. Estado de login, extensões de navegador, configurações de cookies, exclusão de IP do escritório e coisas do tipo fazem com que o
_glpareça presente na sua máquina, mas a transferência falhe sob condições reais de visitantes (um navegador diferente, proteção contra rastreamento, estado de consentimento). - Caminhos que envolvem um clique em anúncio são difíceis de reproduzir. Para realmente confirmar "quando alguém chega via um anúncio e cruza domínios, isso ainda se conecta à campanha de aquisição," você precisaria clicar em um anúncio ativo para recriar o caminho — o que carrega o risco de violação de política de anúncios por autoclique.
Julgar "o _gl está presente, então está tudo bem" na sua própria máquina tende a deixar passar o problema de a transferência falhar no caminho real que seus visitantes percorrem.
Checklist de verificação
- Todos os domínios entre os quais os usuários transitam estão registrados em "Configure your domains" do GA4?
- Há variantes de subdomínio não cobertas (
wwwvs semwww, etc.)? - O
_gl=aparece na URL após uma navegação cross-domain? - O
_glé preservado mesmo através de botões, formulários e redirecionamentos? - No DebugView, o
client_idé idêntico entre os dois domínios? - Seu próprio domínio ou o domínio de pagamento aparece no relatório de referência?
- Você adicionou domínios de terceiros (gateways de pagamento, etc.) à lista de exclusão de referência?
- Seu CMP compartilha o estado de consentimento entre todos os domínios, de modo que o GA4 tenha permissão para gravar cookies no destino?
- Você testou a jornada completa no Safari (onde o ITP limita cookies a 7 dias)?
- A transferência se mantém sob condições reais de usuários em produção (não apenas o seu único teste)?
Perguntas frequentes
P. Se eu colocar a mesma tag do GA4 em ambos os domínios, isso já é cross-domain tracking? R. Não. Além de instalar a tag, você precisa registrar os domínios em "Configure your domains" do GA4. Instalação e configuração são tarefas separadas.
P. O que o parâmetro _gl faz?
R. É o parâmetro linker do GA4. Ele é adicionado automaticamente à URL durante a navegação por link cross-domain e carrega informações de identificação, como o client_id, até o destino. Sem ele, o destino conta o visitante novamente como um novo usuário.
P. O que é um self-referral? R. É quando outro domínio seu, ou um domínio de pagamento, é registrado no GA4 como "fonte de tráfego (referência)." Causado por configuração de cross-domain ausente ou exclusão de referência faltando, isso desvia a atribuição da sua real fonte de aquisição.
P. Eu uso um gateway de pagamento externo. O que devo configurar? R. Registre os domínios que você possui em "Configure your domains", e adicione o domínio do gateway de pagamento que você não possui à lista de exclusão de referência do GA4. Faça as duas coisas juntas.
P. Preciso de cross-domain tracking para subdomínios?
R. Não. O GA4 lida automaticamente com subdomínios do mesmo domínio pai (por exemplo, www.seusite.com e shop.seusite.com), porque o cookie é definido no domínio pai. A configuração de cross-domain só é necessária quando usuários se movem entre domínios completamente diferentes.
P. Banners de consentimento de cookies podem quebrar o cross-domain tracking?
R. Sim. Se o seu CMP não compartilha o estado de consentimento entre domínios, o GA4 no destino pode não ter permissão para gravar cookies — mesmo que o parâmetro _gl tenha chegado corretamente. Certifique-se de que seu gerenciamento de consentimento esteja configurado para compartilhamento de consentimento cross-domain.
P. O Safari afeta o cross-domain tracking de forma diferente?
R. Sim. O ITP do Safari limita cookies definidos via JavaScript (incluindo o cookie _ga do GA4) a 7 dias de inatividade. Isso significa que usuários recorrentes do Safari costumam ser contados como novos, e jornadas cross-domain de múltiplas sessões são especialmente frágeis. A definição de cookies no lado do servidor pode mitigar isso.
P. Minha contagem de usuários está mais alta do que deveria — o cross-domain é a causa?
R. Pode ser. Quando a transferência falha, o mesmo usuário é reatribuído como novo no destino, inflando as contagens de usuários e sessões. Verifique no DebugView se o client_id está sendo transferido.
Conclusão: não pare no disparo — verifique a transferência
Verificar o cross-domain tracking exige mais do que checar se a tag dispara em cada domínio. O que importa é o que vem depois — se a identidade é transferida entre domínios como o mesmo usuário, e se o client_id é preservado no caminho real que seus visitantes percorrem em produção. Para o panorama completo, veja o guia completo de rastreamento de conversões do GA4.
O ConversionOK executa sua página real em um navegador independente e isolado e intercepta os eventos e o client_id efetivamente enviados, então os verifica — sem necessidade de clicar no seu próprio anúncio e sem interferência do seu ambiente de escritório. Comece com uma verificação estática gratuita para confirmar o ponto de entrada da sua medição.