Pixel da Meta vs Conversions API não coincidem? (2026)

Cerca de 65 por cento dos anunciantes da Meta que reportam conversões contadas duas vezes ou ausentes em 2026 perdem a medição num único ponto localizável — normalmente uma chave de deduplicação quebrada, não uma falha de toda a pilha — e contudo a maioria responde desativando uma fonte, o que deita fora a cobertura em vez de corrigir a causa. A Meta é explícita: deve executar ao mesmo tempo o Pixel do navegador e a Conversions API; a correção nunca é desligar uma por reflexo, é encontrar o único ponto onde os dois eventos deixam de coincidir.

Este guia avança a partir do evento por cinco pontos de falha — o event_id, o event_name, a Event Match Quality, a configuração do lado do servidor, e as marcas temporais e moedas — para que dedique o seu tempo à causa, não ao sintoma. Para verificar automaticamente a sua conta face às fugas de medição mais comuns, execute a nossa free 5-axis ad account audit.

Atualizado a 2026-05-10 com o comportamento atual da deduplicação do Events Manager, da Event Match Quality e do gateway da Conversions API observado em contas dos EUA, do Reino Unido e europeias.

TL;DR — porque os eventos do Pixel e da CAPI não coincidem :

Um único event_id partilhado por evento, passado ao Pixel e à CAPI — esta é a chave única sobre a qual a Meta deduplica. 2. event_name coincidente — Purchase no navegador deve igualar Purchase no servidor. 3. Executar ambas as fontes — redundância mais chave partilhada melhora a cobertura sem inflar os totais. 4. A Event Match Quality mede quão bem os seus parâmetros identificam uma pessoa — eleve-a a partir do servidor. 5. Um gateway ou parceiro pode reescrever o event_id — inspecione o caminho do servidor antes de confiar nos números.

Como devem o Pixel do navegador e a CAPI do servidor trabalhar juntos?

A relação entre as duas fontes é o alicerce, por isso compreenda-a antes de perseguir qualquer discrepância. O Pixel do navegador dispara a partir do dispositivo do visitante, enquanto a Conversions API envia os mesmos eventos a partir do seu servidor — e a Meta concebe-os para funcionarem juntos, não como alternativas.

Porquê ambos — O Pixel do navegador perde eventos por bloqueadores, prevenção de rastreio e pedidos de consentimento, enquanto a Conversions API do servidor pode perder eventos quando um parâmetro está ausente ou um pedido falha. Juntas, cada fonte cobre as lacunas da outra e o sinal combinado é mais completo e resiliente do que qualquer uma sozinha.

Redundante por desenho — A Meta recomenda enviar os mesmos eventos a partir das duas fontes ao mesmo tempo. É uma redundância deliberada, não um erro. O senão é que a redundância só funciona quando a Meta consegue reconhecer os dois relatos como um evento e fundi-los, que é o que a deduplicação faz.

A chave partilhada — O mecanismo que torna a redundância segura é um event_id partilhado. Quando o Pixel e a Conversions API enviam ambos o mesmo event_id, a Meta emparelha-os e conta uma conversão. Quebre essa chave e a redundância torna-se contagem dupla. Para ver como isto se compara com o modelo da Google, leia o nosso guia Meta CAPI versus Google Enhanced Conversions.

Porque é que a deduplicação por event_id falha?

A deduplicação é o ponto de falha mais comum porque depende de dois valores coincidirem exatamente através de dois caminhos de código independentes. Quando quebra, cada conversão pode ser contada duas vezes. Verifique três coisas.

event_id divergente — A Meta emparelha um evento do navegador e um evento do servidor quando partilham o mesmo event_id dentro de uma janela curta. Se o servidor gerar o seu próprio event_id em vez de reutilizar o que o Pixel criou, os dois parecem sem relação e ambos são contados. Gere o id uma vez e passe-o a ambos os lados.

event_name divergente — A deduplicação também exige o mesmo event_name em ambas as fontes. Um Purchase no navegador e um purchase ou um nome personalizado no servidor não emparelham. Mantenha os nomes de eventos padrão idênticos, carácter a carácter, entre Pixel e Conversions API.

