Conversions API da Meta explicada para quem não é dev

A Conversions API (CAPI) é um canal para o seu servidor enviar à Meta os eventos de negócio, como compra e lead, sem depender só do navegador. Ela não substitui o Pixel: a Meta recomenda usar os dois ao mesmo tempo, compartilhando os mesmos eventos. Para a Meta não contar a mesma compra duas vezes, cada evento leva um event_id igual nos dois canais.

O que a Conversions API resolve

O Pixel roda no navegador da pessoa. A CAPI roda no seu servidor, que já sabe quando um pedido foi pago, quando um lead foi qualificado ou quando uma venda fechou no CRM. A documentação da Meta descreve a CAPI como uma conexão entre os dados de marketing do anunciante e a Meta, a partir de servidores, sites, apps e CRMs, usada para melhorar a segmentação, reduzir o custo por resultado e medir resultados.

Um ponto que ajuda a perder o medo: segundo a documentação, os eventos de servidor são processados como os eventos enviados pelo Pixel. Ou seja, eles servem para medição, relatórios e otimização do mesmo jeito. Não existe um "tipo de conversão" separado para a CAPI.

Isso não significa que a CAPI corrija qualquer problema de medição. Ela envia o que o seu servidor sabe. Se o servidor registra o evento errado, a Meta recebe o evento errado.

Pixel e CAPI juntos, não um no lugar do outro

A página de boas práticas diz: use a Conversions API além do Pixel da Meta e compartilhe os mesmos eventos pelas duas ferramentas. A consequência é direta. Se os dois canais mandam a mesma compra, a Meta recebe duas notificações da mesma venda. Sem um jeito de reconhecer que são a mesma, o relatório mostraria o dobro.

Deduplicação: o papel do event_id

Para a Meta tratar dois eventos como um só, a documentação pede estas correspondências:

• o eventID do Pixel deve ser igual ao event_id da CAPI;
• o event do Pixel deve ser igual ao event_name da CAPI.

Se as duas chaves batem e os eventos foram enviados ao mesmo Pixel ID em até 48 horas, a Meta descarta os eventos seguintes. Quando o conteúdo dos dois eventos não difere de forma relevante, a documentação diz que a Meta em geral prefere o evento recebido primeiro. A página não define o que é "difere de forma relevante", então não conte com uma regra além dessa.

O event_id é opcional, mas recomendado. A documentação diz que ele pode ser qualquer texto único escolhido por você, e cita número de pedido ou identificador de transação como boas opções. Se não houver um identificador natural, vale um valor aleatório, desde que seja o mesmo no evento do navegador e no do servidor.

Existe um plano B, mas ele é mais frágil

A Meta também descreve deduplicação por event_name mais fbp e/ou external_id. O fbp é o identificador do navegador, vindo do cookie _fbp; o external_id é um identificador seu para a pessoa. A própria documentação lista uma limitação: o evento de servidor não é descartado se nenhum evento de navegador foi recebido nas últimas 48 horas, mesmo que um evento de navegador idêntico chegue depois do de servidor.

E um aviso importante: a deduplicação não acontece quando você usa uma única fonte, só navegador ou só servidor. Ela serve para o par Pixel mais CAPI.

Um exemplo hipotético do estrago

Os números abaixo são inventados para ilustrar a conta. Uma loja gasta R$ 10.000 em anúncios em um mês e vende 100 pedidos de R$ 300, o que dá R$ 30.000 de receita e ROAS de 3,0 (30.000 ÷ 10.000). Suponha que o Pixel registre 70 desses pedidos e que o servidor envie os 100. Sem event_id compartilhado, a Meta poderia receber 170 compras.

• Realidade

  Compras

  100

  Receita

  R$ 30.000

  ROAS

  3,0

• Pixel e CAPI sem event_id (hipótese)

  Compras

  170

  Receita

  R$ 51.000

  ROAS

  5,1

• Pixel e CAPI com event_id

  Compras

  100

  Receita

  R$ 30.000

  ROAS

  3,0

A conta confere: 170 × R$ 300 = R$ 51.000, e 51.000 ÷ 10.000 = 5,1. O ROAS inflado em 70% (5,1 contra 3,0) levaria a decisões de verba baseadas em um retorno que não existe. É a razão de conferir a deduplicação antes de qualquer outra otimização.

Os campos que a Meta pede em cada evento

Cada evento da CAPI tem um conjunto de campos. Segundo a documentação, os principais são:

