A API de Conversões do Meta (CAPI) existe por causa de um problema que o Pixel sozinho não consegue resolver: você não controla o que acontece no navegador do usuário. Ad blockers bloqueiam o script, o iOS 14 recusa o traqueamento e o modo privado descarta cookies antes mesmo do evento sair. O Pixel depende do ambiente que o usuário criou, e esse ambiente ficou cada vez mais hostil ao traqueamento desde 2021.

O guia completo de traqueamento de conversões cobre esse problema em detalhe, junto com todas as outras peças do traqueamento. Aqui o foco é especificamente na CAPI: como funciona, o que configura e como medir se está funcionando.

API de Conversões do Meta vs Pixel: a diferença técnica

O Pixel é client-side: um script JavaScript que roda no navegador do usuário, captura dados locais e envia para os servidores do Meta via requisição HTTP. Quando o usuário tem um ad blocker, o domínio connect.facebook.net é bloqueado e o script nem carrega. Quando o iOS bloqueou o traqueamento, os cookies first-party do Meta têm vida curta.

A API de Conversões roda no seu servidor, não no navegador do visitante. Em vez de depender do script no navegador, o seu servidor (ou um servidor intermediário como o GTM Server-Side) envia os eventos diretamente para a API Graph do Meta, usando um token de acesso gerado no Gerenciador de Eventos. Esse envio nunca passa pelo navegador do usuário, portanto não pode ser bloqueado por extensão, por iOS ou por qualquer configuração de privacidade do navegador.

O diagrama mental é simples: Pixel = navegador → Meta. CAPI = seu servidor → Meta. O usuário nem fica sabendo que o evento foi enviado.

Por que o Pixel sozinho perdeu dados (e como a CAPI resolve)

Antes do iOS 14 (abril de 2021), o Pixel tinha acesso a cookies third-party e conseguia acompanhar usuários em vários sites. Depois, a Apple obrigou os apps a pedir permissão explícita de traqueamento, e a maioria dos usuários recusou. Sem esses cookies, o Meta perdeu a capacidade de associar cliques de anúncio a compras feitas em apps e Safari.

Nas contas que auditamos, a perda de atribuição de conversão em campanhas com público iOS costuma ser expressiva, e não é raro o Pixel deixar de contar uma fatia relevante das compras. Em nichos onde o iPhone domina (cursos online com público feminino 25-45, por exemplo), a diferença entre o que o checkout registra e o que o Meta reporta fica ainda mais visível.

Com a CAPI, você recupera esses eventos. O servidor recebe a confirmação de compra, monta o payload com os dados do comprador (email e telefone em hash SHA-256, além de FBC e FBP capturados na página de venda), e envia para o Meta. O Meta associa esses dados ao perfil do usuário e conta a conversão, mesmo que o Pixel não tenha conseguido disparar no checkout.

Obs.: a CAPI não "engana" o iOS nem viola nenhuma política de privacidade. Você está enviando dados que o usuário forneceu voluntariamente (ao comprar) para fins de atribuição de publicidade. O hashing SHA-256 do email e telefone é exigido pelo próprio Meta para proteger os dados.

O que é Event Match Quality e Connect Rate

No Gerenciador de Eventos do Meta, cada fonte de eventos tem uma pontuação de Event Match Quality (EMQ), de 0 a 10, que indica o quão bem o Meta consegue associar seus eventos a perfis de usuário. No ecossistema Castnexo chamamos isso de Connect Rate: quanto da sua audiência o Meta de fato reconhece a cada evento enviado.

Os parâmetros de matching não pesam igual. A ordem de força para o Meta reconhecer a pessoa, do mais forte para o mais fraco, é esta:

Email em hash (em): SHA-256 do email em letras minúsculas, sem espaços. É o matcher individual mais forte.
Telefone em hash (ph): hash SHA-256 do telefone normalizado em E.164 (confira o formato exato no Gerenciador de Eventos do Meta).
Nome em hash (fn e ln): primeiro e último nome em SHA-256.
FBC (_fbc, o Facebook Click ID): capturado quando o usuário clica no anúncio.
FBP (_fbp, o Facebook Browser ID): cookie persistente do navegador.
Localização: cidade, estado, CEP e país (também em hash).
external_id: o ID do usuário no seu próprio sistema.
IP e User-Agent: capturados pelo servidor e enviados junto com o evento.

Vale separar dois papéis que costumam ser confundidos. Email e telefone hasheados são os matchers mais fortes para o Meta reconhecer a pessoa por trás do evento, e é isso que move o EMQ. Já o _fbc tem outra função, insubstituível: ele atribui o clique ao anúncio específico que gerou a visita. Um evento pode ter EMQ alto por email e telefone e ainda assim perder a atribuição da campanha se o _fbc não for enviado. Por isso a regra é mandar todos os identificadores disponíveis em cada evento, não escolher entre eles.

Não existe um número de corte oficial. O jeito prático de ler o Connect Rate é comparar com a média histórica da própria conta: uma queda em relação ao que você costuma ver indica problema de matching (payload incompleto, hash malformado, parâmetro faltando), e vale investigar antes que a otimização de campanha sofra.

