Google tag gateway: o que ele resolve — e o que não resolve

Você fez o que todo mundo mandou fazer. Migrou pro server-side GTM. Apontou um subdomínio pra ele, track.sualoja.com.br, bonitinho, mesmo domínio do site. O consultor chamou aquilo de first-party.

E o GA4 continua sem bater com o seu financeiro.

E não é por pouco. A loja diz 800 pedidos no mês. O GA4 diz 610. A Meta reivindica 540 e alguma coisa, com uma casa decimal que dá aquela impressão de precisão. Ninguém consegue te dizer qual está certo, e a resposta honesta é: nenhum.

O que quase nunca é dito: mudar o servidor nunca foi a correção. Onde o evento é processado e como o navegador é obrigado a chegar até esse processador são dois problemas diferentes. O server-side GTM resolve o primeiro. Quase toda implementação que existe por aí erra o segundo. E é o segundo que o bloqueador e o Safari olham.

O Google documentou a resposta dele pra isso em julho de 2024 e colocou em beta com a Cloudflare em outubro. Chamava-se First-Party Mode, virou Google tag gateway for advertisers em maio de 2025, e chegou em disponibilidade geral no Google Cloud em 1º de junho de 2026. É melhor do que o que existia antes. E também não resolve o que você acha que resolve.

Vamos abrir isso.

Por que só migrar pro server-side GTM não segura bloqueador

Rastreamento server-side impede bloqueador de anúncio? Não. Sozinho, não. Bloqueador não audita a arquitetura do seu servidor. Ele olha a requisição que o navegador está prestes a fazer: o hostname, o caminho, os parâmetros de query e, em alguns navegadores, para onde aquele hostname aponta de verdade.

O server-side muda quem processa o evento depois que ele chega. Não muda nada na requisição que precisa sair do navegador antes disso. Se essa requisição for reconhecível, ela morre ali, e o seu servidor nunca fica sabendo que o evento existiu.

Ou seja: a pergunta nunca foi "meu tagueamento é server-side?". A pergunta é: quando o navegador olha pra essa requisição, ele vê o seu site, ou vê um rastreador vestindo a camisa do seu site?

Na maioria das implementações de sGTM, ele vê a segunda coisa. Explico.

O que é CNAME cloaking, e por que parou de funcionar

A implementação padrão de sGTM é assim. Você cria track.sualoja.com.br. Aponta esse subdomínio, via um registro CNAME de DNS, para a infraestrutura da ferramenta. Pronto: o navegador pede uma URL do seu próprio domínio, e um terceiro atende em silêncio.

Isso é CNAME cloaking. Funcionou por um tempo porque a resolução de DNS acontece abaixo da camada web. A barra de endereço, os cabeçalhos, a origem, tudo continua dizendo sualoja.com.br até o fim. O navegador ouve um nome e outra pessoa atende o telefone.

CNAME cloaking ainda funciona em 2026? Na maior parte dos casos, não. Deixou de ser técnica confiável lá por 2020, e o cerco só apertou desde então.

E vale saber que isso foi estudado direito antes de qualquer navegador agir. Pesquisadores do Sokendai, no Japão, junto com a agência nacional de cibersegurança da França (ANSSI), varreram os 300 mil sites do topo do Alexa em janeiro de 2020 e acharam 1.762 sites mascarando 56 provedores de rastreamento diferentes, prática que eles rastrearam até pelo menos 2016. É esse trabalho que o WebKit cita no próprio anúncio. Não foi achismo. Foi medido, publicado, e depois viraram engenharia contra.

Como o Safari e os bloqueadores detectam isso de fato

São dois mecanismos diferentes, e eles pegam a coisa de dois jeitos diferentes.

Safari: a divergência de CNAME e de IP

A regra do WebKit é pública, e é mais estreita do que a maioria imagina:

"CNAME cloaking de terceiro é definido como um sub-recurso first-party que resolve através de um CNAME diferente do domínio first-party e diferente do CNAME do host do frame principal, se houver algum."

Quando isso dispara, o Safari corta a validade de qualquer cookie definido naquela resposta HTTP para 7 dias. Ele não bloqueia a requisição. Ele só encurta a vida do seu identificador em silêncio, o que é pior, porque nada parece quebrado. Isso saiu no Safari 14, no iOS e iPadOS 14, e no macOS a partir do Big Sur.

O detalhe importa, então aqui está a própria tabela de cenários do WebKit. Setup legítimo de CDN é explicitamente isento. Só dispara o corte quando o salto vai para um domínio registrável diferente do seu site e do CDN do seu site.

