Tracking server-side em e-commerce: evento duplicado não é venda duplicada

O erro de diagnóstico que encontramos nas duas auditorias de rastreamento que fizemos entre setembro e outubro de 2026 foi o mesmo: confundir evento duplicado com venda duplicada. O gestor abre o Gerenciador de Eventos, vê o servidor mandando o dobro de compras que a loja registrou e conclui que o ROAS está inflado em 100%. Às vezes está. Em uma delas o servidor nem estava envolvido. Na outra, o reenvio do servidor explicou a menor parte da diferença.

A plataforma recebe o evento bruto e decide o que conta. Quando o servidor reenvia a mesma compra com o mesmo identificador, a Meta descarta a cópia na contagem. Isso não garante que a atribuição fique intacta, como o caso do Lead mostra adiante. Nas auditorias, o número que inflou o ROAS veio de outro lugar. Ou era o mesmo pedido disparado em dois momentos, com identificadores diferentes. Ou era um pixel recebendo vendas de produtos que a campanha nunca anunciou.

Tracking server-side não corrige número errado. Ele envia para a plataforma, com mais fidelidade, o número que você já tinha. Se a regra de disparo estava errada no navegador, o servidor replica o erro com qualidade de correspondência alta. Por isso a auditoria vem antes da escala de verba, e não depois.

A montagem das camadas está em Setup técnico de tracking para e-commerce em 2026. Aqui o assunto é outro: como saber se o número que sai dessas camadas é verdadeiro.

O dobro no Gerenciador de Eventos

A leitura mais comum é intuitiva e faz sentido. O gestor liga a CAPI, passa a ver eventos chegando por dois canais e encontra uma razão de 2 para 1 entre servidor e loja. Conclui que cada venda está sendo contada duas vezes. Corta a verba da campanha que parecia campeã, ou pede para o time técnico desligar o servidor.

Nós já caímos nessa leitura. Em uma operação de infoproduto acompanhada pela Moyker, em 28 de setembro de 2026, o servidor enviou cerca de 600 eventos de compra para 304 vendas reais no checkout. O fluxo de automação reenviava a compra a cada atualização do webhook do checkout, e o checkout manda o mesmo status "aprovado" duas vezes: uma na aprovação, outra na confirmação do pagamento. O volume bruto quase dobrou. A primeira reação foi tratar isso como inflação de resultado.

Não era. O identificador do evento era o mesmo nas duas remessas, montado a partir do número da transação. A Meta desduplicou, e a compra atribuída do dia ficou em 290. Na compra, o dobro existia no evento bruto e sumia antes do relatório de campanha.

Quando server-side nem é a pergunta certa

Se a sua loja tem menos de 50 compras por mês por conta de anúncio, auditoria de servidor não é prioridade. Nesse volume, a pergunta útil é se o evento de compra dispara uma vez, com valor correto, na página certa. Uma planilha com os pedidos da semana e o número do Gerenciador de Eventos ao lado responde isso em 20 minutos.

O mesmo vale para quem roda só Google Shopping com conversão importada do GA4. O GA4 já descarta compra repetida com o mesmo transaction_id, segundo a documentação oficial do Google Analytics. O problema de duplicação ali tem outra cara: compra sem transaction_id, ou com identificador gerado no navegador a cada recarga da página de obrigado.

Server-side vale o esforço quando a operação tem volume, roda mais de uma plataforma e já tomou decisão de verba com base em ROAS de plataforma. É aí que um erro como os 27% do caso de Lead descrito adiante custa caro.

Três origens do ROAS inflado

Encontramos três origens. Só uma delas é o servidor mandando duas vezes, e foi a que menos pesou. As outras duas passam pela desduplicação porque, para a plataforma, os eventos são diferentes.

Causa 1: o mesmo pedido disparado em dois momentos

Em uma loja Nuvemshop que lançou em setembro de 2026, o pixel registrou 33 compras em dois dias. O painel da loja, no mesmo período, mostrava 18 pedidos criados e 15 pedidos pagos. A soma é exata: 18 mais 15 dá 33. A loja via 2,2 compras no pixel para cada pedido pago.

