CAPI vs pixel de navegador: quanto sinal você perde — e por que isso não conserta a sua decisão

Você configurou o pixel direitinho, testou no navegador, viu o evento disparar. Mas boa parte das suas vendas nunca chega à Meta. Não é bug de instalação — é a arquitetura do rastreamento de navegador ruindo há anos, corroída por privacidade, bloqueadores e pelas regras da Apple. A resposta técnica se chama CAPI (API de Conversões), ou rastreamento server-side. Ela ajuda muito. E, mesmo assim, não resolve o problema que mais custa dinheiro. Vamos por partes.

Por que o navegador perde sinal

O pixel é um script que roda no navegador do cliente e grava um cookie (o _fbp) para casar a conversão com o clique no anúncio. Três forças atacam exatamente esse mecanismo:

• Bloqueadores de anúncio e de rastreamento — simplesmente impedem o script de carregar ou de enviar o evento.
• ITP do Safari — a Prevenção Inteligente de Rastreamento limita qualquer cookie escrito por JavaScript a 7 dias; e, quando a URL de destino traz um parâmetro de clique (como o fbclid), o corte cai para 24 horas. Se a sua janela de atribuição é maior que uma semana, a compra volta como "sessão nova", sem ligação com o anúncio (Datafly Signal).
• App Tracking Transparency (iOS) — desde o iOS 14.5 o usuário precisa autorizar o rastreamento. E ele não autoriza: em 2024 o opt-in global caiu para cerca de 13,85%, segundo a Singular. Ou seja: para a maioria dos iPhones, o sinal de navegador nasce capado.

Quanto se perde — com números

Somadas, essas forças fazem o pixel deixar passar até 40% dos eventos de navegador, com casos relatados de até 70% a depender do mix de dispositivos e do público (Rockads). Vale insistir num ponto que quase ninguém junta: o pixel erra para os dois lados ao mesmo tempo. Para baixo, porque perde eventos bloqueados. E para cima, porque conta como "venda" a intenção de compra — boleto gerado, Pix não pago, pedido que depois vira reembolso. Menos sinal e sinal inflado convivendo no mesmo relatório.

O que a CAPI (server-side) recupera

A CAPI muda de onde o evento sai: em vez do navegador do cliente, é o seu servidor que envia a conversão direto para a Meta. Como roda fora do navegador, bloqueador, cookie de 7 dias e opt-in de iOS não a atingem. Na prática, ela recupera de 20% a 40% das conversões que o pixel deixava passar (AdAdvisor) — e, com identificadores fortes (e-mail, telefone, IDs próprios), o casamento com o clique melhora ainda mais.

É um ganho real: mais eventos válidos alimentando o algoritmo significam entrega mais eficiente e um custo por resultado mais próximo da realidade. Mas repare no verbo: a CAPI recupera evento. Ela devolve à Meta um sinal que estava sumindo — não converte esse sinal em verdade de caixa.

Por que a Meta manda rodar Pixel + CAPI com deduplicação

Aqui está a parte que costuma ser mal entendida: a CAPI não substitui o pixel. A própria Meta recomenda rodar os dois em paralelo, enviando os mesmos eventos pelos dois canais. O pixel captura o comportamento no navegador (bom para quem não bloqueia); a CAPI cobre o que o navegador engole. Redundância de propósito.

O problema óbvio da redundância seria contar a mesma compra duas vezes. É para isso que existe a deduplicação por event_id: você envia, nos dois canais, o mesmo event_name e o mesmo event_id. Ao receber dois eventos com esse par e um timestamp próximo (janela de 48h), a Meta mantém só um (documentação oficial da Meta). Se o servidor manda um event_id diferente — ou não manda nenhum —, a dedup falha e o seu relatório infla com duplicatas. Ou seja: uma CAPI mal deduplicada piora o problema que você foi resolver.

Onde a CAPI não te salva

Suponha o cenário ideal: pixel e CAPI rodando, dedup certinha, sinal recuperado. O seu ROAS no gerenciador subiu e ficou mais estável. Ótimo para o algoritmo. Agora a pergunta que decide o seu mês: esse número já pode mandar você escalar?

Não. Porque a CAPI resolveu o lado do sinal técnico, não o lado do dinheiro. O evento que a CAPI recuperou pode ser exatamente um boleto que nunca será pago ou um Pix iniciado e abandonado — a CAPI, aliás, é ótima em capturar e enviar esses eventos server-side com precisão. Você agora tem uma contagem mais completa de intenção de compra. Continua sem saber quanto dinheiro entrou no caixa por trás daquele criativo. E é o caixa que paga a conta da mídia.

O número que fecha a conta

O único dado que não infla, não some por bloqueador e não conta intenção é a venda real: o pedido pago e confirmado na sua plataforma ou ERP, já limpo de reembolso e de Pix não pago. Configure pixel e CAPI com deduplicação — isso é higiene de mídia e você deve fazer. Mas, na hora de escalar, cortar ou manter, cruze gasto × venda real × margem por campanha, todos os dias. Evento decide entrega; caixa decide dinheiro.

É isso que a Diwalli faz: puxa o gasto do Meta e do Google, cruza com a venda real da sua loja — a que fecha com o extrato — e mostra o retorno e o lucro reais por campanha, ao vivo. A CAPI melhora o que a Meta enxerga; a Diwalli mostra o que o seu caixa enxerga. Você precisa das duas coisas, e só uma delas decide para onde vai o próximo real de budget.