Para ver o Connect Rate: Gerenciador de Eventos → selecione sua fonte de dados (Pixel) → aba Visão Geral → coluna "Qualidade do match do evento".

Como configurar a API de Conversões via GTM Server-Side

O GTM Server-Side é um container GTM que roda em um servidor, não no navegador. Ele recebe os eventos do GTM web (client-side), processa e encaminha para as plataformas de destino via API. Para o Meta, existe um template oficial de API de Conversões disponível na galeria de templates do GTM.

O fluxo de configuração em 4 passos:

Provisionar o servidor GTM: você pode usar o Stape (stape.io) que gerencia a infraestrutura por você, ou provisionar no Google Cloud Platform / AWS manualmente. O Stape custa a partir de US$ 10/mês e é a opção mais prática para a maioria dos casos.
Configurar o GTM Web para enviar ao servidor: instale o template "Google Tag" no container web e aponte o transport URL para o servidor GTM. A partir daí, os eventos do GTM web passam pelo servidor antes de chegar ao Meta.
Instalar o template da API de Conversões: no container server, adicione o template "Facebook Conversions API" da galeria. Configure com o Pixel ID e o token de acesso gerado no Gerenciador de Eventos.
Configurar deduplicação: use o mesmo event_id no Pixel (via parâmetro do GTM web) e na CAPI (via tag do GTM server). O Meta usa esse ID para deduplicar e não contar o mesmo evento duas vezes.

A verificação é feita na aba "Teste de Eventos" do Gerenciador de Eventos: você vai ver eventos chegando com origem "Navegador" (Pixel) e "Servidor" (CAPI). Se ambos aparecem com o mesmo event_id, a deduplicação está ativa.

Para o caso específico de checkouts em plataformas terceiras, veja o artigo sobre traqueamento server-side vs client-side e sobre instalação do Pixel via GTM. E, no blog do GTM Audit, os erros mais comuns de configuração no GTM.

Impacto real da CAPI: o que esperar

Depois de implementar a CAPI corretamente, o que você vai observar no painel do Meta:

Aumento no número de eventos reportados: o Meta passa a receber eventos que antes eram perdidos. Esse volume extra é real: são compras que o Pixel deixava de contar, não inflação de traqueamento.
Melhoria no Connect Rate: com email, telefone, FBC e FBP sendo enviados, o matching fica mais preciso.
Melhoria no aprendizado do algoritmo: mais dados = otimização mais eficiente. Campanhas que estavam com aprendizado estagnado podem se recuperar.
CPA possivelmente menor no médio prazo: não acontece em todos os casos, mas com dados mais completos o algoritmo tende a encontrar melhores compradores.

Ou seja: a CAPI repara a infraestrutura de dados, não otimiza a campanha diretamente. O benefício é que o Meta passa a trabalhar com dados reais em vez de estimativas.

FAQ

Posso usar a API de Conversões sem o Pixel?

Tecnicamente sim, mas não é recomendado. O Pixel captura dados comportamentais em tempo real (PageView, cliques, scroll) que a CAPI não captura naturalmente. A combinação Pixel + CAPI com deduplicação é o que dá os melhores resultados: o Pixel cobre o comportamento, a CAPI garante as conversões.

A API de Conversões viola a LGPD?

Não, desde que você tenha base legal para processar os dados do usuário (geralmente consentimento ou execução de contrato) e informe no aviso de privacidade que os dados são compartilhados com plataformas de publicidade. O hashing SHA-256 é uma camada de proteção, não substitui a base legal. Consulte seu advogado para adequação específica.

Quanto tempo leva para ver resultado após implementar a CAPI?

O Gerenciador de Eventos começa a receber eventos em tempo real assim que a integração está ativa. O impacto no algoritmo de otimização leva mais tempo, geralmente 7 a 14 dias para o modelo se ajustar aos dados novos. Se a campanha estava em aprendizado, pode sair mais rápido.

Qual é a diferença entre a CAPI nativa da Hotmart e a configuração via GTM?

A integração nativa da Hotmart envia o evento Purchase diretamente para o Meta quando a venda é aprovada, sem necessidade de GTM. É a opção mais simples para quem vende na Hotmart. A configuração via GTM dá mais controle (você pode enriquecer o payload, adicionar parâmetros customizados, usar o mesmo servidor para múltiplas fontes), mas exige mais setup.

É esse problema de matching que o Tracker resolve por baixo dos panos: ele centraliza o PII do comprador (email, telefone, nome), aplica o hash SHA-256 no formato que o Meta espera e envia todos os identificadores em cada evento CAPI, sem você configurar hash manual nem arriscar telefone sem normalizar. Um evento montado assim, com email, telefone e _fbc bem formados, é o que leva o EMQ para a faixa de 7+ em que o Meta atribui com confiança. Veja a atribuição real, as sessões e os perfis no Tracker: comece os 30 dias grátis.

API de Conversões do Meta: o que é e como configurar