Deduplicação de eventos: como evitar contar a mesma conversão duas vezes (Pixel + CAPI)

Se você mede conversões no Meta Ads (ou em qualquer plataforma que aceite eventos de servidor), muito provavelmente está enviando o mesmo Purchase duas vezes: uma pelo navegador, via Pixel, e outra pelo servidor, via Conversions API (CAPI). Isso não é um erro de implementação — é a arquitetura recomendada. O problema aparece quando essas duas cópias não são reconhecidas como o mesmo evento. Aí a plataforma conta duas conversões onde houve uma, o ROAS aparente infla, o CPA despenca artificialmente e o algoritmo de otimização começa a aprender com números que não existem.

Este artigo destrincha o mecanismo de deduplicação: por que o envio duplo é necessário, qual é a chave que amarra as duas cópias, como o Meta realmente decide que dois eventos são o mesmo, e os modos de falha silenciosa que fazem a dedup parar de funcionar sem que ninguém perceba.

Por que você envia o mesmo evento duas vezes

Antes de resolver a duplicação, vale entender por que ela é intencional. Pixel e CAPI cobrem lacunas diferentes.

O Pixel roda no navegador. Ele captura o contexto rico do lado do cliente — cookies de primeira parte, parâmetros de URL, fbp, fbc — no exato momento da ação. Mas está à mercê do ambiente: bloqueadores de anúncio, restrições de cookies de terceiros, ITP do Safari, falhas de rede no meio do carregamento e usuários que fecham a aba antes do disparo. Uma fatia real de conversões simplesmente nunca chega quando você depende só do browser.

A Conversions API roda no seu servidor. Ela dispara o evento a partir do backend, onde a conversão realmente se confirma (o pedido foi pago, o webhook do gateway chegou, o CRM marcou o lead como ganho). É imune a ad blocker e a limitações do navegador, e você controla exatamente quando o evento sai. Em troca, ela costuma ter menos sinais de browser se você não os propagar com cuidado.

A recomendação oficial do Meta é redundância proposital: envie os dois. O Pixel garante o contexto do cliente e a cobertura de eventos de navegação; a CAPI garante a entrega das conversões que importam. Juntos, elevam a cobertura e a qualidade do sinal. Mas redundância proposital exige deduplicação proposital — senão você troca cobertura por inflação.

O problema da contagem dupla, na prática

Imagine uma loja com 100 compras reais no dia. O Pixel entrega 78 (perdeu 22 por bloqueio e abandono de aba). A CAPI entrega 100 (dispara no servidor, no confirmado). Sem deduplicação, a plataforma soma tudo: 178 "conversões". Seu painel mostra 78% a mais de compras do que aconteceram.

O estrago não é cosmético. O lance automático (Advantage+, tCPA, tROAS) otimiza para o sinal que recebe. Se o sinal diz que cada real gasto rende 1,78x mais conversão do que na realidade, o algoritmo vai escalar campanhas que parecem lucrativas e não são, redistribuir orçamento com base em ruído e aprender padrões falsos de público. Pior: a duplicação raramente é uniforme entre campanhas, então ela distorce a comparação relativa — a campanha que deveria receber corte recebe reforço. Sinal duplicado é pior que sinal ausente, porque parece confiável.

A chave da deduplicação: <code>event_id</code>

O mecanismo central é simples de enunciar e fácil de errar: cada evento de conversão real recebe um identificador único, e as duas cópias (Pixel e CAPI) carregam esse mesmo identificador. No vocabulário do Meta, esse campo é o event_id.

No Pixel, ele viaja no terceiro argumento do disparo:

