Medição
Rastreamento no lado do servidor
O rastreamento no lado do servidor envia eventos de conversão e comportamento para plataformas de análise e anúncios a partir do próprio servidor de um lojista, em vez de usar o navegador do comprador.
Ele recupera eventos que o rastreamento baseado no navegador perde para bloqueadores de anúncios, recursos de prevenção de rastreamento e falhas de rede — geralmente uma parcela substancial de conversões, o que se manifesta como desempenho subnotificado e otimização pior da plataforma de anúncios.
Não é uma solução alternativa de privacidade e não deve ser vendido como tal: as obrigações de consentimento se aplicam ao evento, independentemente de onde ele é enviado. O ganho é confiabilidade, não permissão.
O modo de falha a ser observado é a contagem dupla. Executar o rastreamento do navegador e do servidor simultaneamente sem uma chave de deduplicação compartilhada significa que cada conversão que o navegador relatou é contada duas vezes, o que infla o desempenho relatado e ensina a plataforma de anúncios a otimizar para o sinal errado. Ambos os lados devem enviar o mesmo ID de evento.
O que realmente muda: onde o evento é montado e enviado
Com um pixel de navegador, um script executado no dispositivo do comprador monta o evento. Ele lê a página para obter o valor e o conteúdo do pedido, lê seus próprios cookies para os identificadores de clique e navegador, e envia o payload para o domínio da plataforma a partir do dispositivo. Tudo nessa cadeia está fora do seu controle: o script precisa carregar, executar e completar sua solicitação antes que o comprador navegue para outra página, em um dispositivo que pode estar executando um bloqueador de anúncios e um navegador que limita a duração dos cookies.
Com a entrega server-side, seu servidor constrói o evento a partir de registros que já possui — o pedido, o cliente, os itens da linha — e o envia para o endpoint de conversões da plataforma como uma chamada server-to-server autenticada com um token de acesso. O navegador do comprador não está envolvido no momento do envio. O evento é acionado porque um pedido foi gravado em seu banco de dados, que é o sinal mais confiável no negócio.
Os identificadores também mudam de forma. Em vez de depender de um cookie que o navegador pode ter expirado, o servidor envia chaves de correspondência hash — endereço de e-mail normalizado, número de telefone, nome, código postal — juntamente com qualquer identificador de clique capturado quando o comprador chegou e armazenado com o pedido, além do endereço IP e user agent. A qualidade da correspondência então depende do que você coletou no checkout, em vez do que o navegador preservou.
| Capacidade | Pixel do navegador | Evento do servidor |
|---|---|---|
| Onde o payload é montado | No navegador do comprador, a partir do contexto da página e dos cookies | No seu servidor, a partir dos registros de pedido e cliente |
| Bloqueado por bloqueadores de anúncios e prevenção de rastreamento | Sim — o script pode nunca ser executado | Não — a chamada nunca toca o dispositivo do comprador |
| Sobrevive ao comprador fechar a aba durante o redirecionamento | Não | Sim |
| Vê o comportamento na página, como profundidade de rolagem e cliques em adicionar ao carrinho | Sim | Somente se o navegador o reportar ao seu servidor primeiro |
| Vê eventos pós-compra: reembolsos, renovações, estornos | Não | Sim |
| Carrega o identificador de clique de anúncio | Sim, da URL de destino e de seu próprio cookie | Somente se você o capturou na chegada e o armazenou com o pedido |
| Requer base legal e consentimento | Sim | Sim — de forma idêntica |
O que ele corrige e o que não corrige
Ele corrige a entrega. Eventos de compra que foram perdidos devido a um script bloqueado, uma solicitação falha ou um comprador fechando a aba no redirecionamento de pagamento agora chegam, e chegam com chaves de correspondência extraídas do registro do pedido, em vez do que sobreviveu no navegador. Ele também desbloqueia uma classe de eventos que o navegador nunca pode ver: reembolsos, renovações de assinatura, estornos, cancelamentos e pedidos offline ou por telefone, todos os quais acontecem muito depois do término da sessão e todos os quais alteram materialmente o que a plataforma deve otimizar.
Ele não corrige o consentimento. Este é o mal-entendido mais comum e o mais caro. A obrigação se refere ao processamento de dados pessoais, não ao meio pelo qual eles viajam. Enviar um evento sobre um comprador que recusou o consentimento é o mesmo processamento com uma rota mais longa, e a decisão de consentimento agora precisa ser levada do navegador para o registro do seu pedido para que o servidor saiba se tem permissão para enviar — trabalho que o pixel costumava fazer implicitamente.
Ele não cria uma identidade que você nunca coletou. Um checkout de convidado sem e-mail e sem identificador de clique armazenado não será correspondido, quer o evento saia de um navegador ou de um servidor. Ele também não substitui os sinais de comportamento na página: se você deseja profundidade de rolagem ou interações de adicionar ao carrinho server-side, o navegador ainda precisa reportá-los a você primeiro.
E não melhora o desempenho, apenas o relatório. Ativá-lo aumenta as conversões relatadas e diminui o custo por aquisição relatado imediatamente, porque eventos que sempre estavam acontecendo agora estão sendo contados. Isso é uma quebra na série temporal, não um resultado. Marque a data no gráfico e não deixe ninguém comparar o mês seguinte com o mês anterior como se as campanhas tivessem mudado.
Deduplicação: o contrato do ID do evento
Uma vez que ambos os caminhos estejam ativos, cada conversão que o navegador relatou com sucesso também é relatada pelo servidor. A plataforma contará ambos, a menos que você diga que são o mesmo evento, e a maneira de fazer isso é com um identificador de evento compartilhado: ambos os lados enviam o mesmo nome de evento e o mesmo ID, a plataforma mantém o que chegar primeiro e descarta o outro dentro de sua janela de deduplicação.
Avalie o risco com um exemplo. Suponha 1.000 compras reais em um mês e que 30% dos eventos do navegador são perdidos — o navegador relata 700, o servidor relata todos os 1.000. Sem deduplicação, a plataforma registra 1.700 conversões contra 1.000 reais, uma superestimação de 70%, e o custo por aquisição relatado cai para cerca de 59% da verdade. O otimizador então aprende com um sinal em que alguns pedidos contam duas vezes e outros uma vez, o que é pior do que qualquer um dos caminhos isoladamente.
- Derive o ID de algo que ambos os lados já conhecem — o ID do pedido é a escolha óbvia. Gerar um ID aleatório independentemente em cada lado garante que eles nunca correspondam.
- Mantenha o ID estável em todas as tentativas. Uma nova tentativa que regenera o identificador transforma seu próprio tratamento de erros em uma máquina de contagem dupla.
- Corresponda o nome do evento exatamente, incluindo maiúsculas/minúsculas e tipo. As plataformas deduplicam no par, então um evento de navegador e um evento de servidor que diferem apenas na nomenclatura serão ambos mantidos.
- Envie os identificadores de clique e de navegador com o evento do servidor também. Eles são o que permite à plataforma reconhecer os dois relatórios como sendo do mesmo usuário, não apenas do mesmo pedido.
- Respeite a janela de deduplicação. Um evento entregue dias depois — um webhook atrasado, um backfill — está fora dela e será contado novamente.
- Teste com pedidos reais antes de confiar nos números e concilie a contagem de conversões relatada pela plataforma com sua própria contagem de pedidos para o mesmo período. Eles devem estar próximos; uma lacuna sistemática em qualquer direção é uma falha de conexão.
O custo operacional para o qual ninguém orça
Um pixel é uma tag que alguém cola uma vez. A entrega do lado do servidor é um serviço que você agora possui, com um token de acesso, um esquema, uma política de repetição e um modo de falha, e cada um deles falha silenciosamente. Um token expirado, uma versão da API da plataforma que parou de aceitar o payload que você envia, um deploy que removeu a captura do identificador de clique na página de destino, um bug de hashing onde os endereços de e-mail não foram convertidos para minúsculas e aparados antes do hashing — nenhum desses gera um erro que a equipe de marketing verá. Eles se apresentam como um declínio gradual na qualidade da correspondência ou uma queda repentina nas conversões que se parece exatamente com uma semana ruim de publicidade.
Portanto, o monitoramento não é opcional e é simples: compare os eventos do servidor enviados com os pedidos criados, todos os dias, e alerte sobre divergências. Observe os diagnósticos de eventos da própria plataforma ou a pontuação de qualidade de correspondência, porque uma taxa de correspondência em queda geralmente é um problema de dados, e não de público. Registre a resposta a cada envio em vez de 'disparar e esquecer', já que um payload rejeitado é, de outra forma, indistinguível de um bem-sucedido.
Orce também a infraestrutura de consentimento. A decisão deve ser capturada no navegador, persistida com o pedido e lida pelo servidor antes do envio — três componentes que precisam estar em acordo, em um sistema onde a falha é silenciosa em uma direção e um problema de conformidade na outra.
O resumo honesto é que o rastreamento do lado do servidor troca uma categoria de falta de confiabilidade que você não pode corrigir por uma categoria de manutenção que você pode. Essa é geralmente a troca certa, e deixa de ser a troca certa se ninguém for o responsável pelo pipeline após o trimestre em que foi construído.
Perguntas frequentes
- O que é rastreamento do lado do servidor?
- O rastreamento do lado do servidor envia eventos de conversão e comportamento para plataformas de análise e publicidade a partir do próprio servidor de um comerciante, em vez de usar o navegador do comprador. O evento é construído a partir de registros de pedidos e clientes que o servidor já possui e é enviado para o endpoint de conversões da plataforma por meio de uma chamada autenticada de servidor para servidor.
- Qual a diferença entre o rastreamento do lado do servidor e um pixel de navegador?
- Um pixel de navegador monta o evento no dispositivo do comprador e depende de um script carregar, executar e ser concluído antes que ele saia da página. Um evento de servidor é construído a partir do registro do pedido e enviado da sua infraestrutura, então bloqueadores de anúncios, limites de tempo de vida de cookies e uma aba fechada não podem impedi-lo. Ele também pode relatar reembolsos e renovações, o que um pixel nunca vê.
- O rastreamento do lado do servidor ignora o consentimento ou contorna os bloqueadores de anúncios?
- Não é um mecanismo de consentimento. As obrigações de proteção de dados se aplicam ao processamento de dados pessoais, não ao transporte, então um evento sobre um comprador que recusou o consentimento é o mesmo processamento enviado de uma forma diferente. Ele contorna os bloqueadores de anúncios, porque a chamada nunca toca o dispositivo do comprador — mas a base legal ainda precisa existir.
- Como evitar a contagem duplicada entre o pixel e o servidor?
- Envie o mesmo nome de evento e o mesmo ID de evento de ambos os caminhos, derivados de algo estável como o ID do pedido, e a plataforma mantém a primeira chegada e descarta a duplicata dentro de sua janela de deduplicação. IDs gerados aleatoriamente em cada lado nunca correspondem, e uma nova tentativa que regenera o ID reintroduz a contagem duplicada.
- O rastreamento do lado do servidor vai melhorar meu ROAS?
- Ele vai melhorar o ROAS relatado, porque as conversões que sempre estavam acontecendo começam a ser contadas. Essa é uma mudança de relatório, não uma mudança de desempenho, então marque a data da transição no gráfico. O benefício genuíno está a jusante: um sinal de conversão mais completo permite que a plataforma otimize com base na realidade, em vez de otimizar com base no subconjunto que ela podia ver anteriormente.
- Ainda preciso do pixel de navegador?
- Geralmente sim. O navegador vê o comportamento na página que o servidor não consegue — profundidade de rolagem, interações de adicionar ao carrinho, visualizações de produtos — e ele captura os identificadores de clique que tornam os eventos do servidor correspondentes. A configuração comum executa ambos, com um ID de evento compartilhado para que a plataforma deduplique, em vez de tratar a entrega do servidor como uma substituição.