API de Conversões da Meta (CAPI): o guia de implementação sem jargão

Seu gerenciador de anúncios mostra 200 conversões no mês. Seu sistema interno registrou 280 vendas. Essa diferença de 80 vendas não é erro de contagem. É o navegador apagando o sinal antes dele chegar na Meta.

Quando o iOS 14.5 chegou em abril de 2021 com o App Tracking Transparency, a taxa de usuários que permitem rastreamento despencou para cerca de 11% no mundo logo no lançamento, segundo a Flurry. Sem o identificador do aparelho, a Meta perdeu metade do que enxergava. O algoritmo passou a otimizar campanha com um terço dos olhos vendados. E a maioria dos anunciantes ainda roda em cima desse sinal quebrado, reclamando que "a mídia não performa mais".

A resposta não é gastar mais. É consertar o cano por onde o dado vaza antes de chegar na plataforma. A API de Conversões (CAPI) é a peça que faz isso. Este é o blueprint de como ela funciona e como instalar sem o jargão que ninguém explica.

O que é a API de Conversões (de verdade)

CAPI é a sigla de Conversions API, a ferramenta de tracking server-side da Meta. Tradução sem enrolação: em vez de o evento de conversão sair do navegador do usuário (o pixel, JavaScript rodando no browser), ele sai direto do seu servidor para o servidor da Meta.

Por que isso muda tudo: o evento não passa mais pelo browser. E o browser é onde o sinal morre. Ad blocker bloqueia o pixel. A proteção anti-tracking do Safari e do Firefox bloqueia o pixel. Cookie que expira, aba fechada antes do disparo, conexão que cai: tudo isso derruba o pixel. O servidor não tem nenhum desses problemas. Ele fala direto, máquina com máquina.

Agora o erro que custa caro, e que quase todo mundo comete: a CAPI não substitui o pixel. A Meta recomenda rodar os dois em paralelo. Não é redundância por preguiça, é redundância proposital. O pixel pega o que dá pelo navegador, a CAPI pega o que o navegador perde, e os dois juntos cobrem o evento por dois caminhos.

CAPI não é o pixel 2.0. É o segundo cano para o mesmo evento. Desligar o pixel achando que a CAPI cobre tudo é perder sinal, não ganhar.

E quando o mesmo evento chega pelos dois caminhos? É aí que entra a peça técnica que faz o sistema não contar dobrado.

A peça que faz tudo funcionar: deduplicação por event_id

Se o pixel dispara a compra e a CAPI dispara a mesma compra, a Meta veria duas conversões onde só houve uma. Resultado: relatório inflado, otimização confusa, decisão errada.

A solução é a deduplicação por event_id. Cada evento recebe um identificador único. O pixel manda a compra com o event_id abc123. A CAPI manda a mesma compra com o mesmo event_id abc123. A Meta vê os dois, reconhece pelo identificador que é o mesmo evento, e conta uma vez só.

Sem o event_id casado entre pixel e CAPI, você cria contagem dobrada e quebra o seu próprio relatório. Com ele, você tem cobertura dupla sem distorção. Essa é a engrenagem central da implementação. Tudo o que vem depois depende de o event_id estar batendo entre os dois lados.

A diferença não é cosmética. O tracking só client-side captura, em cenário típico, de 60 a 70% das conversões reais. Os outros 30 a 40% se perdem para ad blocker, proteção do iOS, opt-out e falha de rede. Vale a ressalva honesta: esse "até 40%" é uma faixa estimada de mercado, não um estudo fechado. Mas a direção é consistente. Pixel mais CAPI, com a deduplicação certa, costuma levar a cobertura para perto de 95%.

O blueprint: como a CAPI envia o evento

Vamos abrir o capô. O caminho de um evento de compra com CAPI tem quatro estágios. Entender os quatro é o que separa "instalei um plugin e torço" de "sei exatamente o que está acontecendo".

Estágio 1: o evento acontece no seu lado

O usuário compra. Seu servidor, seu checkout ou sua plataforma registra essa compra. Esse é o fato gerador. Diferente do pixel, que depende da página carregar um script, aqui o gatilho é o evento real do seu sistema. Mais confiável por definição.