Janela e ordem — Os dois eventos devem chegar suficientemente próximos no tempo para caírem dentro da janela de dedup, e um atraso longo do servidor pode afastar o par. Envie o evento do servidor com prontidão e mantenha marcas temporais honestas. Para a arquitetura mais profunda, veja a nossa comparação gateway versus GTM do lado do servidor.

Contagem dupla ou eventos ausentes — como distingui-los?

Os dois sintomas parecem opostos mas muitas vezes partilham uma causa raiz, e distingui-los aponta-o direto para a correção. Compare os totais da Meta com a verdade da sua loja ou CRM antes de julgar qualquer campanha.

Sinal de contagem dupla — Um total de Purchase no Events Manager perto do dobro do seu número real de encomendas quase sempre significa que a deduplicação está a falhar. Os eventos do navegador e do servidor aterram ambos mas a Meta não os emparelha, por isso uma venda é registada como duas.

Sinal de eventos ausentes — Um total abaixo das suas encomendas reais aponta para o outro lado: uma fonte está a perder eventos. O navegador pode estar bloqueado por bloqueadores ou consentimento, ou o servidor pode não disparar quando um parâmetro ou acionador está ausente. Aqui a correção é cobertura, não dedup.

A reconciliação — Extraia o seu número real de encomendas para uma janela limpa e compare-o com o total deduplicado. Um valor perto do dobro sinaliza uma quebra de dedup; um valor bem abaixo sinaliza eventos perdidos; um valor perto da verdade significa que a medição está saudável. Esta reconciliação é a forma mais rápida de saber que problema tem realmente.

Uma Event Match Quality fraca esconde as suas conversões?

Com a dedup compreendida, a Event Match Quality é o suspeito seguinte porque um emparelhamento fraco torna os eventos mais difíceis de atribuir e pode ler-se como ausente nos relatórios. A pontuação diz-lhe quão bem a Meta consegue ligar cada evento a uma pessoa.

Event Match Quality — É a classificação da Meta, de fraca a excelente, dos parâmetros de informação do cliente que envia. Não quebra a deduplicação por si só, mas uma pontuação baixa enfraquece a atribuição e a otimização, que é muitas vezes a razão pela qual as conversões parecem desaparecer dos relatórios.

Parâmetros de informação do cliente — Um emparelhamento forte usa email e telefone com hash, nome, cidade, distrito, código postal, país, o endereço IP e os identificadores do Facebook fbc e fbp. Normalize e aplique hash a estes valores corretamente; um parâmetro malformado ou sem hash é ignorado e baixa a sua pontuação.

Vantagem do servidor — A Conversions API pode acrescentar parâmetros que o navegador nunca vê, como um IP fiável ou dados de encomenda do seu backend. Enviar informação do cliente mais rica a partir do servidor é a forma mais direta de elevar a pontuação. O nosso guia sobre a discrepância de atribuição entre Meta e GA4 aborda como o emparelhamento alimenta os relatórios.

Está a usar os eventos de teste e o separador de diagnósticos?

Antes de confiar em qualquer número em direto, valide a correção com as próprias ferramentas da Meta. Duas funcionalidades do Events Manager confirmam em minutos o que de outra forma levaria dias de adivinhação.

Eventos de teste — Esta ferramenta permite-lhe disparar uma conversão real e observar a chegada em tempo real dos eventos do navegador e do servidor. É a verificação definitiva de que um event_id partilhado funciona, porque a Meta mostra se o par está deduplicado à medida que acontece.

Separador de diagnósticos — O separador de diagnósticos traz à superfície os problemas que a Meta deteta no seu dataset, de parâmetros ausentes e domínios não verificados a avisos de configuração. Leia-o antes e depois de cada alteração; um aviso eliminado prova que uma correção aterrou, e um novo sinaliza uma regressão.

Validação de ponta a ponta — Dispare uma compra pelo funil real, confirme que o event_id e o event_name coincidem, verifique a moeda e o valor, e observe o estado de deduplicação. Só depois de os eventos de teste mostrarem um par limpo e deduplicado deve confiar nos relatórios em direto. Esta única validação evita publicar uma correção que falha em silêncio na produção.

