API de Conversões da Meta no E-commerce: Pixel + Servidor do Jeito Certo

Compare as compras que o pixel da Meta reportou no mês passado com os pedidos no admin da sua loja. Os números não vão bater. Bloqueadores de anúncio matam o script antes de ele carregar, iOS e Safari estrangulam os cookies, banners de consentimento o suprimem, e parte dos compradores fecha a aba antes de a página de obrigado disparar. Cada uma dessas compras perdidas é uma venda com a qual o algoritmo da Meta nunca aprendeu — e um pedido pelo qual suas campanhas não recebem crédito nenhum.

A API de Conversões existe para fechar exatamente esse buraco. Este guia cobre o que a CAPI realmente é, por que a configuração recomendada é redundância e não substituição, como a deduplicação por event_id mantém seus números honestos, e quais campos de dados do usuário elevam o Event Match Quality o suficiente para fazer diferença.

O Que a API de Conversões Realmente É

O pixel do navegador é um JavaScript rodando dentro do navegador do visitante. Ele observa o que acontece na página e reporta à Meta — desde que nada o impeça.

A API de Conversões é o mesmo fluxo de eventos enviado a partir do seu servidor. Quando um pedido cai no seu backend — confirmado, pago, real — o seu sistema faz uma chamada HTTPS para o endpoint da Meta com o evento. Não há script para bloquear, não há cookie de terceiros para expirar, não há dependência de o navegador do comprador sobreviver ao checkout. Se o pedido existe no seu banco de dados, o evento chega.

Duas coisas que a CAPI não é:

• Uma taxonomia de eventos diferente. Eventos de servidor usam os mesmos nomes do pixel — Purchase, AddToCart, InitiateCheckout — então suas campanhas e conversões personalizadas continuam funcionando sem mudança.
• Um substituto do pixel. Enviar só eventos de servidor joga fora o contexto de navegador que o servidor nunca enxerga. O padrão recomendado é os dois, juntos.

Por Que Redundância Vence Substituição

Pixel e servidor têm pontos cegos — e, convenientemente, pontos cegos diferentes:

Rode os dois e cada um cobre as falhas do outro. Conta ilustrativa (não é benchmark): se a sua loja fatura 1.000 pedidos por mês e o pixel só consegue disparar em 850 deles, uma configuração só-pixel deixa 150 compras invisíveis para a otimização e a atribuição da Meta. A configuração redundante entrega os 1.000 — e a deduplicação garante que a Meta conte 1.000, não 1.850.

Essa segunda metade é a parte que as equipes erram.

Uma Venda, Um Evento: Deduplicação por event_id

Com redundância, a Meta recebe a maioria das compras duas vezes — uma do pixel, outra do seu servidor. O contrato de deduplicação é simples: as duas cópias precisam carregar o mesmo event_name e o mesmo event_id. Quando a Meta vê o par, mantém uma e descarta a outra (documentação de deduplicação).

A escolha natural para o event_id é o ID do pedido — é único, estável e os dois lados conseguem conhecê-lo na hora do disparo.

O que dá errado na prática:

• Cada lado gera o próprio ID aleatório. A Meta vê dois eventos distintos, conta a venda duas vezes, e o seu ROAS reportado infla exatamente na proporção dos pedidos em que ambos disparam.
• Um dos lados omite o event_id. Mesmo resultado: sem chave, sem dedup.
• Os IDs batem mas os nomes de evento não (Purchase vs. purchase numa integração feita à mão). O par nunca se junta.

Se você ligou a CAPI e as conversões "saltaram" na mesma semana, verifique a deduplicação antes de comemorar. O salto costuma ser contagem dupla fantasiada de sucesso.

Event Match Quality: A Nota Que Decide Se Seus Dados Valem

Um evento de servidor só serve se a Meta conseguir ligá-lo a uma pessoa. O Event Match Quality (EMQ) é a nota de 1 a 10 no Gerenciador de Eventos que avalia exatamente isso, por tipo de evento (sobre o EMQ). EMQ baixo significa que os eventos chegam mas não correspondem a ninguém — eles existem e não mudam nada.

Os campos de user_data que elevam a nota:

• E-mail (hash SHA-256) — o identificador que carrega o piano. Seu checkout o tem em todo pedido; envie em todo evento de compra.
• Telefone (hash SHA-256) — forte sozinho, mais forte combinado com o e-mail.
• Endereço IP do cliente + user agent — contexto de navegador que o servidor precisa repassar explicitamente, já que a requisição para a Meta sai do seu datacenter, não do aparelho do comprador.
• Cookie fbp — o identificador de navegador da Meta, gravado pelo pixel no seu domínio.
• Cookie fbc — presente quando a visita veio de um clique em anúncio da Meta; carrega o ID do clique e é a linha mais direta de volta à campanha.
• external_id — o seu próprio ID de cliente, útil para compradores recorrentes.

O pixel envia fbp e fbc automaticamente. O seu servidor não os tem, a menos que algo os tenha capturado no momento do clique e guardado junto da sessão, para serem reaproveitados quando o pedido chegar minutos ou dias depois. Esse encanamento é a lacuna mais comum nas integrações de CAPI feitas em casa — e é exatamente para isso que serve uma camada de rastreamento first-party. O pipeline do Decisa, por exemplo, registra fbc, fbp e IDs de clique no instante em que o visitante chega, e os anexa ao pedido verificado antes de empurrar o evento pelo servidor — a compra chega com a carga de identidade completa, em vez de um e-mail pelado.

Colocando Compras Verificadas no Ar Esta Semana

1. Mantenha o pixel. Redundância é o padrão; nada é arrancado.
2. Escolha a sua fonte server-side. Integração nativa da plataforma (Shopify e os grandes checkouts têm), um gerenciador de tags server-side, uma integração direta com a API, ou uma plataforma de atribuição que envia por você. Integrações diretas dão mais controle sobre o user_data.
3. Defina event_id = ID do pedido nos dois lados. O evento de compra do pixel e o do servidor precisam carregar o valor idêntico.
4. Envie o user_data mais rico que puder, dentro da lei. E-mail e telefone com hash a partir do pedido, IP e user agent da sessão original, fbp/fbc capturados no clique.
5. Verifique no Gerenciador de Eventos antes de confiar em qualquer coisa. Use a ferramenta de eventos de teste, confirme que os eventos de servidor chegam, confirme que os duplicados estão sendo deduplicados e acompanhe a nota de EMQ do evento de Purchase.
6. Envie a verdade, não o carrinho. Reporte o valor realmente cobrado, dispare só com pagamento confirmado e trate reembolsos — um algoritmo treinado com pedidos cancelados otimiza para pedidos cancelados.

O pixel conta para a Meta o que aconteceu no navegador. A CAPI conta para a Meta o que aconteceu no seu negócio. Um e-commerce precisa dos dois — amarrados pelo mesmo event_id, carregando identidade suficiente para o match — porque as campanhas só conseguem otimizar para as vendas que têm permissão de ver.