Meta Conversions API (CAPI): o guia técnico para quem faz tráfego

# Meta Conversions API (CAPI): o guia técnico para quem faz tráfego

Durante anos, o Pixel do Facebook foi suficiente. Um trecho de JavaScript no navegador do usuário disparava eventos — PageView, AddToCart, Purchase — e a Meta usava esses sinais para otimizar campanhas, atribuir conversões e construir públicos. O modelo funcionava porque o navegador era um canal confiável: o código rodava, o cookie persistia, o evento chegava.

Esse mundo acabou. Bloqueadores de anúncios interceptam o script antes que ele carregue. O App Tracking Transparency (ATT) do iOS, lançado em abril de 2021, deu ao usuário o poder de negar o rastreamento entre apps — e a maioria negou. Navegadores como Safari e Firefox limitaram a vida útil de cookies de terceiros a dias, às vezes horas. O resultado prático é que uma parcela relevante das conversões reais simplesmente nunca chega à Meta pelo navegador. E campanha otimizada sobre sinal incompleto entrega pior, custa mais e mente sobre o próprio desempenho.

A Conversions API (CAPI) é a resposta da Meta para essa erosão. Este guia é técnico e concreto: o que a CAPI é de fato, como um evento server-side é estruturado, por que o hashing importa, o que é qualidade de correspondência (EMQ) e onde a maioria das implementações falha.

O que é a Conversions API e por que ela existe

A CAPI é uma interface que permite ao seu servidor enviar eventos de conversão diretamente para a Meta, sem depender do navegador do usuário. Em vez de o Pixel dizer "esse browser acabou de comprar", o seu backend diz "essa compra aconteceu, aqui estão os dados para correspondência".

A diferença é de canal, não de propósito. O Pixel vive no cliente, exposto a bloqueadores, extensões, falhas de rede e restrições de cookie. A CAPI vive no servidor, num canal que você controla. Quando um pedido é confirmado no seu e-commerce, no seu CRM ou no seu gateway de pagamento, essa informação existe de forma inequívoca — ela não depende de um script sobreviver ao navegador do usuário.

Vale destacar o que a CAPI não é. Ela não substitui a atribuição da Meta por uma sua; a Meta continua sendo quem decide qual evento credita a qual anúncio. Ela também não é um atalho para rastrear quem recusou consentimento — os requisitos de privacidade e a governança de dados continuam valendo integralmente. A CAPI recupera o sinal de conversões legítimas que se perderiam por limitação técnica do navegador, não amplia o que você tem direito de coletar.

Pixel e CAPI: rivais ou complementares?

A pergunta mais comum é se a CAPI substitui o Pixel. Não substitui. A arquitetura recomendada pela Meta é redundante por desenho: os dois canais operam em paralelo, cada um cobrindo o ponto cego do outro.

O Pixel captura sinais ricos de comportamento no navegador — rolagem, cliques, navegação — e o contexto do cookie de primeira parte. A CAPI garante que o evento crítico, a conversão, chegue mesmo quando o Pixel é bloqueado. Juntos, elevam a taxa de eventos recebidos.

O preço dessa redundância é que o mesmo evento tende a chegar duas vezes: uma pelo navegador, outra pelo servidor. Sem tratamento, a Meta contaria a mesma compra em dobro, inflando resultados e envenenando a otimização. É por isso que a deduplicação de eventos é o alicerce de qualquer implementação híbrida séria — o tema que detalhamos em como a deduplicação entre Pixel e CAPI realmente funciona. O ponto a fixar aqui: rodar CAPI sem uma estratégia de deduplicação não é uma implementação incompleta, é uma implementação errada.

Anatomia de um evento server-side

Um evento CAPI é um objeto estruturado. Entender cada campo é o que separa quem configura de quem depura. Os campos que importam:

<code>event_name</code>

