Desde que a Apple passou a exigir autorização explícita para rastreamento entre apps (ATT, a partir do iOS 14.5), pixels que dependem só do navegador perdem visibilidade sobre uma parte do tráfego. A resposta do mercado foi a API de Conversões (CAPI/Conversions API) — mas "ativar a CAPI" virou um item de checklist que muita gente marca sem entender exatamente o que ela resolve e o que continua sendo problema.
O que o iOS 14 mudou de fato
Antes do ATT, um pixel de navegador (Meta Pixel, por exemplo) conseguia associar um evento de conversão a um usuário específico usando identificadores de dispositivo compartilhados entre apps. O ATT exige que o usuário autorize esse compartilhamento explicitamente, app por app. Quem não autoriza — e a Apple já deixou esse fluxo de recusa mais simples do que o de aceite — passa a gerar eventos que o pixel client-side não consegue atribuir com a mesma precisão de antes.
Isso não significa que o rastreamento parou de funcionar. Significa que ele passou a depender de uma fonte de dados que não esteja sujeita às mesmas restrições: o servidor.
O que o CAPI resolve
A API de Conversões envia o evento diretamente do seu servidor (ou de uma camada intermediária, como um Google Tag Manager server-side) para a Meta ou o Google, sem depender do navegador do usuário para disparar o pixel. Isso contorna três problemas específicos:
- Bloqueadores de anúncio e navegadores restritivos (Safari com ITP, Firefox com Enhanced Tracking Protection) não afetam um evento que nunca passou pelo navegador.
- Perda de sinal por falha de carregamento do pixel — conexão lenta, script bloqueado, aba fechada antes do disparo — deixa de ser um ponto de falha, porque o evento é enviado do lado do servidor, de forma mais confiável.
- Consistência de dados entre plataformas, já que o mesmo evento pode ser normalizado e enviado para múltiplas plataformas (Meta, Google, TikTok) a partir de uma única fonte.
O que o CAPI não resolve sozinho
A CAPI não recupera identidade que nunca existiu. Se o usuário não autorizou rastreamento e não há nenhum identificador (e-mail, telefone, ID de clique) para fazer o match do lado do servidor, o evento chega à plataforma, mas com menos capacidade de atribuição individual — o volume de eventos sobe, a precisão da atribuição por usuário, não necessariamente.
Também não resolve deduplicação sozinha: se você mantém o pixel client-side ativo (o que é recomendado, não um erro) e adiciona a CAPI, os dois vão reportar o mesmo evento de conversão para a mesma plataforma, a menos que você implemente o parâmetro de deduplicação (`event_id` na Meta, por exemplo) corretamente nos dois lados.
Pixel e servidor rodando juntos: o problema da duplicação
A recomendação de mercado é rodar pixel e CAPI em paralelo, não escolher um dos dois. O pixel client-side ainda captura sinais de comportamento (visualização de página, tempo no site) que o servidor não vê sozinho; a CAPI garante que o evento de conversão chegue mesmo quando o navegador não coopera.
O ponto de atenção é técnico: sem um identificador único de evento compartilhado entre as duas fontes, a plataforma de anúncios pode contar a mesma compra, o mesmo lead ou o mesmo cadastro duas vezes — uma vez vindo do pixel, outra vinda do servidor. Isso infla artificialmente o número de conversões reportadas e distorce qualquer decisão de otimização de campanha baseada nesse número.
Como comparar os dois sem se perder
O jeito prático de auditar isso é comparar, evento a evento, o que o pixel registrou e o que o servidor registrou, olhando para o mesmo período e o mesmo tipo de evento. Divergências grandes entre os dois geralmente apontam para um de três problemas: deduplicação mal configurada, pixel bloqueado com mais frequência do que o esperado, ou eventos do servidor sendo disparados em duplicidade por conta de reenvio automático.
O LeadInsight faz esse cruzamento automaticamente — client-side e server-side lado a lado, com deduplicação já tratada — para que a comparação vire uma leitura simples do dashboard, em vez de uma auditoria manual de logs.
Perguntas frequentes
Conclusão
iOS 14 não encerrou o rastreamento de conversões — deslocou parte dele para o servidor, e quem depende só do pixel client-side está deixando dado na mesa. O ganho real não vem de "ativar a CAPI" isoladamente, mas de rodar pixel e servidor juntos, com deduplicação correta e visibilidade sobre onde cada evento realmente veio.
Veja como a API de Conversões e o pixel de conversão do LeadInsight funcionam lado a lado, com deduplicação já resolvida.