Tracking para Facebook Ads: o que decide a atribuição do Meta
Pixel, Conversions API, _fbc, _fbp e deduplicação. O que cada peça faz, onde o rastreamento costuma quebrar e como auditar a sua conta antes de contratar qualquer coisa.
Atualizado em 7 de setembro de 2026 · por WYB Trackers
O que é tracking para Facebook Ads?
Tracking para Facebook Ads é o conjunto de mecanismos que informa ao Meta quais conversões vieram de quais anúncios. Em 2026 ele se apoia em duas vias que trabalham juntas: o Pixel, que roda no navegador do comprador, e a Conversions API (CAPI), que envia o mesmo evento a partir de um servidor. As duas mandam o mesmo event_id para que o Meta descarte a duplicata.
O que separa uma implementação que funciona de uma que apenas parece funcionar são dois parâmetros: _fbc e _fbp. Eles existem somente no navegador do comprador. Qualquer arquitetura que não rode código nesse navegador — integração por webhook de checkout, por exemplo — envia o evento sem eles, e o Meta perde o vínculo entre a venda e o clique que a gerou.
Por que o Pixel sozinho perde conversões
O Pixel é JavaScript rodando no navegador de outra pessoa. Tudo que interfere nesse navegador interfere no seu dado. Não é um problema de configuração — é uma característica da arquitetura, e ela se acumula:
| Causa | O que ela faz | Efeito no evento |
|---|---|---|
| App Tracking Transparency (iOS) | Desde o iOS 14.5, em abril de 2021, o app precisa de permissão explícita para rastrear o usuário entre apps e sites. | Reduz o sinal disponível para casar a conversão com o perfil. |
| ITP do Safari | Limita a validade de cookies primários gravados por JavaScript. | O _fbp expira antes da compra em ciclos de decisão mais longos. |
| Bloqueadores de anúncio | Bloqueiam requisições para os domínios do Meta direto no navegador. | O evento simplesmente nunca sai. |
| Checkout em domínio de terceiro | A compra acontece em outro domínio (plataforma de checkout), não no seu. | Os cookies do seu domínio não acompanham o comprador até a compra. |
As três arquiteturas — e o que cada uma consegue enviar
Quase toda discussão sobre tracking no Meta se resolve entendendo esta tabela. As três usam o nome "server-side" em algum material de venda, mas o que chega ao Meta é bem diferente:
| Arquitetura | Onde roda | Captura _fbc / _fbp | Deduplicação |
|---|---|---|---|
| Pixel client-side puro | Só no navegador | Sim, mas só se o navegador deixar | Não se aplica (via única) |
| CAPI por webhook de checkout | Só no servidor da plataforma | Não — a plataforma não tem acesso aos cookies do comprador | Depende de a plataforma emitir event_id |
| GTM Web + GTM Server-Side | Navegador e servidor próprio | Sim — o navegador coleta e repassa ao servidor | Sim, event_id gerado uma vez e usado nas duas vias |
Onde mora a confusão de mercado
_fbc e _fbp: o que são, de verdade
_fbc — o identificador do clique
Quando alguém clica em um anúncio do Meta, a plataforma anexa um parâmetro fbclid na URL de destino. O Pixel lê esse valor e grava o cookie _fbc no formato fb.<índice>.<timestamp>.<fbclid>. É o que amarra a conversão a um clique específico.
_fbp — o identificador do navegador
É um identificador criado pelo Pixel na primeira visita e persistido como cookie primário. Ele é o que permite ao Meta entender que a pessoa que visitou o site na terça é a mesma que comprou na sexta.
Os dois vão sem hash
_fbc e _fbp vão em texto puro. Aplicar hash neles quebra o casamento por completo — o valor deixa de ser reconhecível. É um dos erros mais comuns em implementação apressada.Deduplicação: mandar duas vezes é o desenho certo
Enviar o mesmo evento pelo navegador e pelo servidor não infla venda — desde que os dois carreguem o mesmo event_name e o mesmo event_id. A redundância é o ponto: quando o navegador é bloqueado, o servidor cobre; quando o servidor atrasa, o navegador já chegou.
A janela de deduplicação é de aproximadamente 48 horas a partir do primeiro evento com aquele event_id. Na prática isso raramente aperta, porque o envio do servidor costuma sair segundos depois do navegador. Vira problema em rotinas que processam eventos em lote horas depois.
A condição que quase ninguém menciona: tem que ser o mesmo pixel
A Meta deduplica apenas dentro do mesmo pixel. Se o evento do navegador vai para o pixel A e o evento do servidor vai para o pixel B, não existe deduplicação possível — são dois conjuntos de dados distintos, e cada um conta a venda uma vez. Esse é o erro estrutural mais caro que a WYB Trackers encontra em auditoria, e o mais comum em contas que "duplicaram as vendas" logo depois de instalar a Conversions API.
O event_id precisa ser determinístico, não aleatório
Para o servidor reproduzir exatamente o mesmo event_id que o navegador enviou, esse valor não pode ser sorteado. A chave correta é o identificador do pedido: order_id, transaction_id ou o identificador único da transação.
A armadilha: a variável {{Event ID}} gerada pelo GTM Web produz um valor aleatório por disparo. O servidor não tem como reproduzi-lo, então a deduplicação simplesmente não acontece — mesmo com tudo o mais configurado corretamente.
Como reconhecer dedup quebrada sem abrir o container
event_source_url presente em metade dos eventos e ausente na outra metade. A metade sem URL de origem é a que veio do servidor.Existe um caso em que a deduplicação web↔server é impossível pelo caminho normal: quando o frontend do checkout não injeta o identificador da transação no payload do navegador. Aí não há chave comum a compartilhar. A correção é mover a fonte de verdade do evento para o servidor, ou fazer o checkout expor esse identificador.
Event Match Quality: como ler o score
O Meta atribui a cada conjunto de dados uma nota de 0 a 10conhecida como Event Match Quality. Ela reflete a quantidade e a qualidade dos parâmetros de identificação enviados com os eventos e o quanto eles casam com perfis reais na plataforma. Não é uma nota de "quão bem seu anúncio vende" — é uma nota de quão reconhecível é o dado que você manda.
O score sobe conforme você acrescenta parâmetros válidos: e-mail e telefone com hash, _fbc, _fbp, IP e user agent reais do comprador, nome, cidade, país. Um evento com apenas e-mail casa muito menos do que um evento com e-mail mais os dois identificadores de navegador.
Faixa observada nos projetos da WYB
Como auditar seu tracking do Meta em 10 minutos
Dá para fazer sozinho, sem ferramenta paga e sem contratar ninguém. Se estiver tudo certo, você economizou o orçamento:
- 1Abra o Gerenciador de Eventos do Meta e selecione o conjunto de dados da sua conta.
- 2Compare o volume de eventos de Purchase dos últimos 30 dias com os pedidos aprovados no seu checkout. Uma diferença grande é o primeiro sinal.
- 3Abra um evento de Purchase recente e vá em detalhes do evento, seção de dados do cliente.
- 4Confirme primeiro a origem do tráfego da sessão testada: sem clique em anúncio do Meta não existe fbclid, e portanto não existe _fbc — ausência aí é esperada, não defeito.
- 5Em um evento originado de clique em anúncio, procure _fbc e _fbp. Vazios nesse caso indicam que o vínculo com o clique não está chegando.
- 6Verifique a nota de Event Match Quality do conjunto de dados.
- 7Confira se há deduplicação ativa: eventos de navegador e de servidor com o mesmo event_id aparecem como um só, não como dois.
Quando você não precisa disso
O que a WYB implementa em contas de Meta Ads
Escopo real dos nossos pacotes, sem promessa embutida. A camada de navegador e a de servidor são montadas juntas — é a combinação que preserva _fbc e _fbp até o envio final:
- GTM Web com DataLayer mapeado — os eventos do funil disparados a partir de dados estruturados da página, não de seletor de CSS que quebra na próxima alteração de layout.
- GTM Server-Side hospedado na Stape.io — servidor próprio recebendo os eventos do navegador e repassando ao Meta.
- Meta Conversions API com Advanced Matching — dados do usuário normalizados e com hash, mais os identificadores de navegador em texto puro.
- Deduplicação por event_id entre navegador e servidor.
- User Unique ID e cross-domain tracking — mantém a identidade quando o comprador atravessa do seu site para o checkout em outro domínio.
- Eventos auditados e validados antes da entrega: PageView, ViewContent, AddToCart, InitiateCheckout, add_payment_info e Purchase.
Trabalhamos com infoproduto (Hotmart, Kiwify, Ticto, PerfectPay, Braip, Cakto), e-commerce (Shopify, WooCommerce, VTEX, Nuvemshop, Yampi), operações COD e checkout nativo da Shopify.
Perguntas frequentes
O Pixel do Meta sozinho ainda funciona em 2026?
Funciona, mas registra menos do que acontece de verdade. O Pixel depende de JavaScript rodando no navegador do comprador, e esse navegador pode estar com bloqueador de anúncios, com restrição de cookies do Safari ou com o rastreamento de apps negado no iOS. Cada uma dessas situações derruba uma parte dos eventos. Por isso o desenho recomendado hoje é Pixel e Conversions API juntos, com deduplicação, e não um substituindo o outro.
Qual a diferença entre Conversions API e tracking server-side?
A Conversions API é o endpoint do Meta que recebe eventos vindos de um servidor. Tracking server-side é a arquitetura que alimenta esse endpoint. Dá para usar a CAPI de várias formas — inclusive por webhook de plataforma de checkout — e a qualidade do resultado muda bastante conforme a forma escolhida, porque o que determina a atribuição é quais parâmetros chegam no payload, não o fato de ter usado a API.
Por que _fbc e _fbp são tão importantes?
São os identificadores que ligam o evento a um navegador e a um clique específico em anúncio. O _fbc é derivado do fbclid que o Meta anexa na URL quando alguém clica no anúncio; o _fbp é o identificador do navegador criado pelo Pixel. Sem eles, o Meta recebe a informação de que houve uma conversão, mas tem muito menos material para saber a qual pessoa e a qual clique ela pertence. Os dois vivem no navegador do comprador — quem não roda código no navegador não consegue capturá-los.
Preciso hashear _fbc e _fbp antes de enviar?
Não. Ao contrário de e-mail e telefone, que devem ir com hash SHA-256, os parâmetros _fbc e _fbp são enviados em texto puro. Aplicar hash neles quebra o casamento — o Meta não consegue mais reconhecer o valor. É um erro comum em implementações feitas às pressas.
Enviar o evento pelo Pixel e pela CAPI conta a venda duas vezes?
Não, desde que três condições sejam atendidas: mesmo event_name, mesmo event_id e — a que mais escapa — o mesmo pixel nas duas pontas. A Meta deduplica apenas dentro do mesmo conjunto de dados, então navegador em um pixel e servidor em outro conta a venda duas vezes, sem correção possível. Além disso, o event_id precisa ser determinístico (order_id ou transaction_id): o {{Event ID}} aleatório do GTM Web quebra a deduplicação porque o servidor não consegue reproduzir o mesmo valor.
Tracking avançado resolve CPA alto?
Não diretamente. O que ele faz é fazer o CPA que você vê no gerenciador se aproximar do CPA real, e dar ao algoritmo do Meta um volume maior de eventos bem casados para otimizar. Se a oferta, o criativo ou a margem estão errados, tracking não conserta — só mostra o problema com mais nitidez. Vale desconfiar de quem promete redução de CPA sem olhar a operação antes.
Documentacao de referencia
Continuar lendo
Tracking para Google Ads
GCLID, Enhanced Conversions e por que a lógica do Google é diferente da do Meta.
WYB Trackers vs plataformas de rastreio
O que cada uma faz bem, onde as duas se sobrepõem e quando usar as duas juntas.
Pix e boleto: conversão perdida
Por que o Purchase da página de obrigado conta pedido criado, não pedido pago.
fbc e fbp: como verificar
O passo a passo detalhado da verificação no Gerenciador de Eventos.
Perguntas frequentes e preços
Quanto custa, o que está incluso, prazo de implementação e o que não prometemos.
Quer saber se a sua conta está perdendo evento?
Fazemos um diagnóstico gratuito de 30 minutos olhando o seu Gerenciador de Eventos. Se o tracking estiver saudável, a gente fala isso.
Agendar diagnostico gratuito