Venda no checkout não marca na campanha? O indexador que falta

A venda no checkout não marca na campanha quando o pagamento e o clique chegam a sistemas diferentes sem uma chave comum. A LP conhece a URL do anúncio. O checkout conhece o pedido. O webhook conhece a aprovação. Se nenhum índice atravessar essas três etapas, a venda pode aparecer corretamente no financeiro e ainda ficar sem campanha na plataforma de mídia.

O conserto é criar um identificador first-party curto na LP, persistir no servidor o vínculo entre esse índice e os dados do clique, enviar o índice por um parâmetro aceito pelo checkout e recuperá-lo quando a venda aprovada chegar por webhook. Neste artigo, chamaremos esse índice de xcod. Em checkouts que aceitam sck, uma forma prática é transportar xcod como valor de sck, sem colocar e-mail, telefone ou a campanha inteira na URL.

Principais pontos

• sck é o campo de transporte aceito por alguns checkouts. xcod é a chave criada pela sua operação.
• O mapa entre xcod e o clique precisa existir no servidor antes do redirecionamento ao pagamento.
• Cookie e localStorage ajudam no navegador, mas o webhook não consegue lê-los.
• O caminho do campo varia entre Hotmart, Kiwify e Cakto. O payload real do seu produto é a prova.
• Venda recebida e venda atribuída são estados diferentes. Teste os dois.

Por que a venda no checkout não aparece na campanha?

Porque confirmar uma transação não identifica automaticamente o anúncio que trouxe a pessoa. O webhook costuma carregar o pedido, o status financeiro e os dados liberados do comprador. Já a atribuição de mídia depende de informações observadas antes, como UTM, identificador de clique ou uma referência própria. Quando o botão da LP manda o visitante para outro domínio sem preservar um índice, o checkout cria o pedido sem conhecer o registro first-party da visita. Mais tarde, o webhook informa que a compra foi aprovada, mas não tem como consultar o navegador que iniciou a jornada. A tag server side pode disparar e o endpoint pode responder com sucesso. Mesmo assim, a plataforma de mídia recebe uma venda sem a referência necessária para ligá-la à campanha. Por isso o diagnóstico começa antes do webhook: confira qual chave nasceu na LP, qual valor entrou no link de pagamento e qual campo voltou com o pedido.

Esse é um problema de junção de dados. O evento financeiro existe. Falta a chave que aponta para a linha certa do clique.

O que é o indexador first-party da LP?

É um identificador opaco, criado num domínio controlado pela operação, que representa uma visita ou tentativa de compra. O xcod não precisa explicar a campanha. Ele só precisa apontar, sem colisão, para um registro server side que guarda o contexto permitido: horário, página de entrada, UTMs, identificadores de clique disponíveis e o estado de consentimento usado na coleta. Um valor como 7F4K9M2Q8R6T3V5X é melhor que um texto longo com nome de campanha. Cabe em mais integrações, não expõe dados pessoais e permite mudar o esquema interno sem alterar o checkout. A gravação precisa acontecer antes de abrir a página de pagamento. Se o servidor só salvar o mapa depois do clique no botão, uma navegação rápida, um bloqueio de rede ou o fechamento da aba pode deixar o pedido sem registro. Trate a criação do índice e a persistência do mapa como uma etapa única: primeiro confirme a gravação, depois monte o link do checkout.

First-party aqui descreve controle e contexto do dado. Não significa ignorar consentimento, finalidade ou retenção. O índice deve carregar a menor informação possível na URL.

Qual é a diferença entre sck e xcod?

sck e xcod cumprem papéis diferentes. sck é um nome de parâmetro reconhecido por checkouts. Na Hotmart, ele identifica a origem da página de pagamento e volta no Webhook 2.0 em purchase.origin.sck, segundo a documentação de origem de vendas e a referência do webhook. A Kiwify lista sck entre os parâmetros aceitos e informa que esses valores ficam associados à compra em cookie. A documentação de parâmetros da Kiwify também mostra onde conferir os dados no pedido. A API da Cakto expõe sck no objeto do pedido, conforme a referência oficial de pedidos.

xcod é uma convenção da sua implementação. Pode ser enviado dentro de sck, desde que o checkout e o payload usado no projeto preservem o valor.

Elemento	Quem define	Função	Exemplo
sck	Checkout	Transportar uma referência de origem no pedido	?sck=7F4K9M2Q8R6T3V5X
xcod	Sua operação	Indexar o registro first-party do clique	7F4K9M2Q8R6T3V5X
Mapa first-party	Seu servidor	Ligar o xcod aos dados coletados na LP	xcod associado ao clique e à campanha

Como persistir o índice da LP até o webhook?

Comece no primeiro carregamento elegível da LP. Leia os parâmetros permitidos, gere um xcod aleatório e grave o mapa num endpoint first-party. O servidor deve responder somente depois de confirmar a persistência. Ao montar o botão, acrescente o índice ao parâmetro suportado pelo checkout, preservando qualquer query string que já exista. Quando o pedido for aprovado, valide a origem do webhook, extraia o campo que contém o índice e consulte o mapa. Só então monte o evento de conversão com os identificadores exigidos pelo destino. A venda precisa de outra chave para idempotência, como o ID do evento ou do pedido. O xcod liga compra e clique; ele não deve ser usado sozinho para impedir reenvio do mesmo webhook. Uma pessoa pode comprar duas vezes partindo da mesma visita, e uma transação pode gerar notificações distintas de aprovação, reembolso e chargeback.

