Por que uma compra aparece duas vezes no Meta?

As causas mais comuns são dois disparos de navegador para a mesma transação, pixel e CAPI sem o mesmo event_id, reprocessamento do webhook ou duas transações legítimas dentro da mesma jornada. O diagnóstico começa pelos códigos de transação, pela origem de cada evento e pelo event_id recebido.

Order bump conta como outra compra no Meta?

Pode contar, porque a Hotmart processa o order bump separadamente da oferta principal. A transação complementar recebe identidade própria e pode virar outro Purchase. Use parent_purchase_transaction para agrupá-la com a compra principal nos relatórios sem apagar a receita adicional.

Um upsell deve usar o mesmo event_id da compra inicial?

Não. Se o upsell gerou outra transação, ele representa outra venda e precisa de um event_id próprio. Reutilizar o ID da compra inicial faria a Meta tratar dois pagamentos diferentes como se fossem uma repetição.

Quanto tempo a Meta leva para deduplicar eventos?

A janela documentada para casar o evento do navegador com o evento do servidor pode chegar a 48 horas. Os dois envios podem aparecer durante o teste, mas só devem formar uma conversão quando event_name e event_id forem idênticos. Duas origens com IDs diferentes não serão corrigidas pela espera.

Compra duplicada no Meta: order bump, upsell ou pixel repetido?

Q: Como saber se o pixel da plataforma ficou ligado?

Abra uma compra controlada no modo de teste e filtre as requisições do pixel no navegador. Se o Purchase sair uma vez pela integração nativa da plataforma e outra pelo GTM ou por código manual, existem dois donos do evento. Desative um deles e repita o teste antes de alterar a CAPI.

Compra duplicada no Meta pode ser erro ou pode ser faturamento real. Uma jornada com produto principal, order bump e upsell pode gerar três transações e, portanto, três eventos Purchase. Já uma única transação enviada pelo pixel da plataforma, pelo GTM e pela API de Conversões é uma venda repetida. Somar tudo e chamar de duplicata apaga receita legítima. Aceitar tudo infla o relatório.

O diagnóstico certo compara três campos antes de mexer em qualquer tag: código da transação, origem do evento e event_id. Transações diferentes ficam separadas. O mesmo pagamento recebido mais de uma vez precisa carregar a mesma identidade ou ser bloqueado antes do envio. Essa distinção resolve o caso em que o painel mostra três vendas para uma pessoa, sem confundir pessoa, jornada e transação.

Por que uma compra aparece duas ou três vezes no Meta?

Uma compra aparece repetida quando dois sistemas descrevem o mesmo pagamento como eventos independentes. Isso acontece se a integração nativa do checkout ainda dispara o pixel e o GTM dispara outro Purchase, se o navegador e a CAPI usam IDs diferentes, ou se o webhook é processado de novo. Existe também o caso legítimo: o comprador aceitou produtos adicionais e o checkout abriu outra transação para cada oferta. O e-mail pode ser o mesmo, o intervalo pode ser de poucos segundos e a campanha pode ser uma só. Nada disso prova duplicidade. A unidade que decide é a transação financeira. Se os códigos de transação diferem, investigue primeiro se houve order bump ou upsell. Se o código é o mesmo, compare as origens e os IDs enviados ao Meta. Esse recorte evita a correção mais perigosa, que é desligar um evento válido porque o total por comprador parece alto.

Use esta leitura rápida:

O que você encontrou	Diagnóstico provável	Ação
Três códigos de transação na mesma jornada	Principal, bump e upsell legítimos	Manter três vendas e agrupá-las para análise
Um código, dois eventos de navegador	Pixel nativo e GTM ou código manual	Escolher um único dono do `Purchase` no navegador
Um código, navegador e servidor, mesmo ID	Dupla entrega esperada	Conferir a deduplicação antes de remover uma origem
Um código, navegador e servidor, IDs diferentes	Deduplicação quebrada	Propagar o mesmo ID para os dois canais
Mesmo webhook processado mais de uma vez	Idempotência quebrada	Bloquear pelo ID da notificação e pela transação

Order bump e upsell são compras duplicadas?

Order bump e upsell não são duplicatas quando geram cobranças próprias. A Central de Ajuda da Hotmart informa que a transação do order bump é processada separadamente da oferta principal. No Webhook 2.0, o objeto purchase.order_bump traz is_order_bump e parent_purchase_transaction. O primeiro identifica a compra complementar; o segundo aponta para a transação principal que originou as compras da página de pagamento. Um upsell aceito depois da compra inicial também é uma oferta adicional e pode abrir sua própria transação. Nesse cenário, uma pessoa passou por uma jornada, mas a operação vendeu mais de um produto. Para o Meta, cada pagamento pode ser um Purchase com valor, conteúdo e event_id próprios. Para o relatório interno, agrupe as transações pela relação pai e pelo pedido de origem. Agrupar serve para contar jornadas. Deduplicar serve para remover cópias do mesmo fato.

Um exemplo deixa a diferença visível:

Produto principal: transação HP-A, valor R$ 297.
Order bump: transação HP-B, valor R$ 47, ligada à HP-A como transação pai.
Upsell: transação HP-C, valor R$ 197, aceita depois da primeira compra.

