Toda vez que abro uma conta nova de cliente, a primeira coisa que olho não é criativo nem ROAS. Olho o Events Manager. Se o painel está com aviso amarelo dizendo “deduplication issues” ou EMQ menor que 6, o resto da conta não importa: o Meta está tomando decisão de leilão com dado pela metade. E quase sempre o problema não é o Pixel; é a CAPI que nunca foi setada direito.

Esse post é o passo a passo que eu mesmo executo nas contas que rodo. Vamos cobrir os dois caminhos via Google Tag Manager (Web container e Server container), o que escolher dependendo do seu volume, como gerar event_id que casa client e server, e como debugar quando o Test Events fica vazio mesmo com a tag publicada. Sem promessa de mágica.

Por que setar CAPI via GTM (e não direto no site)

Existe três jeitos de mandar evento server-side pro Meta: integração direta no backend (devs do produto codam), via plataforma intermediária tipo Stape ou Segment, ou via GTM. Os três funcionam. A diferença é custo, controle e velocidade de mudança.

O backend direto é o mais limpo, mas depende de fila de dev. Toda vez que você quer adicionar um evento novo, vira ticket. Para uma equipe de marketing que precisa testar dois eventos novos por semana, isso é morte por mil cortes. Plataformas como Stape resolvem o problema da fila mas adicionam custo recorrente que escala com volume: a partir de uns 500 mil eventos/mês começa a doer no caixa.

GTM resolve os dois lados: você não depende de dev pra adicionar evento novo, e o custo é praticamente zero (GTM Web é gratuito; Server GTM custa Google Cloud Run, que pra maioria das contas BR fica entre cinco e vinte dólares por mês). Aprender mais sobre como funciona o Meta Ads ajuda a entender por que o algoritmo precisa desse dado server-side em primeiro lugar.

Pré-requisitos: Pixel rodando, GTM publicado, Meta Business

Antes de tocar em qualquer tag, três coisas precisam estar funcionando. Não dá pra pular nenhuma porque CAPI por design complementa o Pixel; não substitui.

Primeiro: o Pixel já tem que estar disparando eventos no site (PageView, ViewContent, AddToCart, Purchase). Abra o Events Manager, vá em “Test Events”, e confirme que pelo menos PageView e Purchase aparecem em tempo real. Se não aparece, o problema é Pixel; resolve esse primeiro lendo Pixel e Conversions API do Meta antes de continuar.

Segundo: GTM tem que estar publicado e o snippet instalado no site. Os dois trechos de código (head e noscript do body) precisam estar em todas as páginas. Se você só instalou no header e o tema do site não inclui o snippet no checkout, metade dos eventos vai sumir.

Terceiro: acesso de admin ao Meta Business pra gerar o token da CAPI. Não é o mesmo token que você usa pra Marketing API. É um token específico do Pixel, gerado em Events Manager > Settings > Conversions API > Generate Access Token.

Caminho 1: CAPI tag dentro do GTM Web container

Esse é o setup mais simples e o que eu recomendo pra contas que faturam até uns R$ 200 mil/mês ou disparam menos de 100 mil eventos/mês. Você não precisa de Cloud Run, não precisa configurar domínio próprio de tracking, não precisa abrir conta no Google Cloud. O evento sai do navegador, passa pelo GTM Web, e o GTM faz a chamada server-side direto pro endpoint da Meta.

O passo a passo: dentro do GTM Web, vá em Tags > New > Tag Configuration > Discover more tag types in the Community Template Gallery. Procure por “Facebook Conversions API Tag” (template do Stape ou da própria comunidade) e adicione. Configure os campos:

• Pixel ID: o ID do seu Pixel (ex: 123456789012345)
• Access Token: o token gerado no Events Manager (cole inteiro, sem aspas)
• Event Name: variável dinâmica baseada no event da dataLayer (PageView, Purchase, etc.)
• Event ID: variável que gera UUID único por evento (vamos detalhar abaixo)
• User Data: hashed email, phone, IP, user agent, fbp, fbc
• Custom Data: value, currency, content_ids (pra eventos de e-commerce)

