Rastreamento server-side: o que é, quando vale e como implementar

O Google Ads diz 31 leads no mês. O CRM diz 52. A Meta diz 19. Ninguém sabe qual está certo, e a campanha está sendo otimizada em cima do menor. Uma parte desse buraco é estrutural: quase todo rastreamento de site ainda roda dentro do navegador, e o navegador deixou de ser um lugar confiável para medir. Este guia explica o que o rastreamento no servidor recupera, quanto custa manter, o que a LGPD exige e quando ele não vale a pena.

O que é rastreamento server-side

No modelo tradicional (client-side), cada plataforma carrega o próprio script na página: a tag do Google, o pixel da Meta, o insight tag do LinkedIn. Cada script lê cookie, monta o evento e manda direto para o servidor da plataforma. Isso quebra em três lugares:

1. Bloqueador de anúncio e de rastreador. Extensões e navegadores com proteção embutida impedem o script de carregar ou a requisição de sair. O evento não existe.
2. Proteção de rastreamento do Safari (ITP). O WebKit apaga cookies criados por JavaScript depois de 7 dias sem interação com o site, e corta para 24 horas quando a pessoa chega por um link com parâmetro de rastreamento vindo de domínio classificado como rastreador.^[1] Em B2B, onde o lead volta três semanas depois, o cookie da primeira visita já sumiu. A visita de retorno parece gente nova e a origem vira “direto”.
3. Consentimento. Com banner de cookies bem-feito, quem recusa não é rastreado. Isso é correto e não é para ser contornado. Mas sem o Consent Mode configurado, você perde até o sinal agregado que as plataformas usam para modelar essas conversões.

No modelo server-side, o site manda um fluxo de eventos para um servidor que é seu, como o contêiner de servidor do Google Tag Manager. Esse servidor decide o que repassar, para quem e em que formato. Para a Meta, o repasse vai pela API de Conversões (Conversions API, ou CAPI). Para o Google, pelas tags de servidor do GA4 e do Google Ads. O Google descreve o ganho principal como controle: só você tem acesso ao dado no servidor até decidir mandá-lo para algum lugar.^[2]

Duas distinções que confundem gente boa:

• Server-side não é “sem navegador”. Quase sempre sobra um pedaço no navegador, que captura o evento e manda para o seu servidor. A diferença é que é um pedido para o seu domínio, e não cinco pedidos para cinco domínios de terceiros.
• API de Conversões não substitui o pixel. A Meta recomenda usar os dois juntos, mandando os mesmos eventos pelos dois caminhos e deduplicando.^[3] O pixel pega o que o servidor não vê (comportamento na página); o servidor pega o que o pixel perdeu.

E a diferença que mais pesa no bolso: o servidor pode mandar evento que nunca aconteceu no navegador. O lead preencheu o formulário na terça; na sexta o vendedor marcou como qualificado no CRM. Esse “qualificado” nunca passou pelo site. Com servidor, ele volta para a Meta e para o Google, e o algoritmo aprende a buscar lead que vira reunião, não lead que só preenche formulário. É aqui que server-side deixa de ser detalhe técnico e vira CAC menor.

Como medir se o servidor se paga

Não existe fórmula canônica de server-side. Existe uma conta que decide se a implantação se paga: quanto sinal você recupera contra quanto custa manter. A primeira metade é a cobertura de eventos.

Não existe percentual universal de recuperação. Depende do público (mais Safari e iPhone perde mais), do tipo de bloqueio e de quantos visitantes recusam cookie. Fornecedor que promete “+30% de conversões” sem medir o seu site antes está chutando.

A pegadinha da conta: comparar “conversões no GA4 antes” com “conversões no GA4 depois” mede também a duplicação que você criou sem querer. Se o total subiu mais que o número de formulários no CRM, você está contando o mesmo lead duas vezes, não recuperando sinal.

A outra metade é o custo. O Google estima cerca de US$ 45 por servidor por mês no Cloud Run e recomenda no mínimo 2 instâncias em produção, para reduzir o risco de perder dado numa queda.^[4] Some o servidor de preview, que é separado e roda com exatamente 1 instância.^[5] Ou seja: a conta de nuvem começa na casa de algumas dezenas de dólares por mês por servidor e sobe com o volume e o número de tags. A linha que costuma pesar mais é outra: a hora de quem implanta e mantém. Hospedagem gerenciada de sGTM existe e tem tabela de preço própria.

Benchmarks: as regras que definem o jogo

Server-side não tem meta numérica. Os números que importam são as regras dos navegadores e das plataformas, porque são elas que decidem o que você consegue medir. Percentual de perda por bloqueador varia demais por público, e não encontramos fonte primária confiável para o Brasil; por isso ele não entra na tabela.

A leitura que importa: o Safari derruba cookie de JavaScript em 7 dias^[1], e o ciclo de compra B2B costuma ser maior que isso. Quem mede só no navegador perde a origem justamente dos leads que demoram mais para decidir. Em B2B, esses costumam ser os de ticket maior.

Como implementar na prática

Armadilhas comuns