Estágio 2: você monta o pacote do evento

O servidor empacota o evento com os dados que a Meta precisa para casar a conversão com um usuário: o tipo do evento (Purchase), o valor, a moeda, o event_id (o mesmo que o pixel vai usar) e os dados do cliente para matching (e-mail, telefone, sempre com hash, nunca em texto aberto). Quanto melhor o conjunto de dados de matching, maior o match rate, ou seja, maior a chance da Meta reconhecer aquele usuário.

Estágio 3: o servidor envia para a Meta

O pacote vai do seu servidor direto para o endpoint da Meta. Sem navegador no meio. Sem ad blocker. Sem cookie de terceiro. É uma chamada de API limpa, servidor para servidor.

Estágio 4: a Meta deduplica e atribui

A Meta recebe o evento pela CAPI, compara o event_id com o que chegou pelo pixel, deduplica, e usa o dado para atribuir a conversão e alimentar o algoritmo de otimização. Mais sinal limpo entrando significa decisão de leilão mais precisa saindo.

Esse fluxo é o mesmo conceito de tracking server-side que vale para o Google e para qualquer plataforma séria. A CAPI é a implementação da Meta. Se você quer entender a lógica server-side por baixo de tudo isso, sem ficar preso a uma plataforma:

Os dados: por que isso vira dinheiro no caixa

Argumento técnico bonito não paga conta. Vamos aos números que importam, separando o que é dado oficial do que é estimativa de mercado, porque misturar os dois é como o pixel quebrado mente para você.

Métrica	Valor	Origem
CAPI + pixel: melhora no custo por resultado	13% (média)	Meta, meta-análise de 15 testes A/B, 99% de confiança, 2024-2025
Captura só client-side (pixel)	60 a 70%	Faixa estimada de mercado
Captura pixel + CAPI	~95%	Faixa de mercado alinhada à narrativa da Meta
Opt-in do ATT no lançamento (iOS 14.5)	~11% global / ~4% EUA	Flurry, abril de 2021
Opt-in do ATT até Q1 2024	~50% global / ~44% EUA	AppsFlyer
Janela de atribuição padrão da Meta	7 dias clique / 1 dia visualização	Meta, desde 26/04/2021

O número-âncora é o 13% de melhora no custo por resultado. Esse é o dado mais sólido do tema, e por um motivo: não é estimativa de vendor. É uma meta-análise da própria Meta, com 15 experimentos A/B, a 99% de confiança, rodada entre maio de 2024 e janeiro de 2025 em APAC, EMEA e América do Norte. Tem amostra, tem intervalo de confiança, tem período, tem região. Quando alguém disser que CAPI "não muda nada", esse é o número que responde.

Repare também na divergência do opt-in do ATT. A Flurry mediu cerca de 11% no lançamento. A AppsFlyer chegou a 50% em Q1 2024. As duas estão certas: medem coisas diferentes, em momentos diferentes, com bases diferentes. A lição vale para todo dado de tracking: número solto sem fonte é achismo disfarçado de fato. Quando você ler "X% dos usuários permitem rastreamento", a primeira pergunta é: segundo quem, e quando.

Um aviso de honestidade. Circulam por aí números como "17,8% de queda no custo" e "23% de redução de CPA com Signals Gateway" atribuídos à Meta. Não consegui confirmar a fonte primária de nenhum dos dois. Provavelmente são blogs de fornecedor projetando. O número confirmado e defensável é 13%. Prometer mais do que o dado sustenta é o tipo de coisa que destrói credibilidade na primeira contestação.

O contexto que explica a urgência: por que o tracking quebrou

Para entender por que a CAPI deixou de ser "nice to have" e virou obrigatória, você precisa saber o que o ATT fez.

Antes de abril de 2021, a Meta tinha um identificador que seguia o usuário entre apps no iPhone. Com o App Tracking Transparency, todo app passou a ter que pedir permissão. A maioria dos usuários disse não. Sem o identificador, a Meta perdeu a visão cross-app no iOS.

