Você configurou a Conversions API (CAPI) pensando: "agora sim vou recuperar o que o iOS e os bloqueadores de anúncios estavam derrubando" — mas você já confirmou de verdade se os eventos estão chegando à Meta a partir do seu servidor? Você pode acreditar que a CAPI está configurada, mas um token de acesso expirado ou um servidor que nunca dispara podem significar que nenhum evento sequer está chegando à Meta. Pior: como o pixel do navegador continua funcionando, pode parecer que "o rastreamento está tudo certo" — e esse é o caso mais difícil de pegar.
Algo disso soa familiar?
- No Gerenciador de Eventos, os eventos de servidor continuam "não recebidos", ou a contagem está suspeitosamente baixa
- O pixel do navegador aparece, mas você não encontra o evento do lado do servidor em lugar nenhum
- Você recebe um aviso de que o Event Match Quality está baixo, mas não sabe o motivo
- Desde que adicionou a CAPI, sua contagem de conversões parece ter dobrado
Este guia organiza como confirmar se a CAPI está realmente funcionando, por que eventos podem ser enviados pelo servidor e mesmo assim não serem aproveitados, e como pensar nisso sem ficar chutando.
Antes de verificar: a CAPI não substitui o pixel — ela complementa
Vamos alinhar a premissa primeiro. A CAPI não é um mecanismo que substitui o pixel do navegador (aquele que o fbevents.js envia para facebook.com/tr); ela envia eventos diretamente à Meta a partir do seu servidor para complementá-lo. O objetivo é preencher a parcela que o pixel do navegador perde por causa de ITP, bloqueadores de anúncios, perda de sinal no iOS, entre outros, através de envios do lado do servidor.
É exatamente por isso que o que você precisa verificar é diferente de uma configuração só com pixel. Separar esses três níveis torna o diagnóstico muito mais fácil.
| Nível | Significado | Armadilha comum |
|---|---|---|
| ① Envio do servidor | Seu servidor envia o evento para a API da Meta | Token expirado / servidor nunca dispara |
| ② Recebimento pela Meta | A Meta aceita o evento do servidor | Parâmetros faltando / destino errado (pixel ID) |
| ③ Correspondência e deduplicação | Cruza com o lado do navegador, vincula a uma pessoa, remove duplicatas | Divergência de event_id causa contagem duplicada, EMQ baixo |
O ponto principal: ① enviar e ③ corresponder são coisas diferentes. Mesmo que as requisições saiam do seu servidor, problemas na deduplicação com o lado do navegador ou na qualidade de correspondência podem significar que os eventos não estão em uma forma utilizável para otimização. A maioria das verificações para em ①.
Quando você roda a CAPI junto com o pixel do navegador, a Meta deduplica os dois eventos que compartilham o mesmo nome de evento e o mesmo
event_id. Umevent_idausente ou divergente causa contagem duplicada ou perda de eventos. Veja Verificando a deduplicação (event_id) para mais detalhes.
Passo 1: Veja o "método de conexão" no Gerenciador de Eventos
Primeiro, no Gerenciador de Eventos → seu conjunto de dados (pixel) → detalhes de cada evento, verifique de onde o evento está chegando.
- Cada evento mostra um método de conexão, como "Servidor", "Navegador" ou "Servidor e navegador"
- O evento que você está mirando (
Purchase,Lead, etc.) mostra Servidor? - O horário de recebimento do evento de servidor é recente (ou seja, não parou)?
O que isso mostra: se existe um histórico de eventos chegando pelo servidor (a verificação mais próxima de ① e ②). O que isso não mostra: se o código que você está configurando agora está enviando corretamente (o Passo 2 cobre isso).
Armadilha comum: presumir que "configurei a CAPI, então está funcionando". Não é raro que alguém apenas salve a tela de configurações enquanto o código do lado do servidor ou o conector nunca disparou uma única vez. Sempre olhe o registro real de eventos recebidos.
Passo 2: Test Events + test_event_code
O recurso oficial de Test Events da Meta (Gerenciador de Eventos → seu conjunto de dados → Test Events) mostra os eventos chegando em tempo real. Para a CAPI, o truque é anexar um test_event_code ao envio do seu servidor.
- Pegue o
test_event_codemostrado na tela de Test Events (uma string comoTEST12345) - Inclua esse
test_event_codeno payload do envio do seu servidor e envie um evento de teste - Em poucos segundos, ele deve aparecer no fluxo do Test Events como um evento Servidor
O que isso mostra: que o seu código de servidor, especificamente, consegue enviar um evento em um formato que a Meta recebe (a prova mais próxima de ③).
Armadilha comum: se dar por satisfeito só com uma ação no navegador. Um evento de navegador aparecendo no Test Events é prova de que o pixel está funcionando — não é prova de que a CAPI (o servidor) está. Sempre confirme que uma linha originada do servidor aparece.
Verifique as respostas da API no lado do servidor
Um detalhe que concorrentes costumam destacar e que é fácil de passar despercebido: seu servidor recebe uma resposta HTTP toda vez que chama a Conversions API da Meta. Registrar e verificar essas respostas é uma das formas mais rápidas de pegar problemas.
| Status HTTP | Significado | Ação |
|---|---|---|
| 200 | A Meta aceitou o evento | Confirme se a contagem de events_received no corpo da resposta bate com o que você enviou |
| 400 | Requisição inválida — payload malformado ou campos obrigatórios faltando | Leia a mensagem de erro; causas comuns são falta de event_time, action_source ou user_data com hash incorreto |
| 401 / 403 | Falha de autenticação ou permissão | Seu token de acesso expirou, foi revogado ou não tem o escopo necessário — gere um novo no Gerenciador de Eventos |
Se você não registra as respostas da API hoje, está voando às cegas. Uma taxa de erro acima de alguns pontos percentuais significa que eventos estão sendo descartados silenciosamente.
Dica: antes de colocar mudanças em produção, cole seu payload JSON no Payload Helper da Meta (dentro do Gerenciador de Eventos → Conversions API → Payload Helper). Ele valida campos obrigatórios, hashing correto e erros comuns — sem realmente enviar o evento para o seu pixel.
Passo 3: Navegador e servidor estão presentes — e deduplicados?
Quando você roda a CAPI junto com o pixel, o estado saudável é que ambos apareçam e depois sejam deduplicados. No Test Events, confirme o seguinte.
- Para a mesma conversão, você consegue ver tanto o evento de navegador quanto o de servidor?
- Os dois compartilham o mesmo nome de evento e o mesmo
event_id? - A Meta os reconhece como "deduplicados" e não conta em dobro?
O que isso mostra: não apenas que os eventos chegam, mas que estão sendo cruzados corretamente e a contagem duplicada está sendo evitada.
Armadilha comum: o navegador e o servidor constroem o
event_idde formas diferentes (só um lado o define, ou usam valores diferentes). Nesse caso, a Meta trata como eventos separados e suas conversões dobram. Alinhe a lógica de geração doevent_idnos dois envios.
Passo 4: Event Match Quality (EMQ) e parâmetros de dados do cliente
O valor da CAPI não é só "ela chega" — é o evento se vincular a uma pessoa. O que mostra isso é o Event Match Quality (EMQ).
- Nos detalhes de cada evento no Gerenciador de Eventos, verifique a pontuação de qualidade de correspondência e quais parâmetros de dados do cliente estão sendo enviados
- E-mail (
em), telefone (ph), nome (fn/ln), ID externo (external_id) e afins estão sendo enviados após passar por hash? - Quanto mais — e mais precisos — forem os parâmetros enviados, geralmente maior é a qualidade de correspondência
O que isso mostra: se os eventos que chegam se vinculam a uma pessoa na Meta de uma forma utilizável para otimização e atribuição.
Armadilha comum: tentar enviar informações pessoais como estão (em texto puro). Campos como
emephprecisam passar por hash (SHA-256). Enviar valores brutos faz com que a Meta não consiga tratá-los corretamente, e eles não vão corresponder. Sempre confirme que o hashing acontece no lado do servidor.
Não esqueça de fbp, fbc e sinais de dispositivo
Além dos campos de PII como e-mail e telefone, vários parâmetros que não são PII aumentam significativamente a qualidade de correspondência — e os guias dos concorrentes destacam isso consistentemente:
fbp(Facebook browser ID): o valor do cookie_fbpdefinido pelo pixel da Meta. Encaminhá-lo do navegador para o envio do servidor permite que a Meta vincule o evento de servidor à mesma sessão de navegador.fbc(Facebook click ID): o valor do cookie_fbc, preenchido quando um usuário chega através do clique em um anúncio. Enviá-lo é essencial para atribuir eventos de servidor ao anúncio que gerou a visita.client_ip_addresseclient_user_agent: a Meta usa esses dados para corresponder o evento de servidor ao evento de navegador. Sem eles, a qualidade de correspondência cai visivelmente mesmo quando há PII com hash presente.
Esses quatro campos não exigem consentimento do usuário além do que o pixel já precisa, mas deixá-los de fora é um dos motivos mais comuns para um EMQ baixo. Para mais sobre perda de sinal em navegadores, veja Safari ITP e Perda de Conversões.
Por que eventos podem ser enviados pelo servidor e mesmo assim não serem contabilizados
Você confirmou o envio (①), mas a conversão não está sendo aproveitada como esperado. Motivos comuns:
- Token de acesso expirado: o token de acesso da CAPI está expirado ou revogado, então o envio é rejeitado
- Deduplicação com falha: navegador e servidor não compartilham um
event_id, causando contagem duplicada ou perda - Parâmetros com hash insuficientes: pouca informação do cliente significa baixa qualidade de correspondência, então o evento é subaproveitado na otimização
- O servidor não está disparando: o envio do lado do servidor simplesmente não está rodando no momento da conversão
- Destino errado (pixel ID): você está enviando para um conjunto de dados diferente ou um destino inválido
Em resumo, confirmar que o servidor "consegue enviar" não é prova de que a Meta recebeu, correspondeu e deduplicou o evento em produção.
O que uma verificação na sua própria máquina não consegue te dizer
Verificar uma vez, manualmente, na sua própria máquina, tem duas limitações estruturais.
- Seu ambiente não é o ambiente dos seus visitantes. Seu envio de teste com um
test_event_codepode funcionar, mas isso não significa que o mesmo envio dispara no caminho real do servidor de produção no momento em que um visitante de verdade compra ou entra em contato. Um envio de teste bem-sucedido não é o mesmo que um fluxo de produção bem-sucedido. - Conversões envolvendo clique em anúncio são difíceis de verificar. Para ver de verdade "isso realmente rastreia e otimiza via um anúncio", você precisaria clicar em um anúncio ao vivo para recriar o caminho — o que traz o risco de violar a política de anúncios como um autoclique.
Julgar que "o envio de teste funcionou, então está tudo certo" tende a deixar passar o problema de eventos de servidor sumindo no caminho real que seus visitantes percorrem.
Um checklist para verificar com confiança
- No Gerenciador de Eventos, o evento alvo mostra o método de conexão Servidor?
- O horário de recebimento do evento de servidor está recente, sem ter parado?
- Um envio de servidor com
test_event_codeaparece no Test Events como Servidor? - Para a mesma conversão, tanto navegador quanto servidor estão visíveis e deduplicados com o mesmo
event_id? - O token de acesso da CAPI está válido (não expirado)?
- As informações do cliente (
em,ph, etc.) são enviadas com hash, com a qualidade de correspondência em um nível aceitável? - Além do seu próprio envio de teste, os eventos de servidor não estão faltando no caminho real dos visitantes em produção?
Perguntas frequentes
P. Se o pixel do navegador funciona, a CAPI não é redundante? R. Não. A CAPI complementa, do lado do servidor, a parcela que o pixel do navegador perde por causa de ITP, bloqueadores de anúncios, perda de sinal no iOS, entre outros. Só com o pixel, essa parcela perdida simplesmente se vai. Para a verificação de disparo, veja também Verificando o disparo do pixel da Meta.
P. Os eventos aparecem no Test Events, mas não dizem "Servidor".
R. Provavelmente só o pixel do navegador está funcionando. Envie um evento do seu servidor com um test_event_code anexado e confirme se uma linha originada do Servidor aparece no fluxo. Se não aparecer, suspeite que o código do servidor não está disparando ou que o token é inválido.
P. Desde que adicionei a CAPI, minhas conversões parecem ter dobrado.
R. É provável que os eventos de navegador e servidor não compartilhem um event_id e não estejam sendo deduplicados. Alinhe o nome do evento e o event_id nos dois. Veja Verificando a deduplicação (event_id) para mais detalhes.
P. Como eu aumento o Event Match Quality (EMQ)? R. Envie mais — e mais precisos — parâmetros de dados do cliente com hash. Enviar e-mail, telefone, nome, ID externo e afins, com hash corretamente aplicado (SHA-256) no servidor, geralmente aumenta a pontuação.
P. Eu usei a configuração de CAPI de um clique da Meta (CAPI Gateway). Ainda preciso verificar? R. Sim. A CAPI de um clique (lançada em abril de 2026) remove a complexidade da configuração, mas você ainda precisa confirmar se os eventos chegam com método de conexão Servidor, se a deduplicação funciona e se o EMQ está em um nível aceitável. Como a Meta hospeda a infraestrutura, você não terá acesso direto aos logs do servidor — então as verificações dos Passos 1 a 4 acima se tornam ainda mais importantes. Vale notar que a CAPI de um clique cobre apenas eventos padrão de web; eventos personalizados ou conversões offline ainda exigem uma implementação manual que você precisará verificar separadamente.
P. Quanto tempo até o token de acesso expirar? R. O prazo de validade depende do tipo de token e de como ele foi emitido. Como uma expiração interrompe silenciosamente os envios do seu servidor, o mais seguro é verificar regularmente o registro de eventos recebidos e, para operação de longo prazo, definir uma política de renovação de token com antecedência.
Conclusão: não pare em "está enviando" — confirme que "a Meta recebeu e fez a correspondência"
Passar pelo Passo 1 (método de conexão) → 2 (test_event_code) → 3 (deduplicação) → 4 (qualidade de correspondência) permite isolar tudo, do envio à correspondência. O que importa é o quadro completo: se os eventos de servidor são recebidos, correspondidos e deduplicados em relação ao lado do navegador, e registrados no caminho real dos visitantes em produção. Para o panorama completo do rastreamento de conversões da Meta, veja O Guia Completo de Rastreamento de Conversões da Meta.
A ConversionOK executa sua página ao vivo em um navegador independente e isolado e intercepta os eventos realmente enviados, então os verifica — sem necessidade de clicar no seu próprio anúncio e sem interferência do ambiente do seu escritório. Comece com uma verificação estática gratuita para confirmar o ponto de entrada da sua mensuração.