Deduplicação Meta Pixel + CAPI: Como Verificar se o event_id Está Funcionando

Para medir as conversões da Meta com precisão, você envia o mesmo evento tanto pelo Pixel (navegador) quanto pela Conversions API (CAPI / servidor) — essa é a configuração que a própria Meta recomenda. Se um dos lados falhar por causa de consentimento ou restrições do navegador, o outro ainda consegue capturar o evento, criando redundância. Mas quando esse "enviar dos dois lados" roda sem deduplicação, uma única conversão acaba sendo contada duas vezes. Um design pensado para redundância se transforma diretamente em números inflados.

Alguma dessas situações soa familiar?

• Desde que você adicionou o Pixel e o CAPI, as conversões estão mais altas do que a realidade
• No Events Manager, a mesma compra aparece como dois eventos — um do navegador, outro do servidor
• A receita total (value) está inflada além das vendas reais
• Você configurou a deduplicação, mas as duplicatas não desapareceram

Este guia organiza por que a deduplicação da Meta é necessária, sua condição (event_id mais nome do evento), e como verificar se ela está realmente funcionando entre o navegador e o servidor — de uma perspectiva prática e mão na massa.

Primeiro princípio: "enviar dos dois lados" e "contagem duplicada" estão a um fio de distância

Vamos começar pela premissa. A Meta recomenda rodar o Pixel e a Conversions API juntos para reduzir eventos perdidos. O lado do navegador é fácil de perder para proteções de rastreamento e bloqueadores de anúncios; o lado do servidor é praticamente imune a isso. Então você envia o mesmo evento pelos dois lados, na premissa de que a Meta vai mesclar a duplicata em um único evento (deduplicação).

Estado	O que acontece
Enviar apenas um lado	Eventos perdidos são prováveis (sem redundância)
Enviar dos dois lados + deduplicação ativa	Contado corretamente como um evento (recomendado)
Enviar dos dois lados + deduplicação inativa	O mesmo evento único é inflado para dois

Ou seja, o problema não é "enviar dos dois lados" — é se a deduplicação funciona depois que você enviou dos dois lados. O que você precisa verificar não é "foi enviado" e sim "a Meta mesclou em um só."

A condição de deduplicação: mesmo event_id + mesmo nome de evento

A condição para a Meta tratar um evento do navegador e um evento do servidor como "o mesmo" é simples.

• event_id coincidindo … para uma única conversão, passe o mesmo valor exato do navegador e do servidor
• event_name coincidindo … use o mesmo nome de evento nos dois lados, como Purchase ou Lead

Só quando esses dois itens se alinham a Meta decide "isso é a mesma ocorrência chegando tanto do navegador quanto do servidor" e mescla em um só. O fbp (ID do navegador, o valor do cookie _fbp) também é usado como sinal de apoio, mas o eixo central é sempre a coincidência entre event_id e nome do evento.

Erro comum: fazer o nome do evento coincidir mas anexar o event_id a apenas um dos lados. Nesse caso, é tratado como "mesmo nome, mas ocorrência diferente," e dois eventos sobrevivem sem serem deduplicados. Por outro lado, mesmo que você alinhe o event_id, uma divergência no nome do evento como Purchase vs. purchase também faz com que sejam contados como coisas separadas (guia de rastreamento de conversão da Meta).

A janela de 48 horas para deduplicação

A Meta não guarda eventos indefinidamente para fazer a correspondência. Quando um evento do navegador e um evento do servidor compartilham o mesmo event_id e nome de evento, a Meta só vai mesclá-los se ambos chegarem dentro de 48 horas um do outro. Depois que essa janela se fecha, mesmo uma correspondência perfeita de event_id é ignorada — os dois eventos são contados separadamente.

Na prática, isso raramente causa problemas, porque o Pixel dispara instantaneamente e o CAPI normalmente segue em segundos ou minutos. Mas se o seu pipeline do lado do servidor tiver um atraso longo — jobs em lote que rodam durante a madrugada, filas que se acumulam nos fins de semana, ou lógica de retry que segura eventos que falharam — o evento do CAPI pode cair fora da janela de 48 horas e a deduplicação para de funcionar silenciosamente.

Dica: se você processa conversões em lote, mantenha o atraso bem abaixo de 48 horas. Envio em tempo real ou quase em tempo real a partir do servidor é a abordagem mais segura.

Como verificar: o event_id do navegador e do servidor coincidem?

Verificar se a deduplicação está funcionando se resume a comparar o event_id nos dois lados e confirmar que é o mesmo valor. Passo a passo.

1. Leia o event_id do lado do navegador

