API de Conversões do Meta para e-commerce: o que enviar além do Purchase

A API de Conversões do Meta (CAPI) virou item obrigatório de checklist. O problema é que muita loja liga a API, manda só a compra e acha que resolveu. Este guia mostra o que enviar, como deduplicar e o que medimos quando a API é usada inteira.

O que é, em uma frase

A API de Conversões envia os eventos do servidor da loja direto para o Meta. O pixel depende do navegador da pessoa (e perde muito em iPhone dentro do app do Instagram); a API não.

Ela complementa o pixel. O Meta recomenda os dois juntos, com deduplicação.

Quais eventos enviar

Enviar só o Purchase desperdiça a API: o Meta aprende muito mais cedo na jornada, e é nos eventos do meio que o navegador mais perde.

Deduplicação: o passo que mais dá errado

Quando pixel e servidor enviam o mesmo evento, o Meta precisa saber que é um só. A regra:

1. Gerar um event_id único no navegador para cada evento.
2. Enviar o mesmo event_id e o mesmo nome de evento pelo pixel e pela API.
3. O Meta mantém um e descarta o outro.

Sem isso, a compra conta duas vezes e o ROAS dobra do nada. Com o event_id diferente nos dois lados, dá no mesmo. Vimos isso na prática: nos três primeiros dias de uma troca de trackeamento, o PageView saiu duplicado até corrigirmos a deduplicação, e esses dias tiveram de ficar fora das medições.

Parâmetros que ajudam o Meta a reconhecer a pessoa

• E-mail e telefone, normalizados e com hash SHA-256.
• fbc, o identificador do clique no anúncio (vem do fbclid da URL).
• fbp, o cookie do pixel.
• external_id, o seu ID da pessoa (com hash).
• IP e user agent do navegador, não do servidor.

Quanto mais eventos levam esses dados, mais pessoas o Meta consegue ligar a um perfil, e melhor a campanha otimiza.

O que medimos ao herdar a identidade

O problema: a pessoa só deixa o e-mail no checkout. Os eventos anteriores (visita, produto, carrinho) chegam ao Meta sem e-mail. No Spark, guardamos a identidade quando ela aparece e passamos a enviá-la junto com os eventos seguintes da mesma pessoa. Resultado num cliente, em eventos com e-mail:

E 99,9% das compras saíram com o ID do navegador ligado ao checkout.

Um resultado que não melhorou, e vale contar: herdar o fbc quase não muda nada, porque quem não tem o identificador do clique em geral não veio de anúncio.

Só pedido pago vira compra

O pixel dispara a compra quando o pedido é criado. Se ele for cancelado ou recusado no pagamento, o Meta já contou. Pela API dá para enviar a compra só quando o pedido for pago. Numa loja que atendemos, isso tirou da conta do Meta pedidos cancelados que vinham inflando a receita todo mês.

Checklist

1. Pixel e API ativos, com o mesmo event_id nos dois.
2. Funil inteiro pela API, não só a compra.
3. E-mail, telefone, fbc, fbp, external_id, IP e user agent sempre que existirem.
4. Purchase só de pedido pago.
5. Conferir o connect rate antes e depois.

Fazer isso com o GTM server-side é possível, mas dá trabalho e depende da tag do navegador: comparamos em Stape ou Spark?. O Spark faz tudo isso pronto para e-commerce.