O efeito em cascata foi brutal. A Meta passou a sub-reportar conversões em uma faixa estimada de 15 a 30% em média no pós-ATT, segundo agências, com casos chegando perto de 50% dependendo de quanto da base é iOS. (De novo: faixa estimada de mercado, não estudo oficial.) E a janela de atribuição padrão encolheu de 28 dias de clique para 7 dias de clique, 1 dia de visualização, para campanhas iniciadas a partir de 26 de abril de 2021. No iOS, só o evento de maior prioridade é enviado, e com atraso de até 72 horas.

Tradução para o caixa: o número no seu gerenciador "encolheu da noite para o dia" não porque a mídia piorou, mas porque a régua de medição mudou. Campanha curta perde a conversão que acontece depois da janela. O algoritmo otimiza com menos sinal. E você toma decisão de orçamento em cima de um relatório que enxerga menos do que a realidade. A CAPI é o que devolve parte desse sinal para a Meta. É o mesmo diagnóstico que detona qualquer leitura de retorno de mídia, e que detalho em Seu ROAS é mentira: o problema raramente é a campanha, é o tracking por baixo dela.

Antes de mexer em qualquer coisa, vale o mesmo princípio de toda operação: medir onde está o gargalo antes de otimizar. Como diagnosticar um funil furado é o passo anterior a esse. Tracking quebrado é um dos vazamentos, não o único.

Sobre LGPD: o antídoto contra o mito

Existe uma crença perigosa de que server-side "fura" o consentimento, como se mandar o dado pelo servidor escondesse o usuário da lei. Errado, e perigoso para a marca.

Server-side não dispensa consentimento. O dado de um usuário que não consentiu não pode ser enviado, ponto. O que a CAPI e o GTM server-side oferecem é controle: você decide o que sai do seu servidor, pode filtrar e anonimizar o que vai para a Meta, o que na prática ajuda na conformidade com LGPD e GDPR. A diferença honesta é essa: server-side dá controle sobre o dado distribuído, não passe livre para ignorar a permissão. Quem vende como "driblar o consentimento" está vendendo um risco jurídico embrulhado de solução técnica.

Implementação: o que fazer na segunda-feira

Você não precisa da arquitetura perfeita amanhã. Precisa parar de mandar sinal quebrado para a Meta. Nesta ordem:

1. Confirme que o pixel já está instalado e disparando certo. A CAPI trabalha com o pixel, não no lugar dele. Antes de adicionar a camada server-side, garanta que a base está de pé. Use o Test Events da Meta para ver os eventos chegando.

2. Padronize o event_id em todos os eventos. Esse é o passo que faz ou quebra tudo. O mesmo evento, disparado pelo pixel e pela CAPI, precisa carregar o mesmo event_id. Sem isso, você cria contagem dobrada. Comece pelo evento que mais importa: a compra.

3. Escolha o caminho de envio. Há três rotas: o Conversions API Gateway da Meta (mais direto, menos controle), o GTM server-side (mais controle, mais setup) ou integração direta via servidor próprio (máximo controle, exige dev). Para a maioria das operações, o Gateway ou o GTM server-side resolvem sem reinventar a roda.

4. Maximize o match rate. Quanto mais dados de matching com hash você enviar (e-mail, telefone), maior a chance da Meta casar a conversão com o usuário. Match rate baixo significa CAPI rodando, mas com metade da força. Monitore esse número na própria interface da Meta.

5. Valide a deduplicação antes de confiar no relatório. Olhe no gerenciador se os eventos estão sendo deduplicados (a Meta mostra). Se você vir conversões dobrando, o event_id não está batendo. Conserte antes de tomar qualquer decisão de orçamento em cima desse dado.

6. Respeite o consentimento na origem. Configure o filtro para não enviar dado de quem não consentiu. Isso não é detalhe legal opcional: é o que mantém a operação limpa e fora de risco.

A CAPI não é mágica nem moda. É a peça que devolve para a Meta o sinal que o navegador apaga, e os 13% de melhora no custo por resultado, medidos pela própria Meta, são a prova de que sinal limpo vira leilão mais barato. O anunciante que continua rodando só no pixel está otimizando campanha com um relatório que enxerga 60% da realidade, e pagando o preço dessa cegueira em CPA inflado.

A diferença entre os dois não é orçamento. É engenharia de tracking.