No Safari 17, o WebKit estendeu a mesma lógica para endereços IP, e isso roda na navegação normal, não só na anônima. Essa é a parte que pega setup honesto no contrapé. O host do seu site e o host do seu tracking contam como partes diferentes se um for IPv4 e o outro IPv6, se os IPv4 compartilharem menos de 16 bits de máscara, ou se os IPv6 compartilharem menos de 64. Sem CNAME nenhum. Basta o subdomínio morar longe do site.

E por que 7 dias dói mais do que parece:

Os seus _fbp e _fbc são gravados por JavaScript, então já viviam num relógio de 7 dias. O objetivo inteiro de migrar pra um cookie gravado pelo servidor era escapar disso. Se o servidor que grava está atrás de um CNAME ou de um IP distante, você não escapou de nada. Você reconstruiu a mesma janela de 7 dias, agora com muito mais infraestrutura embaixo.

Bloqueadores: revelação por DNS, e agora por IP

O que é CNAME uncloaking? É o bloqueador resolver o hostname por conta própria antes de decidir.

O uBlock Origin lançou isso na versão 1.24.1b0, no fim de 2019, usando a API browser.dns.resolve do Firefox. Ele consulta pra onde o seu subdomínio de tracking realmente aponta e roda a requisição de novo pelo motor de filtros usando o hostname real. O seu subdomínio não compra nada, porque o bloqueador parou de ler o nome que você deu. O Brave lançou o equivalente nativamente nos shields no fim de 2020. Mais recentemente, o uBlock passou a casar também pelo IP resolvido, então nem trocar de hostname resolve.

Extensão no Chrome não consegue fazer isso: o Chrome não oferece API de DNS para extensões, e com o Manifest V3 o uBlock Origin completo nem roda mais lá; a versão Lite também não tem acesso a DNS. Ou seja, a cobertura é desigual, e é exatamente por isso que dá pra viver com o problema até o dia em que não dá. O mesmo estudo de 2020 mediu o uBlock Origin pegando rastreamento com CNAME em cerca de 70% dos sites onde estava presente, e o Brave em torno de 50% só com listas de bloqueio, antes de ele ter a revelação nativa.

E aqui é onde o Brasil é diferente

Vale ser honesto com o número. O Safari é cerca de 6,9% dos navegadores no Brasil no geral, e 11,5% no mobile (StatCounter, meados de 2026). Não é os Estados Unidos, onde o iOS domina.

Isso significa que o ITP importa menos aqui? Menos do que lá fora, sim. Irrelevante, não, por três motivos práticos. Primeiro: quem usa iPhone no Brasil concentra ticket médio mais alto, então esse pedaço pesa mais na receita do que na contagem de sessões. Segundo: historicamente, o que o WebKit lança acaba adotado de alguma forma pelos outros motores — bloqueio total de cookie de terceiro, particionamento de armazenamento, corte de referrer, tudo começou lá. Um setup que só funciona porque o Chrome ainda é leniente é dívida técnica com prazo de validade. Terceiro, e mais imediato: o problema do bloqueador e o problema do destino do dado não dependem de Safari nenhum. Esses valem pra 100% do seu tráfego.

O Google tag gateway muda alguma coisa?

Muda, numa camada. E vale ser preciso aqui, porque chamar o Tag Gateway de CNAME cloaking com logo novo também está errado.

Na implantação pelo CDN ou balanceador, ele encaminha um caminho do domínio atual, como /metrics, para servir e medir tags do Google. A requisição pode sair como https://www.sualoja.com.br/metrics/…: mesmo host, mesma origem e sem um salto de CNAME de terceiro naquela rota. Isso elimina a superfície específica de cloaking por CNAME. A documentação do Google também permite servir scripts pelo servidor de tagueamento, em caminho no mesmo domínio ou em subdomínio personalizado. Por isso, avalie a URL e a resolução reais do seu setup — não apenas o nome da solução.

O caminho no mesmo host é uma melhora técnica real sobre um subdomínio que mascara um terceiro. Mas não é uma garantia de duração de cookie nem de entrega de evento. O próprio comportamento do ITP depende da topologia e das heurísticas do navegador; valide a validade que o Safari aplicou, em vez de inferi-la pela arquitetura no diagrama.

Bloqueador não decide só pelo DNS. Um caminho de mesma origem remove a técnica de CNAME cloaking, mas não torna uma requisição impossível de filtrar. Regras podem usar hostname, caminho, parâmetros ou padrões conhecidos do protocolo. Teste a implementação que está em produção nos navegadores e bloqueadores relevantes para o seu público; não trate o gateway como uma forma de burlar preferências de privacidade.

O gateway muda a entrega das tags do Google; não vira um roteador completo de dados. Para uma configuração mais durável, a documentação do Google recomenda combinar o gateway com server-side tagging. É nessa segunda camada que você centraliza o processamento e define os destinos. Portanto, o gateway não responde sozinho onde o endpoint de coleta está hospedado, quem pode acessar o dado ou como outros destinos receberão o evento.