Que configuração do lado do servidor quebra a deduplicação?

Como envia os eventos do servidor molda se a dedup sobrevive, porque cada configuração trata o event_id de forma diferente. Há três caminhos comuns, e cada um tem o seu modo de falha característico.

Integração direta — O seu próprio servidor chama a Conversions API diretamente. Isto dá-lhe controlo total do event_id, mas um erro de código que regenera o id por pedido, ou envia eventos para um dataset diferente do Pixel, quebra a dedup em silêncio.

Conversions API Gateway — Um gateway alojado reencaminha os eventos por si. É rápido de implementar, mas um gateway que constrói o seu próprio event_id em vez de ler o que o Pixel definiu produzirá dois eventos não emparelhados. Confirme que o gateway preserva o event_id original.

Integração de parceiro — Uma plataforma ou aplicação envia os eventos em seu nome. Cómodo, mas tem o menor controlo: um parceiro pode usar um event_name diferente, um dataset separado ou o seu próprio esquema de event_id. Verifique que o parceiro partilha as chaves do Pixel. O nosso guia gateway versus GTM compara estes caminhos em profundidade.

Não desative uma fonte para parar a contagem dupla :

Desligar o Pixel ou a Conversions API para corrigir a contagem dupla parece óbvio, mas deita fora a cobertura que a Meta desenhou no duplo dispositivo — deixando-o cego ao que essa fonte captava de forma única. O navegador vê eventos que o servidor perde, e o servidor vê eventos que os bloqueadores escondem. Corrija o event_id partilhado para que a deduplicação funcione, depois mantenha ambas as fontes ativas para que a redundância proteja a sua medição em vez de a inflar.

Como alinhar as marcas temporais e as moedas?

O último ponto de falha são os dados dentro do evento, onde pequenas inconsistências quebram em silêncio o emparelhamento e distorcem o valor. Com chaves e configuração limpas, alinhe os detalhes e remeça uma alteração de cada vez.

Marcas temporais — Ambas as fontes devem reportar o evento suficientemente próximo no tempo para cair dentro da janela de dedup. Um servidor que agrupa eventos ou dispara horas depois pode afastar o par ao ponto de a Meta os contar separadamente. Envie o evento do servidor com prontidão e marque-o com a hora real do evento.

Moeda e valor — O Pixel e a Conversions API devem reportar o mesmo código de moeda e o mesmo valor para uma dada compra. Um servidor que envia uma moeda diferente ou um valor antes de impostos enquanto o navegador envia o valor com impostos enviesa o seu ROAS e pode confundir o emparelhamento.

Uma alteração de cada vez — Após cada correção, verifique de novo a coluna de deduplicação e reconcilie com o seu número real de encomendas, não depois de todas as alterações de uma vez, para saber que alavanca moveu o resultado. Dimensione os seus retornos antes de escalar com o nosso ROAS calculator, e para trazer à superfície automaticamente cada fuga de medição, execute o free 5-axis audit da SteerAds.

Sources

Fontes oficiais consultadas para este guia:

FAQ

Porque é que os meus eventos do Meta Pixel e da Conversions API não coincidem?

Uma discrepância quase sempre tem origem num de cinco pontos, e encontra-a avançando a partir do evento. Primeiro o event_id: se o Pixel do navegador e a CAPI do servidor não enviarem exatamente o mesmo event_id, a Meta não consegue emparelhá-los e conta ambos. Segundo o event_name: a deduplicação precisa de nomes idênticos como Purchase em ambos os lados. Terceiro a Event Match Quality: parâmetros de cliente fracos impedem a Meta de associar o evento a uma pessoa. Quarto a configuração do servidor: um gateway ou parceiro pode remover ou reescrever o event_id. Quinto, marcas temporais e moedas que divergem. Diagnostique nesta ordem e cerca de 70 por cento das discrepâncias resolvem-se depressa.

Vejo compras contadas duas vezes no Events Manager — o que verifico primeiro?