Abra a aba "Network" (Rede) do DevTools do seu navegador e filtre por facebook.com/tr. Execute a ação de conversão alvo uma vez, e verifique o parâmetro eid (= event_id) na requisição que dispara. O eventID de fbq('track', 'Purchase', {...}, {eventID: '...'}) viaja aqui.

2. Leia o event_id do lado do servidor

No lado do CAPI, confirme que o payload que o seu servidor envia para a Meta (data[].event_id) contém o mesmo valor. Usando seus logs de implementação ou código de teste de eventos, compare com o valor exato que você confirmou no navegador.

3. Reconcilie em "Test Events" no Events Manager

Abra o Events Manager → seu dataset → Test Events, e gere uma conversão no site. Dois eventos devem chegar — um do navegador, um do servidor. Se a Meta mesclá-los em um só como "deduplicated" (deduplicado), isso vai aparecer indicado. Se os dois permanecerem listados separadamente, a deduplicação não está funcionando.

Erro comum: o Test Events só mostra "este momento, no seu ambiente." Mesmo que esteja alinhado na sua máquina, se o ponto onde você gera o event_id dinamicamente em produção sair de sincronia, as duplicatas aparecem apenas no caminho dos visitantes reais. Não se acomode com um único padrão testado na sua própria máquina.

Lendo as taxas de deduplicação no Events Manager

O Test Events mostra um único instantâneo, mas o Events Manager também fornece métricas agregadas de deduplicação para monitoramento contínuo. Para encontrá-las:

1. Abra o Events Manager e selecione seu dataset (pixel).
2. Clique em um nome de evento específico — por exemplo, Purchase.
3. Na visão detalhada, compare a contagem de Received (total de eventos brutos de todas as fontes) com a contagem de Deduplicated (eventos reconhecidos como duplicatas e mesclados).

A diferença entre esses dois números é a deduplicação que realmente aconteceu. Uma configuração saudável com duas fontes (Pixel + CAPI disparando de forma confiável) geralmente mostra uma taxa de deduplicação de aproximadamente 40–70% para um determinado evento. O que os números indicam:

Taxa de dedup	Significado provável
40–70%	Saudável — ambas as fontes estão disparando e a Meta está mesclando
Perto de 0%	O event_id não está sendo passado ou não está coincidindo
Perto de 100%	Incomum — possivelmente uma fonte não está chegando à Meta de forma alguma

Observação: as taxas de deduplicação na aba Overview não são em tempo real. Aguarde pelo menos 48–72 horas de tráfego real antes de tirar conclusões, especialmente logo após um deploy.

Motivos comuns pelos quais a deduplicação não funciona

Você adicionou o event_id mas as duplicatas não desaparecem — aqui estão os padrões típicos.

1. O event_id difere entre os dois lados

A causa mais comum. Se o navegador e o servidor geram o event_id de forma independente, os valores não vão coincidir e serão tratados como coisas diferentes. O event_id precisa de um mecanismo que sempre produza o mesmo valor nos dois lados — passe o valor gerado no lado do navegador para o servidor, ou derive o mesmo valor a partir de uma lógica compartilhada.

2. O event_id existe apenas em um dos lados

Você passa o eventID para o Pixel mas não inclui o event_id no CAPI (ou vice-versa). Sem nada em um dos lados, não há nada para reconciliar, e a deduplicação nunca acontece.

3. O nome do evento não coincide

Purchase vs. purchase, ou misturar um evento padrão com um evento personalizado — uma divergência no nome do evento também desativa a deduplicação. Use exatamente o mesmo nome nos dois lados.

4. fbp / fbc não estão sendo passados

Se o fbp (ID do navegador) ou fbc (ID de clique), usados para reconciliação de apoio, não forem passados para o lado do servidor, isso afeta a precisão da reconciliação e a qualidade da correspondência. A coincidência do event_id é o eixo principal, mas passar esses valores também é a configuração preferível.

Passando o event_id pelo GTM Server-Side

Se você usa o Google Tag Manager (GTM) Server-Side para sua implementação do CAPI, o fluxo para manter o event_id consistente nos dois lados normalmente se parece com isto:

1. Gere o event_id no cliente. No JavaScript do seu site (ou em uma tag GTM do lado do cliente), crie um ID único (um UUID ou ID de pedido) para cada conversão.
2. Passe-o para o Pixel. Inclua o ID como eventID na sua chamada fbq('track', ...).
3. Encaminhe-o para o container do servidor. Envie o mesmo ID como um parâmetro no seu evento GA4 (ou via uma variável personalizada de data layer) para que ele chegue ao container GTM do lado do servidor.
4. Mapeie na tag CAPI da Meta. Na configuração da sua tag Meta do lado do servidor, mapeie o parâmetro recebido para o campo event_id.