A loja disparava Purchase quando o pedido era criado e de novo quando o pagamento era confirmado. Os dois eventos chegavam com identificadores diferentes, porque nasciam em momentos diferentes. A Meta não tinha como saber que eram a mesma venda. O ROAS da conta ficou inflado em cerca de 120% sobre os pedidos pagos. Pior: a campanha estava a ponto de otimizar para compra, e o algoritmo aprenderia com um evento que acontece duas vezes por cliente.

O detalhe que confirmou o diagnóstico foi o contraste. No mesmo período, o PageView do pixel deu 1.236 eventos para 232 visitas no painel da loja, ou 5,3 páginas por sessão, sem nenhuma soma estranha. Se fosse diferença de janela ou de definição, o PageView também estaria fora. Só a compra estava.

O caso nasceu na regra de disparo, sem servidor nenhum envolvido. E é exatamente o tipo de erro que o servidor replica com fidelidade quando alguém liga a CAPI em cima de um pixel já errado.

Causa 2: o servidor que reenvia, e a desduplicação que segura

O caso do infoproduto, descrito acima, é a segunda causa. Ela existe, mas o estrago real foi menor do que o número bruto sugeria. A documentação de desduplicação da Meta define a regra: eventos com o mesmo event_name e o mesmo event_id, recebidos em até 48 horas um do outro, contam uma vez.

Na mesma operação, o evento Lead mostrou o padrão com clareza. Entre 26 de agosto e 16 de setembro de 2026, a razão entre servidor e navegador ficou entre 1,01 e 1,02, com a CAPI espelhando o pixel. A partir de 17 de setembro, com uma nova rota de servidor ligada, a razão subiu para perto de 2. A tela de desduplicação mostrava cobertura de 99,98% e a própria Meta relatava só 4% de conversões adicionais vindas da CAPI.

O volume bruto dobrou e a contagem atribuída subiu bem menos que o bruto. Subiu, porém. Os leads atribuídos contra os contatos novos do CRM passaram de uma razão de 1,1 para 1,4 no período. São 27% a mais de leads atribuídos, a conta de 1,4 dividido por 1,1. Na prática, o custo por lead do Gerenciador passou a aparecer cerca de 21% abaixo do que aparecia com a mesma base. Longe da metade que o bruto sugeria.

A aba de desduplicação relatava 4% de conversões adicionais. A conciliação com o CRM mostrou 27%. A causa exata da diferença não foi isolada até a publicação deste texto. A nova rota coincidiu com a alta, e a hipótese mais forte é uma mudança no gatilho do formulário, que passou a gerar Lead na validação do campo e não só no envio. Se a hipótese se confirmar, o reenvio foi segurado pela desduplicação e o que vazou nasceu no gatilho, não no servidor. A aba sozinha não explicava nada disso.

Essa diferença muda a decisão. Quem lê o bruto corta a campanha pela metade do resultado. Quem lê o atribuído conciliado com o CRM corrige os 21% do custo por lead e mantém o que funciona.

Causa 3: o pixel compartilhado e a janela de visualização

A terceira causa é a mais cara e a menos visível. Na mesma operação de infoproduto, um teste de preço rodou entre 25 e 27 de setembro de 2026 com três versões da oferta: R$ 37, R$ 47 e R$ 67. O Gerenciador apontou a versão de R$ 47 como vencedora: 12 compras e ROAS de 2,19. O checkout mostrava outra coisa: 4 vendas reais e ROAS de 0,79. A versão de R$ 37, que parecia pior no painel, teve 10 vendas reais e ROAS de 0,97. A de R$ 67 marcou 1 compra no painel e nenhuma no checkout.

Pelo painel, o 47 ganhou. Pela venda real, o 37 ganhou.

A duplicação bruta existia no período, mas era desduplicada e não explica a diferença. O pixel era compartilhado por todo o negócio, então recebia as vendas de todos os produtos, vendidos em outras frentes. A janela de atribuição dos conjuntos incluía um dia após a visualização. Quem viu o anúncio do teste e comprou outro produto no mesmo dia virava compra do teste. A ajuda da Meta sobre configuração de atribuição descreve essa janela de visualização. A regra de crédito funciona como documentado. Combinada com pixel compartilhado, ela credita à campanha uma venda que ela não fez.

O servidor não tem nenhum papel aqui. Ele pode estar perfeito. O número continua errado, porque a pergunta que o número responde é diferente da pergunta que o gestor fez.

