Meta Ads / 11 min de leitura / Atualizado set 2026

Conversions API (CAPI) no Meta Ads: o que é e como configurar em 2026

O pixel sozinho não enxerga mais o que acontecia antes. A Conversions API manda o mesmo evento direto do seu servidor pro Meta, e isso muda a qualidade da otimização. Veja o que é, como configurar e os erros que fazem o setup falhar.

GP Por Giorgio Pasquale · Especialista em mídia paga
Capa do artigo sobre Conversions API (CAPI) no Meta Ads, com título grande em duas linhas e selo do canal
TL;DR · Em 3 linhas

O que você vai entender lendo isso

  • CAPI manda eventos de conversão direto do servidor pro Meta, sem depender de cookie de navegador. É o complemento do pixel, não substituto dele.
  • Deduplicação é a parte que mais quebra. Sem event_id igual entre pixel e servidor, você conta a mesma compra duas vezes e o relatório mente.
  • Quem configura bem recupera sinal que o iOS e os bloqueadores de cookie estavam cortando, e o algoritmo volta a ter dado de qualidade pra otimizar lance.

A Conversions API existe porque o pixel do Meta, sozinho, parou de enxergar boa parte do que acontece depois do clique. Navegador bloqueando cookie de terceiro, iOS limitando rastreamento, extensão de privacidade cortando script de tracking client-side: o evento de compra acontecia, mas o Meta não ficava sabendo. A CAPI resolve isso enviando o mesmo evento (compra, lead, cadastro) direto do seu servidor pro servidor do Meta, por uma rota que nenhum bloqueador de navegador consegue tocar. Neste guia eu explico o que é, como configurar sem duplicar conversão, e os erros de setup que mais vejo em auditoria de conta.

O que é a Conversions API – explicação rápida

A Conversions API (CAPI) é uma forma de enviar eventos de conversão pro Meta diretamente do seu servidor, em vez de depender só do navegador do usuário. Ela funciona em paralelo ao pixel: os dois mandam o mesmo evento por caminhos diferentes, e o Meta usa deduplicação pra juntar as duas versões numa só.

Na prática, o fluxo é assim:

  1. O usuário completa uma ação no seu site (compra, cadastro, lead).
  2. O pixel, no navegador, tenta mandar o evento pro Meta via client-side.
  3. Ao mesmo tempo, seu servidor (ou o Google Tag Manager Server-Side, ou um plugin de e-commerce) manda o mesmo evento via CAPI, direto servidor a servidor.
  4. O Meta recebe as duas versões, compara o event_id, e conta como um evento único se os IDs baterem.

O resultado é uma cobertura de evento mais alta e mais confiável, principalmente em cenários onde o pixel sozinho perde sinal: Safari com ITP, usuários com bloqueador de anúncio, ou aquele checkout que redireciona pra um domínio de pagamento diferente.

Por que o pixel sozinho não é mais suficiente

Até alguns anos atrás, o pixel client-side dava conta do recado. O problema é que o ecossistema de navegador mudou de baixo pra cima: Safari e Firefox restringem cookie de terceiro por padrão, iOS pede permissão explícita de rastreamento desde o App Tracking Transparency, e uma fatia relevante de usuário roda extensão que bloqueia script de tracking antes mesmo dele carregar.

Cada uma dessas barreiras corta um pedaço do funil que o pixel via antes. O evento de compra continua acontecendo, o cliente comprou e pagou, só que o Meta não fica sabendo – e sem saber, o algoritmo de otimização de lance não consegue aprender com aquela conversão. Ele otimiza pro que consegue medir, e se metade das conversões está invisível, a otimização fica torta.

100%server-side
A CAPI manda o evento direto do seu servidor, fora do alcance de bloqueador de navegador, cookie de terceiro ou configuração de privacidade do dispositivo. É a rota que sobrevive às restrições que o pixel sozinho não atravessa.

Isso não é exclusividade do Meta. O mesmo raciocínio motivou o Consent Mode v2 no Google Ads e o Enhanced Conversions da mesma plataforma: a indústria inteira está migrando de rastreamento client-side puro pra uma combinação de client-side + server-side, porque só client-side já não fecha a conta de atribuição.

Como configurar a Conversions API – os três caminhos

Não existe uma única forma de implementar CAPI. Em 2026, três caminhos cobrem a maioria dos casos:

