Você Está Perdendo Entre 20% e 40% dos Seus Dados: Agora Mesmo
Não é projeção. Não é cenário pessimista.
É o que os estudos de implementação de server-side tracking mostram consistentemente: empresas que operam com rastreamento client-side tradicional perdem, em média, entre 20% e 40% dos eventos que deveriam ser capturados.
Para uma empresa com R$ 60 mil/mês em mídia paga, isso significa que as decisões de otimização de campanha estão sendo tomadas com base em, no máximo, 80% da realidade. O algoritmo do Google Ads está otimizando para conversões que ele não consegue ver. O GA4 está reportando um funil incompleto.
E o responsável por essa perda tem um nome: rastreamento client-side.
Este artigo explica o que é server-side tracking, por que ele deixou de ser uma vantagem técnica e passou a ser um requisito operacional para quem investe seriamente em mídia paga — e como implementá-lo via Google Tag Manager Server Container.
Client-Side vs. Server-Side: A Diferença que Importa
Como Funciona o Rastreamento Client-Side (o Padrão Atual)
No modelo tradicional, o rastreamento acontece no navegador do usuário:
- O usuário acessa seu site
- O navegador carrega o GTM (via tag JavaScript)
- O GTM dispara as tags: GA4, Google Ads, Meta Pixel, etc.
- Cada tag envia dados diretamente do navegador para os servidores da plataforma
O problema está na etapa 3 e 4. Entre o navegador do usuário e os servidores do Google ou Meta, existem várias camadas que podem bloquear, distorcer ou impedir o envio desses dados:
- Ad blockers (uBlock, AdBlock Plus, Brave Shield): bloqueiam scripts de rastreamento por padrão
- ITP (Intelligent Tracking Prevention) do Safari: limita a duração dos cookies de terceiros a 7 dias
- Extensões de privacidade: interceptam e bloqueiam chamadas para domínios de rastreamento conhecidos
- Falhas de carregamento: se o script do GTM não carrega completamente, nenhuma tag dispara
No mercado B2B de tecnologia — onde grande parte do público usa navegadores com proteções de privacidade ativadas — essa perda é estruturalmente maior que a média.
Como Funciona o Server-Side Tracking
No modelo server-side, o intermediário não é mais o navegador do usuário. É um servidor sob o seu controle:
- O usuário acessa seu site
- O navegador envia os dados de evento para o seu próprio servidor (não para Google ou Meta diretamente)
- O seu servidor — configurado via GTM Server Container — processa esses dados
- O servidor repassa os eventos para GA4, Google Ads, Meta API, e qualquer outra plataforma
A diferença crítica: o bloqueador de anúncios do usuário não sabe que o seu servidor existe. Ele só bloqueia chamadas para domínios conhecidos de rastreamento (como google-analytics.com). Quando a chamada vai para dados.seusite.com.br, ela não é reconhecida como rastreamento — e passa.
Os Três Problemas que o Server-Side Resolve
Problema 1: Ad Blockers e Perda de Eventos
Estudos de implementação em mercados com alta adoção de ad blockers mostram recuperação de 15% a 35% nos eventos de conversão após migração para server-side.
No B2B de tecnologia, a taxa de uso de ad blockers entre o público decisor (desenvolvedores, gestores técnicos, CTOs) é consistentemente mais alta que a média geral — exatamente o público que você está tentando rastrear.
Problema 2: Cookies de Terceiros e a Morte do ITP
O Safari, que representa parcela relevante do tráfego em dispositivos corporativos e mobile, limita cookies de terceiros a 7 dias via ITP. Para um ciclo de venda B2B de 90 dias, isso significa que qualquer usuário que retornar ao site depois de 7 dias será tratado como um novo visitante — quebrando a jornada de atribuição completamente.
Com server-side tracking, os cookies são configurados como first-party (originados do seu próprio domínio), o que não está sujeito às restrições do ITP. A janela de identificação do usuário passa de 7 dias para até 400 dias, dependendo da configuração.
Problema 3: Qualidade e Controle dos Dados Enviados
No modelo client-side, os dados são enviados na íntegra para as plataformas de publicidade — incluindo dados sensíveis que não deveriam sair do seu ambiente. No server-side, você tem controle total sobre o que é enviado para cada destino.
Isso é relevante tanto do ponto de vista de privacidade (LGPD) quanto de qualidade de dados: você pode limpar, enriquecer e validar os eventos antes de enviá-los, garantindo que o GA4 e o Google Ads recebam apenas dados precisos.
Quando o Server-Side Tracking É Obrigatório
Não é toda empresa que precisa implementar agora. Mas há situações em que postergar tem custo direto e mensurável:
Implemente imediatamente se:
- Você investe mais de R$ 30 mil/mês em mídia paga e usa conversões para otimização de lances
- Seu público-alvo tem perfil técnico (desenvolvedores, gestores de TI) com alta propensão a usar ad blockers
- Você opera com ciclo de venda acima de 30 dias e depende de atribuição precisa para decisões de orçamento
- Você usa o Meta Ads (Facebook/Instagram) em paralelo com Google — a Conversions API do Meta só funciona de forma robusta via server-side
- Você está sujeito à LGPD e precisa de controle sobre quais dados saem do seu ambiente para terceiros
Pode aguardar se:
- Investimento em mídia abaixo de R$ 15 mil/mês (o custo de implementação ainda não se paga rapidamente)
- Ciclo de venda curto com conversão majoritariamente na primeira sessão
- Público com baixa adoção de ad blockers
Como Implementar: GTM Server Container Passo a Passo
Pré-Requisitos
Antes de iniciar, confirme que você tem:
- Acesso de administrador ao GTM (conta web já configurada)
- Acesso ao provedor de cloud para hospedar o servidor (Google Cloud Platform é o mais comum)
- Subdomínio disponível para o servidor (ex:
collect.seusite.com.br) - Acesso ao DNS do domínio para apontar o subdomínio
Passo 1 — Criar um Container Server no GTM
No Google Tag Manager:
- Acesse sua conta GTM
- Clique em Criar container
- Em “Plataforma de segmentação”, selecione Servidor
- Nomeie o container (ex: “99Online – Server”)
O GTM vai gerar um URL de configuração do servidor — guarde esse valor, você vai precisar na próxima etapa.
Passo 2 — Provisionar o Servidor no Google Cloud
O GTM Server Container precisa rodar em uma instância de cloud. O Google Cloud Platform (GCP) é a opção recomendada por ter integração nativa:
No GTM, após criar o container server, acesse Administrador → Configurações do container server e clique em Provisionar automaticamente no Google Cloud.
O processo cria automaticamente:
- Um projeto no GCP
- Uma instância do Cloud Run (serverless — você paga apenas pelo uso)
- A URL padrão do servidor (formato:
https://[hash].a.run.app)
Custo estimado de infraestrutura: para volumes típicos de B2B (até 500 mil eventos/mês), o custo no GCP fica entre R$ 80 e R$ 300/mês dependendo do tráfego.
Passo 3 — Configurar o Subdomínio Personalizado
A URL padrão do GCP não é ideal — ela é facilmente identificável como um servidor de rastreamento. Configure um subdomínio próprio:
No seu provedor de DNS, crie um registro CNAME:
collect.seusite.com.br → [sua-url-cloudrun].a.run.app
No GTM Server Container, acesse Administrador → Configurações do container e adicione o domínio personalizado. O GTM vai verificar e provisionar o certificado SSL automaticamente.
A partir desse momento, todos os eventos serão enviados para collect.seusite.com.br — um domínio que pertence a você e que não é reconhecido por ad blockers.
Passo 4 — Configurar o Cliente GA4 no Server Container
No container server do GTM, você precisa configurar um Cliente — o componente que recebe e interpreta os eventos vindos do site.
- Acesse Clientes → Novo
- Selecione o template GA4
- Configure o caminho de requisição (padrão:
/g/collect)
Esse cliente vai capturar todos os eventos enviados pelo GA4 do seu site e torná-los disponíveis para processamento no servidor.
Passo 5 — Modificar a Tag GA4 no Container Web
No seu container GTM web (o que já existe no site), localize a tag de configuração do GA4 e adicione o campo:
| Nome do campo | Valor |
|---|---|
server_container_url | https://collect.seusite.com.br |
Isso redireciona todos os eventos do GA4 para o seu servidor antes de serem enviados ao Google Analytics.
Passo 6 — Criar a Tag GA4 no Server Container
No container server, crie uma nova tag:
- Tipo: Google Analytics: GA4
- ID de medição: seu Measurement ID (G-XXXXXXXX)
- Gatilho: All Pages (ou o cliente GA4 configurado no Passo 4)
Essa tag é responsável por reenviar os eventos — agora processados pelo seu servidor — para o GA4. O fluxo completo fica:
Navegador do usuário
↓
collect.seusite.com.br (seu servidor GTM)
↓
GA4 / Google Ads / Meta API
Passo 7 — Configurar os Cookies First-Party
Para garantir que a identificação do usuário persista além das restrições do Safari ITP, configure os cookies via server-side:
No container server, acesse as configurações do cliente GA4 e habilite a opção de cookies first-party. O servidor vai setar o cookie _ga como first-party no domínio seusite.com.br, com validade de até 400 dias.
Isso resolve o problema de fragmentação de jornada causado pelo ITP sem nenhuma alteração visível para o usuário.
Validação: Como Confirmar que Está Funcionando
Após a implementação, valide em três camadas:
1. Preview do GTM Server No container server, ative o modo Preview e navegue pelo site. Os eventos devem aparecer no painel de debug do servidor antes de serem repassados ao GA4.
2. DebugView do GA4 Acesse GA4 → Administrador → DebugView e confirme que os eventos estão chegando com os parâmetros corretos — especialmente session_id e client_id, que indicam se a identificação do usuário está funcionando.
3. Network Tab do Navegador Abra as ferramentas de desenvolvedor do Chrome (F12 → Network) e filtre por collect. As requisições devem aparecer indo para collect.seusite.com.br, não para google-analytics.com. Ative o uBlock Origin e repita o teste — as requisições devem continuar passando.
O que Fazer Depois da Implementação
Com o server-side funcionando, você tem a base técnica para:
- Integrar a Meta Conversions API (CAPI) — enviando eventos de conversão diretamente para o Meta sem depender do Pixel client-side, que sofre bloqueio massivo em iOS 14+
- Implementar o Measurement Protocol do GA4 — para importar eventos offline (fechamentos de contrato do CRM) com os mesmos parâmetros de sessão coletados pelo server-side
- Enriquecer eventos com dados do CRM — ao processar no servidor, você pode adicionar campos como
deal_stage,mrr,customer_segmentantes de enviar ao GA4, criando dimensões personalizadas que não existem nativamente
O Custo de Não Implementar
Vamos ser diretos sobre o cálculo:
Uma empresa com R$ 80 mil/mês em mídia paga e 25% de perda de dados por rastreamento client-side está, na prática, otimizando campanhas com base em 60 mil reais de informação — e deixando 20 mil reais de investimento completamente invisível para o algoritmo.
O custo de implementação do server-side — infraestrutura mais trabalho técnico — geralmente se paga no primeiro mês, apenas pela melhora na qualidade dos dados que alimentam a otimização automática de lances do Google Ads.
Não é uma questão técnica. É uma questão financeira.
Conclusão: Rastreamento Server-Side Não É Mais Diferencial
Era, em 2021. Hoje, para qualquer empresa que compete a sério por clientes de alto ticket com investimento relevante em mídia paga, é infraestrutura básica.
A diferença entre quem implementou e quem não implementou é simples: um está otimizando com dados reais, o outro está otimizando com uma fotografia com 30% das partes apagadas.
Se você chegou até aqui, já sabe o que precisa fazer. A questão é se vai fazer internamente — com as complexidades de infraestrutura de cloud, configuração de DNS e validação de dados — ou com uma equipe que já fez isso dezenas de vezes.
A 99 Online implementa Server-Side Tracking completo — do provisionamento no GCP à integração com GA4, Google Ads e Meta CAPI — para empresas que não podem se dar ao luxo de tomar decisões com dados incompletos.
→ Fale com um especialista e avalie se o seu rastreamento atual está custando performance
Publicado por 99 Online | Inteligência de Dados para Empresas B2B de Alto Ticket
