A Conversions API (CAPI) do Meta é uma integração server-side que envia eventos de conversão diretamente do seu servidor para o Meta, em paralelo ao pixel. Configurá-la envolve gerar um token no Gerenciador de Eventos, montar o payload com dados de match em hash SHA256 e deduplicar por event_id. Segundo a documentação oficial da Meta (Business Help Center, 2025), a combinação pixel + CAPI aumenta o número de eventos atribuídos e melhora a estabilidade da otimização frente à perda de dados do navegador.
Este guia assume que você já entendeu por que conectar mídia ao CRM importa. Se ainda não, vale ler antes como integrar Meta Ads ao CRM e parar de otimizar por CPL — aqui o foco é o como, na camada técnica.
O que a CAPI resolve que o pixel não resolve
O pixel é JavaScript que roda no navegador do usuário. Isso significa que ele depende de três coisas frágeis: o navegador executar o script, o usuário não ter bloqueador, e o sistema operacional não restringir o rastreamento. Cada uma dessas falha com frequência.
Bloqueadores de anúncios impedem o pixel de carregar. O iOS, desde a versão 14.5, restringe rastreamento entre apps e sites. Redes lentas e abas fechadas cedo cortam eventos pela metade. O resultado é um pixel que reporta menos eventos do que realmente aconteceram — e um algoritmo otimizando com informação incompleta.
A CAPI resolve isso porque roda no servidor, não no navegador. O evento é enviado direto da sua infraestrutura para o Meta, via requisição HTTP. Não há bloqueador que intercepte. Não há iOS que restrinja. E, criticamente para B2B, o servidor pode enviar eventos que não acontecem no site — como um deal marcado como "ganho" no CRM três meses depois do clique.
As duas formas de implementar
Existem dois caminhos, e a escolha define o resto do trabalho:
- CAPI via GTM Server-Side: você monta um container de servidor no Google Tag Manager que recebe os eventos do site e os repassa ao Meta. É a arquitetura mais limpa e escalável, porque centraliza o rastreamento de todas as plataformas num só lugar. Exige um servidor (Cloud Run, Stape ou similar).
- CAPI direta via webhook: o próprio CRM (ou uma camada como Make/Zapier) dispara a chamada HTTP para o endpoint da CAPI quando um evento acontece. Mais simples de começar, ideal para o evento de "venda fechada" que nasce no CRM, não no site.
Para a maioria das operações B2B, a combinação vencedora é: GTM Server-Side para os eventos de site (formulário, pageview) e webhook do CRM para os eventos de venda. Este guia cobre a segunda parte — a que fecha o loop de receita. Para a primeira, veja o que é GTM server-side.
Passo 1: gerar o token de acesso
No Gerenciador de Eventos do Meta Business Suite, selecione o seu conjunto de dados (dataset/pixel) → Configurações → role até Conversions API → Gerar token de acesso. Copie e guarde esse token em local seguro — ele dá acesso de escrita ao seu dataset e não deve ir para o front-end nem para repositórios públicos.
Onde guardar o token
Variável de ambiente no servidor, secret manager (Google Secret Manager, AWS Secrets), ou o campo de credencial criptografada da sua ferramenta de automação. Nunca em código versionado, nunca no navegador.
Passo 2: montar o payload do evento
A CAPI recebe uma requisição POST com um corpo JSON. A estrutura mínima de um evento de compra é esta:
Endpoint
https://graph.facebook.com/v19.0/{dataset_id}/events?access_token={token}
Corpo (campos essenciais)
event_name: "Purchase" · event_time: timestamp Unix · event_id: id único · action_source: "system_generated" (para eventos de CRM) · user_data: { em, ph, fn, ln, ct, st, fbc, fbp } · custom_data: { value, currency }
Três campos merecem atenção porque são onde a maioria das implementações falha:
- event_id: precisa ser o mesmo id enviado no pixel para o evento correspondente, para o Meta deduplicar. Se o evento nasce só no servidor (venda de CRM sem equivalente no site), gere um id estável — por exemplo, o id do deal no CRM.
- action_source: use
"website"para eventos de site e"system_generated"ou"physical_store"para eventos que vêm do CRM ou de vendas offline. Esse campo diz ao Meta a natureza do evento. - user_data: é o que permite o match. Quanto mais parâmetros válidos, maior o EMQ (Event Match Quality). O parâmetro mais poderoso é o
fbc— capturado do clique original no anúncio.
Passo 3: normalizar e fazer o hash dos dados
Para o Meta cruzar o evento com um usuário, os dados de contato precisam ir em formato padronizado e com hash SHA256. A normalização acontece antes do hash — errar a ordem quebra o match:
- Email (em): minúsculas, sem espaços nas pontas → depois SHA256. Ex:
joao@empresa.comvira o hash dejoao@empresa.com. - Telefone (ph): só dígitos, com código do país, sem símbolos → depois SHA256. Ex:
+55 (51) 99999-9999vira o hash de5551999999999. - Nome (fn/ln), cidade (ct), estado (st): minúsculas, sem acento, sem espaço → depois SHA256.
- fbc e fbp: vão em texto puro, sem hash. São os cookies do clique e da sessão. O fbc tem o formato
fb.1.timestamp.fbclid.
"O erro mais comum que vejo: enviar email com hash mas telefone com maiúsculas e símbolos. Metade dos parâmetros não bate e o EMQ despenca. Normalizar é chato, mas é o que separa 30% de 70% de match rate."
Passo 4: capturar e persistir o fbc
Este é o passo que quase ninguém faz — e é o que mais aumenta o match rate no B2B. Quando alguém clica no seu anúncio, a URL de destino recebe um parâmetro fbclid. Esse valor precisa ser capturado no momento do primeiro contato e salvo no CRM junto com o lead.
Por quê? Porque no B2B a venda acontece semanas ou meses depois do clique. Quando você finalmente envia o evento "Purchase" via CAPI, o navegador do usuário já não tem mais o cookie. Se você guardou o fbc no CRM lá no início, consegue enviá-lo agora — e o match com o clique original fica muito mais forte.
Na prática: configure seu formulário para capturar o fbclid da URL (ou o cookie _fbc) num campo oculto, e mapeie esse campo para uma propriedade do lead no CRM. Todo evento futuro daquele lead pode então carregar o fbc.
Passo 5: verificar no Gerenciador de Eventos
Depois de enviar os primeiros eventos, vá ao Gerenciador de Eventos → seu dataset → aba "Visão geral". Você deve ver os eventos chegando com a fonte marcada como "Servidor". Cheque três indicadores:
- Eventos recebidos: confirmam que o payload está sendo aceito. Erros de formato aparecem aqui com a descrição.
- Deduplicação: se você roda pixel + CAPI, deve ver a indicação de que eventos duplicados foram unificados pelo event_id. Se não aparecer, seu event_id está inconsistente.
- Event Match Quality (EMQ): a nota de 0 a 10 da qualidade dos dados de match. Mire acima de 6. Abaixo de 5, a maioria dos seus eventos não está sendo atribuída — revise a normalização e adicione mais parâmetros de user_data.
O erro que anula todo o trabalho
Configurar a CAPI e não enviar o fbc nem os parâmetros de match suficientes é o equivalente a instalar um cano e não abrir a torneira. Os eventos chegam, o Gerenciador mostra "recebido", tudo parece certo — mas o EMQ está em 3, o Meta não consegue atribuir a maioria dos eventos a usuários reais, e o algoritmo continua otimizando às cegas.
A CAPI só entrega valor quando o match rate é alto. E o match rate depende inteiramente da qualidade e quantidade dos dados de user_data que você envia em cada evento. Priorize isso acima de qualquer refinamento de arquitetura.
Perguntas frequentes sobre Meta CAPI
Preciso manter o pixel se já uso a CAPI?
Sim. A recomendação da Meta é rodar os dois em conjunto, com deduplicação por event_id. O pixel traz contexto de sessão; a CAPI garante que o evento chegue mesmo com bloqueador, iOS ou falha de rede. Usar só um deixa buracos de cobertura.
O que é event_id e por que importa?
É um identificador único enviado igual no pixel e na CAPI. Quando o Meta recebe dois eventos com o mesmo event_id e event_name em até 48h, conta como um só. Sem event_id consistente, o mesmo evento é contado em dobro — inflando conversões e distorcendo a otimização.
Como o Meta faz o match do evento com o usuário?
Cruzando os parâmetros de user_data (email, telefone, nome, cidade e principalmente fbc/fbp) contra a base do Meta. Email e telefone vão em SHA256; fbc e fbp em texto puro. O parâmetro mais forte é o fbc, capturado do clique — por isso vale persisti-lo no CRM desde o primeiro contato.
Qual é um bom valor de EMQ?
O EMQ vai de 0 a 10. Acima de 6 é bom, acima de 8 é excelente. Para subir, envie múltiplos parâmetros de user_data por evento — email, telefone, nome, sobrenome, cidade, estado, fbc e fbp. EMQ abaixo de 5 indica que a maioria dos eventos não está sendo atribuída.
Próximo passo
Sua CAPI está enviando eventos
ou enviando eventos que batem?
Ter a CAPI instalada não é o mesmo que ter EMQ alto e match rate que sustenta a otimização. Se você investe R$ 30k+/mês em Meta Ads, vale auditar. Conversa sem compromisso.
Conversar sobre sua operação →