``javascript fbq('track', 'Purchase', { value: 199.90, currency: 'BRL' }, { eventID: 'order_10432' // note o "ID" maiúsculo no Pixel }); ``

Na Conversions API, o mesmo valor vai no campo event_id do payload do servidor:

``json { "event_name": "Purchase", "event_time": 1734100800, "event_id": "order_10432", "action_source": "website", "user_data": { "em": ["<hash-sha256>"] }, "custom_data": { "value": 199.90, "currency": "BRL" } } ``

Quando o Meta recebe duas ocorrências com o mesmo event_id e o mesmo event_name, dentro de uma janela de tempo, ele mantém apenas uma e descarta a outra. As duas cópias colapsam em um único evento canônico.

O valor do event_id precisa ser estável e determinístico por conversão. O padrão mais robusto é derivá-lo de algo que já é único no seu domínio: o ID do pedido, o ID da transação do gateway, o ID do lead no CRM. Evite gerar o event_id com um número aleatório no navegador e outro no servidor — se cada lado inventa o seu, eles nunca vão bater, e a dedup não acontece. A regra de ouro: o event_id nasce de um identificador de negócio que ambos os lados conseguem enxergar.

<code>event_name</code>, <code>event_time</code> e a janela de deduplicação

O event_id não trabalha sozinho. O Meta usa a combinação de event_id mais event_name para casar as cópias. Duas consequências práticas:

Primeiro, o nome do evento tem que ser idêntico dos dois lados. Um Pixel que dispara Purchase e uma CAPI que dispara purchase ou CompletePurchase não deduplicam — para o Meta, são eventos diferentes que por acaso compartilham um ID. Padronize os nomes de evento em uma única fonte de verdade e não deixe cada integração escolher o seu.

Segundo, existe uma janela de deduplicação. O Meta reconcilia cópias que chegam com alguma distância no tempo — o Pixel dispara na hora, a CAPI pode chegar segundos ou minutos depois, dependendo do seu pipeline. A janela existe justamente porque as duas entregas quase nunca são simultâneas. Mas ela não é infinita. Se a cópia de servidor atrasa demais — porque ficou presa numa fila, num retry ou num job noturno — ela pode cair fora da janela e ser contada como um evento novo. O event_time de cada cópia deve refletir o momento real da conversão, e não o momento em que seu backend finalmente conseguiu despachar. Mandar event_time muito divergente entre as duas cópias é um dos jeitos mais comuns de a dedup falhar sem erro aparente.

<code>fbp</code>, <code>fbc</code> e por que eles importam aqui

Mesmo com a dedup por event_id funcionando, você quer que as duas cópias sejam o mais parecidas possível na identificação do usuário — porque isso melhora tanto o casamento quanto a atribuição. Os dois parâmetros centrais são cookies de primeira parte que o próprio Pixel cria:

• fbp (_fbp): o cookie de browser do Meta, que identifica o navegador de forma persistente.
• fbc (_fbc): derivado do parâmetro fbclid que o Meta anexa à URL quando o usuário chega de um anúncio; é o elo direto entre o clique no anúncio e a conversão.

O Pixel envia fbp/fbc naturalmente. A CAPI, rodando no servidor, não os tem a menos que você os capture e propague. Na prática: leia os cookies _fbp e _fbc no momento da ação do usuário, guarde-os junto com o pedido, e inclua-os no user_data do evento de servidor. Uma cópia de CAPI sem fbc perde justamente o sinal que liga a conversão ao clique pago — ela até deduplica, mas com qualidade de correspondência menor. Deduplicar bem e casar bem são objetivos complementares: o event_id evita a contagem dupla; fbp/fbc e os dados hasheados de usuário elevam a taxa de correspondência do evento que sobrevive.

Como o Meta deduplica, resumido

Juntando as peças, o algoritmo de reconciliação do lado da plataforma segue esta lógica:

1. Chega um evento (do Pixel ou da CAPI).
2. O Meta procura, dentro da janela de deduplicação, outro evento com o mesmo event_id e o mesmo event_name.
3. Se encontra, trata as duas ocorrências como uma só e mantém um evento canônico — normalmente priorizando o que traz mais sinal e preservando os dados de ambos quando possível.
4. Se não encontra correspondência dentro da janela, o evento é contado como único.

Há também um caminho secundário: quando o event_id está ausente, o Meta tenta deduplicar por heurística — combinando fbp, event_name e proximidade temporal. Essa via é frágil e você não deve depender dela. É um paraquedas, não a estratégia. A estratégia é event_id explícito, idêntico, presente nos dois lados.

Modos de falha silenciosa

O que torna a deduplicação traiçoeira é que ela falha sem gerar erro. Nenhuma requisição retorna 500; o painel só mostra números "bons demais". Os modos de falha mais comuns:

• event_id ausente no servidor. A implementação do Pixel manda eventID, mas o time de backend que escreveu a integração da CAPI esqueceu do campo. Cada compra vira duas. É o erro número um.
• IDs gerados de forma independente. Cada lado cria seu próprio identificador (um uuid no browser, outro no servidor). Nunca batem. Efeito idêntico ao anterior.
• event_name divergente. Purchase de um lado, purchase ou um nome customizado do outro. Case-sensitive; não casa.
• event_time muito distante. A cópia de servidor sai de um job atrasado e cai fora da janela. Deduplica às vezes, outras não — o pior cenário, porque a inflação é intermitente e difícil de diagnosticar.
• Disparo em página de "obrigado" recarregável. Se o Pixel de Purchase mora numa página que o usuário pode recarregar (F5) ou revisitar, e o event_id é regenerado a cada carregamento, você multiplica a conversão pelo número de refreshes. O event_id tem que ser preso ao pedido, não à visita à página.
• Múltiplas fontes de verdade. Pixel, CAPI, um GTM server-side e um plugin de e-commerce, todos disparando Purchase com regras próprias de ID. Quatro cópias, dedup parcial, caos.

O denominador comum de quase todos esses casos é o mesmo: não existe um único ponto que decide "esta conversão é real, este é o seu event_id canônico, e é assim que ela sai para todos os destinos".

Onde uma camada de consolidação resolve

O jeito estruturalmente correto de acabar com a contagem dupla é parar de tratar Pixel e CAPI como duas integrações que precisam se coordenar por convenção e passar a tratá-las como duas saídas de uma mesma fonte de verdade. Uma camada de consolidação de dados fica entre suas plataformas de origem (checkout, gateway, CRM) e os destinos de mídia, e faz três coisas que a coordenação manual não garante:

Ela decide quando a conversão é real — dispara no evento confirmado (pagamento aprovado, webhook do gateway recebido, lead marcado como ganho), e não em toda navegação otimista até uma página de obrigado. Ela gera um event_id canônico único derivado do identificador de negócio da transação, e usa exatamente esse mesmo ID em toda cópia que sai, para todo destino. E ela normaliza event_name, event_time e os dados de usuário de forma consistente entre as saídas, eliminando a divergência de nome e de tempo que quebra a janela de dedup.

O resultado é que a duplicação deixa de ser um problema a ser corrigido caso a caso e passa a ser impossível por construção: uma conversão real, um evento canônico, um event_id, entregue pelos caminhos que precisar. A deduplicação do lado do Meta continua acontecendo — mas agora ela recebe cópias que sempre casam, porque nasceram do mesmo lugar. Se você quer se aprofundar em como esse rigor se estende para além da dedup, vale ler nosso guia sobre qualidade de dados de conversão, que trata dos outros eixos — completude, frescor e correspondência — que decidem se o algoritmo de lance vai aprender com a verdade ou com ruído.

Checklist prático

Para auditar sua deduplicação hoje:

1. Confirme que todo disparo de Purchase (e demais conversões) carrega um event_id/eventID — no Pixel e na CAPI.
2. Garanta que esse ID é o mesmo dos dois lados e que deriva de um identificador de negócio (ID do pedido/transação), não de aleatório por sessão.
3. Padronize os event_name numa única fonte; verifique caixa e grafia idênticas.
4. Faça a CAPI mandar event_time do momento real da conversão e propague fbp/fbc capturados no cliente.
5. Prenda o event_id ao pedido, não à página — recarregar a tela de obrigado não pode gerar ID novo.
6. Use a ferramenta de teste de eventos do Meta e o campo de "eventos deduplicados" do Events Manager para confirmar que as cópias estão colapsando, e não somando.

Deduplicação bem-feita não aparece no painel como um número bonito — ela aparece como um número honesto. E é do número honesto que o algoritmo precisa para otimizar de verdade.