E-commerce e infoprodutos

Postback da Hotmart, Kiwify e Monetizze: como ligar a venda ao anúncio que a gerou

Por Equipe Affilitrack · · 11 min de leitura
Resposta curta

Você gera um link de redirect que cria um click_id único a cada clique e repassa esse identificador à plataforma no parâmetro que ela aceita — src na Hotmart, sck e src conforme o caso, subid em outras. Quando a venda acontece, a plataforma dispara um postback server-side para a URL do seu tracker, devolvendo o mesmo identificador junto com valor, status e id da transação. O tracker casa esse postback com o clique original e a venda passa a ter campanha, anúncio e custo associados. O pixel do navegador deixa de ser a única fonte de verdade: ele continua alimentando a otimização, mas a contabilidade passa a vir do servidor.

Quem vende infoproduto com tráfego pago convive com uma lacuna específica: a plataforma de checkout sabe que a venda aconteceu, o gerenciador de anúncios sabe que houve cliques, e ninguém junta as duas metades de forma confiável. O pixel tenta juntar, mas depende de navegador, de cookie, de consentimento e de a página de obrigado carregar até o fim.

Postback resolve a lacuna por outro caminho. É uma chamada de servidor para servidor, disparada pela plataforma de vendas quando o evento acontece, que chega ao seu tracker mesmo que o comprador feche a aba, troque de aparelho ou bloqueie scripts. Este artigo mostra como montar essa ligação com Hotmart, Kiwify e Monetizze, o que conferir em cada etapa, e onde o processo costuma quebrar.

O que precisa estar ligado antes do postback existir

O postback só é útil se houver a que casar. A ordem correta é: primeiro o identificador de clique, depois o retorno do evento.

O fluxo tem quatro etapas:

  1. Clique. O usuário clica no anúncio e cai em um link de redirect no formato /r/{slug}. Nesse instante nasce um click_id único, gravado com campanha, fonte, criativo, dispositivo e horário.
  2. Repasse. O redirect envia o usuário para a página de vendas ou checkout já carregando o click_id no parâmetro que a plataforma aceita.
  3. Venda. O comprador finaliza. A plataforma guarda o valor daquele parâmetro junto com o pedido.
  4. Postback. A plataforma chama a URL do seu tracker devolvendo o identificador, o valor, o status e o id da transação.

Se a etapa 2 falhar, a etapa 4 chega vazia. Por isso a maior parte dos problemas de postback na verdade é problema de parâmetro na URL — assunto que o material sobre como funciona o rastreamento por click_id e atribuição detalha com mais calma.

A URL da oferta: onde o click_id entra

Cada plataforma tem um ou mais campos de rastreamento livres que ela carrega do checkout até o postback. Os nomes variam e mudam de tempos em tempos, então a regra prática é: abra a documentação da sua plataforma, procure por "parâmetro de rastreamento", "src", "sck", "subid" ou equivalente, e confirme dois pontos — se o campo é aceito na URL e se ele volta no postback. Campo que entra mas não volta não serve.

Na prática, uma URL de oferta com o identificador fica assim:

https://pay.suaplataforma.com/checkout/abc123?src={click_id}

E o link que você usa no anúncio é o do redirect:

https://rastreio.seudominio.com.br/r/oferta-vsl-01

O redirect gera o click_id, substitui a macro e encaminha. São 33 macros disponíveis para montar a URL de destino — campanha, criativo, palavra-chave, dispositivo, posicionamento, entre outras. E há um detalhe que evita dor de cabeça: macro desconhecida fica intacta. Se você escrever algo que o sistema não reconhece, ela não é apagada nem substituída por vazio, o que impede que um erro de digitação silencie um parâmetro inteiro.

Exemplo com mais campos preenchidos:

https://pay.suaplataforma.com/checkout/abc123?src={click_id}&sck={campaign_name}_{ad_id}

Um campo carrega o identificador técnico, que é o que casa a venda. O outro carrega rótulo legível, útil para quem abre o painel da plataforma de vendas e quer entender a origem sem consultar outro sistema.

A URL de postback: onde o evento volta

Do lado de retorno, você cadastra na plataforma de vendas uma URL para onde ela deve disparar os eventos. O endpoint é /postback (ou /pb), e a identificação da conta acontece de duas formas:

  • Com token por workspace, quando você usa o domínio padrão.
  • Sem token, quando você usa domínio de tracking próprio — nesse caso o próprio domínio já identifica a conta.

Formato típico com token:

https://rastreio.affilitrack.com.br/postback?token=SEU_TOKEN&click_id={SRC}&event=sale&value={VALOR}&txid={TRANSACAO}