O rastro que cada causa deixa

Os três casos produzem o mesmo sintoma no painel: ROAS acima do que o caixa confirma. A diferença está no rastro que cada um deixa. A tabela abaixo resume o que procurar e onde.

O rastro do disparo em dois momentos

O sinal mais limpo é a soma exata. Puxe os pedidos do período com status, separe criados e pagos e compare com o Purchase do Gerenciador de Eventos no mesmo fuso horário. Se o pixel bate com a soma das duas colunas, o diagnóstico está feito. Se bate só com os pagos, a regra de disparo está certa.

Um segundo rastro: o evento de compra aparece em horários em que nenhum pagamento foi aprovado. Pedido criado às 23h com boleto, compra registrada às 23h, pagamento confirmado dois dias depois e compra registrada de novo. O guia de validação do Pixel Meta pós-iOS 14 mostra como usar o modo de teste de eventos para ver isso em tempo real.

O rastro do reenvio do servidor

Aqui o sinal é a distância entre bruto e atribuído. No Gerenciador de Eventos, o evento mostra quantos chegaram por navegador e quantos por servidor. Na aba de desduplicação, a Meta mostra a cobertura de event_id e a porcentagem de eventos desduplicados.

Cobertura acima de 95% indica que a maior parte do excesso é volume. Indica, sem absolver: no caso do Lead, com 99,98% de cobertura, a conciliação com o CRM ainda achou 27% a mais de leads atribuídos. Por isso a leitura da aba vem sempre acompanhada da conciliação com a loja ou com o CRM. O reenvio também custa dinheiro. Na operação de infoproduto, o servidor da Stape estourou o limite do plano no ciclo anterior com 1,45 milhão de requisições.

Se a cobertura está abaixo de 80%, o caso muda. Eventos sem par não são desduplicados, e o servidor está somando compra de verdade. O guia sobre como configurar a CAPI da Meta em e-commerce detalha como gerar o mesmo event_id nos dois lados.

O rastro do pixel compartilhado

O sinal é o valor. Divida o valor de conversão atribuído pelo número de compras atribuídas da campanha. Compare com o preço do produto que a campanha anuncia. Se a campanha vende um produto de R$ 37 e o valor médio por compra atribuída passa de R$ 100, ela está recebendo crédito por venda de outro produto.

O caso extremo apareceu em 21 de setembro de 2026, um dia de webinário na mesma operação. A campanha de um produto de R$ 37 mostrou ROAS de 14,94. Naquele dia, um produto de R$ 454,40 de ticket vendeu 260 unidades contra 10 do produto anunciado, e caía no mesmo pixel. Somado à janela de um dia após visualização, isso explicava o número. O valor médio atribuído denunciava o problema de longe.

O sinal tem limite. No teste de preço, o valor médio atribuído à versão de R$ 47 foi de R$ 57,90, só 23% acima do preço. Complementos vendidos junto com a oferta também sobem o ticket, então o valor sozinho não fechava o diagnóstico. Quem fechou foi a conciliação com o checkout: 12 compras no painel, 4 vendas reais.

O texto sobre modelos de atribuição em GA4 e Meta aprofunda a escolha de janela. O verbete Modelo de atribuição traz a definição curta para quem precisa alinhar o time.

Onde o server-side ajuda de verdade

Seria desonesto dizer que tracking server-side é teatro. Ele resolve problemas reais, e é por isso que montamos servidores para operações com volume. O ponto é que os problemas que ele resolve são de perda de sinal, não de excesso.

O primeiro é o bloqueador de anúncio. Pixel e tag do Google carregados direto dos domínios das plataformas caem quando o visitante usa bloqueador. Com o contêiner do Google Tag Manager servido no domínio da loja, o carregamento passa a vir de um endereço próprio. A documentação do Google sobre tagueamento do lado do servidor descreve esse desenho, e a página de domínio personalizado mostra como configurar.