A operação continua sendo decisão de infraestrutura. CDN, balanceador ou servidor de tagueamento têm responsabilidades, custo e limites diferentes. Antes de migrar, defina quem opera a rota, quais cookies podem atravessá-la e como o comportamento será monitorado depois da mudança.

Números de “sinal observado” divulgados por fornecedores não são conversão nem receita. Meça antes e depois contra uma fonte independente, como pedidos aprovados ou oportunidades no CRM, e separe ganho de carregamento de ganho de atribuição.

Quanto vale, de verdade, o tráfego que o bloqueador come

É aqui que quase todo mundo que escreve sobre isso fica pouco confiável. Então vamos com cuidado.

Cerca de 29,5% dos usuários de internet no mundo usam bloqueador de anúncio pelo menos de vez em quando, algo como 1,77 bilhão de pessoas (GWI, 2º trimestre de 2025, via DataReportal, medindo de 16 a 64 anos). Repara no "de vez em quando": não são 29,5% das sessões. A jogada de sempre é multiplicar o número da manchete pelo seu faturamento e chamar de prejuízo. Está errado, e errado de um jeito que importa.

Bloqueador não impede compra. A pessoa bloqueada entra, navega e finaliza igual. Sua receita está inteira. O seu painel da Kiwify sabe de cada um desses pedidos. O que você perdeu não foi a venda. Foi o registro dela chegando na plataforma de anúncio.

Então a pergunta certa é: quanto vale um registro de conversão que não chegou?

Não vale o valor do pedido. Um sinal de conversão vale o que o otimizador da plataforma consegue fazer com ele, e esse valor é tudo menos linear. A orientação pública da Meta costuma usar cerca de 50 eventos de otimização em até 7 dias como referência para a fase de aprendizado. Essa não é uma promessa de performance nem uma regra estática: objetivos, edições e o próprio produto mudam. Mas ela ilustra por que volume semanal e cobertura de sinal precisam ser vistos juntos.

Perder sinal não implica uma perda proporcional de resultado. Pode fazer um conjunto ficar mais distante do volume de referência, mas não prova, por si só, a causa de custo ou entrega. Compare cobertura, estrutura da campanha e receita antes de atribuir o problema ao tracking.

O que leva a uma conclusão bem contraintuitiva:

Faz a conta. Quatro conjuntos, 25% de perda de sinal no navegador:

• 400 vendas/mês → 23 eventos por conjunto por semana, 17 depois da perda. Continua abaixo da referência nos dois cenários.
• 1.200 vendas/mês → 69 por conjunto por semana, caindo para 52. Com 30% de perda, chega a 48; é o tipo de conta em que a cobertura pode mudar a proximidade com a referência.
• 2.000 vendas/mês → 115 caindo para 86. A perda não a leva abaixo dessa referência, embora dado melhor ainda possa ajudar a qualidade do lance.

Com 25% de perda no exemplo, a faixa em que essa perda pode levar um conjunto de quatro abaixo da referência fica entre cerca de 870 e 1.160 conversões mensais. Com 40%, o teto chega a aproximadamente 1.450. Isso é aritmética de cenário, não diagnóstico de uma conta: volume, objetivo de otimização, segmentação, criativo e orçamento continuam importando. Meça a cobertura atual antes de gastar com infraestrutura.

O que sobra em pé: mesmo host, mesmo IP

Tirando o marketing, a configuração que sobrevive é sem graça:

O endpoint que recebe os eventos roda no mesmo host do site, ou numa infraestrutura que resolve pra mesma faixa de endereço. Sem CNAME saindo do seu domínio. Sem IP que o Safari leia como parte diferente. O cookie de identidade é gravado pelo servidor, com Set-Cookie, e não por JavaScript. Aí o Safari respeita a validade declarada, e a sua janela de atribuição passa a ser medida em meses, não em dias-desde-a-última-visita.

O WebKit publica o que pretende e o que não pretende atrapalhar, e "analytics no escopo de um único site" está na lista do que ele não quer quebrar. Coleta first-party no mesmo host mora nessa categoria.

Só não estique isso mais do que dá, e prefiro falar agora a te deixar descobrir depois. O WebKit define rastreamento entre sites incluindo "a retenção, o uso ou o compartilhamento de dados dessa atividade com partes que não sejam o first-party em que foi coletado". No instante em que você encaminha uma conversão pra Meta CAPI ou pro Google Ads, você está compartilhando além do first-party. Cookie gravado pelo servidor no mesmo host sobrevive às heurísticas de hoje por causa de como essas heurísticas são construídas, e não porque alguém deu bênção. Isso é uma afirmação sobre mecânica. Trate como tal, e colete consentimento pro encaminhamento, que é a parte que realmente precisa.

