O sintoma: o Gerenciador de Eventos mostra Purchases ou Leads que o seu sistema de pedidos ou CRM não consegue associar a nada. Um anunciante relatou 105 compras em um dia a partir de um anúncio de tráfego, contra zero pedidos na loja (discussão na comunidade da plataforma de lojas, iniciada em 25 dez. 2023, relatado por anunciantes). Essa diferença aponta para eventos que nunca aconteceram ou para bugs de rastreamento. Uma ação fraudulenta real não deixa diferença nenhuma, porque o pedido ou o lead existe; ela aparece depois, como um estorno ou um lead que ninguém consegue contatar. Para entender como bots e tráfego inválido chegam aos anúncios da Meta, comece pelo nosso guia sobre fraude de cliques no Meta Ads.
Como verificamos. Não fizemos nenhum teste em conta de anúncios. O comportamento da Meta vem de páginas da Meta for Developers lidas em 12 de novembro de 2026, e os padrões dos anunciantes vêm de discussões de comunidade com data.
Como os eventos falsos do Meta Pixel são criados?
Os eventos suspeitos têm três causas: eventos que nunca aconteceram (um script ou navegador headless disparando o pixel), ações fraudulentas reais que geram eventos reais (como pedidos de teste de cartão) e bugs de rastreamento (instalações duplicadas, regras de configuração que disparam errado, um test_event_code esquecido). Uma pergunta separa a maioria deles: existe um registro no seu sistema de pedidos ou CRM? Sem registro e com o evento se reproduzindo na sua própria página, é um bug; sem registro e sem reprodução, ele nunca aconteceu; e um registro fraudulento significa fraude real.
A documentação mais recente da Meta chama o repositório dos seus eventos de conjunto de dados: o Meta Pixel envia eventos do navegador para ele, a API de Conversões da Meta envia eventos do servidor, e o Gerenciador de Eventos mostra os dois. O pixel é um script público cujo ID fica no código-fonte da sua página. A Meta define Purchase como “quando uma compra é feita ou o fluxo de finalização é concluído” e lista currency e value como obrigatórios para ele (referência do Meta Pixel). Nada nessa chamada prova que uma compra aconteceu.
Eventos que nunca aconteceram. Qualquer script que consiga executar o pixel pode chamar fbq('track', 'Purchase') com qualquer valor. Um navegador headless faz o mesmo de forma menos visível, disparando os eventos que uma pessoa dispararia.
Ações fraudulentas reais. Um bot de teste de cartão que conclui a finalização da compra com um cartão roubado cria um pedido real, então o Purchase é um evento real. Um lojista relatou em maio deste ano bots pedindo centenas de unidades do mesmo produto, o que afetou o pixel dele (discussão na comunidade da plataforma de lojas, iniciada em 16 mai. 2026, relatado por anunciantes). Nossa página sobre proteção contra fraude de cliques em e-commerce cobre o lado da loja.
Bugs de rastreamento. Os mais comuns são instalações duplicadas do pixel, uma página de agradecimento que dispara de novo ao recarregar, um test_event_code esquecido em produção, chaves de deduplicação quebradas e regras de configuração que disparam Purchase na página errada. Uma resposta de outubro de 2026 na discussão das 105 compras citada no início sugeriu verificar se há uma regra da Event Setup Tool (ferramenta de configuração de eventos) que transforma visualizações de página em eventos de Purchase (relatado por anunciantes).
Bugs do lado da Meta. Um lojista relatou compras de valor zero inflando as contagens e depois escreveu, em 20 de fevereiro de 2025, que a Meta tinha corrigido um bug do lado dela, vindo de uma publicação de código entre 8 e 11 de fevereiro, já revertida (discussão na comunidade da plataforma de lojas, iniciada em 10 fev. 2025, relatado por anunciantes).
Por que a Meta otimiza para eventos falsos?
Nossa leitura: a veiculação da Meta aprende com as conversões que você reporta, então um Purchase ou Lead falso a ensina a encontrar mais visitas parecidas com o falso.
A otimização por valor acrescenta uma segunda distorção: uma sequência de Purchases de US$ 0 ou de valor redondo distorce o valor que o sistema acha que um comprador traz, de novo uma leitura nossa.
Onde os eventos falsos aparecem no Gerenciador de Eventos?
O Gerenciador de Eventos mostra volumes, métodos de conexão e taxas de deduplicação, e as verificações de dados documentadas pela Meta sinalizam dados malformados, não eventos falsos do Meta Pixel. Use-o para localizar uma diferença e confirme a causa em outro lugar.
- Visão geral (Overview). A Meta diz que a Visão geral mostra “o número de eventos que recebemos antes de serem deduplicados” e que “em Método de conexão, você vê o canal pelo qual aquele evento foi enviado” (Verificando sua configuração, Meta for Developers). Compare a contagem diária de Purchase dela com os pedidos pagos.
- Detalhes do evento (Event Details). Aberta a partir da Visão geral, a aba Event Deduplication (deduplicação de eventos) mostra a “porcentagem de eventos que foram deduplicados de cada fonte de evento” e com que frequência cada chave de deduplicação é usada (mesma página).
- Dataset Quality API. A Dataset Quality API da Meta verifica eventos cujo “parâmetro de valor ou moeda está ausente ou é inválido”, endereços IP de cliente que “não correspondem aos do Meta Pixel” e eventos que “compartilham o mesmo e-mail de preenchimento em vez de um e-mail real” (Dataset Quality API, Meta for Developers). São verificações de formato; não encontramos nenhuma página da Meta que descreva uma verificação de bot, spam ou fraude, então um falso bem formado passa por todas.
- Test Events (eventos de teste). O caminho da Meta é Gerenciador de Eventos, depois Fontes de dados, depois o seu pixel, depois Test Events, e os eventos de servidor que você envia com o parâmetro test_event_code aparecem ali (Usando a API de Conversões).
- Event Match Quality (EMQ). O EMQ mostra o quanto as informações do cliente em um evento podem corresponder a uma conta da Meta (Boas práticas da API de Conversões), não se o evento é fraudulento. A Meta diz que ele “é pontuado de 1 a 10” e recomenda que você “busque uma pontuação de Event Match Quality de 6,0 ou mais” (Verificando sua configuração).
Nossa leitura, não a da Meta: se o EMQ dos eventos de lead cai enquanto o volume de leads sobe, verifique os leads, porque dados de contato inventados não correspondem a contas reais. Um formulário que parou de passar um campo também reduz o EMQ.
É um evento falso ou um bug de rastreamento?
A maioria dos padrões tem uma explicação inocente e outra hostil, e uma verificação em geral resolve qual das duas você tem.
| Padrão | Em geral é um bug quando | Nunca aconteceu ou é fraude real quando | Verificação que resolve |
|---|---|---|---|
| Purchase sem ID de pedido | Sua configuração nunca passa um ID de pedido | Nunca aconteceu: Purchases reais carregam um | Associe o horário de cada evento a um pedido |
| Purchase disparado na URL de uma página de produto | Dispara toda vez que você recarrega a página | Nunca aconteceu: não se reproduz e nenhum pedido corresponde | Recarregue a página com o painel de rede aberto |
| Valor redondo ou zero | Uma regra envia um valor fixo ou vazio | Nunca aconteceu: o valor não corresponde a nenhum produto | Compare os valores com seus preços e pedidos |
| Eventos só do navegador, sem gêmeo no servidor | Seu servidor envia só alguns eventos | Nunca aconteceu: seu servidor envia todo Purchase real | Compare os métodos de conexão na Visão geral |
| Eventos de um domínio que não é seu | O domínio é uma pré-visualização da loja ou uma sessão de teste | Nunca aconteceu: o domínio não tem ligação com o seu negócio | Revise os domínios nas configurações do seu pixel |
| Muitos Leads idênticos de um mesmo visitante em segundos | O formulário é enviado duas vezes | Fraude real: um bot enviou o formulário, então existem registros no CRM | Associe leads a registros do CRM e a horários |
| Pico de AddToCart, InitiateCheckout estável | Uma regra dispara AddToCart na visualização da página | Nunca aconteceu: visitas automatizadas clicam em adicionar ao carrinho | Agrupe o pico por origem, página e hora |
| Contagens exatamente em dobro | Duas instalações disparam ou as chaves de deduplicação diferem | Raramente é um dos dois: dobrar aponta para a configuração | Leia a aba Event Deduplication |
| Pico em uma loja ou campanha novinha | A configuração ainda está sendo testada | Nunca aconteceu: visitas automatizadas sondam o site novo | Compare com pedidos e datas de teste |
| O EMQ cai enquanto o volume sobe | Um formulário parou de passar um campo | Fraude real: os leads novos trazem dados de contato inventados | Revise os leads novos no seu CRM |
| Eventos com test_event_code em produção | O código nunca foi removido | Raramente é um dos dois: um código esquecido é um erro de configuração | Procure test_event_code no payload do seu servidor |
Anunciantes relataram vários desses padrões em discussões de comunidade da plataforma de lojas:
- Purchases de valor fixo. Uma discussão iniciada em 17 out. 2021, intitulada a partir de falsas compras de 99 dólares, descreve eventos de Purchase só do navegador disparados na página de produto. Uma resposta posterior disse que o suporte da Meta conseguia ver que os eventos tinham sido configurados por uma integração de parceiro.
- Lojas novas. Um lojista viu eventos falsos de adicionar ao carrinho, finalização e compra dois dias depois de abrir a loja (iniciada em 25 nov. 2020), e outro viu o mesmo em duas lojas com menos de 15 dias (iniciada em 19 out. 2022).
- Domínios desconhecidos. Um lojista encontrou cerca de 40 nas permissões de tráfego, incluindo subdomínios de pré-visualização da loja, e uma resposta sugeriu que sessões de teste poderiam explicar alguns (iniciada em 10 abr. 2024).
O que a deduplicação remove e o que ela não consegue
A deduplicação remove cópias de um mesmo evento real; ela não faz nada com um evento falso do navegador que não tem cópia no servidor. A Meta associa os eventos “com base no ID e no nome deles”, ou seja, o event_id e o nome do evento, e só os deduplica “se forem recebidos dentro de 48 horas” do primeiro evento com aquele ID (Deduplicar eventos do pixel e do servidor, Meta for Developers).
Os limites importam mais. A Meta diz que “não deduplica eventos quando só se usa uma fonte de eventos, isto é, só navegador ou só servidor”, e que dois eventos consecutivos do navegador com as mesmas informações são mantidos. A Meta também diz que o método com fbp ou external_id “em geral” só funciona para eventos “enviados primeiro pelo navegador e depois pelo servidor” (mesma página). Então um script que dispara Purchase no navegador é contado todas as vezes. Para montar a configuração do ID de evento, veja como configurar a deduplicação e as conversões filtradas contra fraude.
Como rastrear um Purchase suspeito
Escolha um Purchase que você não consegue associar a um pedido e siga-o até uma página, uma regra ou um script. Este exemplo é ilustrativo, não uma conta real.
- Encontre a diferença na Visão geral. Defina o intervalo de datas para o dia da diferença e leia o Método de conexão do Purchase.
- Colete o valor e a moeda. Seus logs da API de Conversões os guardam para os eventos de servidor. Um Purchase só do navegador cujo valor não corresponde a nenhum produto é a pista.
- Associe o horário a um pedido. Nenhum pedido pago em poucos minutos significa que o evento não tem cliente por trás.
- Abra o painel de rede das ferramentas do desenvolvedor do seu navegador e recarregue a página de produto. Veja quais requisições do pixel disparam e com quais parâmetros.
- Confirme com o Meta Ads Data Advisor. A Meta diz que a extensão, antes chamada de Meta Pixel Helper, mostra “o número de eventos do Pixel disparados na página atual” e os parâmetros deles (Meta for Developers).
- Reproduza no Test Events. Use um conjunto de dados de teste e nunca deixe o test_event_code no payload de produção. A Meta avisa que os eventos enviados com ele “não são descartados” e “entram no Gerenciador de Eventos e são usados para segmentação e para medição de anúncios” (Usando a API de Conversões).
- Confira os domínios que enviam eventos nas permissões de tráfego do seu pixel. A página de ajuda da Meta sobre essa configuração não carregou para nós em 12 de novembro de 2026.
Um Purchase que dispara quando você recarrega a página dispara para todo visitante. Se uma regra, o código do tema ou uma integração explica isso, você tem um bug; se nada explica, procure um script injetado. Se ele não se reproduz e nenhum pedido corresponde, confira o domínio e o método de conexão dele: uma chamada disparada à mão ou o script de outro domínio nunca aparece no seu painel de rede.
Como impedir eventos falsos na Meta
Para impedir eventos falsos do Meta Pixel, restrinja os domínios que enviam eventos, corrija as chaves de deduplicação, remova o test_event_code e depois envie o Purchase do seu servidor com dados de pedidos pagos.
- Revise as permissões de tráfego. Descarte pré-visualizações e sessões de teste e depois permita só os seus próprios domínios, se as suas telas atuais oferecerem isso. Uma lista de permissão não impede um script em um domínio que é seu.
- Corrija as chaves de deduplicação. Passe o mesmo ID de evento e o mesmo nome de evento do navegador e do servidor para cada evento real.
- Envie os eventos de conversão do servidor com um ID de evento compartilhado. Seu servidor sabe quais pedidos foram pagos. Isso não remove os eventos falsos do navegador, que continuam sendo contados, mas lhe dá uma contagem de Purchase confirmada pelo servidor para compará-los.
- Remova o test_event_code. Procure por ele nos payloads do servidor antes de cada lançamento.
- Faça a conciliação toda semana. Compare os eventos de Purchase e Lead com pedidos pagos e registros do CRM, seu registro de verdade.
Com a Black Friday em 27 de novembro, exporte agora as contagens diárias de Purchase, Lead e AddToCart por método de conexão, para avaliar os picos do dia da promoção em relação a uma linha de base, como o nosso checklist de fim de ano para Google Ads e Meta orienta.
Para leads que são pessoas reais sem intenção, veja como distinguir leads de baixa intenção de bots. Se a diferença começa antes, no clique, leia cliques no link vs. visualizações da página de destino.
O que a ClickFortify faz e o que ela não consegue impedir
A ClickFortify sinaliza conversões suspeitas depois de um clique em anúncio da Meta e pode filtrar eventos de servidor enviados pelo proxy de CAPI dela; ela não remove eventos que o Meta Pixel dispara no navegador.
A ClickFortify reconhece os cliques em anúncios da Meta pelo fbclid e pontua cada visita com mais de 100 pontos de dados de dispositivo, rede e comportamento no caminho da página de destino. Ela sinaliza três padrões de conversão suspeita no registro do clique: uma conversão em até 2 segundos depois do clique, uma conversão de um visitante já classificado como bot e um dispositivo com 3 ou mais conversões. Quando o proxy de CAPI está ativado, as conversões enviadas pela ClickFortify são verificadas contra a pontuação de fraude do visitante, e os eventos sinalizados são descartados ou marcados antes de a Meta recebê-los. Esse filtro cobre apenas os eventos de servidor enviados pelo proxy. Os eventos que o Meta Pixel dispara no navegador continuam chegando à Meta, e a ClickFortify não consegue impedir um script ou bot que dispara o pixel à mão.
A ClickFortify não verifica o endereço de e-mail nem o telefone de um lead, então combine-a com verificações no CRM. Os leads de formulários instantâneos não são eventos de pixel e a ClickFortify não consegue vê-los; para eles, veja o nosso guia sobre leads falsos nos anúncios de leads do Facebook. Ela não bloqueia endereços IP nem cria exclusões de público na Meta. Veja a ClickFortify para Meta Ads para a configuração.
Também anuncia no Google Ads? O lado das ações de conversão está no nosso guia sobre conversões falsas no Google Ads.
Nosso veredito: concilie os eventos com os pedidos e corrija os bugs primeiro, porque são a causa mais barata de descartar. Acrescente verificações de conversão quando a diferença acompanhar os cliques pagos e sobreviver à limpeza. Para o restante do grupo de temas, veja todos os guias de fraude no Meta Ads.