O segundo é a vida útil do cookie no Safari. O WebKit limita a sete dias os cookies gravados por respostas de domínios disfarçados por CNAME que apontam para terceiros, como explica o post oficial do WebKit sobre CNAME cloaking. Na prática: servidor de tracking em subdomínio da loja, mas configurado como CNAME para o domínio do provedor, perde os cookies _fbp, _fbc e _gcl_aw em uma semana no Safari. Vimos exatamente esse desenho em outubro de 2026, na verificação de um servidor de tracking pela ferramenta do próprio provedor, que deu nota 58 em 100. A correção é servir o tracking pela mesma infraestrutura do site, por proxy ou pela CDN da loja, ou usar o recurso de preservação de cookie do provedor.

O terceiro é o dado de cliente. O servidor consegue anexar e-mail e telefone com hash ao evento de compra, o que melhora a correspondência. A referência de parâmetros de evento de servidor da Meta lista os campos. No Google, o equivalente são as Enhanced Conversions no Google Ads. Mas aqui também mora uma armadilha. Na operação de infoproduto, o evento de compra chegava ao servidor com o identificador de clique (fbc) em só 3,8% dos casos. A tabela de leads tinha o fbc em 100% dos contatos. A busca pelo e-mail do comprador usava o caminho errado do webhook e achava zero. Um conserto de uma linha.

Os três ganhos recuperam sinal que se perdia. Nenhum deles corrige um evento que dispara errado.

Como agir: a auditoria antes da escala

A auditoria abaixo cabe em uma tarde para uma operação com até três plataformas. Ela segue a ordem das três causas, porque a primeira é a mais barata de conferir e de corrigir.

1. Concilie a compra do pixel com o pedido pago

Abra o painel da loja e exporte os pedidos dos últimos 7 dias com coluna de status e data de criação. No Gerenciador de Eventos da Meta, abra o evento Purchase, escolha o mesmo período e anote o total por dia. Faça o mesmo no GA4, em Relatórios, Monetização, Compras de e-commerce, e no Google Ads, na coluna de conversões da ação de compra.

O que medir: a razão entre compras de cada plataforma e pedidos pagos, dia a dia. Gatilho de decisão: razão entre 0,8 e 1,1 é saudável. Entre 1,1 e 1,3, concilie pedido a pedido em um dia de amostra antes de mexer em qualquer coisa. Acima de 1,3 em qualquer dia, a regra de disparo é suspeita. Exatamente igual à soma de criados e pagos, o diagnóstico da Causa 1 está confirmado e a correção vem antes de qualquer outra coisa.

Na Cris e Cia, o ROAS de referência é calculado sobre venda real. Em fevereiro de 2026, foram R$ 1,031 milhão em vendas com R$ 50.479 investidos, ROAS de 20,43x. É esse o número que autoriza verba. O ROAS de cada plataforma serve para decidir dentro dela, não para decidir quanto investir.

2. Leia a desduplicação, não o volume

No Gerenciador de Eventos, clique no evento Purchase e abra a aba de visão geral com a divisão por origem. Anote eventos de navegador e eventos de servidor. Depois abra a seção de desduplicação e anote a cobertura de event_id.

O que medir: cobertura de event_id nos dois lados e porcentagem de conversões adicionais atribuídas à CAPI. Gatilho: cobertura acima de 95% com servidor em 2x indica reenvio desduplicado; confirme com a conciliação da etapa 1 e corrija o reenvio na semana. Entre 80% e 95%, descubra qual rota manda evento sem event_id antes de qualquer decisão de verba. Abaixo de 80%, o servidor soma compra real; pare a leitura de ROAS dessa conta até corrigir.

Se a loja manda compra só pelo servidor, sem par no navegador, a regra muda: confira se o event_id repete nas reentregas do webhook. No checkout que reenvia o status "aprovado", o identificador montado a partir do número da transação é o que salva a contagem.

3. Compare ticket atribuído com ticket anunciado

No Gerenciador de Anúncios, adicione as colunas de compras, valor de conversão de compras e custo por compra no nível da campanha. Divida valor por compras. Compare com o preço do produto anunciado.

O que medir: ticket médio atribuído contra preço da oferta. Gatilho: ticket atribuído acima do preço da oferta somado ao complemento mais caro vendido junto indica crédito de venda de outro produto. Ticket dentro dessa faixa não absolve a campanha: concilie as compras atribuídas com as vendas do checkout por versão da oferta. A correção é criar conversão personalizada por valor ou por content_ids do produto e medir com ela por três dias antes de trocar a otimização.

