Se você rodou pixel e API de Conversões ao mesmo tempo e viu suas conversões praticamente dobrarem de um dia para o outro, você não melhorou nada. Você está contando a mesma venda duas vezes.

Esse texto é sobre a parte que a documentação da Meta descreve em dois parágrafos e que na prática é onde quase toda implementação quebra: a deduplicação.

Por que a CAPI existe

O pixel do Facebook roda no navegador do visitante. Ele carrega junto com a página, monta o evento ali e manda direto do dispositivo da pessoa para a Meta.

Esse caminho tem três buracos conhecidos. Bloqueadores de anúncio derrubam a requisição antes dela sair. O Safari limita a duração dos cookies criados por JavaScript, então quem volta depois de uma semana chega como visitante novo. E extensões de privacidade cortam chamadas para domínios de rastreamento conhecidos.

A API de Conversões resolve isso mudando quem fala com a Meta. Em vez do navegador, é o seu servidor que envia o evento. Servidor não tem bloqueador instalado. O consentimento do visitante é uma frente à parte, que afeta tanto o pixel quanto o que o servidor pode enviar, e o guia sobre banner de cookies integrado ao GA4 e à Meta cobre essa parte.

Diagrama: o evento do pixel e o evento da CAPI usam o mesmo event_id, então a Meta casa os dois e conta uma única conversão.
É o event_id que junta os dois. Sem ele, a Meta enxerga duas compras onde houve uma.

O erro conceitual mais comum

Muita gente instala a CAPI achando que ela substitui o pixel. Não substitui, e a própria Meta recomenda os dois juntos.

O motivo é que cada lado enxerga uma coisa. O navegador tem o fbp, tem o fbc quando a pessoa chegou por anúncio, tem o comportamento na página. O servidor tem o dado da transação confirmada, o e-mail real do comprador, o valor que o gateway aprovou.

Rodar só um dos dois é abrir mão de metade da informação. Rodar os dois sem deduplicação é pior ainda, porque aí você não perde dado, você inventa dado.

Como a Meta deduplica

A Meta olha dois campos: event_name e event_id.

Se o evento que chegou pelo navegador e o que chegou pelo servidor tiverem o mesmo event_name e o mesmo event_id, ela entende que é o mesmo acontecimento e conta uma vez. A janela é de aproximadamente 48 horas.

O event_name quase nunca é o problema, porque os dois lados mandam Purchase. O problema é sempre o event_id.

O erro que quebra tudo

O event_id precisa ser o mesmo valor exato dos dois lados. Isso parece óbvio até você ver como as implementações erram.

O padrão errado mais comum é gerar o ID em cada lado de forma independente:

// no navegador
event_id: crypto.randomUUID()

// no servidor
event_id: crypto.randomUUID()   // valor diferente, dedup não acontece

Dois UUIDs válidos, dois eventos válidos, zero deduplicação. A Meta recebe duas compras.

O padrão correto é gerar uma vez e propagar:

// gera UMA vez, no momento do evento
const eventId = crypto.randomUUID();

// vai para o pixel
fbq('track', 'Purchase', { value: 297.00, currency: 'BRL' }, { eventID: eventId });

// e o MESMO valor viaja para o servidor
// (no dataLayer, no payload do checkout, ou persistido junto do pedido)

Repare no detalhe que consome tarde da noite: no pixel do navegador o campo se chama eventID, com I e D maiúsculos. Na API de Conversões ele se chama event_id, minúsculo com underscore. Escrever event_id no lado do navegador não gera erro, não aparece aviso, e simplesmente não deduplica.

Onde o ID costuma se perder

Nos casos reais que passam por aqui, o event_id se perde em três lugares.

Entre a página de checkout e o webhook do gateway. A pessoa compra, o gateway confirma minutos depois por webhook, e nesse momento ninguém lembra qual ID foi usado no navegador. Se o ID não foi salvo junto do pedido, ele não existe mais. A correção é persistir o event_id no momento do begin_checkout e recuperá-lo quando o webhook chegar.

Em redirecionamento entre domínios. Checkout de Hotmart, Kiwify ou Eduzz costuma acontecer fora do seu domínio. O que estava na memória da página anterior morreu ali.

Em disparo duplicado do próprio pixel. Página de obrigado que recarrega, ou tag configurada em dois gatilhos, gera dois eventos de navegador com IDs diferentes. Aí nem a deduplicação com o servidor salva, porque o problema está antes.

Como conferir que está funcionando

Não confie no modo de visualização. Ele prova que a tag disparou, não que o evento chegou íntegro do outro lado.

O teste que vale é uma compra real, com cartão real, e depois:

  1. Abra o Gerenciador de Eventos da Meta e vá no evento de Purchase.
  2. Confira a origem. Deve aparecer navegador e servidor no mesmo evento, não duas linhas separadas.
  3. Procure a indicação de eventos deduplicados. Se a Meta estiver deduplicando, ela informa quantos eventos redundantes foram descartados.
  4. Compare o total de Purchase do dia com o número de vendas aprovadas no seu gateway. Se estiver perto do dobro, a deduplicação não está acontecendo.

O passo 4 é o que mais gente pula e é o único que não mente.

Ilustração da tela de origem do evento, mostrando a mesma compra recebida do navegador e do servidor, e uma terceira linha sem event_id.
A terceira linha é o que a Meta enxerga quando falta o event_id: uma compra a mais que nunca existiu.

O outro número: EMQ

Deduplicação resolve contagem. Ela não resolve correspondência.

A Qualidade da Correspondência de Eventos, o EMQ, é uma nota de 0 a 10 que mede o quanto de informação identificável você manda junto do evento. Nota baixa significa que a Meta recebeu a conversão mas não conseguiu ligar aquilo a uma pessoa, então a atribuição piora mesmo com o evento chegando.

O que move essa nota, em ordem de impacto: e-mail e telefone com hash, external_id estável, fbp e fbc, e os campos de endereço quando você os tem. Enviar pelo servidor ajuda justamente porque é lá que o dado confirmado do comprador existe.

Vale mais subir o EMQ de 4 para 8 do que adicionar mais um evento no funil.

Para fazer essa leitura sem tratar a nota como um boletim geral da conta, veja o guia do Gerenciador de Eventos e qualidade da correspondência, com parâmetros, roteiro de diagnóstico e um antes e depois real do mesmo conjunto de dados.

O que fazer na ordem certa

  1. Confirme que existe problema. Compare Purchase no Gerenciador de Eventos com as vendas aprovadas no gateway, no mesmo período.
  2. Coloque o container server-side de pé antes de mexer em tag de plataforma. Se ainda não tem um, o guia da Stape cobre a parte de hospedagem e os custos.
  3. Gere o event_id uma vez, propague para os dois lados e persista junto do pedido.
  4. Só então ligue a CAPI, e confira eventID no navegador contra event_id no servidor.
  5. Valide com transação real e compare os totais de novo.
  6. Depois de contar certo, trabalhe o EMQ.

Inverter os passos 3 e 4 é o motivo mais comum de alguém ter CAPI ligada e ainda assim não confiar no próprio número.

Em checkout com ofertas adicionais, a contagem exige outro corte: veja como separar compra duplicada, order bump e upsell no Meta sem deduplicar transações legítimas.