O Pixel da Meta mede eventos enviados pelo navegador; a Conversions API envia eventos a partir do servidor ou de uma integração. Usar os dois pode melhorar resiliência e controle, mas não garante capturar “100%” das conversões. Consentimento, bloqueios, qualidade da implementação e regras da plataforma continuam valendo.
O papel de cada camada
- Pixel: observa carregamento de páginas e ações no navegador, onde contexto como URL e cookies pode estar disponível.
- Conversions API: permite enviar eventos do servidor, CRM, backend ou parceiro compatível.
- Gerenciador de Eventos: mostra recebimento, diagnóstico, correspondência e deduplicação.
A documentação da Conversions API recomenda usar o canal servidor em complemento ao Pixel quando ambos representam o mesmo funil.
Defina eventos a partir do negócio
Antes do código, desenhe uma tabela com ação, evento, origem e valor. Exemplos:
| Ação | Evento possível | Quando enviar |
|---|---|---|
| Visualizou produto | ViewContent | quando a página válida carregar |
| Iniciou checkout | InitiateCheckout | após a ação real, não só uma visita |
| Enviou formulário | Lead | depois da confirmação de envio |
| Pagamento confirmado | Purchase | quando o backend confirmar o pedido |
Não use Purchase para clique no botão ou boleto gerado. O nome do evento precisa representar a etapa real.
Como funciona a deduplicação
Quando o mesmo evento sai do navegador e do servidor, envie o mesmo event_name e o mesmo event_id nos dois canais. A Meta usa essa identidade para reconhecer que os sinais descrevem uma única ação. IDs aleatórios gerados separadamente impedem a deduplicação.
Navegador: event_name=Purchase, event_id=pedido_8472
Servidor: event_name=Purchase, event_id=pedido_8472O identificador não deve expor dados pessoais. Gere-o no fluxo da aplicação e mantenha consistência entre as camadas.
Dados do usuário e privacidade
Parâmetros de correspondência podem ajudar a atribuição, mas só devem ser enviados com base legal e conforme as regras da Meta. Normalize e faça hash dos campos exigidos pela documentação; não envie informação sensível, senha, conteúdo de formulário ou dado desnecessário.
Consentimento precisa ser aplicado antes da coleta que depende dele. CAPI não é um atalho para ignorar a escolha do usuário. Documente quais eventos são estritamente necessários, quais são publicidade e como a revogação é tratada.
Três caminhos de implementação
Integração nativa
Plataformas de e-commerce e CRM podem oferecer Pixel e CAPI. É o caminho mais rápido, mas revise eventos, IDs, valores e duplicidade; “conectado” não significa “correto”.
Gateway ou tag server-side
Centraliza parte da coleta e encaminhamento. Inclua hospedagem, atualização, consentimento e observabilidade no custo.
Backend próprio
Oferece mais controle para pedido, lead e CRM, mas exige versionamento, filas, retentativas, segurança e manutenção.
Validação antes de usar em campanha
- abra a ferramenta de eventos de teste;
- execute uma conversão por vez;
- confirme nome, horário, URL, moeda e valor;
- verifique se navegador e servidor aparecem deduplicados;
- repita com consentimento aceito e recusado;
- compare uma amostra com pedidos ou leads reais;
- monitore diagnósticos depois da publicação.
Erros que prejudicam os dados
- dois plugins enviando o mesmo evento sem
event_idcomum; - valor ou moeda diferentes entre navegador e servidor;
- lead disparado no carregamento da página;
- compra enviada antes da confirmação;
- token exposto no código do navegador;
- dados pessoais em URL ou log;
- evento servidor enviado mesmo após recusa de publicidade;
- concluir que toda diferença entre painel e banco é falha técnica.
Fontes e limites
Revisamos a Conversions API, a orientação de deduplicação de eventos e os Padrões de Publicidade da Meta. A Meta não promete recuperação total de dados; resultados dependem da implementação e da elegibilidade dos sinais.