TL;DR, Resposta rápida
9 min de leituraO server-side tracking envia eventos de um servidor que você controla para plataformas de analytics e publicidade, em vez de enviá-los do navegador do visitante. Ele recupera a duração dos identificadores que o Safari corta, resiste às listas de filtros que citam hostnames de fornecedores e precisa de um ID de evento compartilhado para que a mesma conversão não seja contada duas vezes. Ele não elimina a exigência de consentimento do artigo 5(3) da Diretiva ePrivacy nem a necessidade de uma base legal sob o GDPR.
O que é server-side tracking?
Um site usa server-side tracking (rastreamento do lado do servidor) quando o navegador envia um evento para um servidor que o próprio site controla, e esse servidor repassa o evento para as plataformas de analytics e publicidade, em vez de o navegador fazer isso. O que muda de lugar é o trecho de saída: o payload, os identificadores e a lista de destinos ficam em uma infraestrutura que você pode inspecionar e registrar em log. Liste os eventos que o seu backend consegue confirmar sozinho, porque são eles que mais ganham com a mudança.
A alternativa é o client-side tracking, em que um script do fornecedor fala diretamente com o endpoint do fornecedor. A troca é controle contra visibilidade: o seu servidor vê um pedido verificado, mas o analytics client-side e server-side diverge sobre alguém enxergar o rage click que nunca chegou ao seu backend.
Por que as equipes levaram o tracking para o servidor?
Os navegadores encurtaram a vida dos identificadores dos quais as tags client-side dependem. O Intelligent Tracking Prevention 2.1 do WebKit, publicado em 21 de fevereiro de 2019, determinou que "all persistent client-side cookies, i.e. persistent cookies created through document.cookie, are capped to a seven day expiry". O WebKit veio em seguida, em 24 de março de 2020, bloqueando totalmente os cookies de terceiros no Safari 13.1 e no iOS 13.4, com a afirmação de que "cookies for cross-site resources are now blocked by default across the board". Esse limite de cookies de 7 dias corta qualquer medição de visitantes recorrentes ou de atribuição que guarde o seu ID com JavaScript.
O Chrome foi para o lado oposto. O Google anunciou em 22 de abril de 2025 que havia "made the decision to maintain our current approach to offering users third-party cookie choice in Chrome, and will not be rolling out a new standalone prompt for third-party cookies". Os cookies de terceiros continuam funcionando no Chrome padrão, então a pressão vem do Safari, dos bloqueadores de conteúdo e das taxas de consentimento, e não de uma data única de descontinuação.
Como funciona uma configuração de server-side tracking?
Duas peças fazem o trabalho: um servidor de tagging que recebe os eventos e uma API de destino que os aceita. O Tag Manager server-side do Google roda o servidor de tagging no Google Cloud Run ou no App Engine, ou em "a platform of your choice", e reaproveita "the same tag, trigger, and variable model" do contêiner web. Um cliente dentro do contêiner de servidor assume uma requisição HTTP recebida e a transforma em um objeto de evento, que as tags do contêiner repassam adiante.
A Conversions API da Meta é um desses destinos, com ou sem gerenciador de tags. A Meta a descreve como uma conexão que leva dados de marketing "from an advertiser's server, website platform, mobile app, or CRM to Meta systems" e afirma que "server events are linked to a dataset ID and are processed like events sent using the Meta Pixel". Confira primeiro as regras de parâmetros da Meta, porque um campo rejeitado vira uma correspondência perdida sem nenhum aviso.
O server-side tracking restaura a duração dos cookies no Safari?
Não quando o servidor de tagging fica atrás de um CNAME. O WebKit anunciou em 12 de novembro de 2020 que "ITP now caps the expiry of cookies set in so-called third-party CNAME-cloaked HTTP responses to 7 days", colocando um endpoint de fornecedor apontado por CNAME sob os mesmos sete dias de um cookie de JavaScript. Um servidor de tagging no seu próprio subdomínio, que grava o cookie com um cabeçalho Set-Cookie em vez de usar document.cookie, fica fora do limite do ITP 2.1, e esse é o mecanismo por trás da maioria das promessas de tracking com cookies first-party.
| Regra do navegador | Fonte e data | O que um servidor de tagging muda |
|---|---|---|
Limite de sete dias para cookies de document.cookie | WebKit ITP 2.1, 21 de fevereiro de 2019 | O servidor grava o cookie com Set-Cookie, então o limite não o atinge |
| Todos os cookies de terceiros bloqueados por padrão | WebKit, 24 de março de 2020 | Nada. O cookie do fornecedor some de qualquer jeito |
| Limite de sete dias para cookies de respostas camufladas por CNAME | WebKit, 12 de novembro de 2020 | Nada se um CNAME apontar para um fornecedor. Hospede o endpoint você mesmo |
| Escolha sobre cookies de terceiros deixada ao usuário | Google, 22 de abril de 2025 | Nada. O Chrome continua permitindo esses cookies por padrão |
O server-side tracking elimina a necessidade de consentimento?
Não. O artigo 5(3) da Diretiva ePrivacy exige consentimento para "o armazenamento de informações ou a possibilidade de acesso a informações já armazenadas no equipamento terminal de um assinante ou utilizador", com exceções para efetuar uma transmissão e para o que for "estritamente necessário" à prestação do serviço solicitado. A regra trata do ato de ler ou gravar no dispositivo, e não do hostname que executa esse ato, então levar a etapa de repasse para o seu próprio servidor deixa a leitura no dispositivo, onde ela já estava. Mantenha a camada de consentimento de tracking e trate o servidor de tagging como uma mudança de transporte.
A questão do GDPR fica por cima dessa. Assim que um evento chega ao seu servidor, você está tratando dados pessoais, o que exige uma base legal sob o artigo 6 e um caminho lícito para qualquer transferência para fora da UE. Equipes que usam o consent mode mantêm a mesma estrutura depois da mudança, porque o estado de consentimento viaja com o evento para cada destino.
Como evitar a contagem dupla quando o navegador e o servidor disparam o evento?
Envie um ID compartilhado nas duas cópias e deixe a plataforma descartar a duplicata. A documentação de deduplicação da Meta afirma que "a Meta Pixel's eventID must match the Conversion API's event_id" e "a Meta Pixel's event must match the Conversion API's event_name", e que os eventos "are only deduplicated if they are received within 48 hours" do primeiro evento com aquele ID.
reported conversions = browser events + server events - matched duplicates
Pegue um dia com 1.000 checkouts concluídos. O Pixel chega à Meta em 700 deles, o servidor envia todos os 1.000, e cada evento do servidor leva o event_id que o seu gêmeo no navegador usou. As duplicatas correspondidas somam 700, então as conversões reportadas são 700 + 1.000 - 700 = 1.000, o número real. Tire o event_id do payload do servidor e as duplicatas correspondidas caem para 0, e a Meta reporta 700 + 1.000 = 1.700 compras contra 1.000 pedidos, uma contagem 70 por cento acima do real que todo número de custo por aquisição herda.
Quais eventos ficam no servidor e quais ficam no navegador?
Coloque no servidor os eventos que o seu backend consegue verificar e deixe os sinais de comportamento no navegador.
Flowsery
Teste gratuito
Painel em tempo real
Rastreamento de metas
Rastreamento sem cookies
| Evento | Onde fica | Por quê |
|---|---|---|
| Compra, reembolso, mudança de assinatura | Servidor | O processador de pagamentos confirma, e o navegador pode fechar antes |
| Cadastro, início de teste, upgrade de plano | Servidor | O seu banco de dados é o registro, então uma requisição bloqueada não consegue apagá-lo |
| Pageview e mudança de rota client-side | Navegador | O servidor nunca vê uma navegação que não foi pedida a ele |
| Rage click, dead click, profundidade de rolagem | Navegador | Esses eventos existem só como interações dentro do DOM |
| Erro de JavaScript e fluxo quebrado | Navegador | A falha é o motivo de nenhuma requisição ter chegado ao servidor |
O analytics privacy-first precisa de um servidor de tagging?
Não. Um servidor de tagging conserta um stack baseado em cookies: ele realoca os identificadores que os navegadores continuam encurtando e desvia chamadas de hostnames que as listas de filtros continuam citando. Um analytics construído sem esses identificadores não tem nada para realocar. O Flowsery não usa cookies e é hospedado na UE, entrega um único script com menos de 10 KB e não aplica amostragem de dados, então o analytics privacy-first roda sem um proxy na frente, junto com a atribuição de receita do Stripe, Paddle, Polar, Lemon Squeezy e Shopify.
Use um servidor de tagging quando uma plataforma de anúncios precisar de eventos de servidor que ela não consegue obter da página. Medir o seu próprio produto é uma decisão separada.
Perguntas frequentes
O server-side tracking é a mesma coisa que o server-side rendering?
Não. O server-side rendering monta o HTML no servidor antes de o navegador exibi-lo, e o server-side tracking repassa eventos de analytics a partir de um servidor que você controla. Os dois compartilham o lugar e nada mais. Um site pode renderizar todas as páginas no servidor e ainda assim enviar os eventos direto do navegador.
O server-side tracking funciona sem JavaScript na página?
Em parte. Eventos que pertencem ao seu backend, como um pagamento concluído ou um webhook do Stripe recebido, não precisam de código no navegador. Eventos que descrevem o que alguém fez em uma página precisam de um script que os observe e os envie para o seu endpoint.
Um servidor de tagging derrota os bloqueadores de conteúdo?
Ele muda aquilo que o bloqueador identifica. As listas de filtros citam hostnames conhecidos de analytics e publicidade, e uma requisição para o seu próprio subdomínio não está nessas listas. Os bloqueadores também verificam caminhos de requisição e nomes de arquivo de scripts, então um caminho de fornecedor copiado literalmente para o seu domínio continua sendo pego.
Quais dados de clientes posso enviar pela Conversions API da Meta?
A Meta aceita campos de contato e demográficos, incluindo e-mail, telefone, nome, sobrenome, data de nascimento, gênero, cidade, estado e CEP, e exige hash SHA256 nesses campos. A Meta afirma que client_ip_address e client_user_agent "must never be hashed". Um e-mail com hash continua identificando uma pessoa para qualquer um que tenha o mesmo hash, então você precisa de uma base legal antes de enviá-lo.
Ainda preciso do Meta Pixel se usar a Conversions API?
A orientação de deduplicação da Meta pressupõe que os dois estão rodando, já que compara o eventID do Pixel com o event_id da Conversions API. Remover o lado do navegador elimina o ID de navegador fbp e o ID de clique fbc que o Pixel define. Rode os dois e deduplique.
O server-side tracking reduz o peso da página?
Ele reduz o peso quando você troca vários scripts de fornecedores por uma única chamada ao seu próprio endpoint, e aumenta o peso quando você mantém todas as tags de fornecedores e duplica os eventos delas no servidor. O Google lista "improve page performance" entre os motivos para usar o tagging server-side. Meça a página antes e depois em vez de presumir que a configuração entregou esse ganho.
Onde posso rodar um contêiner de Tag Manager no lado do servidor?
O Tag Manager do lado do servidor do Google roda no Google Cloud Run, no App Engine ou em "uma plataforma de sua escolha". O contêiner reaproveita "o mesmo modelo de tags, triggers e variáveis" do contêiner web, então a lógica de tags já existente continua valendo. A escolha de hospedagem não muda o que acontece por dentro, um client continua recebendo a requisição e transformando-a em um objeto de evento.
O Chrome vai limitar cookies de terceiros como o Safari faz?
Não no ritmo que o Safari impôs. O Google anunciou em 22 de abril de 2025 que manteria sua abordagem atual de escolha de cookies de terceiros no Chrome e não lançaria um novo aviso independente para eles. Os cookies de terceiros continuam funcionando por padrão no Chrome, então a pressão para mover o tracking para o servidor vem do Safari, dos bloqueadores de conteúdo e das taxas de consentimento, não do Chrome.
Quanto tempo tenho para enviar o evento de servidor correspondente e a deduplicação funcionar?
A Meta só deduplica eventos recebidos dentro de 48 horas após o primeiro evento com aquele event_id. Perdendo essa janela, tanto a cópia do navegador quanto a do servidor da mesma conversão são contadas, a mesma contagem duplicada causada por um event_id ausente. Envie o pixel e a requisição de servidor perto o suficiente no tempo para que ambos caiam dentro dessa janela de 48 horas.
Preciso de um tag manager para usar a Conversions API da Meta?
Um tag manager não é obrigatório. A Meta descreve a Conversions API como uma conexão que carrega dados de marketing "do servidor de um anunciante, da plataforma do site, do app móvel ou do CRM para os sistemas da Meta", e uma única integração pode chamá-la diretamente. Eventos de servidor enviados assim seguem "vinculados a um dataset ID e são processados como eventos enviados pelo Meta Pixel".
Este artigo foi útil?
Diga-nos o que pensa!
Veja-nos mais no Google
Um clique marca a Flowsery como fonte preferida e nossos artigos passam a aparecer mais acima nas suas Principais notícias, no modo IA e nas visões gerais com IA.
Antes de ir...
Flowsery
Analytics orientado para receitas para o seu site
Rastreie cada visitante, fonte e conversão em tempo real. Simples, poderoso e sem cookies.
Painel em tempo real
Rastreamento de metas
Rastreamento sem cookies
Termos relacionados do glossário
Como uma janela de atribuição decide quais pontos de contato recebem crédito
Mude a janela de atribuição de 7 para 90 dias e um pedido de $1,800 paga três conjuntos de canais diferentes. Veja a aritmética e os padrões das plataformas.
O Google lista sete causas distintas de not set no GA4
O Google dá a not set no GA4 uma causa diferente por dimensão, de um session_start ausente a um content_group vazio. Veja cada causa e a correção.
O que estes números revelam sobre a taxa de rejeição média por setor
Nove setores rastreados mostram uma taxa de rejeição média por setor documentada, entre 35.76% e 48.38%, segundo dados da Databox de setembro de 2024.
Como aplicar a fórmula do valor médio do pedido passo a passo
A fórmula do valor médio do pedido divide a receita total pelos pedidos, e um único cupom de desconto pode distorcer cada número que uma equipe reporta.
Como sites B2B e B2C se comparam nos benchmarks de duração média de sessão
A Databox coloca, com dados próprios, os benchmarks de duração média de sessão em 77.61 segundos no B2B e 92.33 segundos no B2C, por setor e dispositivo.
O que a duração média de sessão realmente mede
Na analytics clássica, a duração média de sessão dá zero tempo registrado à última página vista de cada sessão, o que puxa a média para baixo silenciosamente.
Artigos relacionados
Por que beforeunload vs pagehide decide se o analytics sobrevive
Comparar beforeunload vs pagehide mostra por que o celular pula beforeunload, bloqueia o bfcache e pagehide envia dados de forma confiável com sendBeacon.
O que a análise comportamental rastreia que as visualizações de página perdem
Diferente de uma contagem de visualizações de página, a análise comportamental registra o que um visitante faz na página, como eventos vinculados a ele.
Como a impressão digital do navegador te identifica sem um cookie
Canvas, fontes instaladas, tamanho de tela e fuso horário, combinados pela impressão digital do navegador em um identificador que sobrevive à exclusão.