Deduplicação de eventos no Pixel e CAPI: guia prático

Quem roda Pixel e CAPI juntos — a configuração recomendada pela própria Meta — esbarra cedo ou tarde numa dúvida: por que o número de conversões da campanha parece maior do que deveria? Na maioria dos casos, a resposta é deduplicação malfeita: o mesmo evento chegando por dois canais e sendo contado duas vezes. Este guia mostra o mecanismo por trás disso, como implementar o event_id compartilhado corretamente e como validar que está funcionando.

Se você ainda não sabe o que é CAPI ou por que ele passou a ser necessário num funil de Telegram, vale ler primeiro o guia educacional de API de Conversões — este artigo assume esse contexto e foca só no mecanismo de deduplicação. A definição rápida de deduplicação de eventos também está no glossário, caso só precise do resumo.

Por que Pixel e CAPI duplicam o mesmo evento

Pixel e CAPI não sabem, por padrão, que estão reportando a mesma coisa. O Pixel dispara no navegador quando o script carrega numa página; o CAPI dispara pelo servidor quando o backend (no caso de um funil de Telegram, o bot) identifica que o evento aconteceu. Se os dois estão configurados pra reportar o mesmo evento — por exemplo, o clique numa página intermediária e a entrada subsequente no canal — cada um manda sua própria chamada ao Meta, sem nenhuma relação entre elas por padrão.

Do ponto de vista do Meta, duas chamadas sem identificador em comum são dois eventos distintos. O resultado é uma conversão real virando duas linhas no relatório da campanha — inflando o número reportado sem que exista qualquer ganho de verdade por trás.

Como o event_id resolve isso

O mecanismo de deduplicação da Meta funciona em cima de um campo específico: o event_id. Quando o mesmo event_id é anexado tanto à chamada do Pixel quanto à chamada do CAPI, o Meta reconhece que as duas chamadas descrevem o mesmo evento visto por dois canais diferentes — e conta só uma vez no relatório.

Pra isso funcionar, três condições precisam ser verdadeiras ao mesmo tempo:

• O event_id precisa ser idêntico nas duas chamadas (não parecido, idêntico).
• O event_name também precisa bater entre as duas chamadas — um event_id compartilhado entre um evento Lead e um evento Purchase não deduplica, mesmo que o identificador seja o mesmo.
• As duas chamadas precisam chegar dentro da janela de deduplicação que a Meta aplica — não é instantâneo, mas também não é ilimitado no tempo.

Sem qualquer uma dessas três condições, o Meta trata as duas chamadas como eventos separados, e a duplicação volta a acontecer mesmo com um event_id presente nos dois lados.

Passo a passo: implementando a deduplicação corretamente

1. Gerar o event_id no primeiro disparo. Normalmente isso acontece no Pixel, na página intermediária — um identificador único é criado no momento em que o script dispara (um UUID, por exemplo).
2. Repassar esse mesmo event_id até onde o CAPI é disparado. Num funil de Telegram, isso significa guardar o identificador no registro do clique feito na página intermediária, pra que ele esteja disponível quando a entrada no canal for atribuída a esse clique e a chamada de CAPI do enter_channel for montada.
3. Usar o mesmo event_name nos dois disparos. Se o Pixel dispara como Lead e o CAPI dispara como enter_channel, os dois eventos nunca vão deduplicar — ainda que compartilhem o mesmo event_id.
4. Montar a chamada de CAPI incluindo o event_id recebido, sem gerar um novo — o erro mais comum aqui é o backend criar seu próprio identificador em vez de reaproveitar o que veio da página intermediária.
5. Validar no Gerenciador de Eventos antes de considerar o fluxo pronto (ver seção seguinte).

Como validar se a deduplicação está funcionando

O Gerenciador de Eventos do Meta Ads, na aba Eventos de Teste, mostra em tempo real cada evento recebido — de qual fonte veio (Pixel ou CAPI) e se ele foi reconhecido como duplicado de outro. Um evento corretamente deduplicado aparece com as duas fontes agrupadas sob o mesmo evento; um evento mal configurado aparece como duas linhas separadas, cada uma com sua própria fonte.