Caminho Complexidade Quando usar
Integração direta por parceiro (Shopify, WooCommerce, VTEX etc.) Baixa Loja em plataforma de e-commerce com app oficial do Meta; setup guiado, sem escrever código
Google Tag Manager Server-Side Média Site próprio, já usa GTM no client-side, quer centralizar client e server num container só
Implementação via API direto no back-end Alta Produto com time de engenharia, checkout customizado, volume alto e precisão máxima

Pra quem já estruturou eventos no pixel, vale revisar antes o próprio setup e hierarquia de eventos no Meta Ads – a CAPI replica exatamente os mesmos eventos e parâmetros, então se o pixel está mal configurado, a CAPI só duplica o problema em dois lugares em vez de um.

⚠ Importante

CAPI não é opcional só pra quem “tem verba pra time técnico”. Mesmo o caminho mais simples (integração via app da plataforma de e-commerce) já recupera parte relevante do sinal perdido. O ponto de partida errado é achar que precisa de engenharia própria pra começar.

Deduplicação – o ponto onde a maioria erra

Se você manda o mesmo evento de compra duas vezes (uma pelo pixel, outra pela CAPI) sem dizer pro Meta que são a mesma coisa, ele conta duas conversões onde só houve uma. O relatório infla, o ROAS parece melhor do que é, e a decisão de escalar campanha fica baseada em número errado.

A solução é o event_id: um identificador único gerado no momento da conversão e enviado junto no evento do pixel e no evento da CAPI. Quando o Meta recebe as duas versões com o mesmo event_id, ele deduplica automaticamente e conta como um evento só.

  • Gere o event_id uma vez por conversão, não um novo a cada tentativa de envio.
  • Use o mesmo valor nos dois lados. Se o pixel manda event_id: "compra_8841", o servidor precisa mandar exatamente o mesmo valor pro mesmo evento.
  • Confira no Events Manager. O Meta mostra, evento por evento, se ele está sendo deduplicado corretamente – é a primeira tela a olhar depois de subir a integração.

Eu já vi conta rodando havia meses com CAPI “configurada” mas sem event_id compartilhado, contando cada compra duas vezes. O ROAS reportado estava quase o dobro do real. Ninguém tinha percebido porque o número parecia bom demais pra questionar – e é exatamente aí que mora o risco: métrica inflada não dispara alarme, ela só engana silenciosamente.

Métrica duplicada não avisa que está errada. Ela só parece boa demais até alguém cruzar com o financeiro. – Observação recorrente em auditoria de conta

Qualidade do evento – o EMQ que ninguém olha

Além de mandar o evento, a CAPI permite enviar parâmetros de correspondência (e-mail, telefone, nome, endereço) de forma hasheada junto com cada conversão. Quanto mais desses parâmetros você inclui, maior o Event Match Quality (EMQ), a nota que o Meta dá pra qualidade da correspondência entre o evento e um usuário real na base dele.

8+parâmetros de match
O Meta recomenda enviar o máximo de parâmetros de correspondência possível (e-mail, telefone, nome, cidade, IP, user agent, external_id) em cada evento CAPI. Mais parâmetros de match não significa mais dado bruto exposto – tudo isso viaja hasheado (SHA-256) antes de sair do seu servidor.

Um erro comum é configurar a integração via parceiro (Shopify, por exemplo) e nunca voltar pra olhar o EMQ depois. Se a loja só manda e-mail e mais nada, o EMQ fica baixo e a correspondência trabalha com metade do potencial. Vale revisar isso junto com a checagem geral de auditoria de conversion tracking, porque EMQ baixo é um dos sintomas mais comuns de tracking mal calibrado.

CAPI e janela de atribuição – o que muda na prática

A CAPI não altera a janela de atribuição que você escolhe pra campanha (7 dias de clique, 1 dia de visualização etc.), mas melhora a chance de o evento dentro dessa janela ser efetivamente capturado. Isso é especialmente relevante depois das mudanças de atribuição que o Meta vem aplicando desde 2024 – se você ainda não revisou isso, o guia de atribuição no Meta Ads em 2026 explica as janelas atuais e o que mudou.

Na prática, contas que implementam CAPI bem costumam reportar um número de conversões mais próximo do real (mais perto do que o financeiro vê no banco), porque menos eventos se perdem no caminho entre o clique e a conversão. Isso não significa “mais vendas” – significa visibilidade mais honesta sobre vendas que já estavam acontecendo, só não sendo contabilizadas.

Mitos comuns sobre a Conversions API

Em conversas com quem está implementando pela primeira vez, alguns mal-entendidos aparecem com frequência:

Mito

“CAPI substitui o pixel, posso remover o pixel do site.”

“CAPI expõe dado pessoal do cliente pro Meta sem proteção.”