A trigger é a mesma do seu Pixel client-side: dispara em “Purchase” da dataLayer, “AddToCart” da dataLayer, etc. Você está duplicando o disparo de propósito; a dedup é resolvida pelo event_id que casa nos dois lados.

Caminho 2: Server GTM com Meta CAPI tag (mais performance)

Server GTM é um contêiner separado que roda na nuvem (Google Cloud Run). Em vez do navegador chamar a Meta diretamente, o navegador chama um endpoint seu (ex: sgtm.seusite.com.br), esse endpoint processa o evento, enriquece com dados server-side (IP, user agent, cookies first-party) e aí sim manda pra Meta. Mais detalhes em server-side tagging com GTM.

Por que vale o trabalho? Três motivos. Um: EMQ score melhor, porque você pode injetar IP e user agent corretos no payload (no Web container o GTM não tem acesso confiável a esses dados). Dois: você controla o cookie _fbp em first-party, então o cookie vira “primeira parte” no navegador e sobrevive mais tempo. Três: você pode adicionar lógica server-side (validar produto, enriquecer com CRM) antes de mandar pra Meta.

O custo aproximado: Cloud Run cobra por requisições. Pra conta com 100 mil eventos/mês, fica em torno de US$ 5-12/mês. Pra 1 milhão de eventos/mês, US$ 30-60. Não é zero, mas é o custo de uma camada de tracking sob seu controle. Eu uso Server GTM em contas acima de R$ 500 mil/mês de faturamento; abaixo disso, o caminho 1 já entrega resultado suficiente.

Setup passo a passo: container, trigger, tag, parâmetros

Vou mostrar o caminho 1 detalhado, porque é o que cobre 80% dos casos. Quem for de Server GTM, a lógica é parecida: muda só onde a tag mora (container web vs server) e como o evento chega lá.

event_id pra deduplicação: como gerar e injetar

Esse é o ponto que mais vejo gente errar. Sem event_id casado nos dois lados, o Meta recebe o mesmo evento duas vezes (uma pelo Pixel, uma pelo CAPI) e conta como duas conversões. Isso infla o reportado e o algoritmo otimiza pra ruído.

O event_id precisa ser único por evento e idêntico entre Pixel e CAPI. Não pode ser o ID do produto, nem o ID do pedido (porque dois Purchase do mesmo pedido em refresh seriam tratados como o mesmo evento). Eu uso UUID v4 gerado no momento do dispar e injeto via dataLayer:

// dataLayer push no checkout (script do site)
window.dataLayer = window.dataLayer || [];
dataLayer.push({
  event: 'purchase',
  event_id: crypto.randomUUID(), // ex: "f47ac10b-58cc-4372-a567-0e02b2c3d479"
  ecommerce: {
    value: 197.00,
    currency: 'BRL',
    transaction_id: 'PED-12345'
  }
});

// payload CAPI que o GTM monta e manda pra Meta
{
  "data": [{
    "event_name": "Purchase",
    "event_time": 1715600000,
    "event_id": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
    "event_source_url": "https://seusite.com.br/checkout/sucesso",
    "action_source": "website",
    "user_data": {
      "em": ["sha256_hash_do_email"],
      "ph": ["sha256_hash_do_phone"],
      "client_ip_address": "189.xxx.xxx.xxx",
      "client_user_agent": "Mozilla/5.0...",
      "fbp": "fb.1.1715600000.123456789",
      "fbc": "fb.1.1715600000.IwAR1..."
    },
    "custom_data": {
      "value": 197.00,
      "currency": "BRL",
      "content_ids": ["SKU-001"],
      "content_type": "product"
    }
  }],
  "access_token": "EAAxxxxxx..."
}

Repare que o Pixel client e o CAPI server mandam o mesmo event_id. É isso que o Meta usa pra entender “esses dois sinais são o mesmo evento, vou contar uma vez só”. Se você esquecer disso, o resto não importa.

Advanced Matching: hashed PII (email, phone, fbp)

