Em fevereiro recuperei 28% dos eventos de compra de um e-commerce de moda que tava rodando só Pixel há dois anos. Não mexi em copy, criativo ou público – só liguei o Conversions API direito, com event_id de deduplicação e Advanced Matching ativo. CPA caiu 19% na mesma semana, não porque o algoritmo ficou mais “esperto”, mas porque finalmente entregamos pra ele os sinais que ele já deveria estar recebendo.

Esse é o ponto que quase ninguém entende: Pixel + CAPI não é otimização avançada, é tracking funcional em 2026. Sem isso, você tá otimizando no escuro e culpando o iOS pelo CPA alto.

Por que só Pixel não basta mais em 2026

O Pixel é JavaScript que roda no navegador do usuário. Isso virou um problema sério depois de 2021. Safari corta cookies de terceiros, iOS 14.5 deu opt-out via ATT (App Tracking Transparency), bloqueadores como uBlock e Brave matam o script antes dele disparar, e até Chrome começou a apertar com Privacy Sandbox.

Resultado prático: numa conta de e-commerce típica no Brasil, com tráfego majoritário mobile, é normal perder de 15% a 40% dos eventos de conversão só por causa de bloqueio client-side. Em nichos como saúde e finanças, onde o público é mais privacy-conscious, já vi perda chegar em 50%.

Esses eventos perdidos não somem do mundo – a compra aconteceu, o lead converteu. Mas o Meta não sabe disso. E quando o algoritmo não sabe, ele otimiza pra quem ele acha que converteu, que é uma amostra cada vez mais distorcida do seu público real.

Se você ainda acha que o algoritmo do Meta Ads funciona “magicamente” mesmo com tracking ruim, recomendo testar: rode CAPI por 14 dias e compare os volumes. A diferença não é sutil.

O que CAPI faz que Pixel não consegue

O Conversions API (CAPI) é um endpoint server-to-server. Em vez do navegador disparar o evento, é o seu servidor (ou um servidor intermediário, tipo CAPI Gateway ou GTM server-side) que manda os dados direto pra infraestrutura do Meta. Não passa pelo navegador, não depende de cookie de terceiro, não pode ser bloqueado por extensão.

O que isso destrava na prática:

• Eventos que o navegador bloqueou continuam chegando – bloqueador de ads não enxerga uma chamada de servidor pra servidor.
• Dados de pós-compra (refund, upsell, cancelamento) que só existem no backend agora podem virar sinal pro algoritmo.
• Eventos de eventos offline (telefonema convertido, venda em loja física) entram no mesmo pipeline.
• Advanced Matching com dados completos hasheados melhora drasticamente o EMQ score (mais sobre isso abaixo).

CAPI não é mágica. É só remover o navegador do caminho crítico e mandar dados melhores, com mais campos e mais frequência. A documentação oficial do Meta Conversions API tem o esquema completo de payload, vale ler antes de implementar.

Como Pixel + CAPI rodam lado a lado (não substituição)

Erro de iniciante: achar que ativar CAPI permite desligar o Pixel. Não permite. Os dois rodam em paralelo, cada um capturando o que consegue capturar, e o Meta deduplica do lado dele usando event_id.

Por que rodar os dois?

• Pixel captura sinais comportamentais que o servidor não vê: scroll, tempo de página, micro-interações, fbp/fbc cookies. Esses sinais alimentam Advantage+ Audiences e otimização de delivery.
• CAPI garante que o evento de conversão chega mesmo se o Pixel falhar. É a rede de segurança.
• Juntos eles dão o melhor EMQ score possível – o Pixel manda fbp/fbc/IP/user agent, o CAPI complementa com email/telefone/nome hasheados.

O que é event_id e por que deduplicação é obrigatória

Aqui é onde 80% dos setups errados moram. Se você liga CAPI sem event_id idêntico ao Pixel, o Meta vai contar cada conversão duas vezes. Você acha que dobrou os resultados, otimiza CBO em cima de número inflado, e queima orçamento perseguindo um CPA fake.

event_id é uma string única por evento (geralmente UUID v4 ou order_id da compra). O Pixel dispara com aquele event_id, o CAPI dispara com o mesmo event_id, e o Meta vê que são duas representações do mesmo evento – fica com a versão mais completa e descarta a duplicata.

Validação rápida: abre Events Manager, vai em “Test Events” ou “Overview” do seu Pixel, e procura o card “Event Deduplication”. Se mostrar 0% deduplicado ou taxa muito baixa (menos de 30%), tem coisa errada no event_id. Idealmente você quer 70-90% de deduplicação – isso significa que CAPI e Pixel estão se reconhecendo.

Setup CAPI direto via Meta vs CAPI Gateway vs server-side GTM

Três caminhos comuns, com tradeoffs diferentes:

1. CAPI direto via integração nativa (Shopify, WooCommerce, Vtex via plugin). Setup mais simples, sai 30 minutos. Limitação: você fica refém do que o plugin manda. Geralmente cobre eventos padrão (Purchase, AddToCart) mas não permite custom events ou parâmetros extras sem código.

2. CAPI Gateway (Stape.io é o player dominante). Container hospedado, você aponta o domínio, eles fazem o resto. Custo: R$80-300/mês dependendo do volume de eventos. Ganho: independência do plugin, sem dor de hospedar GTM server-side, suporte a múltiplos pixels, melhor latência.