O tipo de evento, no vocabulário padrão da Meta: Purchase, Lead, AddToCart, InitiateCheckout, CompleteRegistration. Usar um nome padrão importa: é o que permite à Meta mapear o evento para otimização e para eventos personalizados de conversão. Nome inventado vira evento genérico, que otimiza pior.

<code>event_time</code>

O momento em que o evento ocorreu, em Unix timestamp (segundos). A Meta aceita eventos com atraso de até sete dias, o que é fundamental para conversões que se confirmam depois — um pagamento por boleto, uma venda que só vira Purchase quando o financeiro concilia. Enviar o event_time real da conversão, e não o momento do disparo, mantém a atribuição temporal correta.

<code>event_id</code>

O identificador único do evento. É a chave de deduplicação: quando o mesmo evento chega pelo Pixel e pela CAPI carregando o mesmo event_id (e o mesmo event_name), a Meta reconhece que são a mesma ocorrência e conta uma vez só. Gerar esse ID de forma consistente entre os dois canais é a parte da implementação que mais gente erra.

<code>action_source</code>

Onde a conversão aconteceu: website, app, phone_call, chat, physical_store, system_generated. Não é decorativo — a Meta usa esse campo para calibrar a atribuição e validar a coerência do evento. Uma compra em site com action_source errado degrada a qualidade do sinal.

<code>user_data</code>

O coração da correspondência. É o conjunto de sinais que a Meta usa para associar o evento a uma pessoa real da sua base. Inclui e-mail, telefone, nome, cidade, CEP, além de identificadores de navegador como fbp e fbc. É aqui que o hashing entra — e é aqui que a maioria das implementações vaza qualidade.

Por que o hashing é obrigatório — e como fazer certo

Dados pessoais como e-mail e telefone não podem ser enviados em texto puro para a CAPI. Eles precisam ser transformados com SHA-256 antes de sair do seu servidor. A Meta, do outro lado, mantém os dados dos seus usuários também em SHA-256; a correspondência acontece comparando hashes, nunca valores em claro. Assim, nenhuma das partes precisa expor o dado bruto para que o pareamento ocorra.

O detalhe fatal é a normalização. SHA-256 é determinístico: a mesma entrada gera sempre o mesmo hash, mas qualquer diferença — uma letra maiúscula, um espaço, um símbolo — produz um hash completamente diferente. Se você não normalizar exatamente como a Meta espera, o hash não bate com o dela e a correspondência falha em silêncio. O evento chega, é aceito, e não casa com ninguém.

As regras de normalização antes do hash:

• E-mail: remover espaços nas bordas e converter tudo para minúsculas. João@Email.com vira joao@email.com, e só então passa pelo SHA-256.
• Telefone: formato internacional, só dígitos, com código do país e sem +, sem parênteses, sem traços. Um número brasileiro vira algo como 5511999998888.
• Nome, cidade, estado: minúsculas, sem espaços extras, sem acento quando a Meta assim especifica para o campo.
• CEP: só dígitos, sem hífen.

O padrão de implementação correto é: normalizar, depois aplicar SHA-256, depois enviar. Nunca hashear o valor bruto direto. E jamais enviar o fbp/fbc hasheados — esses são identificadores de cookie e vão em texto puro, ao contrário dos dados pessoais.

<code>fbp</code> e <code>fbc</code>: os identificadores de navegador

O fbp (_fbp) é um cookie de primeira parte que o Pixel cria para identificar o navegador. O fbc (_fbc) codifica o fbclid — o parâmetro que a Meta anexa à URL quando alguém clica no anúncio. Esses dois são os sinais de correspondência mais potentes que existem, porque ligam o evento diretamente ao clique no anúncio. Capturar fbp e fbc no navegador e propagá-los até o evento server-side é o que preserva a linha entre o clique pago e a conversão. Perder esses campos no caminho é perder a atribuição mais valiosa que você tem.

EMQ: a nota da sua correspondência