O ponto crítico: o cliente e o servidor precisam usar uma única fonte de verdade para o ID. Se o container do servidor gerar seu próprio ID em vez de ler o que o cliente enviou, os valores divergem e a deduplicação quebra. Para uma visão mais ampla sobre como verificar sua configuração de GTM server-side, veja verificação do GTM server-side.

O que a verificação na sua própria máquina não pode te dizer

Verificar uma vez, manualmente, na sua própria máquina tem duas limitações estruturais.

1. Seu ambiente não é o ambiente dos seus visitantes. Dependendo do estado de login, extensões e status de consentimento, o event_id pode parecer alinhado na sua máquina mas a deduplicação pode quebrar em condições reais de visitantes (apenas o lado do navegador cai quando o consentimento é negado, o timing de geração do event_id escorrega em uma fonte de tráfego específica, e assim por diante).
2. Conversões envolvendo clique em anúncio são difíceis de verificar. Para recriar corretamente "isso realmente é mesclado em um só via um anúncio," você precisaria clicar em um anúncio ao vivo e seguir o caminho — o que carrega o risco de uma violação da política de anúncios por autoclique.

Em outras palavras, confirmar que "o event_id está alinhado" na sua própria ação não é prova de que a deduplicação funciona no caminho real que seus visitantes percorrem.

Checklist de verificação

• O Pixel e o CAPI passam o mesmo event_id para a mesma conversão?
• O nome do evento (event_name) coincide exatamente nos dois lados (incluindo maiúsculas/minúsculas)?
• Você realmente reconciliou o eid do lado do navegador com o event_id do lado do servidor?
• Você confirmou o status "deduplicated" no Test Events?
• O event_id é único por conversão e idêntico nos dois lados?
• fbp / fbc também são passados para o lado do servidor?
• Além de um único padrão na sua máquina, está livre de duplicatas em condições reais de visitantes em produção?

Perguntas frequentes

P. Eu deveria instalar o Pixel e o CAPI desde o início? R. Sim — é a recomendação da própria Meta. Se um dos lados falhar por causa de consentimento ou restrições do navegador, o outro ainda consegue capturar o evento, criando redundância. Mas isso só é válido na premissa de que a deduplicação (event_id + nome do evento) está funcionando. Se não estiver, enviar dos dois lados vira contagem duplicada direta (os fundamentos da contagem duplicada).

P. Qual valor o event_id deve ter? R. Qualquer valor que identifique unicamente uma única conversão (um ID de pedido, por exemplo) funciona, desde que você use o mesmo nos dois lados: navegador e servidor. As duas coisas que importam: "único por conversão" e "idêntico nos dois lados." Não vai funcionar se um valor diferente for atribuído a cada vez, ou se um dos lados estiver vazio.

P. Fiz o nome do evento coincidir mas as duplicatas não desaparecem. R. Provavelmente o event_id não coincide nos dois lados. Verifique se o valor gerado no lado do navegador está realmente sendo passado para o servidor, e se uma geração independente fez os valores divergirem (verificando o CAPI).

P. Se o Test Events diz deduplicado, a produção também está bem? R. O Test Events é uma verificação do seu ambiente, naquele momento. Em produção, a atribuição e a correspondência do event_id podem quebrar dependendo do status de consentimento e da fonte de tráfego, e um único padrão na sua máquina pode não reproduzir isso. É necessária verificação em condições reais de visitantes.

P. Também quero saber como verificar o próprio Pixel. R. Verificar a instalação, o disparo e o recebimento do Pixel isoladamente é abordado em um artigo separado (verificando o Meta Pixel). A deduplicação deste artigo é o próximo estágio — fazer o Pixel e o CAPI coexistirem.

Conclusão: "enviar dos dois lados" só termina quando "mescla em um só"

Instalar tanto o Pixel quanto o CAPI é a recomendação da Meta e um design sólido para reduzir eventos perdidos. Mas isso depende da premissa de que a Meta os mescla em um só (deduplicação) através do mesmo event_id mais o mesmo nome de evento. Se a deduplicação não funcionar, um design pensado para redundância se torna a causa da contagem duplicada. Comece reconciliando o event_id nos dois lados, e confirme "deduplicated" no Test Events.

Ainda assim, uma única verificação na sua própria máquina não consegue capturar a deduplicação que quebra apenas no caminho dos visitantes reais. A ConversionOK executa sua página ao vivo em um navegador independente e isolado e intercepta os eventos de Pixel e CAPI realmente enviados (e se o event_id deles coincide), então os verifica — sem necessidade de clicar no seu próprio anúncio e sem interferência do seu ambiente de escritório. Comece com uma verificação estática gratuita para confirmar o ponto de entrada da sua medição.