CAPI para infoproduto: quando a venda acontece fora do seu site

Todo guia de CAPI pressupõe que a compra acontece no seu domínio. No infoproduto ela acontece no checkout da plataforma, e isso muda o event_id, o filtro de status e de onde sai o user_data.

Os guias de API de Conversões são quase todos escritos para lojas: a pessoa navega, coloca no carrinho e paga, tudo no mesmo domínio. Quem vende infoproduto vive outra realidade — a compra acontece no checkout da plataforma, e a notícia da venda chega por webhook, minutos ou dias depois.

Isso muda quatro decisões. Nenhuma delas é difícil, e todas são erradas por padrão.

1. O event_id não pode ser gerado na hora do envio

O identificador de evento é o que impede o Meta de contar a mesma compra duas vezes. Se você mantém o pixel no navegador e liga a CAPI, os dois lados precisam mandar o mesmo valor.

Como a venda chega por webhook, a tentação é gerar um identificador no momento do envio. Por definição, ele será diferente do que o navegador mandou. O valor certo vem do negócio: o código da transação que a plataforma devolve, que é estável e igual nos dois caminhos.

2. O status não é o que você imagina

Aqui mora o erro mais caro do segmento. As plataformas de infoproduto têm muito mais estados do que "pago" e "não pago": boleto impresso, PIX gerado, PIX expirado, compra aprovada, compra completa, em disputa, reembolsada, com estorno, atrasada.

Mandar tudo como conversão ensina a campanha a procurar pessoas que geram boleto e não pagam — e ela obedece muito bem. O filtro correto costuma ser um par de estados, e nada além disso.

Existe um detalhe que quase ninguém percebe: o nome do estado que chega no webhook nem sempre é o nome que aparece na tabela da plataforma. Medimos casos em que a tela mostra um nome e o payload entrega outro — e um filtro escrito olhando a tela nunca casa.

A regra prática é medir antes de mapear: peça uma amostra dos últimos eventos reais, liste os estados presentes, e escreva o filtro sobre essa lista — nunca sobre a documentação.

O segundo evento da mesma venda

Várias plataformas emitem um evento de compra aprovada na hora e outro de compra completa dias depois, quando termina o prazo de garantia. São dois eventos da mesma venda. Filtrar os dois como conversão duplica o faturamento; filtrar só o segundo atrasa o aprendizado da campanha em uma semana.

3. O user_data não vem do webhook

O payload da venda traz o e-mail do comprador, e é tentador parar por aí. Mas o webhook não traz o cookie do clique no anúncio nem o do navegador — eles ficaram no site, na visita que aconteceu antes.

Sem eles, você manda uma conversão com e-mail e sem nenhum sinal de navegador, e perde a atribuição direta justamente na venda. A montagem correta do user_data cruza as duas coisas: o que veio no webhook e o que a plataforma já sabia sobre aquela pessoa.

4. A sincronização de histórico não pode virar conversão

Toda plataforma de infoproduto oferece uma API para buscar vendas passadas, e é comum sincronizar de hora em hora para manter o relatório em dia. Isso é ótimo para o relatório e péssimo para o envio.

Se cada sincronização reemite as vendas da janela, a mesma compra vira conversão várias vezes por dia. Num caso que medimos, um único envio produziu cerca de sete entregas por venda — e o relatório do Meta mostrava um faturamento que não existia.

A regra é separar os dois caminhos: o webhook dispara conversão, a sincronização alimenta o relatório. Quando a sincronização encontra uma venda que o webhook perdeu, aí sim ela emite — uma vez.

O resumo para colar na parede

No CrazyLeads essas quatro decisões são o comportamento padrão para Hotmart e Kiwify: identidade de negócio no event_id, filtro escrito sobre uma amostra dos eventos reais da sua conta, user_data montado a partir do grafo, e sincronização que emite apenas o que o webhook não trouxe.