Antes de rodar verba de verdade com uma configuração nova, vale disparar um evento de teste (uma entrada real no canal, num ambiente controlado) e confirmar visualmente que Pixel e CAPI aparecem agrupados como um único evento, não dois.

Erros comuns que quebram a deduplicação

• Gerar um event_id novo em cada lado: o erro mais frequente. O backend (bot) monta sua própria chamada de CAPI com um identificador próprio, em vez de reaproveitar o event_id que a página intermediária gerou — sem saber disso, os dois eventos nunca se encontram.
• event_name diferente entre Pixel e CAPI: mesmo com event_id idêntico, nomes de evento diferentes impedem a deduplicação.
• Perder o event_id no caminho até a chamada de CAPI: se o identificador não é gravado junto com o clique na página intermediária (ou é truncado, ou mal formatado), não há como recuperá-lo na hora de montar a chamada do enter_channel.
• Achar que deduplicação é automática só por rodar os dois canais: rodar Pixel e CAPI juntos sem montar esse compartilhamento de event_id não deduplica nada — só dobra o volume de chamadas.
• Não testar antes de escalar verba: um problema de deduplicação não trava campanha nem gera erro visível — só infla um número que parece bom até alguém comparar com o resultado real.

Deduplicação no fluxo específico de Telegram

Num funil de e-commerce comum, Pixel e CAPI costumam disparar quase no mesmo instante — o mesmo checkout gera os dois eventos em sequência imediata. Num funil de Telegram, o intervalo tende a ser maior: o Pixel dispara na página intermediária, e a entrada real no canal (que gera o evento de CAPI) só acontece depois que a pessoa é redirecionada pro Telegram, abre o app e confirma a entrada — segundos a mais que, na maioria dos casos, ainda cabem dentro da janela de deduplicação da Meta, mas que tornam ainda mais importante guardar o event_id junto com o registro do clique, já que é a atribuição da entrada a esse clique que conecta os dois disparos separados no tempo.

Ver o guia de Pixel e CAPI no Telegram pro fluxo completo, campo a campo, de como o registro do clique carrega o event_id da página até a chamada de CAPI.

O que a experiência prática mostra

Na prática, o padrão mais comum de deduplicação quebrada não é ausência total de event_id — é um event_id que existe nos dois lados, mas é gerado de forma independente em cada um. Isso costuma passar despercebido justamente porque tudo parece configurado: o campo está preenchido, a chamada é aceita, nenhum erro aparece. Só quando alguém compara o número de conversões reportado com o volume real de entradas no canal (ou nota o event_id duplicado ao abrir a aba de Eventos de Teste) é que o problema fica visível.

Onde a Track4you entra nisso

A Track4you gera o event_id uma única vez na página intermediária e guarda esse mesmo identificador no registro do clique; quando a entrada no canal é atribuída a esse clique dentro da janela de atribuição, o disparo de CAPI reaproveita o valor guardado em vez de criar um novo. event_name também fica consistente entre os dois canais (enter_channel na entrada, left_channel na saída), então rodar Pixel e CAPI juntos não exige nenhuma configuração manual de deduplicação: o mecanismo já vem resolvido por trás da instalação do snippet e da conexão do bot.

Perguntas frequentes

Termos como event_id, CAPI e Event Match Quality têm definição rápida no glossário — vale a leitura se algum deles ainda não é familiar. Pra melhorar a qualidade dos eventos depois de resolver a deduplicação, ver o guia de Event Match Quality.

Conclusão

Deduplicação de eventos não é um detalhe técnico menor — é a diferença entre um relatório de campanha confiável e um inflado por eventos contados duas vezes. O mecanismo em si é simples (um event_id e um event_name idênticos nos dois disparos, dentro da janela de tempo aceita pela Meta), mas exige atenção em cada ponto onde esse identificador precisa passar de um sistema pro outro — sobretudo num funil de Telegram, onde página intermediária e bot são dois pontos separados que só se conectam através desse parâmetro. Validar no Gerenciador de Eventos antes de escalar verba é o passo que evita descobrir o problema tarde demais.