Agora a ressalva honesta, que vale pra gente também. Se o seu site está numa hospedagem gerenciada e o seu Node de tracking está numa VPS na faixa de outro provedor, a heurística de IP do Safari pode classificar os dois como partes diferentes e cortar o seu cookie pra 7 dias. Mesmo domínio não é automaticamente mesma parte. Quem decide é a topologia de resolução. Qualquer fornecedor que te disser que subdomínio no seu domínio é seguro por natureza não leu a extensão de IP, ou está torcendo pra você não ter lido.

Quando não dá pra alinhar os hosts, o projeto tem que assumir um token de 7 dias no Safari e carregar a identidade no servidor, em vez de fingir que o cookie vai sobreviver.

Como conferir o seu próprio setup

Dez minutos, sem ferramenta que você já não tenha.

1. Ache o salto de DNS.

dig +short track.sualoja.com.br

Se voltar um CNAME pro domínio registrável de outra pessoa, o Safari está cortando esses cookies e o Firefox com uBlock está resolvendo por cima do seu subdomínio. Se for o seu próprio CDN e o site estiver no mesmo CDN, você caiu numa linha isenta daquela tabela.

2. Compare os IPs.

dig +short A www.sualoja.com.br
dig +short A track.sualoja.com.br
dig +short AAAA www.sualoja.com.br
dig +short AAAA track.sualoja.com.br

Famílias de endereço diferentes, ou IPv4 compartilhando menos de 16 bits iniciais, significa que o Safari pode tratar os dois como partes diferentes mesmo sem CNAME nenhum na jogada.

3. Veja quem grava o seu cookie. DevTools → Application → Cookies. Acha o seu cookie de identidade. Se ele apareceu sem um cabeçalho de resposta Set-Cookie, quem escreveu foi JavaScript, e ele está num relógio de 7 dias independente da validade que você pediu.

4. Leia a validade real no Safari. Não no Chrome. O Chrome vai te mostrar alegremente a validade que você pediu. Abra o site no Safari, faça uma interação de verdade, e inspecione a validade do cookie. Se você pediu 365 dias e vê 7, agora você sabe exatamente em que linha daquela tabela está.

5. Teste com um bloqueador que revela CNAME. Firefox com uBlock Origin, ou Brave com os shields ligados. Carrega uma página, olha a aba de rede, vê se a sua requisição de tracking sobrevive. Se não sobreviver, é assim que uma fatia relevante do seu tráfego enxerga o seu site hoje.

Faça esses cinco e você vai saber mais sobre o seu setup do que a maioria de quem instalou ele.

Nada disso se resolve com mais pixel. É uma questão de onde o seu endpoint de tracking mora de fato e de quem fica com o dado no fim, o que é decisão de infraestrutura, não de tagueamento.

E tem um efeito colateral que o jurídico entende antes do gestor: quando o processamento acontece no servidor que é seu, a LGPD deixa de ser um problema de contrato com terceiro e vira uma característica da arquitetura. Não é um argumento de campanha. É o mesmo argumento, lido por outra pessoa.

É exatamente por isso que o Supreme Tracking existe: o Node roda no seu servidor, no seu host, sob o seu domínio, gravando o próprio cookie pelo servidor. Os seus eventos são processados por uma infraestrutura que você controla, e encaminhados dali pra Meta, Google, GA4, seu CRM, o que você precisar. A gente valida a sua licença. A gente nunca encosta no seu dado de conversão.

Mas, antes de tudo isso, roda os cinco testes aí em cima. Se o seu DNS voltar limpo e os seus cookies no Safari mantiverem a validade declarada, você não tem esse problema, e ninguém deveria te vender solução pra ele.

Fontes

• CNAME Cloaking and Bounce Tracking Defense — WebKit
• Tracking Prevention in WebKit
• Private Browsing 2.0 — WebKit (cloaking por IP de terceiro)
• Characterizing CNAME Cloaking-Based Tracking on the Web — Dao, Mazel e Fukuda, TMA 2020
• CNAME Cloaking-Based Tracking on the Web: Characterization, Detection, and Protection — IEEE TNSM 2021
• uBlock Origin: CNAME uncloaking — documentação do projeto
• uBlock Origin: filtragem por endereço IP — documentação do projeto
• Google tag gateway for advertisers — visão geral do Google
• Servir scripts do Google em contexto first-party — documentação do Google
• Ad Blocker Usage and Demographic Statistics — Backlinko (GWI / DataReportal)
• Browser Market Share Brazil — StatCounter