Estes são os erros que mais aparecem quando a gente abre a medição de um site para implantar o servidor. Quase nenhum é de infraestrutura.

Subir servidor antes de saber o que é conversão

O pedido mais comum que recebemos é “quero server-side porque estou perdendo conversão”. Quando abrimos a conta, o problema é outro: o Google Ads conta clique no botão do WhatsApp como lead, o formulário dispara conversão duas vezes, a página de obrigado é aberta por quem nem preencheu nada. Servidor em cima disso só entrega o erro mais rápido. Primeiro a definição, depois o cano.

Pôr o servidor num subdomínio e achar que o Safari vai respeitar

O jeito mais rápido de subir o sGTM é apontar track.seusite.com.br por CNAME para a nuvem. Funciona, mas o WebKit trata CNAME e IP de terceiro como “cloaking” e limita os cookies definidos nessa resposta a 7 dias.^[1] Você paga o servidor e fica com o mesmo teto do JavaScript. Já vi implantação dar certo em tudo e não mudar nada no Safari por causa disso. Para ganhar durabilidade de verdade, o servidor precisa estar no mesmo origin, ou numa infraestrutura que não caia na regra de IP de terceiro.

Vender server-side como jeito de passar por cima do consentimento

Tem fornecedor que apresenta o servidor como forma de “recuperar quem recusou cookie”. É o caminho mais curto para um problema com a LGPD. O guia da ANPD diz que o legítimo interesse dificilmente é a base adequada para cookie de publicidade e que o consentimento tende a ser a hipótese mais apropriada nesse caso.^[15] O servidor tem que ler o consentimento e obedecer. O que ele recupera legitimamente é o que o bloqueio técnico comeu de quem aceitou, mais o sinal modelado de quem recusou, via Consent Mode.

Esquecer a deduplicação e dobrar os leads

Pixel e API de Conversões mandando o mesmo lead sem event_id igual: a Meta conta dois. O relatório melhora de um dia para o outro, o CPL cai pela metade, alguém comemora. Aí o CRM não acompanha. Sempre que a conversão sobe mais do que o número de formulários que chegaram de verdade, a primeira hipótese é duplicação, não recuperação.

Mandar dado pessoal sem hash, ou com hash onde não pode

O erro vai para os dois lados. E-mail e telefone precisam de SHA-256 antes de sair; IP, user agent, fbc e fbp não podem ter hash, senão a correspondência quebra.^[9] Já vi implantação com tudo hasheado “por segurança”, Event Match Quality lá embaixo e o time sem entender por que a campanha não aprendia.

Tratar o servidor como projeto de uma vez só

O servidor fica no ar, alguém muda o formulário do site, o dataLayer para de disparar e ninguém percebe por três semanas. O servidor segue respondendo 200, o painel da nuvem está verde, e os eventos simplesmente param de chegar. É falha silenciosa. Quem implanta precisa deixar um alarme de volume de eventos, não só de saúde do servidor.

Pagar servidor quando o volume não justifica

Site com poucas dezenas de leads por mês e verba de mídia pequena não dá sinal suficiente para o lance automático aprender, com servidor ou sem ele. O ganho é pequeno e o custo fixo, somando nuvem e manutenção, pesa. Nesse cenário a gente começa pelas conversões otimizadas do Google, que já usam o dado do formulário, e pela importação de conversão offline do CRM. Servidor vem depois.

Quando não vale a pena

1. Não há mídia paga otimizada por conversão. Se o site vive de orgânico e indicação, o ganho é basicamente um analytics mais completo. Raramente paga o custo fixo.
2. O volume de conversão é baixo demais para o algoritmo aprender (dezenas por mês). Resolva a definição de conversão e a importação offline antes.
3. Ninguém vai manter. Servidor sem dono vira ponto cego em três meses.
4. O problema é de CRM, não de site. Se os leads chegam mas o CRM não registra origem, o servidor não resolve. O caminho é atribuição.
5. A expectativa é voltar ao tempo do cookie de terceiro. Não volta. O servidor melhora a qualidade do sinal que você tem direito de coletar; não recria o que o navegador e a lei tiraram.

Metade dos casos de “perda de conversão” que chegam até nós é configuração, não navegador. Vale passar pelos erros comuns no GA4 antes de orçar servidor. E se o site vai ser refeito, a migração é o melhor momento para montar a medição no servidor desde o primeiro dia, e tirar tag do navegador também ajuda nos Core Web Vitals. Quem vai trabalhar CRO ou rodar teste A/B precisa disso resolvido antes: teste com evento perdido em parte das sessões dá resultado torto.

Checklist de implementação

Antes de pagar servidor, veja quanto do seu lead a plataforma enxerga

Quando o número do Google Ads e o do CRM ficam lado a lado, a decisão de implantar ou não fica óbvia. O primeiro passo é o Diagnóstico grátis do site, que mostra o que o site mede hoje. A plataforma Intelligence da Incuca cruza mídia, site e CRM num painel e mostra a cobertura real, mês a mês. Se a decisão for implantar, a Incuca monta o servidor e o Consent Mode com a sua equipe.