Blog

Meta Pixel vs CAPI: arquitetura ideal para dados confiáveis

Confiar só no Meta Pixel no browser significa perder uma fatia grande das conversões para ad blockers, ITP do Safari e o opt-out do iOS. A arquitetura ideal combina Pixel e Conversions API (CAPI) com deduplicação por event_id: o mesmo evento sai do navegador e do servidor, a Meta junta os dois e você recupera cobertura sem contar a conversão duas vezes.

2026-03-01 / Meta Ads / 11 min

01

Por que o Pixel sozinho perde eventos

O Pixel roda no navegador do usuário. Tudo que depende do navegador está sujeito a ser bloqueado, cortado ou não executado, e isso vem crescendo a cada ano. Quando o Pixel não dispara, o evento simplesmente não chega na Meta, a atribuição quebra e o algoritmo de entrega passa a otimizar com dados incompletos.

  • Ad blockers e extensões de privacidade: bloqueiam o script do Pixel antes mesmo dele carregar, derrubando uma parcela relevante do tráfego.
  • ITP (Intelligent Tracking Prevention) do Safari: limita cookies de origem a 7 dias (ou 24 horas em alguns casos), encurtando a janela de atribuição client-side.
  • iOS e App Tracking Transparency: com o opt-out, o sinal do browser fica reduzido e parte das conversões nunca é atribuída pelo lado do cliente.
  • Falhas de rede e abandono de página: se o usuário fecha a aba antes do beacon sair, o evento se perde sem reenvio.
  • Single Page Apps: navegação sem reload pode não disparar o PageView ou o evento de conversão se a instrumentação estiver incompleta.

O ponto não é abandonar o Pixel. Ele continua ótimo para captar sinais ricos do browser (fbp, fbc, contexto da página). O problema é depender exclusivamente dele. A solução é ter um segundo canal, server-side, que não depende do navegador do usuário.

02

Arquitetura híbrida: Pixel + CAPI

Na arquitetura híbrida, cada conversão importante é enviada por dois caminhos: o Pixel no navegador e a Conversions API no seu servidor. Os dois carregam o mesmo event_id, e a Meta usa esse id para deduplicar. Se o Pixel for bloqueado, o servidor garante o evento. Se os dois chegarem, a Meta mantém um só.

   Navegador                         Seu servidor                 Meta
 +-------------+                  +----------------+          +-------------+
 |  Meta Pixel | --event_id-->    |  Backend / API | --CAPI-->  |  Graph API  |
 | (fbq track) |                  | (mesmo eventID)|           | (dedup por  |
 +-------------+                  +----------------+           |  event_id)  |
       |   ad blocker / ITP / iOS pode bloquear o Pixel        +-------------+
       |   mas o servidor envia mesmo assim ----------------------^
       v
 [ evento pode se perder ]            [ evento confiavel, server-side ]

O servidor envia direto para o endpoint da Graph API (graph.facebook.com), autenticado por um token de acesso. Como o envio sai da sua infraestrutura, ele não é afetado por ad blocker nem por ITP. O Pixel continua enriquecendo o sinal com os cookies _fbp e _fbc, que você repassa para o servidor para melhorar o casamento.

  • O Pixel cobre o sinal rico do browser e a experiência client-side.
  • A CAPI cobre confiabilidade e resiliência a bloqueios.
  • O event_id compartilhado evita contagem dupla.
  • Cookies _fbp e _fbc viajam do browser para o servidor e elevam a qualidade do match.

03

Deduplicação por event_id

Deduplicação é o coração do desenho. A regra é simples: gere um event_id único no momento da conversão e use o MESMO valor no Pixel (campo eventID) e na CAPI (campo event_id). A Meta compara event_name + event_id e, se vir o par duas vezes dentro da janela de deduplicação, mantém apenas um.

// 1) Browser (Meta Pixel): gera um event_id unico e dispara o evento.
const eventId = crypto.randomUUID(); // ex.: '6f3c0b2a-9d4e-4a11-8c77-1e2b3f4a5d6e'

fbq('track', 'Purchase', {
  value: 199.90,
  currency: 'BRL',
  content_ids: ['SKU-123'],
  content_type: 'product',
}, {
  eventID: eventId, // <-- chave da deduplicacao no lado do browser
});

// 2) Server (Conversions API): MESMO event_id enviado para o servidor.
// O front passa o eventId no corpo da requisicao de checkout.
await fetch('/api/track/purchase', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ eventId, value: 199.90, currency: 'BRL', sku: 'SKU-123' }),
});

No servidor, o mesmo event_id viaja no payload da CAPI. O exemplo abaixo monta a requisição Purchase, hasheia os dados pessoais em SHA-256 e faz o POST para graph.facebook.com:

// Server-side: envio do mesmo Purchase para a Conversions API.
// O event_id identico ao do Pixel permite que a Meta descarte a duplicata.
import crypto from 'node:crypto';

const sha256 = (value) =>
  crypto.createHash('sha256').update(String(value).trim().toLowerCase()).digest('hex');

