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 identifica que o evento aconteceu. Se os dois estão configurados pra reportar o mesmo evento — por exemplo, o Lead de um formulário enviado ou o Purchase de um checkout — 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 onde a ação acontece — 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. Na prática, o identificador viaja junto com a própria ação — no envio do formulário, no pedido gravado pelo checkout — pra estar disponível quando o servidor montar a chamada de CAPI daquele mesmo evento.
3. Usar o mesmo event_name nos dois disparos. Se o Pixel manda um cadastro como Lead e o servidor manda o mesmo cadastro como CompleteRegistration, 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.
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 conversão real num ambiente controlado, como um cadastro ou uma compra de teste) 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 monta sua própria chamada de CAPI com um identificador próprio, em vez de reaproveitar o event_id que a página 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 é enviado junto com a ação na página (ou é truncado, ou mal formatado), não há como recuperá-lo na hora de montar a chamada do servidor.
• Achar que a deduplicação é automática numa implementação própria: rodar Pixel e CAPI montados por você, sem 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 Telegram, a pergunta muda de forma. O evento que mais importa — a entrada no canal (enter_channel), e também a saída (left_channel) — acontece dentro do app do Telegram, onde nenhum navegador está olhando. Não existe Pixel no navegador capaz de ver essa entrada, então não existe cópia client-side desse evento pra deduplicar: ele só chega à Meta pelo servidor, uma vez.

Isso também desfaz uma confusão comum: o clique no botão da página e a entrada no canal são eventos diferentes, não o mesmo evento visto por dois canais. Um Lead no clique e um enter_channel na entrada não devem deduplicar — os dois precisam ser contados, cada um com seu nome.

Sobram os eventos da página (visita e clique). Num funil montado na mão, em que o Pixel no navegador e o seu servidor mandam o mesmo evento pro mesmo pixel, valem as três condições acima. Num funil da Track4you, o próprio script já manda esses eventos, e a recomendação é não instalar um Pixel à parte nas páginas — a seção seguinte explica. Ver o guia de Pixel e CAPI no Telegram pro fluxo completo do funil.

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 (pedidos, cadastros) 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 manda pro pixel escolhido no funil um evento por etapa: ViewContent na visita à página, Lead no clique no botão, enter_channel na entrada no canal e left_channel na saída. Os dois eventos do canal só existem do lado do servidor — nenhum Pixel no navegador vê a entrada —, então não há cópia da entrada pra deduplicar nem event_id pra você configurar. O que fica do seu lado é confirmar o enter_channel e o left_channel, que são eventos personalizados: o “Evento Teste” faz os dois aparecerem no Gerenciador de Eventos, e a confirmação é feita uma vez por pixel. A lista completa está no help oficial, em quais eventos a Track4you manda pro pixel.

E o Pixel da Meta na página? Como o script da Track4you já manda ViewContent e Lead pro pixel escolhido no funil, a recomendação é não instalar o seu próprio Pixel nas páginas do funil — pros eventos do funil, ele não acrescenta nada. Se ele já estiver instalado (por um tema, um plugin ou um teste antigo), não precisa correr pra tirar: a Meta deduplica automaticamente, sem event_id nenhum pra você montar. Mas, num funil novo, o caminho mais limpo é deixar só o script. Planos e condições em track4you.app.

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. Num funil de Telegram, a entrada no canal nem entra nessa conta — ela só chega pelo servidor. Com a Track4you, os eventos da página também já saem pelo script, sem Pixel à parte pra deduplicar. Quem monta o rastreamento na mão, com Pixel e servidor mandando o mesmo evento, precisa validar no Gerenciador de Eventos antes de escalar verba — é o passo que evita descobrir o problema tarde demais.