API de Conversões (CAPI): o que é e como funciona

Se você já viu a sigla CAPI em qualquer conversa sobre Meta Ads e ficou com dúvida do que exatamente ela resolve, este guia é pra isso. E se seu funil passa por Telegram, vale prestar atenção: aqui, CAPI não é um recurso avançado opcional — é o único jeito de fechar o rastreamento de conversão de verdade.

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

A API de Conversões é o mecanismo que permite enviar eventos de conversão pro Meta Ads diretamente do servidor, sem depender de um script rodando no navegador de quem converteu. Ela existe, em boa parte, como resposta a um problema que cresceu nos últimos anos: bloqueadores de anúncio, restrições de rastreamento no navegador e no aparelho (como o Intelligent Tracking Prevention do Safari e o App Tracking Transparency da Apple) e políticas de privacidade cada vez mais restritivas reduziram a confiabilidade só do rastreamento client-side (via Pixel). O Meta passou a incentivar fortemente o uso combinado de Pixel e CAPI justamente pra compensar essa perda de sinal client-side com um canal mais resistente, que não depende do que acontece (ou deixa de acontecer) no navegador do usuário.

Em termos simples: o Pixel conta o que ele consegue observar de dentro do navegador; o CAPI conta o que o seu próprio sistema sabe que aconteceu, independente do que o navegador reportou (ou deixou de reportar).

CAPI vs Pixel: o que muda

O Pixel roda no navegador de quem visita sua página — é código JavaScript que dispara um evento (PageView, Lead, Purchase) no momento em que algo acontece na tela. O CAPI faz a mesma coisa conceitualmente (informa ao Meta que um evento de conversão aconteceu), mas via uma chamada HTTP autenticada, feita pelo servidor, sem passar pelo navegador em nenhum momento.

Na maioria dos funis web, a recomendação é rodar os dois ao mesmo tempo: o Pixel captura o que consegue no navegador, o CAPI reforça com o mesmo evento (ou eventos que o navegador não conseguiu capturar), e a Meta deduplica os dois quando chegam com o mesmo event_name e o mesmo event_id — cobrindo as lacunas um do outro. Num funil de Telegram com a Track4you a recomendação é outra: o script já cobre os eventos da página, então não se instala um Pixel à parte (detalhes no fim do artigo).

CAPI em diferentes contextos de funil

Vale situar onde o CAPI se encaixa em cada tipo de funil, porque a “obrigatoriedade” dele muda bastante:

• Site/e-commerce comum: o Pixel funciona, mesmo que com perda de sinal variável (bloqueadores, navegadores mais restritivos). CAPI complementa, reforçando o que o Pixel perde.
• App mobile: o rastreamento tende a depender mais de SDKs específicas de mobile measurement, mas o princípio de complementar sinal client-side com server-side se mantém.
• Telegram: não existe navegador nem SDK de app rodando durante a interação dentro do canal — CAPI deixa de ser complemento e vira o único canal de sinal possível pro evento de entrada/saída/depósito.

Por que no Telegram o CAPI não é opcional

Aqui está a diferença que importa pra quem roda tráfego pra Telegram: num site comum, mesmo que o Pixel perca sinal por bloqueio de rastreamento, ele ainda tem uma página rodando, um navegador, um DOM. No Telegram, depois que a pessoa sai do seu site (ou da sua página intermediária) e entra no app do Telegram, não existe navegador nenhum acompanhando o que acontece — o evento de entrada no canal só existe dentro da própria API do Telegram, observável por um bot.

Isso significa que não tem “Pixel reforçado por CAPI” pra esse evento específico — o CAPI é a única forma de esse dado chegar ao Meta. Ver o guia de Pixel/CAPI no Telegram pro fluxo técnico completo desse caso.

Como funciona tecnicamente

Uma chamada de evento pra CAPI carrega, no mínimo: o nome do evento (Lead, Purchase, ou um evento personalizado), o momento em que aconteceu de verdade (não o momento do envio), a origem do evento (de onde ele foi gerado — navegador, sistema, chat), um identificador de deduplicação (event_id), dados do usuário disponíveis (os identificadores pessoais, como e-mail e telefone, em hash SHA-256; IP, user agent e os cookies fbp/fbc vão sem hash) e dados extras de valor, quando aplicável (como o valor de um depósito).

Em estrutura simplificada, uma chamada típica carrega algo como:

event_name: "Lead"
event_time: 1752480000
action_source: "system_generated"
event_id: "abc123"
user_data: { em: "hash_do_email", client_ip_address: "..." }
custom_data: { value: 50, currency: "BRL" }

Cada implementação (bot próprio, ferramenta dedicada) monta essa estrutura de um jeito ligeiramente diferente por baixo dos panos, mas os campos conceituais são sempre esses. Ver o guia de Pixel/CAPI no Telegram pra um passo a passo detalhado desses campos aplicado ao caso específico de entrada de canal.

Por que os identificadores pessoais precisam vir em hash

