Como configurar CAPI Meta em e-commerce: setup completo

A CAPI (Conversions API) não é um segundo pixel. É o canal server-side que manda o evento de compra do seu servidor direto para a Meta, sem depender do navegador do comprador. Isso importa porque bloqueador de anúncio, Safari com ITP e recusa de cookie derrubam parte relevante dos eventos do pixel puro, como a própria documentação da Meta sobre a Conversions API descreve. Antes de abrir o Gerenciador de Eventos, você precisa de três coisas: acesso de administrador ao Business Manager, um desenvolvedor (ou uma plataforma como Shopify, que já traz CAPI nativa) e o pixel do navegador já instalado e disparando compra corretamente.

Essa última é a mais ignorada. CAPI complementa o pixel, não substitui. Se o seu pixel de compra já está quebrado, a CAPI vai duplicar o problema em vez de resolver.

A ressalva vem antes do tutorial. Se o seu e-commerce fatura abaixo de R$ 30k por mês e roda em plataforma sem integração nativa, o custo de desenvolvimento e manutenção da CAPI raramente se paga contra o ganho marginal de sinal. Nesse caso, o Conversions API Gateway ou a integração de parceiro (Shopify, Nuvemshop, WooCommerce com plugin oficial) entrega a maior parte do resultado com uma fração do esforço. CAPI via código próprio faz sentido quando o volume de eventos justifica o controle fino.

O passo a passo do setup

1. No Gerenciador de Eventos, selecione o seu dataset (antigo pixel) e abra a aba "Configurações". Role até "Conversions API" e clique em "Gerar token de acesso". Guarde esse token como senha, porque ele dá acesso de escrita ao seu dataset.

2. Defina a origem do envio. Para código próprio, você faz POST para o endpoint https://graph.facebook.com/v20.0/{dataset_id}/events com o token no parâmetro. Para plataforma, ative a integração nativa e cole o token onde a plataforma pedir.

3. Para cada evento, envie os campos obrigatórios: event_name (Purchase), event_time (unix timestamp), action_source (website), event_source_url e o bloco user_data com o máximo de identificadores hasheados em SHA-256: email, telefone, fbp e fbc (os cookies do navegador). Quanto mais campo casado, maior a qualidade de correspondência.

4. Este é o passo que separa setup certo de setup quebrado: gere um event_id único por compra e envie o MESMO event_id no pixel do navegador e no evento server-side. É esse identificador que a Meta usa para deduplicar os dois eventos e entender que são a mesma compra, não duas.

5. Antes de subir para produção, use o "Test Events" no Gerenciador de Eventos. Copie o código de teste, injete no payload como test_event_code, dispare uma compra real e confirme que o evento aparece marcado como recebido por servidor e navegador ao mesmo tempo.

Os erros que matam o resultado

O primeiro é enviar server-side sem event_id casado. O resultado é compra contada em dobro, ROAS inflado no gerenciador e decisão de escala tomada em cima de número falso. Você acha que está com ROAS 4x, está com 2x, aumenta o budget e o caixa não acompanha.

O segundo é hashear errado. Email precisa estar em minúsculo, sem espaço, antes do SHA-256. Telefone precisa de código do país sem o sinal de mais. A Meta rejeita silenciosamente o identificador malformado, a qualidade de correspondência despenca e você perde a atribuição que era o motivo de usar CAPI. A referência de parâmetros da Meta lista o formato exato de cada campo.

O terceiro é mandar só o email e achar que está completo. Event Match Quality abaixo de 6 sobre 10 significa que a Meta está casando poucos eventos com pessoas reais. Cada parâmetro adicional (telefone, fbc, IP, user agent, ID externo) sobe a nota. Sem isso, o server-side entrega volume de evento sem qualidade de atribuição.

Quando não configurar CAPI

CAPI não conserta campanha ruim. Se o problema é criativo fraco ou oferta sem margem, sinal melhor só vai te dar clareza mais rápida de que a campanha não fecha conta. Configure CAPI depois que a operação já tem tração e você quer proteger a atribuição, não antes, esperando que ela crie demanda.

Também não vale duplicar esforço quando a plataforma já resolve. Shopify, Nuvemshop e a maioria dos CMS de e-commerce sérios já mandam CAPI com deduplicação correta na integração oficial. O mesmo raciocínio de sinal server-side aparece do lado do Google, no feed de produto e no protocolo de commerce. Reescrever tudo isso em código próprio adiciona superfície de manutenção sem ganho, a menos que você tenha eventos customizados que a integração não cobre.

Como medir se funcionou

Três números, todos dentro do Gerenciador de Eventos.

Primeiro, a taxa de deduplicação. Abra o dataset, veja o card de eventos e procure o alerta de eventos redundantes. A Meta reporta o percentual de eventos deduplicados com sucesso. Você quer esse número alto e, ao mesmo tempo, zero aviso de "possível dupla contagem". Se aparecer aviso de eventos não deduplicados, o seu event_id não está casando, volte ao passo 4.

Segundo, o Event Match Quality por evento. Filtre por Purchase e leia a nota de 0 a 10. Abaixo de 6, adicione parâmetros de user_data e meça de novo em 48 horas. Entre 7 e 10, está saudável.

Terceiro, a cobertura server-side. No detalhe do evento, a Meta mostra quantos eventos vieram só do navegador, só do servidor, e de ambos. Um setup maduro tem a maioria em "ambos". Se a fatia de "só navegador" continua grande depois de uma semana, o seu envio server-side está falhando em parte das compras e você tem um bug de implementação, não de configuração.

O gatilho de decisão é direto: EMQ abaixo de 6 ou aviso de dupla contagem ativo significa que a CAPI está te dando número pior do que o pixel sozinho. Nesse estado, corrija antes de confiar em qualquer ROAS que o gerenciador reporta.

Sinal melhor não é o fim, é o começo de uma conversa honesta entre o que o gerenciador diz e o que o seu extrato bancário confirma. Depois que a atribuição para de mentir, a próxima pergunta é se o retorno que você mede sustenta a operação. Onde está o seu Event Match Quality agora?