Pixel do GPT Ads na Hotmart via GTM Server

Você instalou o pixel do GPT Ads no site, viu o page_viewed chegar e considerou a implementação encerrada. Aí a primeira venda cai na Hotmart e o painel da OpenAI continua marcando zero conversão.

Não é bug. É que a compra acontece num domínio que não é seu, num checkout onde o seu pixel nunca vai rodar. O navegador do comprador sai da sua página de vendas e, do ponto de vista da plataforma de anúncios, desaparece.

A saída é parar de depender do navegador. O caminho que uso em produção é o webhook da Hotmart entrando direto no GTM Server e disparando a API de Conversão do GPT Ads, sem middleware no meio. O que quase ninguém conta são as travas do template, que só aparecem quando você lê o código-fonte dele.

O ponto cego do pixel no checkout externo

Qualquer pixel de navegador só dispara onde o seu código roda. Enquanto o visitante está na sua página de vendas, tudo funciona: visualização de página, lead, contato. No instante em que ele clica para comprar, a navegação vai para o domínio da Hotmart e dali em diante você não tem tag, não tem cookie e não tem evento.

A venda existe, mas ela é invisível para a plataforma que você está pagando para trazer o comprador. É o mesmo tipo de buraco que descrevi em a engenharia além do clique, só que agravado: aqui não é perda parcial de sinal, é ausência total do evento que mais importa para o aprendizado da campanha.

A Hotmart resolve a parte dela de um jeito simples. Ela avisa por webhook quando a compra acontece. O seu trabalho é transformar esse aviso de servidor em um evento de conversão que a OpenAI entenda.

O webhook da Hotmart e o gatilho que não depende do corpo

O caminho mais curto é a Hotmart chamando o seu GTM Server direto. Você cria um Data Client no contêiner de servidor escutando um caminho próprio e aponta o webhook da Hotmart para esse endereço.

O payload da versão 2.0 chega aninhado. Os campos que interessam ficam em data.buyer.email, data.purchase.transaction, data.purchase.price.value e data.buyer.address.country_iso. Variáveis de Event Data leem caminho com ponto normalmente, então você mapeia cada um direto, sem precisar achatar o JSON antes.

Agora a parte que derruba a maioria das implementações. O Data Client define o nome do evento como Data quando o payload não traz uma chave event_name. Só que a Hotmart manda um campo event no topo, com valores como PURCHASE_APPROVED, e o cliente adota isso como nome do evento. Resultado: o nome muda conforme o tipo de notificação. Se o seu gatilho filtra por nome de evento, ele funciona no teste e falha quando chegar um boleto impresso ou um reembolso.

Filtre pelo Request Path, não pelo nome do evento. A variável nativa de caminho depende só do endereço que você escolheu, nunca do corpo do JSON.

Há ainda a assinatura. A Hotmart envia um cabeçalho de verificação em cada chamada, e sem conferir isso o seu endpoint aceita compra falsa de qualquer origem. Qualquer pessoa que descubra a URL consegue injetar uma conversão no seu pixel e envenenar o aprendizado da campanha. Duas decisões importam: esse token entra no gatilho, nunca dentro da tag, porque mandá-lo no payload seria vazar uma credencial sua para um terceiro; e você precisa criar uma variável de cabeçalho para lê-lo, senão ele não aparece na pré-visualização e dá a falsa impressão de que a Hotmart não mandou nada.

As travas do template que não aparecem na interface

O template oficial faz validações próprias antes de chamar a API. Elas não estão na tela de configuração, e quando falham o evento simplesmente não sai, sem erro visível.

A primeira: action_source definido como web exige uma URL de origem. Sem esse campo o template aborta antes de tentar a chamada. Num evento vindo de webhook isso morde, porque não existe página. A tentação é preencher com a URL do seu endpoint de servidor, e aí você polui todo relatório por URL com um endereço que o comprador nunca viu. Mande a URL do checkout ou da página de vendas, ou use action_source offline, que dispensa o campo.

A segunda: o identificador do evento é obrigatório, com o mesmo comportamento silencioso. O melhor candidato é o código da transação da própria Hotmart, que é único por compra e ainda permite deduplicar em caso de reenvio.

A terceira: o valor vai em unidade menor, ou seja, centavos. Existe um campo alternativo que aceita o valor normal e converte sozinho. E a moeda passa a ser obrigatória sempre que houver valor.

Vale saber também que o preenchimento automático procura nomes canônicos de campo. Se você batizou suas variáveis de outro jeito, nada é mapeado sozinho. E apenas e-mail e identificador externo são convertidos em hash pelo template: cidade, CEP e país seguem em texto claro, apesar do sufixo que aparece no seletor.

Por fim, desligue nessa tag específica as opções que gravam cookie de clique e de navegador. Elas fazem sentido em visita real, mas numa tag disparada por webhook não existe navegador do outro lado: um identificador novo é gerado a cada requisição e cada compra entra como se fosse um dispositivo diferente, degradando a correspondência.

O dado que a Hotmart não manda

Essa é a limitação honesta do caminho direto. A Hotmart não envia IP do comprador, user agent, URL de página nem identificador de clique. Sem cruzar com o lead, a compra casa por e-mail e mais nada, o que deixa você dependente de um único sinal de correspondência. A lógica para contornar isso é a mesma que destrinchei em qualidade dos eventos no Meta.

Um detalhe que economiza horas de investigação: a Hotmart também não usa utm_source, utm_medium nem qualquer parâmetro utm no webhook. A atribuição dela vive em data.purchase.origin, com duas chaves apenas, src e sck. Quem procura utm no payload não acha nada e conclui, errado, que não há atribuição.

O src é a origem. O sck é texto livre, e é aí que está a oportunidade, porque você controla o que vai nele pelo link do checkout. Montando o sck com os seus próprios parâmetros separados por um caractere, você carrega campanha, criativo e identificador de usuário até dentro do webhook. É assim que se recupera o identificador externo e o clique que o caminho direto perderia: o link sai da sua página já carregando a informação, a Hotmart devolve intacta, e o seu servidor remonta o contexto do outro lado.

Perguntas Frequentes

Preciso de alguma automação no meio do caminho? Não. A Hotmart chama o GTM Server direto e as variáveis de Event Data leem o JSON aninhado sem problema. Middleware só se você precisar enriquecer o payload com dado de outro sistema.

Posso usar o mesmo endpoint para outras plataformas de checkout? Pode, desde que cada uma tenha o seu caminho e a sua validação de assinatura. Misturar plataformas no mesmo endereço obriga a filtrar pelo corpo, que é justamente o que você quer evitar.

E se o evento não aparecer no painel? Confira nesta ordem: o gatilho casou com o caminho e com a assinatura, a URL de origem e o identificador do evento estão preenchidos, e a moeda acompanha o valor. Essas três travas respondem pela maioria absoluta dos casos.

Reembolso também deve ser enviado? A Hotmart notifica reembolso e chargeback em eventos próprios. Trate-os em gatilho separado, porque mandar reembolso como conversão positiva ensina a campanha a buscar o comprador errado.

Montar isso corretamente é menos sobre seguir um passo a passo e mais sobre entender onde cada camada mente para você: o template que valida em silêncio, o cliente que troca o nome do evento, o cookie que inventa um dispositivo. Se você quer dominar essa engenharia do começo ao fim, incluindo GTM web e server, GA4, Meta CAPI e rastreamento de WhatsApp, é exatamente o que ensino no Dominando o Rastreamento.