Quando a chamada inclui e-mail, telefone ou outro identificador pessoal (nome, ID externo), a Meta exige que venha processado em SHA-256 — uma função que transforma o dado original numa sequência de caracteres irreversível. Isso permite que a Meta compare o hash recebido com hashes que ela já tem (de contas de usuário, por exemplo) sem que o dado pessoal em si trafegue ou fique armazenado em texto puro em nenhum momento do processo. Dados técnicos da sessão — IP, user agent e os cookies fbp/fbc — ficam fora dessa regra e vão sem hash.

Deduplicação e Event Match Quality, explicados

Deduplicação é o mecanismo que impede o Meta de contar duas vezes o mesmo evento quando ele chega tanto via Pixel quanto via CAPI — os dois precisam chegar com o mesmo event_name e o mesmo event_id pra o Meta entender que são a mesma conversão vista por dois caminhos.

Event Match Quality (EMQ) é a nota que o Meta dá pra quão bem ele consegue associar aquele evento a uma pessoa/anúncio específico, com base em quantos campos de user_data a chamada inclui (e-mail, telefone, IP, cookies do Pixel). Quanto mais completo o conjunto de dados enviado, mais alto tende a ser o EMQ — e eventos com EMQ baixo tendem a contribuir menos pra otimização de campanha, mesmo estando “corretos”.

A nota fica nos detalhes de cada evento, na Visão geral do pixel no Gerenciador de Eventos (não na aba Eventos de Teste), e vale a pena acompanhá-la periodicamente, não só configurar uma vez e esquecer: mudanças na sua página, no bot ou na forma como os dados são coletados podem impactar o EMQ ao longo do tempo, silenciosamente, sem nenhum erro visível — só uma piora gradual na qualidade da otimização.

Erros comuns de quem está aprendendo CAPI agora

• Confundir CAPI com “melhoria” do Pixel: em contextos onde não existe navegador (como Telegram), CAPI não melhora nada — é o único caminho.
• Errar o que leva hash: identificadores pessoais (e-mail, telefone, nome, ID externo) precisam ir em SHA-256 — mandar em texto puro é erro de implementação. O contrário também acontece: IP, user agent e os cookies fbp/fbc vão sem hash, e hasheados a Meta não consegue usá-los.
• Testar só em produção: o Gerenciador de Eventos do Meta tem uma aba de Eventos de Teste especificamente pra validar chamadas de CAPI antes de rodar campanha de verdade com elas.
• Ignorar o event_time correto: o timestamp deve refletir quando o evento aconteceu de fato, não quando a chamada de API foi processada.
• Esquecer o event_id compartilhado (com o mesmo event_name): sem ele, Pixel e CAPI reportam o mesmo evento como se fossem dois — inflando artificialmente o resultado da campanha.
• Mandar poucos campos de user_data: uma chamada tecnicamente correta, mas com pouquíssimo dado de usuário, ainda assim tende a ter EMQ baixo — vale enviar todos os campos disponíveis, não só o mínimo pra chamada não ser rejeitada.

Onde a Track4you entra nisso

Pro caso específico de Telegram, a Track4you monta e dispara essas chamadas prontas, sem exigir que você implemente do zero a integração técnica descrita acima. Você cadastra o pixel (ID + token da API de Conversões), passa pelo “Evento Teste” e cria o funil; a partir daí, cada etapa chega no pixel como um evento: ViewContent na visita à página, Lead no clique no botão, enter_channel na entrada no canal (a conversão principal) e left_channel na saída. Junto dos eventos, a Track4you envia IP, user agent e os cookies fbp/fbc (quando disponíveis) — os dados de correspondência que alimentam o Event Match Quality, sem campo de user_data pra você montar.

Como o script já manda ViewContent e Lead pro pixel do funil, a recomendação da Track4you é não instalar o seu próprio Pixel nas páginas do funil. Se ele já estiver lá, a Meta deduplica automaticamente — ele só não é necessário.

Registro, FTD e depósito, que acontecem na plataforma e não no canal, chegam pelas Integrações (planos Pro e Enterprise), com postback S2S da plataforma — o FTD como o evento personalizado FTD e o depósito como Purchase. Toda conversão que chega pelo postback é enviada pro pixel, sem prazo do lado da Track4you, e vira sinal pro algoritmo; se ela é creditada a uma campanha no Gerenciador de Anúncios depende da janela de atribuição da Meta (padrão: 7 dias após o clique, 1 dia após a visualização). A lista completa está no help oficial, em quais eventos a Track4you manda pro pixel; planos e condições, em track4you.app.

Perguntas frequentes

Termos relacionados (postback, deduplicação, Event Match Quality) também aparecem no glossário.

Conclusão

CAPI não é um recurso avançado pra quem “já domina o básico” — é a peça que fecha o rastreamento em qualquer contexto onde o navegador não está no meio do caminho, e no Telegram esse é sempre o caso. Entender a diferença entre Pixel e CAPI, por que um não substitui o outro em todo contexto, e o que realmente compõe uma chamada de evento bem-feita (nome, tempo, origem, deduplicação, dados de usuário com os identificadores pessoais em hash) é o primeiro passo pra qualquer configuração de rastreamento séria nesse canal — seja você quem vai implementar isso na mão ou só quer entender o que uma ferramenta dedicada está fazendo por trás do painel.