São R$ 541 em três vendas. Enviar apenas HP-A reduz a receita atribuída. Enviar as três com o mesmo event_id também está errado, porque força três pagamentos distintos a disputar uma única identidade.

Uma jornada pode ter três transações. A deduplicação entra somente quando dois envios representam a mesma transação.

Como saber se o pixel da plataforma ficou ligado?

O pixel da plataforma ficou ligado quando o checkout envia Purchase pela integração nativa e outra implementação envia o mesmo evento pelo navegador. O segundo disparo costuma vir do GTM, de um plugin antigo ou de código colado na página de obrigado. A ajuda oficial da Meta sobre duplicação do pixel orienta começar pela atividade da fonte de dados. No teste técnico, abra as ferramentas do navegador, filtre as requisições do pixel e conclua uma compra controlada. Anote horário, URL, valor, moeda e o identificador de cada chamada. Depois confira o Preview do GTM. Se uma chamada saiu antes de qualquer tag do container e outra apareceu junto do gatilho de compra, há duas instalações ativas. O conserto é definir um dono para o evento do navegador. Desligue a integração nativa ou a tag manual, conforme o desenho escolhido, e teste novamente. Manter duas tags e torcer para o Meta reconhecer a semelhança deixa o resultado dependente de IDs que talvez nem existam.

Não comece removendo a CAPI. Pixel e servidor podem trabalhar juntos quando carregam o mesmo event_name e o mesmo event_id. O erro aqui são dois disparos independentes de navegador, sobretudo quando cada um inventa seu próprio ID.

Como funciona a janela de deduplicação de até 48 horas?

A janela de até 48 horas é o período em que o Meta pode casar o evento do navegador com o evento correspondente enviado pelo servidor. A regra usa a combinação de event_name e event_id, conforme a documentação de deduplicação da API de Conversões. Durante um teste em tempo real, é normal enxergar a chegada por duas origens. Isso prova que os dois canais entregaram dados; ainda não prova que duas conversões serão mantidas. Confira se ambos dizem Purchase e carregam exatamente o mesmo ID. Depois observe o processamento e compare o total consolidado com a base financeira. Esperar só faz sentido quando o par já está correto. IDs diferentes, dois eventos apenas do navegador ou duas transações diferentes não se resolvem com o relógio. A janela também explica alguns alarmes falsos: a equipe vê dois recebimentos logo após a compra, desliga uma tag e quebra uma implementação que estava preparada para deduplicar.

O limite não transforma o Gerenciador de Eventos em razão financeira. Use o painel para verificar recebimento e origem. Use a Hotmart para provar quantas transações foram aprovadas. A reconciliação vem da comparação entre as duas superfícies.

Qual event_id usar em cada compra?

Use uma chave estável e exclusiva da transação como base do event_id. No fluxo da Hotmart, purchase.transaction já identifica a venda e é um candidato direto. A transação principal, o order bump e o upsell recebem valores diferentes. Se o mesmo pagamento for enviado pelo pixel e pela CAPI, os dois lados reutilizam o mesmo valor. No navegador, o parâmetro é eventID; no payload do servidor, é event_id. O conteúdo precisa casar caractere por caractere.

Quatro chaves protegem pontos diferentes do fluxo:

id da notificação do webhook impede processar a mesma entrega novamente;
purchase.transaction impede criar outra compra para o mesmo pagamento;
parent_purchase_transaction agrupa o order bump com a compra principal sem fundir as vendas;
event_id faz pixel e CAPI representarem uma única conversão no Meta.

O artigo sobre rastreamento Hotmart por webhook mostra onde validar o hottok e guardar o ID da notificação. Para entender por que o mesmo identificador precisa viajar pelo navegador e pelo servidor, veja o guia de deduplicação da API de Conversões.

Como testar sem apagar vendas reais?

Teste uma jornada controlada que aceite o order bump e o upsell. Antes do pagamento, registre uma referência de teste e mantenha o mapa de atribuição salvo. O guia do indexador entre a página e o checkout cobre essa ponte. Depois da aprovação, exporte ou consulte as transações na Hotmart e monte uma linha para cada código. A documentação do Relatório de Vendas inclui o tipo de order bump e a transação principal associada.

Faça então o teste em ordem:

Conte as transações aprovadas e some a receita real.
Relacione principal, bump e upsell sem fundir os códigos.
Confira quantos Purchase saíram do navegador para cada transação.
Confira o evento do servidor e compare o event_id com o do navegador.
Reenvie a mesma notificação para provar que a idempotência bloqueia a cópia.
Observe a deduplicação do par correto e reconcilie o total consolidado.

O controle negativo ajuda. Troque um caractere do event_id em ambiente de teste e confirme que o par deixa de casar. Depois restaure o valor. Também desligue temporariamente a integração nativa do pixel e verifique qual chamada desaparece. Esse procedimento identifica o dono de cada envio sem adivinhação.

Se o checkout confirma três transações e o Meta mantém três compras com a mesma soma, o rastreamento está coerente. Se a Hotmart confirma uma transação e o Meta mantém duas, existe duplicação real. Antes de pausar uma campanha por causa de outra tela, veja por que dashboard de atribuição e infraestrutura de eventos podem divergir. A ATA configura o fluxo do webhook à CAPI, define a idempotência e valida a compra de ponta a ponta. Veja o escopo de rastreamento server side da Advanced Tracking Academy.