As chaves em maiúsculo representam os campos que a plataforma preenche. Cada uma usa nomes diferentes — a Hotmart chama de um jeito, a Kiwify de outro, a Monetizze de outro. É exatamente aqui que o mapeamento por merchant entra.

Mapeamento por merchant: o que evita reescrever integração

Em vez de você adaptar a plataforma de vendas ao tracker, o tracker se adapta a ela. Para cada merchant você define três coisas na tela, sem redeploy e sem esperar suporte:

O que define Para que serve Exemplo de valor
Parâmetro de evento Diz se é venda, lead ou reembolso status, event, tipo
Parâmetro de valor Qual campo traz a receita prod_value, valor, amount
Parâmetro de transação Qual campo traz o id único do pedido transaction, order_id, txid

Há presets prontos para Hotmart, Kiwify, Monetizze, Braip e um genérico para qualquer plataforma que dispare webhook com parâmetros na URL ou no corpo. O preset acelera o começo; o editor resolve os casos em que a plataforma muda um campo ou você usa um produto com payload diferente. A lista completa está em integrações disponíveis, e o detalhamento por plataforma em integrações com Hotmart e Kiwify.

Hotmart

A Hotmart trabalha com campos de rastreamento próprios que acompanham o pedido do checkout ao evento de pós-venda. Na configuração, o que importa é identificar qual campo devolve o identificador que você mandou, qual traz o status do pedido (aprovado, cancelado, reembolsado) e qual traz o valor líquido ou bruto. A escolha entre bruto e líquido não é detalhe: ela define se o seu ROI no relatório considera ou não a taxa da plataforma. Escolha um critério e mantenha.

Kiwify

A Kiwify dispara webhook com payload estruturado, incluindo status do pedido e identificador de transação. O ponto de atenção é o mesmo de qualquer plataforma que envia vários eventos para o mesmo pedido: pedido gerado, pedido pago, pedido reembolsado. Você decide qual deles vira conversão no relatório. Contar "pedido gerado" como venda infla o número e destrói a leitura de campanha, principalmente em boleto e Pix, onde a diferença entre gerar e pagar é grande.

Monetizze

A Monetizze também envia postback com status por etapa e tem campos de rastreamento próprios. Vale checar se o produto que você promove está com o postback habilitado no nível certo — em algumas configurações o disparo é por produto, não por conta, e um produto novo entra sem postback ativo. É um dos motivos mais comuns de "parou de funcionar do nada" que na verdade é "nunca foi ligado para este produto".

Deduplicação: por que a mesma venda não vira duas

Plataformas reenviam. Reenviam por retry quando a primeira chamada falha, reenviam quando o status muda, reenviam quando alguém reprocessa a fila. Se o tracker contasse cada chegada como conversão, um pico de retry viraria um dia de faturamento fictício.

A regra aplicada é por id de transação: o mesmo txid não vira segunda conversão. E há um comportamento que merece destaque — quando chega um postback repetido com valor divergente, a conversão original é preservada e o evento divergente é registrado no log. Nada é sobrescrito em silêncio. Se a plataforma mandou R$ 297 às 14h02 e R$ 197 às 14h09 para o mesmo pedido, você vê as duas linhas e decide o que fazer, em vez de descobrir semanas depois que o relatório mudou sozinho.

O log é a ferramenta de diagnóstico

Todo postback recebido é registrado, com classificação:

  • Casado — evento ligado a um clique conhecido. É o cenário desejado.
  • Duplicadotxid já contabilizado. Normal em volume; suspeito se for a maioria.
  • Órfão — evento válido sem clique correspondente. Indica parâmetro não preenchido, tráfego fora do link ou compra vinda de origem que você não rastreia, como lista de e-mail.
  • Inválido — payload que não bate com o mapeamento: campo ausente, formato inesperado, token errado.

A leitura desse log é a diferença entre "o tracking está com problema" e "o parâmetro src não está sendo preenchido nas compras via Pix desde terça". Quando a maioria dos eventos chega órfã, o problema está na URL da oferta. Quando chega inválida, está no mapeamento. Quando não chega nada, está no cadastro da URL de postback na plataforma. A lógica de diagnóstico é a mesma descrita no artigo sobre discrepância entre plataforma e tracker.

Roteiro de configuração e teste