3. Server-side GTM (Google Tag Manager server container). Mais flexibilidade, controle total, custo do Google Cloud Run (geralmente R$50-200/mês). Curva de aprendizado mais íngreme. Cobri o setup completo de server-side GTM aqui – se você já tem GTM client maduro, é o caminho natural.

Minha opinião pra contas brasileiras médias (R$30-200k/mês em ads): Stape resolve 95% dos casos com 10% do esforço. Se você não tem dev dedicado, é o caminho. A documentação do Stape sobre Meta CAPI é didática.

Advanced Matching: por que ativar (e o que parametrizar)

Advanced Matching é o conjunto de dados de identidade que você manda junto com o evento pro Meta fazer matching de usuário com mais precisão. Quanto mais parâmetros, melhor o EMQ score, melhor a atribuição.

Parâmetros que importam (sempre hasheados SHA-256 antes de mandar):

• em – email (o de maior impacto, sempre que tiver)
• ph – telefone com código do país (55 pro Brasil)
• fn, ln – primeiro e último nome
• db – data de nascimento (YYYYMMDD)
• ge – gênero (f/m)
• ct, st, zp – cidade, estado, CEP
• country – código de país (br)
• external_id – seu user_id interno (super importante pra cross-device)
• fbp, fbc – cookies do Facebook (Pixel passa automaticamente, no CAPI você lê e replica)
• client_ip_address, client_user_agent – só CAPI

Como medir EMQ score e o que mover ele de 5 pra 8+

EMQ (Event Match Quality) é a nota que o Meta dá pra qualidade dos seus eventos, de 0 a 10. Você vê isso em Events Manager → Pixel → aba “Overview” → “Event Match Quality” por evento.

Ranges que uso como referência:

• 0-4: setup quebrado, parâmetros faltando, hash errado. Meta praticamente ignora pra otimização.
• 5-6: setup básico, Pixel com email visível. Funciona mas perde sinal.
• 7: bom. CAPI ligado com email hasheado e fbp/fbc.
• 8-9: ótimo. CAPI + Pixel + Advanced Matching completo + external_id.
• 10: raro fora de SaaS B2B com identidade rica. Não persiga 10 a qualquer custo.

Como subir um score baixo:

1. Garanta que email tá hasheado SHA-256 minúsculo sem espaço (email.trim().toLowerCase() antes de hashear).
2. Telefone em formato E.164 sem o “+”, então pra Brasil: 5511987654321.
3. Mande external_id em todos os eventos (Pixel + CAPI).
4. No CAPI, sempre mande client_ip_address e client_user_agent do usuário original – não do seu servidor.
5. Leia fbp e fbc dos cookies e passe no CAPI.

Esse último ponto é o que mais quebra na prática. Se seu CAPI manda IP do servidor da AWS em vez do IP do usuário, EMQ trava em 5 pra sempre.

Setup passo a passo: GTM server-side container → Meta CAPI tag

Pra quem vai pelo caminho 3 (server-side GTM), o fluxo resumido:

Quem quer aprofundar GTM server-side, o blog do Simo Ahava é a referência mundial – quase tudo que eu sei de server-side GTM saiu de lá.

Como debugar (Events Manager Test Events)

Test Events é a ferramenta que separa setup bom de setup chutado. Como usar:

1. Events Manager → seu Pixel → aba “Test Events”.
2. Pega o “Test Event Code” (string tipo TEST12345).
3. Adiciona esse código nos eventos CAPI como parâmetro test_event_code (e/ou na URL do site pro Pixel, via ?fbclid_test=TEST12345).
4. Dispara um evento (clica num produto, faz checkout teste).
5. Volta no Test Events e vê o evento aparecer em tempo real.

O que você quer ver:

• Cada evento aparece uma única vez com dois badges: “Browser” (Pixel) e “Server” (CAPI), agrupados como mesmo evento via event_id.
• Todos os parâmetros de Advanced Matching aparecem como “Matched” (verde), não “Hashed” sem match.
• EMQ do evento de teste aparece na lateral, deve estar 7+.

Se aparecer dois cards separados pro mesmo evento (um “Browser” e outro “Server”), event_id tá quebrado ou diferente. Fix isso antes de qualquer outra otimização.

Erros comuns: event_id missing, parâmetros faltando, double-counting

Os 5 erros que mais vejo em auditoria de conta:

• event_id ausente no CAPI ou diferente do Pixel – gera double-counting, infla métricas, queima budget.
• Email não hasheado ou hasheado errado (com espaço, maiúsculas, ou usando MD5 em vez de SHA-256) – Advanced Matching ignora.
• IP do servidor em vez do usuário no CAPI – EMQ trava em 5.
• fbp/fbc não passados pro CAPI – você perde o vínculo com a sessão do navegador, atribuição piora.
• Eventos custom sem mapeamento de standard event – Advantage+ Shopping não otimiza eventos custom puros, mapeia pro Purchase ou Lead padrão sempre que possível.

Tracking ruim mata margem antes de criativo ruim matar. Se você tá lutando com CPL alto em Meta ou ROAS travado, comece auditando CAPI e EMQ antes de mexer em qualquer outra coisa. E se você também roda Google Ads, o raciocínio se aplica: conversion tracking server-side no Google Ads tem a mesma lógica de Pixel + Enhanced Conversions.

Pra contexto de benchmarks brasileiros, cobri números médios de CPL/CPA/ROAS por nicho aqui – útil pra calibrar expectativa antes de auditar sua conta.

Perguntas frequentes