async function sendPurchaseToCapi({ eventId, email, phone, value, currency, sku, clientIp, userAgent, fbp, fbc }) {
  const payload = {
    data: [
      {
        event_name: 'Purchase',
        event_time: Math.floor(Date.now() / 1000),
        event_id: eventId,                 // <-- mesmo event_id do Pixel (deduplicacao)
        action_source: 'website',
        event_source_url: 'https://loja.exemplo.com/checkout',
        user_data: {
          em: [sha256(email)],             // email hashado em SHA-256
          ph: [sha256(phone)],             // telefone hashado em SHA-256 (formato E.164, so digitos)
          client_ip_address: clientIp,     // nao hashar IP
          client_user_agent: userAgent,    // nao hashar user agent
          fbp,                             // cookie _fbp (nao hashar)
          fbc,                             // cookie _fbc (nao hashar)
        },
        custom_data: { value, currency, content_ids: [sku], content_type: 'product' },
      },
    ],
    // test_event_code: 'TEST12345', // use no Events Manager durante o desenvolvimento
  };

  const url = `https://graph.facebook.com/v19.0/${process.env.PIXEL_ID}/events?access_token=${process.env.CAPI_TOKEN}`;
  const res = await fetch(url, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(payload),
  });
  return res.json(); // { events_received, messages, fbtrace_id }
}
  • Gere o event_id uma vez (no servidor de preferência) e propague para o browser, ou gere no browser e envie ao servidor: o que importa é ser idêntico nos dois lados.
  • Use o mesmo event_name nos dois canais (Purchase com Purchase, Lead com Lead).
  • Mantenha event_time coerente: a janela de deduplicação trabalha em torno do horário do evento.
  • Valide no Events Manager: a aba de eventos mostra a flag de deduplicação e quantos eventos foram unidos.

04

Pixel vs CAPI lado a lado

As duas fontes não competem, se complementam. A tabela resume onde cada uma brilha e por que rodar as duas em paralelo entrega o melhor resultado:

CritérioMeta Pixel (browser)Conversions API (server)
CoberturaCai com ad blocker, ITP e iOS opt-outIndepende do navegador, cobertura alta e estável
ConfiabilidadeSujeita a falha de rede e abandono de páginaReenvio controlado pelo seu backend, mais resiliente
LatênciaImediata no clique, porém pode não sairControlada por você (síncrona ou via fila)
Dado hashadoSinais do browser (fbp, fbc), pouco PII diretoVocê hasheia em SHA-256 (em, ph) antes de enviar
Sinais exclusivosContexto do navegador, cookies de primeira parteDados do seu sistema (CRM, backend, status do pedido)

Resumo prático: o Pixel traz o contexto do navegador, a CAPI traz a confiabilidade. Rodando os dois com event_id compartilhado, você soma cobertura sem dobrar a contagem.

05

Event Match Quality e parâmetros de matching

Recuperar o evento é metade do trabalho. A outra metade é a Meta conseguir casar esse evento com uma pessoa. O Event Match Quality (EMQ), visível no Events Manager, mede a força do casamento com base nos parâmetros de identificação que você envia. Quanto mais campos válidos, melhor a atribuição e a otimização de entrega.

  1. Normalize antes de hashear: minúsculas, sem espaços nas pontas, telefone em E.164 (só dígitos com código do país).
  2. Hasheie PII em SHA-256: email (em) e telefone (ph) nunca saem em texto puro.
  3. Não hasheie campos técnicos: client_ip_address, client_user_agent, _fbp e _fbc vão em texto.
  4. Envie o máximo de parâmetros válidos: quanto mais sinais, maior o EMQ.
  5. Monitore o EMQ por evento no Events Manager e suba os campos fracos.
ParâmetroHashado?Como normalizar
em (email)Sim, SHA-256minúsculas, sem espaços: [email protected]
ph (telefone)Sim, SHA-256E.164 só dígitos: 5511999998888
client_ip_addressNãoIP da requisição, em texto
client_user_agentNãoUser agent completo, em texto
fbp / fbcNãocookies _fbp e _fbc repassados do browser

Cuidado comum: hashear um valor não normalizado (com maiúsculas ou espaços) produz um hash diferente do que a Meta espera e derruba o match. Normalize primeiro, hasheie depois, sempre na mesma ordem nos dois lados.

06

Boas práticas e armadilhas

  • Use test_event_code no Events Manager durante o desenvolvimento para ver os eventos chegando em tempo real sem sujar a produção.
  • Garanta event_id realmente único por conversão (UUID), nunca reutilize o id do pedido se ele puder repetir entre tentativas.
  • Nunca exponha o token da CAPI no front: ele vive só no servidor, em variável de ambiente.
  • Trate a CAPI como envio que pode falhar: coloque em fila com retry idempotente para não perder nem duplicar.
  • Confira a deduplicação real no Events Manager antes de escalar verba: a flag de dedup confirma que o desenho está funcionando.

Com Pixel e CAPI rodando juntos, event_id compartilhado e parâmetros bem hashados, você recupera eventos perdidos, melhora o EMQ e dá ao algoritmo da Meta um sinal muito mais limpo para otimizar campanhas.

FAQ

Perguntas frequentes

Se eu envio o evento pelo Pixel e pela CAPI, não conto a conversão duas vezes?

Não, desde que os dois usem o mesmo event_id e o mesmo event_name. A Meta deduplica esse par dentro da janela de deduplicação e mantém apenas um evento. Sem o event_id compartilhado, sim, você contaria em dobro.

Preciso hashear todos os parâmetros antes de enviar para a CAPI?

Só os dados pessoais (PII) como email (em) e telefone (ph), sempre em SHA-256 e normalizados antes. Campos técnicos como client_ip_address, client_user_agent, _fbp e _fbc vão em texto puro e não devem ser hashados.

A CAPI substitui o Pixel?

Não, eles se complementam. O Pixel captura sinais ricos do navegador e os cookies _fbp e _fbc, enquanto a CAPI garante confiabilidade contra bloqueios. A arquitetura recomendada pela Meta é rodar os dois com deduplicação.

Quer dados de conversão confiáveis?

Posso desenhar e implementar a arquitetura híbrida Pixel + CAPI no seu stack, com deduplicação por event_id, hashing correto em SHA-256 e validação de Event Match Quality no Events Manager. Vamos recuperar os eventos que você está perdendo hoje.