Advanced Matching é o que faz CAPI ter valor real além de “ter CAPI”. O Meta usa esses dados de usuário pra casar com perfis no Facebook/Instagram e atribuir o evento. Quanto mais campo, maior o EMQ (Event Match Quality), que é uma nota de 1 a 10 que o Events Manager mostra.

Os campos que dão mais peso são, em ordem: email, phone, fbp, fbc, client_ip_address, client_user_agent, nome, sobrenome, cidade, estado, CEP. Email e phone precisam ser hash SHA-256 (Meta rejeita texto puro). GTM tem template de hashing built-in; senão, dá pra fazer com Custom JavaScript usando crypto.subtle.digest.

Como debugar (Test Events, Events Manager, Tag Assistant)

Três ferramentas pra usar em paralelo na hora de subir CAPI:

GTM Preview Mode: ativa antes de publicar. Mostra cada tag que disparou na sessão, com os parâmetros que foram enviados. Se a CAPI tag não aparece em “Tags Fired”, o trigger está errado. Se aparece mas com parâmetros vazios, a variável está errada.

Events Manager > Test Events: pega o seu _fbp ou parâmetro de teste, cole em “Test Browser Events” ou “Test Server Events”. Toda vez que você dispara um evento, ele aparece em tempo real com a fonte (Browser ou Server) e o event_id. Se você vê o mesmo event_id nas duas fontes, dedup está funcionando.

Facebook Pixel Helper (extensão Chrome): confirma que o Pixel client está disparando os eventos certos com os parâmetros certos. Útil quando o problema é só no lado client.

Como medir EMQ score e melhorar

Events Manager > seu Pixel > “Diagnostics” e “Overview” mostram EMQ por tipo de evento. Não olhe a média; olhe evento por evento. Purchase precisa estar em 7+. Lead precisa estar em 6+. AddToCart pode ficar em 5+ porque tipicamente tem menos PII.

Pra subir o EMQ, a ordem de prioridade é:

1. Email hashed (sobe 2-3 pontos sozinho)
2. Phone hashed (mais 1-2 pontos)
3. fbp + fbc (cookies first-party, mais 1-2 pontos)
4. IP + user agent (Server GTM ajuda aqui)
5. Nome + sobrenome + CEP (refino final)

Se você está em EMQ 5 e precisa subir pra 8, foca em capturar email no checkout antes do Purchase e injetar no dataLayer já hashed. Esse único passo costuma virar a chave. Vale o mesmo princípio que conto em conversion tracking do Google Ads via GTM: dado de qualidade vence volume bruto.

Erros: event_id ausente, parâmetros faltando, double-fire

Os três erros mais comuns que vejo em auditoria:

Erro 1: event_id só no CAPI, não no Pixel. O cara configura CAPI bonita com UUID, mas esquece de atualizar a tag do Pixel client pra também mandar o mesmo eventID. Resultado: Meta recebe dois eventos, não consegue casar, conta duas conversões. Sintoma: relatório do Ads Manager mostra mais conversões que o dashboard interno.

Erro 2: parâmetros user_data faltando. CAPI dispara, evento aparece em Test Events, mas EMQ fica em 3-4. Você abre o payload e vê que só tem client_ip_address e client_user_agent, nenhum email/phone. Falta mapear as variáveis no GTM (ou o site não captura email antes do Purchase).

Erro 3: double-fire por trigger genérica. A pessoa configura trigger “All Pages” pra PageView CAPI, mas o site já é SPA e dispara mais de um PageView por navegação. Server fica com volume 3x maior que o client. Sintoma: número absurdo de PageViews no CAPI vs Pixel. Solução: usar dataLayer custom event como trigger, não “All Pages”. O contexto de iOS 14.5 e Meta Ads ajuda a entender por que esse tipo de descalibração quebra a otimização do algoritmo.

Pra fechar o ciclo, vale cruzar esses números com benchmarks de mídia paga no Brasil e ver se seu CPA pós-CAPI faz sentido pro seu nicho. Tracking bom é meio caminho; o outro meio é saber o que esperar de retorno.

Referências oficiais que vale ter aberto: Meta Conversions API docs, Server-side tagging guide do Simo Ahava, e a documentação oficial do Server GTM.

Perguntas frequentes