Uma sequência que funciona bem, na ordem:

  1. Crie a oferta no tracker e gere o link /r/{slug}.
  2. Monte a URL de destino com a macro de click_id no parâmetro que a plataforma aceita.
  3. Cadastre a URL de postback na plataforma de vendas, com token ou no domínio próprio.
  4. Selecione o preset do merchant e confira os três campos do mapeamento.
  5. Faça uma compra de teste ou dispare o teste da própria plataforma.
  6. Abra o log e confirme: o evento chegou, está casado, o valor está correto e o txid foi lido.
  7. Cadastre o custo da campanha para que o relatório mostre margem, não só receita.
  8. Só então suba verba.

O passo 7 costuma ser pulado e é o que transforma relatório em decisão. Com custo por campanha configurado — CPC, CPM, CPA fixo ou custo manual por dia — os relatórios por dia, campanha, fonte e sub mostram cliques, leads, vendas, receita e custo na mesma linha.

O que o postback não faz

Importante ser claro para você não configurar esperando algo que não vem:

  • Não envia o evento de volta para Meta ou Google. O postback traz a venda para o seu tracker. Se você quer alimentar o algoritmo com esse evento, isso continua sendo trabalho do pixel ou de uma API de conversões configurada no lado da plataforma de anúncio. A comparação entre as duas camadas está no artigo sobre rastreamento server-side e pixel.
  • Não puxa pedidos por API. O modelo é de recebimento: a plataforma avisa, o tracker registra. Não há consulta ativa ao histórico da loja.
  • Não adivinha origem de quem não passou pelo link. Venda vinda de e-mail, orgânico ou indicação chega órfã se não tiver identificador. Isso não é falha, é ausência de sinal — e o log deixa isso explícito em vez de inventar uma atribuição.

Quando o volume cresce

Com uma oferta e duas campanhas, quase qualquer arranjo funciona. O arranjo precisa ser sólido quando você tem oito ofertas, três plataformas de checkout e criativos trocando toda semana. Nesse ponto, o que sustenta a operação é a padronização: mesmo formato de slug, mesma macro no mesmo parâmetro, mesmo critério de valor, e o log conferido como rotina e não como reação a problema.

Se a sua operação já está nesse estágio ou chegando nele, vale entender como o conjunto se organiza em o que a plataforma faz, como o postback server-to-server se comporta com múltiplos merchants e o que muda quando a atribuição está quebrada. Para quem está escolhendo o arranjo agora, preços e perguntas frequentes ajudam a dimensionar. E termos que aparecem no meio do caminho estão no glossário.

Perguntas frequentes

Preciso de domínio próprio para receber postback?

Não é obrigatório, mas ajuda. Com domínio de tracking próprio a conta é identificada pelo próprio domínio e a URL de postback fica mais curta e estável. Sem domínio próprio, o postback usa token por workspace para saber a qual conta o evento pertence.

Qual parâmetro eu uso para levar o click_id em cada plataforma?

Varia por plataforma e às vezes por tipo de produto. Hotmart, Kiwify, Monetizze e Braip têm campos de rastreamento próprios como src, sck e subid. Confira na documentação da sua plataforma qual campo ela aceita na URL do checkout e devolve no postback, porque esses nomes mudam com o tempo.

O postback repetido vira duas vendas no relatório?

Não. A deduplicação é por id de transação: o mesmo txid não gera segunda conversão. Se chegar um postback repetido com valor divergente, a conversão original é preservada e o evento divergente fica registrado no log para auditoria.

E se o postback chegar sem o click_id?

Ele entra no log como órfão. A venda existiu, mas não há clique para casar, normalmente porque o parâmetro não foi preenchido na URL do checkout ou porque o tráfego entrou fora do link de redirect. O log de órfãos é o melhor termômetro de cobertura do seu rastreamento.

Postback substitui o pixel do Meta ou do Google?

Não. O pixel alimenta o algoritmo de entrega da plataforma de anúncio; o postback alimenta a sua contabilidade. O Affilitrack recebe o postback e mostra a venda ligada ao clique, mas não envia esse evento de volta para Meta ou Google automaticamente.

Dá para testar antes de rodar tráfego pago?

Sim, e é o recomendado. Faça uma compra de teste ou use o disparo de teste da plataforma, confira no log se o evento chegou, se casou com um clique e se o valor foi lido no campo certo. Só depois suba verba.

Equipe Affilitrack

Time que constrói e opera o Affilitrack. Escrevemos a partir de operação real de tracking de afiliados no Brasil — postback de casa de aposta, infoproduto e mídia paga.

Teste o Affilitrack com a sua operação

Postback server-side, atribuição por clique e repasse automático para sub-afiliados. Planos a partir de R$ 97/mês, com Pix ou cartão.

Continue lendo