API de Conversões da Meta: o que é e porque o píxel já não basta

É uma queixa habitual: a loja regista cem encomendas numa semana e o Gestor de eventos da Meta mostra bastantes menos. O píxel está instalado e, mesmo assim, faltam conversões. As campanhas otimizam com esse dado incompleto.

A API de Conversões da Meta (Conversions API ou CAPI) existe para fechar essa lacuna. Explicamos o que é, como se configura sem contar duas vezes cada venda e o que verificar quando as compras não aparecem.

O que é a API de Conversões da Meta

É uma ligação direta entre o seu servidor, o seu CRM ou o seu e-commerce e a Meta. Em vez de depender de um script no navegador, o seu sistema envia cada evento (uma compra, um lead, um registo) com o seu nome, hora, valor, moeda e informação do cliente. A Meta usa-o tal como um evento do píxel: para atribuir, otimizar a entrega e construir públicos.

Porque é que o píxel perde eventos

O píxel só funciona se o navegador carregar o script, guardar os seus cookies e chegar a enviar o pedido. Qualquer um desses passos pode falhar:

• Bloqueadores de anúncios e de rastreio. Muitas extensões e alguns navegadores bloqueiam o script da Meta.
• Limites de cookies. O Safari, com a sua proteção ITP, e o Firefox encurtam a vida dos cookies criados a partir de JavaScript. Se o utilizador comprar dias depois do clique, o navegador pode ter esquecido de onde vinha.
• App Tracking Transparency no iOS. Os utilizadores de iPhone que rejeitam o rastreio entre apps reduzem a informação que a Meta pode usar para relacionar anúncio e compra.
• Consentimento rejeitado. Se o utilizador rejeitar os cookies de publicidade, o píxel não deve disparar. É o correto, e esses eventos não devem chegar por nenhuma via.
• Páginas que se fecham antes do tempo. Se o utilizador pagar num gateway de pagamento externo e não voltar à página de confirmação, a compra nunca é enviada.

A API resolve as falhas técnicas, porque o evento sai do seu servidor quando a encomenda é registada. O consentimento não o resolve, nem deve.

Píxel e API ao mesmo tempo: como desduplicar

A Meta recomenda uma configuração redundante: o píxel envia os eventos a partir do navegador e a API envia os mesmos a partir do servidor. Se um falhar, chega o outro. Se chegarem os dois, a Meta contaria a compra duas vezes.

Para o evitar, cada evento deve levar o mesmo event_name (por exemplo, Purchase) e o mesmo event_id nas duas vias. O event_id é gerado por si, por exemplo o número da encomenda. Se a Meta receber dois eventos com o mesmo nome e identificador num curto intervalo, fica com um.

Além disso, convém enviar pela API os cookies do píxel, _fbp (identificador do navegador) e _fbc (identificador do clique, derivado do fbclid do URL). Não substituem o event_id, mas ajudam a relacionar o evento com a visita e o clique.

Dados de cliente e qualidade da correspondência

Um evento do servidor não traz a sessão do navegador, por isso a Meta precisa de saber quem comprou por outra via: os parâmetros de informação do cliente, email, telefone, nome, apelido, cidade, código postal, país ou um identificador externo como o seu ID de cliente. Normalizam-se (minúsculas, sem espaços, telefone com indicativo) e encriptam-se com SHA-256. O IP e o agente de utilizador enviam-se sem encriptação.

No Gestor de eventos, cada evento tem uma pontuação de qualidade da correspondência (Event Match Quality), de 0 a 10, que indica até que ponto a Meta relaciona bem os seus eventos com os seus utilizadores. Se for baixa, costuma faltar algum parâmetro ou estar mal normalizado. O email e o telefone são os que mais pesam.

Quatro formas de a implementar

1. Integração de um parceiro

O Shopify, o WooCommerce e muitos CRM ativam a API sem programar. É a via mais rápida, embora controle pouco o que se envia.

2. Conversions API Gateway

Uma solução da Meta que se implementa na sua cloud e replica a partir do servidor os eventos do píxel. Pouco trabalho técnico, mas só envia o que o píxel já vê.

3. Google Tag Manager do lado do servidor

Se já tem um contentor server-side do GTM, uma etiqueta da API reencaminha para a Meta os eventos que recebe. Dá controlo sobre os dados e serve para outras plataformas.

4. Integração direta com a API

A sua equipa envia os eventos a partir do backend com um token de acesso. A opção mais flexível e a que exige mais manutenção.

Eventos offline e do CRM pela mesma API

A API também recebe resultados que ocorrem fora do site: um lead qualificado pela equipa comercial, uma venda por telefone ou uma compra em loja. Enviam-se para o mesmo conjunto de dados indicando a sua origem e a Meta atribui-os tal como uma compra online. Explicamo-lo em como enviar conversões offline para o Google Ads e a Meta.

Consentimento

Enviar a partir do servidor não muda as regras: se o utilizador rejeitou a publicidade personalizada, o seu evento também não deve chegar pela API. O seu servidor tem de conhecer a decisão registada no seu CMP e aplicá-la antes de cada envio.

O píxel não regista compras: como diagnosticar

1. Use a ferramenta de teste de eventos. Faça uma compra de teste e confirme no Gestor de eventos que o Purchase chega a partir do navegador, do servidor ou de ambos.
2. Reveja o separador de diagnóstico. A Meta avisa de parâmetros em falta, eventos sem desduplicar ou quedas bruscas de volume.
3. Verifique a página de confirmação. Se o pagamento termina num gateway externo e o utilizador não volta, o píxel não dispara. É a causa mais habitual de compras perdidas.
4. Compare com as suas encomendas. Compare uma semana de compras na Meta com as encomendas do seu e-commerce ou do seu ERP. Se a Meta registar menos, faltam eventos; se registar mais, provavelmente não está a desduplicar.

Erros habituais

• Não desduplicar. O píxel e a API enviam a mesma compra sem um event_id comum e a Meta conta-a duas vezes.
• Enviar poucos dados de cliente. Só o IP e o agente de utilizador dão uma correspondência baixa.
• Ignorar o consentimento. Enviar pelo servidor o que o utilizador rejeitou é um risco legal.
• Esquecer o valor e a moeda. Sem value e currency, a Meta não consegue otimizar por receita nem calcular o ROAS.

O Google e o TikTok têm equivalentes: as conversões otimizadas (Enhanced Conversions) do Google Ads e a Events API do TikTok. A lógica é a mesma.

Como o Babuin o faz

Com a medição server-side da MonkeyFlux, os eventos do seu site e da sua app passam por um servidor no seu próprio domínio. Aí aplica-se o consentimento, descarta-se o tráfego de bots, desduplicam-se por event_id e enriquecem-se com a margem, o LTV ou a qualidade do lead do seu CRM e do seu ERP. Depois chegam à Meta pela API de Conversões, e ao Google, ao TikTok ou ao GA4 por Enhanced Conversions, Events API ou Measurement Protocol. Compatível com o seu contentor server-side do GTM.

Com essas conversões, o Babuin dá ao MonkeyBot o sinal para fazer lances por valor real e ao DBA o dado para distribuir o orçamento entre meios. A Meta otimiza com o que recebe; a API decide quanto do seu negócio ela chega a ver.

Perguntas frequentes