Abra o Events Manager e olhe primeiro para a coluna de deduplicação de eventos do seu evento Purchase, porque uma quebra de dedup é ao mesmo tempo a causa mais comum e a mais rápida de confirmar. Se os eventos do Pixel do navegador e da CAPI do servidor não forem emparelhados, o total quase duplica. Confirme que ambas as fontes enviam o mesmo event_id e o mesmo event_name, depois use os eventos de teste para disparar uma compra real e observar se a Meta marca o par como deduplicado. A maioria das duplicações resulta de um event_id ausente ou divergente, e esta única verificação resolve a maioria dos casos em menos de uma hora.

Pode um event_id quebrado inflar as minhas conversões?

Sim, e é a fuga de dedup mais comum. A Meta deduplica emparelhando o mesmo event_id e o mesmo event_name entre o Pixel do navegador e a Conversions API dentro de uma janela curta. Se o servidor gerar um novo event_id em vez de reutilizar o que o Pixel enviou, ou se um gateway o reescrever, os dois eventos parecem sem relação e ambos são contados. O sinal é um total de Purchase perto do dobro do seu número real de encomendas na loja ou CRM. Confirme que o event_id é criado uma só vez, partilhado entre cliente e servidor, e transmitido intacto por qualquer integração de parceiro.

O que é a Event Match Quality e porque importa?

A Event Match Quality é a pontuação da Meta, de fraca a excelente, sobre quão bem os parâmetros de informação do cliente que envia permitem à Meta associar um evento a uma pessoa. Parâmetros fortes — email com hash, telefone, nome, cidade, IP e os identificadores do clique do Facebook fbc e do navegador fbp — elevam a pontuação e melhoram a atribuição e a otimização. Uma pontuação baixa não quebra diretamente a deduplicação, mas enfraquece o emparelhamento e pode fazer os eventos parecerem ausentes nos relatórios. Envie tantos parâmetros normalizados e com hash quanto puder legitimamente, sobretudo a partir do servidor, onde a Conversions API acrescenta dados que o navegador não vê.

Como evito que os meus eventos do Meta Pixel e da CAPI sejam contados duas vezes?

Para a contagem dupla fazendo a deduplicação funcionar, não desligando uma fonte. Gere um único event_id por evento, passe-o ao Pixel do navegador e à Conversions API, e envie o mesmo event_name em ambos os lados. Confirme no Events Manager que a coluna de deduplicação mostra o par como deduplicado. Mantenha ambas as fontes ativas, porque o navegador captura o que o servidor perde e o servidor captura o que o navegador bloqueia. Verifique qualquer gateway ou configuração de parceiro que possa reescrever o event_id. Use os eventos de teste para validar uma conversão real de ponta a ponta antes de confiar nos números em direto.

Executar ao mesmo tempo o Pixel e a Conversions API é sempre melhor?

Sim, quando a deduplicação está bem configurada. A Meta recomenda enviar os eventos de forma redundante a partir do Pixel do navegador e da Conversions API, porque cada um cobre as lacunas do outro — os navegadores perdem eventos por bloqueadores, ITP e pedidos de consentimento, enquanto o servidor pode ser bloqueado por parâmetros ausentes ou indisponibilidade. Enviadas de forma redundante com um event_id partilhado, as duas fontes melhoram a cobertura e a resiliência sem inflar os totais, porque a Meta deduplica o par. Executar ambas é o padrão correto; o único requisito é que as chaves de dedup coincidam. Sem chaves coincidentes, a redundância transforma-se em contagem dupla.

Quão depressa posso corrigir uma discrepância entre Pixel e CAPI?

Os ganhos mais rápidos chegam num dia. Alinhar o event_id e o event_name entre ambas as fontes surte efeito de imediato e para a contagem dupla evidente na mesma tarde. Uma validação com eventos de teste confirma a correção em minutos depois de o código ser publicado. As melhorias de Event Match Quality precisam de alguns dias de dados frescos para registar uma pontuação mais alta. Uma alteração de configuração do servidor via gateway ou parceiro pode levar um dia a implementar e alguns dias a confirmar. Ordene o trabalho para que a correção de dedup instantânea vá primeiro enquanto as alterações mais lentas de emparelhamento e infraestrutura acumulam dados.