Traqueamento de conversões é a infraestrutura invisível que decide se sua campanha vai escalar ou ficar rodando no escuro. Quando está funcionando, o algoritmo do Meta recebe dados reais de quem comprou e consegue encontrar mais pessoas parecidas. Quando está quebrado, parcialmente ou por inteiro, você está otimizando com achismo.
O problema é que quase nunca ele quebra de forma óbvia. Não pisca um alerta vermelho no painel. O que acontece é o Meta receber menos eventos do que deveria, o Connect Rate cair alguns pontos, o número de conversões vir inflado por atribuição de visualização, e você seguir gastando com a impressão de que está tudo certo. O algoritmo, enquanto isso, aprende com metade da informação.
Se quiser ir direto em um subtópico, cada seção tem seu próprio artigo aprofundado linkado ao final.
Como o Pixel client-side funciona e onde ele perde dados
O Pixel do Meta é um script JavaScript que roda no navegador do usuário. Quando a página carrega, ele envia um evento PageView. Quando o usuário faz uma compra, você dispara um evento Purchase. O script captura informações do navegador (cookies, parâmetros de URL, dados do dispositivo) e envia direto para os servidores do Meta.
Esse modelo tem um problema estrutural: depende do navegador. E o navegador pode bloquear o Pixel.
Há três fontes principais de perda de dados no Pixel client-side:
- iOS 14+ e App Tracking Transparency (ATT): desde 2021, o usuário de iPhone pode recusar o rastreamento entre apps. A ATT é uma permissão de app: ela governa o IDFA e o rastreamento cross-app, não os cookies do navegador. Quem bloqueia cookie no browser é o ITP, do item abaixo. Não confunda os dois. O efeito da ATT é derrubar parte do sinal que o Meta usava para ligar anúncio e conversão dentro dos apps.
- Ad blockers: extensões como uBlock Origin e Adblock Plus bloqueiam o domínio
connect.facebook.net, onde o Pixel carrega. Na minha experiência, em audiências de tecnologia essa taxa de bloqueio é das mais altas que você vai encontrar. - Navegação privada e ITP: o Safari bloqueia cookies de terceiros por padrão. Além disso, o ITP (Intelligent Tracking Prevention) limita a poucos dias de vida os cookies first-party criados via JavaScript, como os
_fbce_fbpque o Pixel gera, mesmo sendo do seu próprio domínio. Em modo privado, qualquer cookie definido pelo Pixel é descartado ao fechar a janela.
Obs.: a taxa de perda varia muito por nicho. Em audiências mais velhas ou menos técnicas, o impacto do iOS é menor. Em público jovem e técnico, na minha experiência a perda de eventos é bem maior. Não existe número único que valha para todo mundo.
O resultado prático: o Meta fica com uma visão incompleta das suas conversões. O algoritmo de otimização trabalha com dados fragmentados e faz suposições estatísticas para preencher os gaps. Isso afeta o aprendizado da campanha e, consequentemente, os resultados.
A API de Conversões: o que é e por que você precisa
A API de Conversões do Meta (CAPI) é a solução complementar ao Pixel. Em vez de depender do navegador do usuário, você envia os eventos de conversão diretamente do seu servidor para os servidores do Meta, usando a API Graph.
O fluxo é diferente: quando um usuário compra no seu site, seu servidor backend recebe a confirmação da compra, monta um payload com os dados do evento (incluindo informações do usuário como email e telefone, em hash) e envia para a API do Meta. Esse evento nunca passa pelo navegador, portanto não pode ser bloqueado por ad blocker, iOS ou modo privado.
O ideal é usar Pixel + CAPI juntos, com deduplicação via event_id. O Pixel envia o evento em tempo real com dados do browser; o CAPI envia o mesmo evento com dados do servidor, mais confiáveis. O Meta faz a deduplicação automaticamente e fica com o melhor dos dois mundos.
O indicador que mede a qualidade do matching entre os dois é o Connect Rate (o Meta chama de Event Match Quality, EMQ, no Gerenciador de Eventos). Quanto mais alto, mais o Meta consegue associar o evento a um perfil de usuário, e mais eficiente fica o algoritmo.
Para configurar a CAPI via GTM, existe um template server-side oficial do Meta. Mas isso exige um servidor GTM intermediário (o GTM Server-Side). Veja o artigo completo sobre API de Conversões do Meta para o passo a passo.
FBC e FBP: os identificadores críticos
Quando alguém clica em um anúncio do Meta, a URL de destino recebe um parâmetro fbclid. O Pixel lê esse parâmetro e gera o cookie _fbc no navegador do usuário. Esse cookie é o Facebook Click ID, a peça que conecta o clique no anúncio à conversão posterior.
Separado disso, o Pixel também gera o cookie _fbp, o Facebook Browser ID. Ele identifica o navegador do usuário de forma persistente. Enquanto o FBC muda a cada clique em anúncio, o FBP fica estável enquanto o cookie não for deletado.
Por que isso importa para a API de Conversões? Quando você envia um evento Purchase via CAPI, você precisa incluir FBC e FBP no payload para que o Meta saiba qual usuário fez essa compra e qual anúncio originou a conversão. Sem FBC, o Meta não consegue fazer a atribuição de clique. Sem FBP, o Connect Rate cai.
Obs.: FBC e FBP importam, mas não são os sinais mais fortes de correspondência. A ordem de força para o Connect Rate começa nos dados primários e desce a partir daí: email, telefone e nome com hash primeiro, depois FBC e FBP, depois external_id e, por último, IP e user agent. Mande todos que conseguir capturar. Quem trata _fbc e _fbp como se fossem o identificador mais forte está deixando o principal na mesa.
O problema frequente: quando o checkout fica em domínio terceiro (Hotmart, Kiwify, Eduzz), o FBC e o FBP definidos na sua página de vendas não são automaticamente passados para a página de obrigado da plataforma. Você perde os identificadores no meio do funil.
Veja o artigo completo sobre FBC e FBP no Meta Ads para entender como verificar se estão sendo capturados e como resolver quando não estão.
Google Tag Manager: a infraestrutura de traqueamento
O GTM é o ponto central de toda infraestrutura de traqueamento. Em vez de instalar cada pixel diretamente no código do site (o que exige dev para cada mudança), você instala apenas o container do GTM e gerencia todos os eventos pelo painel.
Para o Meta, a instalação correta via GTM usa o template oficial do Meta Pixel, não custom HTML. O template tem suporte a Advanced Matching (que envia email, telefone e outros dados do usuário em hash para melhorar o Connect Rate) e é mantido pelo próprio Meta. Veja, no blog do GTM Audit, como auditar a saúde do seu container GTM passo a passo.
Os eventos que você precisa configurar no GTM para o Meta:
- PageView: dispara em todas as páginas, a partir do evento Pageview nativo do GTM
- Lead: dispara quando o usuário preenche formulário ou clica em botão de CTA
- InitiateCheckout: dispara quando o usuário vai para o checkout
- Purchase: dispara na página de obrigado (quando o checkout é no seu domínio)
Quando o checkout está em domínio terceiro, o evento Purchase precisa ser enviado via CAPI com os dados da plataforma de vendas, não via Pixel client-side (porque você não tem controle sobre a página de obrigado da Hotmart ou Kiwify).
Veja o guia completo sobre como instalar o Pixel do Meta com GTM.
O número real vs o número inflado do Meta
O painel do Meta Ads mostra um número de conversões que raramente bate com o da sua plataforma de vendas. O modelo de atribuição do Meta é assim por design; você não tem necessariamente traqueamento quebrado.
O Meta usa atribuição de visualização por padrão na janela de 1 dia. Isso significa que, se um usuário viu seu anúncio e comprou dentro de 24 horas, mesmo sem clicar, o Meta conta como conversão sua. Dependendo do volume de impressões, isso pode inflar bastante o número.
Além disso, desde o iOS 14, o Meta usa modelagem estatística para estimar conversões que não conseguiu rastrear diretamente. Esses números modelados aparecem no painel como se fossem conversões reais, mas são estimativas.
Como comparar: pegue o número de vendas reais na sua plataforma (Hotmart, Kiwify, etc.) no mesmo período e use como base. Se o Meta mostra algo em torno de 50% a mais, a diferença provavelmente é atribuição de visualização somada à modelagem. Esse 50% é só um exemplo de ordem de grandeza, não um limiar mágico. Agora, se o painel mostra bem menos vendas do que a sua plataforma registrou, aí sim você tem um problema sério de traqueamento.
Veja os artigos específicos: por que o Meta infla conversões e como funciona a atribuição de conversão no Meta.
Server-side vs client-side: quando migrar
Traqueamento client-side significa que o script roda no navegador do usuário. Traqueamento server-side significa que um servidor intermediário processa os dados e os envia para as plataformas de destino (Meta, Google, etc.).
A vantagem do server-side é óbvia: elimina a dependência do navegador. Ad blocker, iOS, modo privado, nada disso afeta um servidor. A desvantagem é custo e complexidade. Você precisa de um servidor GTM rodando (pode ser no Stape, que simplifica bastante) e de uma camada de configuração adicional.
A régua que uso na prática: quando a verba de tráfego pago já é relevante, na minha experiência a partir de algo como R$ 30 mil por mês, a perda de dados de um traqueamento puramente client-side fica cara o suficiente para justificar o investimento em server-side. É referência, não corte exato. Abaixo disso, uma CAPI bem configurada via GTM web já resolve a maior parte do problema.
Veja o artigo completo sobre traqueamento server-side vs client-side.
Como verificar se seu traqueamento está funcionando
Antes de olhar para otimização, você precisa ter certeza de que os dados que chegam são confiáveis. Há três pontos de verificação:
1. Meta Pixel Helper: extensão do Chrome que mostra em tempo real quais eventos estão disparando na página, com quais parâmetros, e se há erros. Abra a extensão na página de obrigado depois de fazer um pedido teste e verifique se o evento Purchase aparece com os parâmetros corretos (valor, moeda, content_ids).
2. Gerenciador de Eventos do Meta: em Configurações do Negócio, Fontes de Dados, Pixels, você vê o volume de eventos recebidos, o Connect Rate atual e os erros mais frequentes. Na régua que uso, Connect Rate abaixo de 6 costuma ser sinal de problema.
3. Teste de eventos: na aba "Teste de Eventos" do Gerenciador de Eventos, você pode entrar em modo de teste e navegar pelo seu site para ver os eventos chegando em tempo real, separados por Pixel e por CAPI.
Para lojas de infoprodutos com checkout em plataforma terceira, a verificação mais importante é checar se o evento Purchase está chegando via CAPI, não via Pixel. Se está chegando só via Pixel, você está perdendo todos os compradores que bloquearam o script. Para um diagnóstico estruturado da implementação no GTM, audite seu container gratuitamente e veja o score de qualidade.
Atribuição: janelas, modelos e como interpretar
Atribuição de conversão é a regra que define qual anúncio recebe o crédito por uma venda. O Meta usa, por padrão, uma janela de 7 dias por clique + 1 dia por visualização. Isso significa: se o usuário clicou no seu anúncio nos últimos 7 dias, ou viu nos últimos 1 dia, a conversão é atribuída a esse anúncio.
Você pode mudar a janela nas configurações da conta, e isso muda o número que aparece no painel. Uma janela de 1 dia de clique vai mostrar menos conversões do que 7 dias de clique. Não porque você vendeu menos, mas porque o critério de atribuição ficou mais restrito.
Para comparar campanhas de forma justa, use sempre a mesma janela. E para entender o número real, compare com a plataforma de vendas no mesmo período.
Veja o artigo detalhado sobre atribuição de conversão no Meta Ads.
Traqueando vendas em plataformas de terceiros
A maior dor de cabeça do traqueamento para quem vende infoprodutos: o checkout fica na Hotmart, Kiwify ou Eduzz. Você não controla o código da página de obrigado. O Pixel client-side não consegue disparar o evento Purchase de forma confiável.
A solução é usar a API de Conversões via token de integração. Hotmart e Kiwify têm integrações nativas com o Meta via CAPI: você gera um token na plataforma e registra nas configurações de pixel. A cada venda aprovada, a plataforma envia o evento Purchase diretamente para o Meta, sem depender do navegador do comprador.
A armadilha mais comum: não configurar a deduplicação. Se você tem o Pixel disparando um evento Purchase na página de obrigado E a plataforma enviando via CAPI, o Meta recebe o evento duas vezes. Você precisa usar o mesmo event_id nos dois para que o Meta deduplicar corretamente.
Veja o guia completo em como rastrear vendas do Hotmart, Kiwify e Eduzz.
FAQ
Qual a diferença entre o Pixel do Meta e a API de Conversões?
O Pixel é um script JavaScript que roda no navegador do usuário e captura dados do lado do cliente. A API de Conversões envia eventos diretamente do seu servidor para o Meta, sem passar pelo navegador. Os dois são complementares: Pixel captura dados comportamentais em tempo real; CAPI garante que os eventos de conversão chegam mesmo quando o Pixel é bloqueado.
Por que o número de conversões no Meta não bate com o da Hotmart?
O Meta usa atribuição de visualização (1 dia) além da atribuição de clique (7 dias). Isso significa que usuários que apenas viram o anúncio, sem clicar, podem ser contados como conversão. A Hotmart conta apenas vendas reais. A diferença entre os dois é atribuição de visualização + modelagem estatística do iOS 14.
O que é Connect Rate e qual valor é bom?
Connect Rate (o Meta chama de Event Match Quality) é a porcentagem de eventos que o Meta consegue associar a um usuário identificado. Quanto mais dados do usuário você envia (email, telefone, FBC, FBP), maior o Connect Rate. A régua que uso: em torno de 8 pra cima é ótimo, entre 6 e 8 é aceitável, e abaixo de 6 você costuma estar perdendo atribuição de forma significativa.
GTM é obrigatório para ter a API de Conversões funcionando?
Não. Você pode enviar eventos para a CAPI diretamente via backend, sem GTM. Mas o GTM Server-Side é a opção mais prática para a maioria dos casos: não exige desenvolvimento customizado e o template oficial do Meta já está disponível na galeria de templates. Para checkouts em plataformas terceiras, a integração nativa da plataforma (Hotmart, Kiwify) é a opção mais simples.
Conclusão
Traqueamento não é uma caixinha que você marca uma vez e esquece. É Pixel e API de Conversões trabalhando juntos, os identificadores certos no payload, o Connect Rate de olho e o número do painel reconciliado com a venda real. Cada elo que falha vira dado que o algoritmo não recebe, e dado que o algoritmo não recebe é verba otimizada no escuro.
É exatamente esse último elo que o App Tracker fecha. Na nossa operação, mais de 85% das vendas chegam com o fbclid capturado e amarrado ao checkout real, o que significa atribuição reconciliada com o que a plataforma de vendas de fato registrou, não com a estimativa do painel. É a diferença entre confiar no número e conferir o número.
Se quiser parar de otimizar no escuro e reconciliar suas conversões com a venda real, crie sua conta no App Tracker e ligue o traqueamento na origem.