• event_name: obrigatório, o nome do evento padrão ou personalizado.
• event_time: obrigatório, em segundos no formato Unix, no fuso GMT.
• action_source: obrigatório, diz onde a conversão aconteceu. Valores incluem website, app, email, phone_call, chat, physical_store, system_generated, business_messaging e other.
• event_source_url: obrigatório para eventos de site.
• client_user_agent: obrigatório para eventos de site enviados pela CAPI.
• event_id: opcional, mas recomendado.

Duas regras valem atenção. Primeiro, event_time pode ser de até 7 dias antes do envio. Se um único evento da requisição for mais antigo, a requisição inteira falha e nenhum evento é processado. Em lote, um evento atrasado derruba todos. Segundo, ao usar a CAPI você declara que o action_source é correto até onde sabe; para eventos offline, o valor não deve ser website.

Sobre o momento do envio, a documentação diz que você pode compartilhar os eventos em tempo real ou em lotes próximos do tempo real. Ela não dá um prazo em minutos, então a regra prática é o limite de 7 dias do event_time e a janela de 48 horas da deduplicação.

Dados do cliente e qualidade de correspondência

Para usar um evento na atribuição e na otimização da entrega, a Meta precisa associá-lo a uma pessoa. A documentação diz que só eventos correspondidos servem a esses dois usos, e que enviar mais parâmetros de informação do cliente pode ajudar a aumentar a qualidade de correspondência de eventos (Event Match Quality).

Os parâmetros incluem e-mail (em), telefone (ph), nome (fn, ln), fbp, fbc (do cookie _fbc, que guarda o identificador de clique), external_id, client_ip_address e client_user_agent. As regras de formato são rígidas:

• em, ph, fn, ln e outros campos pessoais devem passar por hash SHA-256 antes do envio.
• Antes do hash, o e-mail leva corte de espaços nas pontas e letras minúsculas. O telefone perde símbolos, letras e zeros à esquerda e inclui o código do país: o exemplo da Meta transforma (650) 555-1212 em 16505551212.
• client_ip_address, client_user_agent, fbp e fbc não passam por hash. O IP deve ser o real, em IPv4 ou IPv6 válido.
• external_id tem hash recomendado, não obrigatório.

A documentação também avisa que combinações amplas demais, como nome mais gênero (fn + ge), são inválidas para correspondência. Não adianta enviar muitos campos fracos: um e-mail ou telefone correto vale mais.

Como o Relator entra nisso

O Relator Digital conecta a Meta, o Google Ads, o GA4 e o CRM do cliente em uma base só, e cruza os negócios ganhos no HubSpot ou no RD Station CRM com a campanha que trouxe o lead. Ele não envia eventos para a Meta pela CAPI. O papel dele aqui é outro: ajudar a conferir se o que a Meta reporta anda coerente com a receita que o CRM registra.

Como aplicar

1. 1.Liste os eventos que importam (compra, lead, lead qualificado) e confirme que o Pixel já os envia.
2. 2.Escolha um event_id por evento, de preferência o número do pedido ou o identificador do lead, e use o mesmo valor no Pixel e na CAPI.
3. 3.Mantenha event_name idêntico nos dois canais.
4. 4.Envie em cada evento de site action_source, event_source_url e client_user_agent.
5. 5.Adicione em e ph normalizados e com hash SHA-256 quando tiver base legal, além de fbp e fbc quando existirem.
6. 6.Nunca envie evento com mais de 7 dias de event_time: separe os atrasados antes de montar o lote.
7. 7.Compare por uma semana as compras da Meta com as do seu servidor. Se a Meta mostrar bem mais, suspeite de deduplicação.

Fontes

Todas conferidas em 15 de outubro de 2026. Ficou de fora, por não termos conseguido ler a página de Ajuda da Meta, a pontuação e a escala da qualidade de correspondência de eventos, além do código de exemplo do Pixel com eventID.

• Meta for Developers, Conversions API: o que a API faz e que os eventos são processados como os do Pixel.
• Meta for Developers, Best Practices: uso junto com o Pixel, campos obrigatórios e qualidade de correspondência.
• Meta for Developers, Deduplicate Pixel and Server Events: regras de event_id, event_name, janela de 48 horas e plano B com fbp.
• Meta for Developers, Server Event Parameters: event_time com limite de 7 dias, action_source e event_source_url.
• Meta for Developers, Customer Information Parameters: hash SHA-256 e normalização.