Compra duplicada no Pixel e na API de Conversões: como deduplicar

Publicado em 10 de outubro de 2026 pela equipe do UTM Builder, na Limner.

A Meta só junta o evento do Pixel com o da API de Conversões quando os dois chegam com o mesmo nome e o mesmo ID. No navegador vão event e eventID; no servidor, event_name e event_id. Se um lado manda ID diferente, ou nenhum, a compra entra duas vezes. No TikTok vale o mesmo, com event e event_id no Pixel e na API de Eventos.

Como a Meta deduplica

A documentação da Meta chama o método por ID de recomendado. As regras:

• O eventID do Pixel precisa ser igual ao event_id da API, e o nome do evento precisa ser o mesmo dos dois lados.
• A deduplicação vale para eventos que chegam em até 48 horas depois do primeiro com aquele ID, no mesmo pixel.
• Quando os dois eventos não diferem de forma relevante no conteúdo, a Meta em geral fica com o que chegou primeiro.
• O eventID deve ser único. O número do pedido serve bem, porque o navegador e o servidor conhecem o mesmo valor.

No Pixel, o ID vai no quarto argumento do fbq, separado dos dados da compra:

Na API de Conversões, o mesmo valor vai no evento do servidor:

O erro clássico é gerar um ID aleatório no navegador e outro no servidor. Os dois parecem certos e nunca batem.

O método por fbp e external_id

Existe um segundo método, que compara event_name com fbp e/ou external_id. A documentação lista as limitações: em geral só funciona quando o evento sai primeiro do navegador e depois do servidor; o evento de servidor não é descartado se não houve evento de navegador nas últimas 48 horas; e ele não deduplica quando há uma fonte só. Dois eventos seguidos de navegador com a mesma informação são mantidos, e o mesmo vale para dois de servidor. Use como reforço do ID.

De onde vem a duplicação no Brasil

• Integração nativa mais Gateway. A Central da Nuvemshop diz que a API de Conversões Gateway não é compatível com a integração nativa e que, com as duas ativas, os dados podem ser contaminados. Ela manda verificar no Gerenciador de Eventos se Gateway aparece como origem ativa e, se aparecer, desconectar.
• Eventos e conversões criados à mão. A mesma central avisa que conversões personalizadas e eventos manuais podem duplicar as conversões que a Nuvemshop já envia, e pede pelo menos 72 horas depois de excluir para a Meta sincronizar.
• Plataforma de checkout mais GTM. A Kiwify configura Pixel e API de Conversões por produto e diz passar um ID único em cada evento. Se você também dispara Purchase pelo GTM na sua página de obrigado, para o mesmo pixel, esse evento chega sem o ID da Kiwify e conta de novo.
• Uma integração nova em cima da antiga. Em abril de 2026 a Meta lançou uma configuração de um clique da API de Conversões para a web. O anúncio diz que, para quem já usa integração de parceiro ou configuração própria, nada muda, e não fala de deduplicação. Antes de ativar qualquer caminho novo, liste o que já manda eventos de servidor.

A regra que resolve quase todos os casos: uma fonte de navegador e uma de servidor por pixel, com o mesmo ID.

Como conferir no Gerenciador de Eventos

1. Na Visão geral do pixel, abra os detalhes do evento Purchase e vá à aba de deduplicação (Event Deduplication, na documentação em inglês).
2. Leia a taxa de eventos deduplicados por fonte. Taxa baixa gera aviso.
3. Leia o uso de chaves de deduplicação. Pouca sobreposição indica ID que não é único, ou ID enviado só por um lado.
4. Em Connection Method aparece o canal por onde cada evento chegou. Se aparece um canal que você não esperava, há uma integração esquecida.
5. Não use a contagem da Visão geral como número de vendas. A documentação diz que ela inclui eventos recebidos antes da deduplicação.
6. Para testar, use o Test Events (Gerenciador de Eventos, fontes de dados, seu pixel). O servidor manda o código de teste em test_event_code, que deve sair do envio em produção.