A Meta atribui a cada fonte de eventos uma pontuação de qualidade da correspondência de eventos (EMQ — Event Match Quality), tipicamente numa escala de 0 a 10. Ela mede quão bem os dados enviados permitem casar o evento com uma pessoa. Não é vaidade de painel: EMQ baixo significa menos conversões atribuídas, públicos menores e otimização mais fraca — a mesma verba entregando menos.

O que move o EMQ para cima é a quantidade e a qualidade dos parâmetros de user_data enviados corretamente. Enviar só e-mail dá um EMQ modesto. Enviar e-mail + telefone + nome + cidade + CEP + fbp + fbc, todos normalizados e hasheados corretamente, eleva o EMQ de forma substancial. Cada campo adicional é uma chave extra para o pareamento acertar.

O ponto contraintuitivo: adicionar mais campos só ajuda se eles estiverem corretos. Um telefone mal normalizado não melhora o EMQ — ele adiciona ruído. É por isso que "aumentar o EMQ" quase nunca é sobre coletar mais dado, e quase sempre sobre parar de corromper o dado que você já tem.

Os erros de implementação que corroem o sinal

Na prática, os mesmos problemas se repetem:

• event_id inconsistente entre Pixel e CAPI. Sem uma chave de deduplicação idêntica nos dois canais, ou você conta em dobro, ou desativa um canal e volta a ter ponto cego.
• Normalização ausente ou parcial. Hashear e-mail com maiúsculas, telefone com máscara, CEP com hífen. O evento é aceito e não casa. Falha silenciosa, a pior de todas.
• Perder fbp/fbc no trajeto. Muito comum em arquiteturas onde o backend que dispara a CAPI não tem acesso ao contexto do navegador. A conversão chega, mas desconectada do clique.
• event_time do disparo, não da conversão. Especialmente danoso para conversões atrasadas (boleto, aprovação manual, venda offline), que chegam com o carimbo errado.
• Disparar sobre intenção, não sobre confirmação. Contar Purchase no clique de "finalizar pedido", antes de o pagamento ser aprovado, ensina a Meta a otimizar para carrinhos abandonados. O evento tem que refletir o que realmente aconteceu.

Esse último ponto é o mais estrutural. A CAPI é tão boa quanto o momento em que você a dispara. Se o sinal sai antes da conversão existir, nenhum hashing perfeito conserta.

Onde uma camada de consolidação muda o jogo

O padrão fragmentado é montar a CAPI dentro de cada plataforma isoladamente: um script no site, uma automação no checkout, um webhook no CRM. Cada ponto normaliza do seu jeito, gera event_id do seu jeito, decide sozinho quando disparar. O resultado é sinal inconsistente, deduplicação frágil e conversões contadas quando não deviam.

Uma camada de consolidação inverte isso. Em vez de cada plataforma falar direto com a Meta, os dados de conversão convergem para um ponto único — que enxerga a jornada inteira: o clique no anúncio (com fbp/fbc), o pedido no e-commerce, a confirmação de pagamento no gateway, o status no CRM. Esse ponto único dispara o evento uma vez, quando a conversão de fato se confirma, com o event_data completo e normalizado de forma consistente, e com o event_id coerente para deduplicação.

Os ganhos técnicos são diretos: EMQ mais alto porque a camada agrega todos os identificadores disponíveis da jornada; zero disparo falso porque o gatilho é a conversão real, não a intenção; deduplicação confiável porque o event_id nasce de uma fonte única, não de dois canais tentando adivinhar. É a diferença entre alimentar a Meta com um fluxo limpo de conversões confirmadas e alimentá-la com fragmentos que ela precisa reconciliar sozinha.

A Conversions API resolve o problema do canal — tirar o sinal da dependência do navegador. Mas o canal só entrega o que você coloca nele. Enviar dados corretos, hasheados corretamente, no momento certo da conversão real, é o que transforma a CAPI de "mais uma integração" em uma fonte de verdade sobre o que a sua verba efetivamente comprou.