Uma sequência segura fica assim:

1. A LP recebe a visita e aplica a regra de consentimento do projeto.
2. O backend gera ou aceita um xcod aleatório, curto e alfanumérico.
3. O backend persiste o vínculo entre xcod e o contexto do clique, com prazo de retenção definido.
4. O botão abre o checkout com sck=<xcod> ou outro campo oficialmente aceito.
5. A venda aprovada chega ao endpoint autenticado.
6. O processador extrai o índice, busca o mapa e envia a conversão.
7. O ID do pedido e o ID da notificação controlam duplicidade e reconciliação.

Se você já recebe a aprovação no server GTM, o guia de rastreamento Hotmart por webhook cobre autenticação, estados financeiros e idempotência. O indexador entra antes desse fluxo e entrega o contexto que o pagamento não cria sozinho.

Como usar o índice na Hotmart, Kiwify e Cakto?

Use a mesma arquitetura, mas confirme o contrato de cada checkout. Na Hotmart, sck é próprio da página de pagamento, tem limite documentado de 30 caracteres e aparece em purchase.origin.sck no Webhook 2.0. Isso favorece um xcod alfanumérico curto. Na Kiwify, sck está entre os parâmetros aceitos na URL; a referência de webhooks da Kiwify mostra o campo sck no JSON de exemplo. Na Cakto, o objeto de pedido documentado inclui sck, enquanto o webhook usa eventos como purchase_approved. A documentação de webhooks da Cakto descreve os eventos e o prazo de resposta. Se o payload entregue ao seu endpoint não trouxer sck, consulte o pedido pela API usando o identificador recebido, em vez de presumir um caminho que não foi documentado para aquele evento.

Não escreva uma função que tenta adivinhar dezenas de nomes. Crie um adaptador por plataforma e versão. Cada adaptador recebe o payload bruto e devolve uma estrutura interna com order_id, event_id, status, value, currency e xcod. Payload desconhecido deve ir para quarentena, com log suficiente para investigação e sem disparar compra.

O webhook precisa receber UTM, sck ou xcod?

Ele precisa receber uma chave que permita recuperar o contexto original. Mandar todas as UTMs no webhook parece mais simples, mas cria URLs longas e acopla o contrato do checkout ao formato da campanha. Algumas plataformas guardam UTMs no pedido; outras não as encaminham no webhook da mesma forma. A própria Hotmart informa que UTMs estruturadas não são repassadas nos envios do Webhook, enquanto purchase.origin.sck faz parte da referência da versão 2.0.0. Um xcod dentro de sck reduz essa dependência: o webhook recebe uma chave curta e o servidor busca os campos atuais do mapa. Se amanhã a operação adicionar um novo identificador de clique, o valor transportado continua igual. O desenho também facilita expiração e acesso restrito, pois os detalhes não ficam expostos na query string do checkout nem espalhados por relatórios exportados.

O mapa precisa sobreviver ao navegador e ao container. Cookie, sessionStorage e localStorage podem manter continuidade na LP, mas nenhum deles está disponível para uma chamada server-to-server feita horas ou dias depois. Use armazenamento durável adequado ao volume e à janela de atribuição do projeto.

Como testar quando a venda continua sem marcar?

Teste a cadeia em ordem, com uma compra controlada e um xcod conhecido. Primeiro, abra a LP com uma URL de campanha de teste e confirme a resposta do endpoint que grava o mapa. Depois inspecione o link final do botão. O sck deve carregar exatamente o índice salvo, sem perder caracteres na concatenação de ? e &. No checkout, conclua o pedido e confira se o parâmetro aparece nos detalhes da venda. Em seguida, abra a entrega real do webhook, pois o evento sintético não traz todas as condições do pedido. Localize o índice no caminho esperado, valide o ID do pedido e consulte o mapa first-party. Por último, confira no destino se a conversão foi recebida uma vez e se ficou associada à campanha de teste. O código de resposta do endpoint prova recebimento; não prova atribuição.

Use estes controles negativos:

• envie um webhook sem xcod e confirme que ele vai para a fila de não atribuídos, sem inventar campanha;
• repita a mesma notificação e confirme que a compra não conta de novo;
• use um xcod inexistente e verifique se o erro fica pesquisável pelo ID do pedido;
• altere um caractere do índice no link e confirme que o sistema não casa por aproximação.

Se a venda chega, mas a campanha segue vazia, o primeiro ponto quebrado do teste indica o dono da correção. A ATA implementa essa ponte da LP ao checkout e do webhook ao destino, com adaptadores por plataforma, armazenamento do índice e teste de compra real. Veja o escopo de rastreamento e atribuição da Advanced Tracking Academy.

O indexador não substitui a validação financeira. Ele preserva a memória do clique. Quando o webhook confirma o pagamento, as duas partes finalmente se encontram.

Quando a venda chega mais de uma vez, o próximo diagnóstico é separar order bump, upsell e pixel duplicado no Meta antes de remover qualquer evento.