A conta que os anunciantes não querem fazer é simples: parte significativa dos seus eventos de conversão nunca chega às plataformas de mídia. Ad blockers bloqueiam o pixel antes de ele carregar. O ITP do Safari limpa cookies primários em dias. O banner de consentimento faz com que boa parte dos usuários simplesmente não aceite ser rastreada. O resultado é uma lacuna crescente entre o que realmente acontece no seu funil e o que o Google Ads ou o Meta Ads reporta como conversões.
Resumo rápido: O rastreamento client-side (pixel no navegador) perde dados por ad blockers, restrições de privacidade do navegador e recusa de consentimento. O server-side tracking envia os eventos do seu servidor diretamente às plataformas de mídia, contornando essas barreiras e recuperando a atribuição — com mais controle sobre o que é compartilhado e melhor alinhamento com a LGPD.
![]()
Por que o pixel client-side perdeu eficiência
O pixel client-side é um trecho de JavaScript que roda no navegador do visitante e envia um evento para a plataforma de anúncios quando uma ação acontece — uma compra, um cadastro, um clique em botão. Durante anos, foi o método padrão porque era simples de implementar e funcionava bem o suficiente.
O problema é que o pixel depende de três condições que estão cada vez menos garantidas: o JavaScript precisa ser executado (ad blockers impedem isso), o cookie precisa existir e ser lido (navegadores com foco em privacidade impõem restrições crescentes a isso) e o usuário precisa ter consentido com o rastreamento (a LGPD e os banners de cookies reduzem essa taxa).
O efeito prático é subreporte de conversões: as campanhas parecem menos eficientes do que são, os lances automáticos das plataformas se calibram com dados incompletos, e as decisões de investimento são tomadas sobre um retrato parcial da realidade.
O que são cookies de terceiros e por que importam para anunciantes
Cookies de terceiros são arquivos criados pelo domínio da plataforma de anúncios (não pelo seu site) no navegador do visitante. Historicamente, eram o mecanismo que permitia ao Meta saber que o mesmo usuário que clicou num anúncio voltou para o seu site e comprou — mesmo dias depois.
À medida que os navegadores foram restringindo ou bloqueando cookies de terceiros por padrão, o rastreamento baseado neles foi perdendo precisão. O Chrome, responsável por grande parte do tráfego web mundial, tem processado mudanças graduais na forma como trata esses cookies — o que afeta a atribuição de conversões em todas as plataformas que dependem desse mecanismo.
É importante ser qualitativo aqui: o cenário está em evolução contínua, com prazos que mudaram diversas vezes. O que é certo é que a direção é de restrição progressiva — independente de quando cada fase entra em vigor, construir uma estratégia de rastreamento que dependa inteiramente de cookies de terceiros é construir sobre base instável.
Como o server-side tracking funciona
No modelo server-side, o evento de conversão é capturado pelo seu servidor antes de ser enviado à plataforma de anúncios. O fluxo muda assim:
No modelo tradicional (client-side):
Navegador do usuário → pixel JavaScript → plataforma de mídia
No modelo server-side:
Navegador do usuário → seu servidor → plataforma de mídia
O ponto crítico é que a segunda etapa do fluxo acontece servidor a servidor, sem passar pelo navegador. Ad blockers não podem bloquear uma requisição que parte do seu servidor. Restrições de cookies de navegador não se aplicam a uma chamada de API entre servidores.
As plataformas de mídia oferecem APIs específicas para receber esses eventos: a Conversions API (Meta), a Enhanced Conversions e Google Ads API (Google) e o Events API (TikTok) são as implementações mais usadas. Cada uma aceita eventos de conversão com dados de correspondência — hash de email, hash de telefone, IP — que permitem atribuir a conversão ao usuário correto sem cookies.
GTM Server-Side: o orquestrador da stack
O Google Tag Manager Server-Side é uma instância do GTM que roda num servidor seu (ou num container gerenciado), recebe os eventos do navegador via um cliente GTM padrão e os redistribui para as plataformas de mídia via tags server-side.
A vantagem do GTM Server-Side é centralizar a configuração: em vez de manter código separado para Meta CAPI, Google Enhanced Conversions e TikTok Events API, você configura tudo num único container. Mudanças de implementação ficam no GTM, não espalhadas pelo código do site.
Outro benefício relevante: com o GTM Server-Side você decide exatamente quais dados são enviados para cada plataforma. Isso significa controle fino sobre conformidade com a LGPD — você pode enviar o hash do email para atribuição sem enviar dados que não deveria. É essa configuração granular que o departamento de Marketing da MaxVision implementa na stack de tracking dos clientes.
Se você ainda não tem clareza sobre o que é tráfego pago e como a atribuição funciona na prática, o artigo o que é tráfego pago cobre os fundamentos antes de entrar na camada técnica.
Client-Side vs Server-Side: comparação direta
| Dimensão | Client-Side (Pixel) | Server-Side Tracking |
|---|---|---|
| Bloqueio por ad blocker | Alta probabilidade de bloqueio | Nao afetado |
| Restricoes de cookies | Impactado por ITP, ETP, etc. | Nao depende de cookies de terceiros |
| Consentimento | Requer consentimento para disparar | Pode disparar com dados anonimizados |
| Qualidade dos dados | Perda proporcional ao bloqueio | Cobertura mais completa |
| Complexidade de implementacao | Baixa (snippet no site) | Alta (servidor, GTM SS, APIs) |
| Custo de infraestrutura | Nenhum adicional | Servidor para o container GTM SS |
| Controle de dados (LGPD) | Limitado (a plataforma decide) | Alto (voce filtra o que envia) |
| Latencia do evento | Instantanea (browser) | Adiciona milissegundos do servidor |
| Debug | Chrome DevTools, GTM Preview | Logs de servidor, GTM SS Preview |
O que muda na atribuição
Server-side tracking não é apenas uma forma diferente de implementar o mesmo rastreamento — ele muda a qualidade dos dados de atribuição disponíveis.
Com dados mais completos chegando às plataformas, os algoritmos de lance automático (tROAS, tCPA, Advantage+) se calibram com informação mais próxima da realidade. Uma campanha que parecia ter CPA alto pode revelar desempenho melhor quando as conversões que estavam sendo perdidas passam a ser contabilizadas.
Outro efeito é na janela de atribuição. Sem cookies de terceiros, atribuir uma compra feita três dias após o clique depende da correspondência por hash de email ou telefone. O server-side, ao enviar esses dados de correspondência diretamente para a Conversions API, recupera parte dessas conversões que antes seriam perdidas na janela de atribuição.
O artigo sobre Google Ads com automação e IA explora como os algoritmos de lance usam esses dados de conversão para otimizar em tempo real — o que reforça por que a qualidade do sinal de entrada importa tanto.
Privacidade e LGPD: o que muda com server-side
Há uma confusão comum: server-side tracking não elimina a necessidade de consentimento. Ele muda onde o controle é exercido.
No modelo client-side, o pixel da plataforma de anúncios tem acesso direto ao comportamento do usuário no seu site. No modelo server-side, você faz a mediação: decide quais dados captura, quais anonimiza e quais envia para cada plataforma.
Isso é relevante para conformidade com a LGPD por alguns motivos:
- Você pode hash-ear dados pessoais (email, telefone) antes de enviá-los, de forma que a plataforma receba apenas o hash para correspondência, não o dado em si.
- Você pode implementar lógica de consentimento no servidor: se o usuário não consentiu, o evento não é encaminhado.
- Você tem log dos eventos enviados, o que facilita responder a solicitações de titulares de dados.
A LGPD exige base legal para tratamento de dados pessoais. Server-side tracking não cria base legal onde não há — mas oferece ferramentas técnicas para implementar o que a base legal determina com mais precisão.
![]()
Qual é o custo e a complexidade reais da implementação
Server-side tracking tem custo de infraestrutura e de implementação que o pixel client-side não tem. É importante ser transparente sobre isso.
Do lado de infraestrutura: o container GTM Server-Side precisa rodar em algum lugar. Pode ser no Google Cloud Run (modelo pay-per-use), num servidor dedicado ou num container Docker na sua infra existente. O custo varia conforme o volume de eventos.
Do lado de implementação: configurar GTM Server-Side com clientes corretos, implementar as tags para cada plataforma (Meta CAPI, Google Enhanced Conversions), mapear os parâmetros de correspondência e testar a precisão dos eventos leva tempo de especialista técnico. Não é o mesmo que colar um snippet de pixel.
O retorno, quando o volume de mídia justifica, é concreto: atribuição mais completa que melhora a tomada de decisão sobre orçamento e ajuda os algoritmos de lance a trabalhar com dados mais reais.
Perguntas Frequentes
Server-side tracking substitui completamente o pixel client-side?
Na maioria das implementações, os dois coexistem. O pixel client-side captura dados de comportamento de navegação que o servidor não tem visibilidade direta (rolagem de página, tempo de permanência, cliques em elementos). O server-side tracking complementa, capturando conversões com mais fidelidade. A deduplicação dos eventos — para não contar a mesma conversão duas vezes — é parte crítica da configuração.
É necessário ter um servidor dedicado para implementar GTM Server-Side?
Não necessariamente. O GTM Server-Side pode rodar em serviços gerenciados como Google Cloud Run, que escala automaticamente e cobra por requisição. Para volumes baixos a médios, o custo é acessível. Para volumes altos, um container num servidor existente costuma ser mais econômico.
Server-side tracking funciona para ecommerce com múltiplos marketplaces?
Funciona para o que acontece no seu próprio site ou app. Eventos que ocorrem dentro de plataformas de marketplace (Mercado Livre, Shopee) ficam fora do seu controle de rastreamento — você depende dos dados que a plataforma disponibiliza. A estratégia server-side é mais valiosa para quem tem e-commerce próprio com volume significativo.
Como garantir que os dados hash-eados para a Conversions API estão corretos?
As plataformas especificam o algoritmo de hash exigido (geralmente SHA-256) e o formato do dado antes do hash (email em minúsculas, telefone no formato E.164). Erros nessa normalização reduzem a taxa de correspondência, o que diminui o benefício da implementação. É um ponto técnico crítico que exige atenção na validação.
O consentimento do usuário ainda é necessário com server-side tracking?
Sim. A LGPD não é contornada pela implementação técnica. O consentimento precisa ser obtido (quando essa é a base legal aplicável) e a implementação técnica precisa respeitar a escolha do usuário — o server-side apenas oferece ferramentas mais precisas para implementar essa lógica no servidor.
Conclusão
O rastreamento client-side ainda funciona — só não funciona tão bem quanto antes, e a tendência é de degradação continuada à medida que navegadores e regulações evoluem. Server-side tracking não é uma solução futurista: é a resposta técnica disponível agora para o problema de perda de dados que já afeta as campanhas.
Para quem investe em mídia paga com volume suficiente para justificar a complexidade de implementação, a recuperação de atribuição que o server-side proporciona tem impacto direto na qualidade das decisões de orçamento e na performance dos algoritmos de lance.
O departamento de Marketing da MaxVision implementa Pixel, Conversions API (Meta), Enhanced Conversions (Google) e GTM Server-Side como parte da stack de operação de mídia — sem terceirizar a configuração técnica e com tudo registrado no nome do cliente. Para avaliar o estado do seu rastreamento atual, entre em contato.