API de conversões ou pixel? Os dois, e o detalhe que quebra tudo
A pergunta "API de conversões ou pixel?" já parte de uma premissa errada. Os dois medem a mesma conversão por caminhos que falham em momentos diferentes. O que separa quem acerta de quem infla o próprio relatório é a deduplicação, e ela tem regras específicas que quase nenhum tutorial em português explica.
Por Fabiano de Medeiros · Fórmula Mídia · 3 de setembro de 2026
Em resumo: os dois, sempre que possível. O pixel mede pelo navegador e perde quem recusa consentimento ou usa bloqueador; a API mede pelo servidor e não enxerga o que acontece na tela. Rodando juntos, a Meta une os dois eventos, desde que ambos levem o event_id idêntico e o mesmo nome de evento, dentro de 48 horas. Sem isso, você conta a mesma venda duas vezes.
Por que "ou" é a pergunta errada
A dúvida aparece assim porque os dois medem a mesma coisa, uma conversão. Mas eles não são alternativas: são dois caminhos diferentes até a Meta, que falham em momentos diferentes.
O pixel roda no navegador de quem visita. A API de conversões roda no seu servidor. Quando o navegador é o problema, e em 2026 ele é, com frequência, quem salva é o servidor. Quando a implementação do servidor tem um bug, quem salva é o navegador.
Não é "qual dos dois". É "os dois estão mandando o mesmo evento com o mesmo identificador?", porque a resposta a essa é o que decide se o seu relatório está certo ou inflado.
O que cada um perde sozinho
| O pixel sozinho perde | A API sozinha perde | |
|---|---|---|
| Consentimento | Entre metade e dois terços dos visitantes recusam cookies em banners de consentimento. Sem consentimento, o pixel não dispara. | Nada, mas você continua obrigado a respeitar a recusa do lado do servidor. Ignorar isso é problema jurídico, não técnico. |
| Bloqueadores | Bloqueador de anúncio e navegadores com proteção antirrastreamento derrubam o disparo antes de sair. | Nada. É o principal motivo de existir. |
| Comportamento na tela | Nada, é justamente o que ele vê melhor. | O que acontece no navegador: rolagem, clique em elemento, microconversão, tempo de página. |
| Redundância | Se o pixel falha, não sobra nada. | Se o servidor falha ou a fila trava, não sobra nada. |
Somando: rodar um só significa aceitar um buraco conhecido. Rodar os dois fecha os dois buracos, e cria um terceiro problema, que é o assunto do resto deste artigo.
O preço de rodar os dois sem deduplicar
Se o pixel manda uma compra e a API manda a mesma compra, e a Meta não consegue perceber que são a mesma, ela conta duas.
O efeito imediato é cosmético e agradável: o ROAS no painel dobra. O efeito real é caro, e demora a aparecer. O algoritmo de otimização aprende com esses eventos, e passa a acreditar que certos públicos, criativos e horários convertem o dobro do que convertem. Ele então investe mais neles.
Não é só relatório errado. É aprendizado envenenado. Um relatório errado você corrige olhando o caixa; um algoritmo treinado em dado duplicado leva semanas para desaprender, e o custo disso já foi pago em mídia.
Como a deduplicação funciona de verdade
A regra é curta e específica. A Meta une um evento de navegador e um de servidor quando os dois têm:
- •o mesmo event_name, e ele é sensível a maiúscula: Purchase e purchase são eventos diferentes;
- •o mesmo event_id, a mesma sequência exata de caracteres, saída dos dois lados;
- •uma janela de até 48 horas entre um e outro.
De onde o event_id deve sair
O caminho seguro é gerar uma vez, usar duas: o servidor cria o identificador, o número do pedido costuma servir bem, e passa para o navegador, que o envia no pixel como eventID. O servidor manda o mesmo valor como event_id na API.
servidor gera: pedido_84213
│
├──▸ navegador fbq('track','Purchase',{...},{eventID:'pedido_84213'})
└──▸ servidor { event_name:'Purchase', event_id:'pedido_84213', … }
Meta recebe os dois, vê mesmo nome + mesmo id → conta 1O erro clássico é cada lado gerar o seu identificador. Os dois são válidos, os dois chegam, e nenhum casa com o outro.
O que NÃO deduplica, e é a confusão mais comum
O fbp (identificador de navegador) e o fbc (identificador de clique) servem para casar o evento com uma pessoa, não para impedir contagem dupla. Vale muito mandá-los junto no evento de servidor, porque melhoram a qualidade de correspondência, mas quem confia neles para deduplicar continua contando duas vezes.
Existe um mecanismo de reserva, em que a Meta tenta unir por nome do evento mais fbp ou identificador externo. Ele só funciona quando o evento do navegador chega primeiro, e é reconhecidamente menos confiável. Serve de rede de segurança, nunca de plano.
Os quatro erros que quebram sem dar erro
Nenhum destes gera mensagem de falha. O evento entra, a requisição responde sucesso, e a contagem sai errada.
- •Identificador gerado em dois lugares. Cada lado cria o seu. Nunca casam.
- •Formatação divergente. Um separador a mais, um prefixo em um lado só, espaço no fim. A comparação é literal.
- •Nome do evento com caixa diferente. O navegador manda Purchase, o servidor manda purchase. São dois eventos distintos para a Meta.
- •Envio do servidor fora da janela. Processo que roda de madrugada em lote manda o evento muito depois do navegador. Passou de 48 horas, não une mais.
Por serem silenciosos, esses erros costumam viver meses numa conta. A forma de descobrir é olhar o painel de eventos: se o mesmo evento aparece com contagem muito acima do que o seu sistema registra, é quase sempre isso.
EMQ: o placar que quase ninguém abre
A Meta calcula uma nota de qualidade de correspondência de evento. Ela é a medida mais direta de se a sua implementação está boa, e três coisas a determinam:
- •Normalizar antes de enviar: minúscula, sem espaço nas pontas, formato padronizado. Telefone com e sem código de país é a falha mais comum.
- •Aplicar hash correto nos dados pessoais. SHA-256, sobre o valor já normalizado. Hashear antes de normalizar gera hash diferente para a mesma pessoa.
- •Deduplicar com identificador compartilhado dentro da janela.
Vale abrir essa nota antes de mexer em criativo ou em público. Uma conta com correspondência baixa está tomando decisão sobre dado incompleto, e nenhuma otimização de mídia conserta isso.
Quando não vale a pena
A resposta honesta inclui o caso em que a resposta é "ainda não".
A API de conversões existe para alimentar um algoritmo de otimização. Algoritmo aprende com volume. Numa conta com pouquíssimas conversões por semana, montar o pipeline entrega uma engrenagem correta girando no vazio, e, pior, parece progresso enquanto o problema real continua sendo outro.
Primeiro garanta que existe volume de conversão sendo gerado. Depois implemente o retorno. Fazer o inverso é o erro mais caro em tempo, e é o que a maioria dos tutoriais ensina, porque tutorial não pergunta quanto você converte por semana.
É o mesmo raciocínio que aplicamos ao anúncio de clique para WhatsApp, onde o problema é ainda mais agudo, e onde, aliás, a deduplicação funciona de forma diferente: em eventos de mensageria a própria Meta avisa que não auxilia nesse controle, e o cuidado com reenvio passa a ser inteiramente seu.
Perguntas e respostas
Preciso mesmo dos dois, ou posso usar só a API de conversões?+
Dá para rodar só a API, e algumas operações fazem isso. Mas você perde o que só o navegador vê, o comportamento antes da conversão, e perde a redundância: quando o servidor falha, não sobra nada. O padrão recomendado é rodar os dois e deduplicar.
O que é o event_id e de onde ele deve sair?+
É um identificador único daquela conversão específica, gerado uma vez e usado nos dois lados. O caminho mais seguro é gerar no servidor, o número do pedido serve bem, e passar para o navegador, em vez de cada lado gerar o seu.
O fbp e o fbc servem para deduplicar?+
Não. A deduplicação olha para event_name e event_id. O fbp e o fbc servem para casar o evento com a pessoa e melhoram a qualidade de correspondência, mas não impedem contagem dupla. É a confusão mais comum sobre o assunto.
Qual a janela de tempo da deduplicação?+
A Meta casa eventos de navegador e servidor recebidos dentro de 48 horas um do outro. Na prática os dois devem sair quase juntos; a janela existe para tolerar atraso de fila, não para justificar envio no dia seguinte.
Por que meu evento aparece duplicado mesmo com event_id configurado?+
Os três motivos mais comuns: o identificador é gerado separadamente em cada lado e por isso nunca coincide; há diferença de formatação, como um separador a mais; ou o nome do evento difere em maiúscula. A Meta trata nome de evento como sensível a caixa, "purchase" e "Purchase" são eventos diferentes.
Isso vale para anúncio de clique para WhatsApp?+
Não da mesma forma. Em eventos de mensageria a própria documentação da Meta avisa que ela não auxilia na deduplicação, e o controle de reenvio é inteiramente seu. É um caso à parte, tratado em outro artigo nosso.
Se o número do painel não bate com o do seu sistema, quase sempre é deduplicação. Dá para verificar em minutos, e a correção costuma ser de uma linha.