“Só empresa grande com time de engenharia consegue implementar.”

“Depois de configurar, o setup nunca mais precisa de manutenção.”

Fato

São complementares. O Meta recomenda rodar os dois juntos – cada um captura eventos que o outro pode perder.

Os parâmetros de correspondência (e-mail, telefone) são hasheados em SHA-256 antes de sair do seu servidor.

Integrações por parceiro (Shopify, WooCommerce) fazem boa parte do trabalho sem exigir código.

Mudança de checkout, novo domínio de pagamento ou nova página de obrigado costuma quebrar o mapeamento de evento – vale revisar periodicamente.

Erros mais comuns na implementação

1. Não compartilhar o event_id entre pixel e servidor. É a causa mais frequente de conversão duplicada, e o motivo pelo qual muita conta reporta ROAS inflado sem perceber.

2. Mandar evento sem os parâmetros mínimos de correspondência. CAPI sem e-mail, telefone ou external_id no payload tem qualidade de match baixa e ajuda muito menos do que poderia.

3. Não testar no Events Manager antes de considerar “pronto”. O Meta tem uma ferramenta de teste de evento dentro do próprio Events Manager; pular essa etapa é publicar sem saber se está funcionando.

4. Esquecer de atualizar depois de mudança no checkout. Troca de gateway de pagamento, novo fluxo de obrigado, migração de plataforma de e-commerce: qualquer uma dessas mudanças pode quebrar silenciosamente o envio de evento via servidor, e ninguém percebe até o volume de conversão cair sem explicação aparente.

Vale a pena implementar agora?

Na minha experiência, sim, quase sempre. O esforço de configurar (principalmente pelo caminho de integração por parceiro) é baixo comparado ao ganho de sinal recuperado, especialmente em conta que depende de tráfego mobile e iOS, onde a perda de sinal client-side é maior. Contas pequenas, validando o canal com R$ 1.000 a R$ 3.000 por mês, também se beneficiam: cada conversão que deixa de ser invisível é dado a mais pro Smart Bidding do Meta aprender com um orçamento que já é apertado.

O único cenário onde eu adiaria é um negócio ainda sem conversion tracking básico funcionando no pixel. Nesse caso, a ordem certa é arrumar o rastreamento client-side primeiro, confirmar que os eventos e a hierarquia fazem sentido, e só depois subir a camada server-side por cima de uma base que já funciona.

FAQ

CAPI substitui o pixel do Meta Ads?

Não. Os dois trabalham juntos. O pixel captura evento pelo navegador, a CAPI captura o mesmo evento pelo servidor, e o Meta deduplica as duas versões usando o event_id. Remover o pixel e ficar só com CAPI reduz a cobertura em vez de aumentar.

É preciso saber programar pra configurar a Conversions API?

Depende do caminho. Integrações via parceiro (app oficial do Meta pra Shopify, WooCommerce, VTEX) têm setup guiado sem código. Já a implementação direta via API, ou via Google Tag Manager Server-Side, pede algum conhecimento técnico ou apoio de alguém que tenha.

Como saber se a CAPI está funcionando corretamente?

O Events Manager do Meta mostra, evento por evento, a origem (navegador, servidor ou ambos) e o status de deduplicação. Se depois de configurar você não vê eventos chegando pela via servidor, ou vê duplicação em vez de dedup, o setup precisa de ajuste antes de considerar concluído.

CAPI aumenta o número de vendas?

Não diretamente. Ela aumenta a visibilidade sobre vendas que já estavam acontecendo mas não eram contabilizadas por bloqueio de cookie, ITP do Safari ou restrição do iOS. O efeito indireto é um algoritmo de lance com dado mais completo, o que tende a melhorar a eficiência de médio prazo.

Quais dados são enviados pela Conversions API?

O evento em si (compra, lead, cadastro, valor) e, opcionalmente, parâmetros de correspondência como e-mail, telefone, nome e IP – todos hasheados em SHA-256 antes de saírem do seu servidor. Nenhum desses dados trafega em texto puro.

Conclusão

A Conversions API deixou de ser um recurso avançado pra virar parte básica de um setup de tracking saudável no Meta Ads. O ganho real não é “mais conversão”, é conversão que já existia voltando a ser visível pro algoritmo otimizar lance com dado completo. Comece revisando a hierarquia de eventos com o guia de eventos de conversão no Meta Ads, depois confirme o event_id compartilhado entre pixel e servidor, e feche o ciclo com uma auditoria de conversion tracking completa antes de escalar orçamento em cima desses números.

Rolar para cima