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

> O que a Conversions API resolve, como evitar compra contada duas vezes com o event_id e o que ajuda a Meta a reconhecer quem comprou.

- URL: https://relator.digital/blog/conversions-api-meta
- Publicado: 2026-10-15
- Atualizado: 2026-10-15
- Autor: Time Relator Digital
- Categoria: marketing-data

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.

> [!NOTE]
> **Em resumo**
> - A CAPI envia eventos do seu servidor, site, app ou CRM para a Meta; ela é processada como os eventos do Pixel.
> - O uso recomendado é Pixel e CAPI juntos, com os mesmos eventos.
> - Para deduplicar, o `event_name` e o `event_id` precisam ser idênticos nos dois canais, e os dois chegarem em até 48 horas.
> - Quanto mais dados do cliente (como e-mail e telefone em hash) o evento traz, maior a chance de a Meta reconhecer a pessoa.
> - Evento com mais de 7 dias derruba a requisição inteira.

## 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.

![Pixel e servidor enviam a mesma compra; a Meta mantém uma](https://uploads.relator.digital/blog/conversions-api-meta/bf3c3fc3-deduplicacao.pt-BR.svg "O mesmo event_id nos dois canais faz a Meta descartar o segundo evento")

## 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.

| Cenário | Compras | Receita | ROAS |
| --- | --- | --- | --- |
| Realidade | 100 | R$ 30.000 | 3,0 |
| Pixel e CAPI sem `event_id` (hipótese) | 170 | R$ 51.000 | 5,1 |
| Pixel e CAPI com `event_id` | 100 | R$ 30.000 | 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.

> [!WARNING]
> Os dados do cliente são dados pessoais. Antes de enviar e-mail ou telefone, confira com o cliente a base legal e o aviso de privacidade do site. Este artigo não trata dessa análise.

## 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. Liste os eventos que importam (compra, lead, lead qualificado) e confirme que o Pixel já os envia.
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. Mantenha `event_name` idêntico nos dois canais.
4. Envie em cada evento de site `action_source`, `event_source_url` e `client_user_agent`.
5. Adicione `em` e `ph` normalizados e com hash SHA-256 quando tiver base legal, além de `fbp` e `fbc` quando existirem.
6. Nunca envie evento com mais de 7 dias de `event_time`: separe os atrasados antes de montar o lote.
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](https://developers.facebook.com/docs/marketing-api/conversions-api/): o que a API faz e que os eventos são processados como os do Pixel.
- Meta for Developers, [Best Practices](https://developers.facebook.com/docs/marketing-api/conversions-api/best-practices): uso junto com o Pixel, campos obrigatórios e qualidade de correspondência.
- Meta for Developers, [Deduplicate Pixel and Server Events](https://developers.facebook.com/docs/marketing-api/conversions-api/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](https://developers.facebook.com/docs/marketing-api/conversions-api/parameters/server-event): `event_time` com limite de 7 dias, `action_source` e `event_source_url`.
- Meta for Developers, [Customer Information Parameters](https://developers.facebook.com/docs/marketing-api/conversions-api/parameters/customer-information-parameters): hash SHA-256 e normalização.