Trocar o evento de otimização reinicia o aprendizado. Por isso a ordem importa: primeiro a conversão personalizada só como coluna de leitura, depois a conferência com o checkout, e só então a troca, de preferência no início da semana.

4. Mapeie quem envia o quê

Esta é a etapa que mais surpreende. Liste toda rota que pode enviar evento para o mesmo pixel. Comece pelo código da loja e pelo contêiner web do Google Tag Manager. Depois vêm cada contêiner de servidor, a integração nativa do checkout, a API de conversões hospedada pela Meta e qualquer fluxo de automação.

Na operação de infoproduto, encontramos dois contêineres de servidor apontando para o mesmo pixel. Um deles tinha uma única tag ativa com gatilho "sempre", disparando em todo evento que chegava, sem filtro de tipo, e com código de evento de teste esquecido em produção. Havia ainda a API hospedada pela Meta, ativa desde abril, que não aparecia em contêiner nenhum. Ninguém no time sabia de todas as rotas ao mesmo tempo.

O que medir: número de rotas por evento. Gatilho: mais de uma rota para o mesmo evento exige event_id idêntico em todas, ou uma delas desligada. A desduplicação funciona com quantas rotas forem, desde que todas gerem o mesmo event_id. Três rotas com três lógicas de identificador somam.

5. Teste o cookie no Safari

Abra a loja no Safari, aceite os cookies e vá em Desenvolver, Mostrar Inspetor Web, aba Armazenamento, Cookies. Procure _fbp, _fbc e _gcl_aw e anote a data de expiração.

O que medir: validade dos cookies de clique. Gatilho: expiração em sete dias ou menos em cookie que deveria durar 90 dias indica CNAME para terceiro. A correção está no DNS e na hospedagem do servidor.

6. Feche a semana com uma linha de conciliação

Crie uma planilha simples, uma linha por semana: pedidos pagos na loja, receita paga, compras e receita de cada plataforma, e a razão entre elas. Não precisa de painel. Precisa de alguém que olhe toda segunda-feira.

O que medir: a soma das receitas atribuídas pelas plataformas contra a receita paga da loja. Gatilho: soma acima de 1,5x a receita da loja indica sobreposição de crédito entre plataformas, que nenhuma correção de tracking elimina, porque cada plataforma atribui pelo seu modelo. Esse número é o que entra no cálculo de margem descrito em ROAS de plataforma versus unit economics.

O que a auditoria não resolve

O primeiro limite: conciliar pixel com loja corrige contagem, não atribuição. Depois da auditoria, a Meta e o Google continuam reivindicando crédito pela mesma venda quando o cliente passou pelos dois. Cada uma segue o próprio modelo de atribuição, e os dois não conversam. A soma das plataformas vai passar da loja em operação que roda os dois canais com força.

O segundo limite: em operação com volume baixo, a auditoria inteira pode virar distração. Um e-commerce com 30 pedidos por mês ganha mais revisando o carrinho do que revisando o servidor. A LR Joias é a lembrança que usamos internamente. Chegou à Moyker em fevereiro de 2023 faturando R$ 1.500 por mês e, em maio, estava em R$ 157 mil por mês. Parte do salto veio do funil: o gargalo estava na passagem do produto para o carrinho, e trocar o tipo de carrinho na Nuvemshop triplicou a taxa de conversão. Nenhuma camada de rastreamento teria mudado aquele resultado.

O terceiro limite é sobre número grande. Na Shop.com, o ROAS da Meta em produtos ficou entre 55x e 73x de forma consistente. Número nessa faixa pode estar certo. Ele só vira decisão de verba depois de passar pela conciliação com o pedido pago. Quanto maior o ROAS reportado, maior o custo de ele estar errado.

A pergunta que fica

Volte ao último aumento de verba que você aprovou. Qual número autorizou a decisão: o ROAS que a plataforma mostrou, ou a receita paga que entrou na conta da loja naquela semana?

Se a razão entre compras do pixel e pedidos pagos ficar perto de 1, a contagem está certa, mas o crédito por campanha ainda não foi conferido. Se ficar perto de 2, você já sabe qual causa procurar primeiro.

Quantas das suas campanhas campeãs continuariam campeãs se o crédito viesse só da venda paga?