O Pixel não dispara direito no checkout da Hotmart e da Kiwify porque a sua página de vendas e o checkout vivem em domínios diferentes. A LP está no seu domínio; o pagamento acontece em pay.hotmart.com ou checkout.kiwify.com.br. Os cookies que o Pixel usa para reconhecer a pessoa (_fbc e _fbp) são first-party do domínio da LP e não atravessam essa fronteira. No redirect, se o fbclid e os UTMs não forem carregados junto no link, eles somem — e o checkout recebe a venda sem saber de onde ela veio. Em popup e embed da Kiwify o efeito é ainda mais forte, porque o pagamento roda dentro de um iframe de outro domínio que não enxerga nada do que aconteceu na sua página.
A defesa real não é reinstalar o Pixel: é fazer o sinal atravessar o domínio antes de ele se perder. Isso se monta em quatro camadas — cookie server-side pelo GET /id, decorator nos links de checkout, fingerprint para reconciliar o que o cookie não carrega, e o webhook do checkout como fonte da verdade da compra. Com essa base montada, na operação do Tracker mais de 85% das vendas chegam com o fbclid capturado. A fração que escapa é justamente esse cenário de checkout externo mal configurado. É disso que trata o artigo.
Por que o cookie do Pixel não atravessa o checkout
O Meta Pixel identifica um visitante por dois cookies gravados no navegador: o _fbp (um ID de browser que o Pixel cria) e o _fbc (que guarda o fbclid, o identificador do clique que veio do anúncio). Esses cookies são first-party: pertencem ao domínio que os criou. Quando o Pixel roda na sua LP em suamarca.com.br, os cookies ficam presos a suamarca.com.br.
No momento em que o comprador clica em "comprar" e é levado para pay.hotmart.com, o navegador entra num domínio de registro diferente. Pela regra de isolamento de cookies dos navegadores, nada gravado sob suamarca.com.br viaja para hotmart.com. O checkout começa do zero, sem _fbc, sem _fbp, sem histórico. Se o único canal de informação era o cookie, a jornada quebra ali.
Sobra um caminho para o dado atravessar: a URL. Se o link de saída para o checkout carregar o fbclid e os UTMs como parâmetros (?fbclid=...&utm_source=meta...), o checkout consegue ler essa origem no destino. O problema é que quase ninguém decora esse link, e as próprias plataformas costumam limpar parâmetros no redirect. Aí o fbclid some no meio do caminho e a venda vira órfã. Escrevi em detalhe sobre o papel desses cookies no guia sobre os parâmetros _fbc e _fbp na atribuição do Meta.
O caso da Kiwify: popup e embed pioram tudo
A Kiwify empurra bastante o checkout em popup e o embed dentro da própria página de vendas. Parece que resolve o problema de domínio — o comprador nem "sai" do site. Não resolve. O conteúdo do popup e do iframe carrega de um domínio da Kiwify, e a política de isolamento continua valendo: o script que roda ali dentro não lê os cookies da sua LP nem os parâmetros da URL da página que o abriu. Do ponto de vista do navegador, é outro contexto.
Na prática, você tem um Pixel disparando PageView e ViewContent lindos na LP e um Purchase que chega no Gerenciador de Eventos com qualidade de matching baixa, sem o clique de origem amarrado. O Meta recebe a compra, mas não consegue casá-la com o anúncio que a gerou. O ROAS que aparece no painel é o que a plataforma conseguiu adivinhar, não o que aconteceu.
Por que a integração nativa da plataforma não resolve
Hotmart, Kiwify e Eduzz oferecem um campo para colar o seu Pixel ID e prometem "disparar o Purchase pra você". Isso cobre metade do problema e deixa a metade que importa de fora. O que a integração nativa faz é disparar o evento de compra a partir do domínio do checkout, no momento da aprovação. O que ela não faz é reconstruir a origem: ela não tem o _fbc da sua LP nem o fbclid do clique, porque esses dados nunca chegaram até o domínio dela.
O resultado é um Purchase tecnicamente presente e praticamente cego. Sem o fbclid amarrado, o Event Match Quality despenca e o Meta atribui a compra pelo que tiver em mãos — muitas vezes nada, ou um match fraco por e-mail que nem sempre bate. A UTM também entra nessa. A Hotmart, em especial, nem sempre repassa os UTMs na compra quando houve redirecionamento no meio, então o pedido chega no seu relatório sem campanha de origem.
Obs.: não estou dizendo para desligar a integração nativa. Ela é útil como piso — garante que existe um Purchase chegando. O ponto é que ela sozinha não fecha atribuição, e tratar aquele campinho de Pixel ID como "traqueamento pronto" é o erro que faz o gestor descobrir tarde demais que metade das vendas está sem origem. Se você vende por essas plataformas, vale ler o passo a passo de como rastrear vendas na Hotmart, Kiwify e Eduzz do jeito certo.
Como recuperar o sinal: as quatro camadas
A ideia é simples de enunciar e chata de executar na mão: o sinal precisa atravessar a fronteira de domínio antes de morrer, e a compra precisa ser reconciliada com a sessão que a originou. São quatro camadas que trabalham juntas, cada uma cobrindo uma falha da anterior.
1. Cookie server-side pelo GET /id
Cookie de navegador comum é frágil: limpeza de cache, modo anônimo e as proteções de privacidade do iOS e do Safari apagam o _fbp em pouco tempo. A defesa é um cookie gravado pelo servidor. No primeiro toque, o tracker chama GET /id e o backend devolve um cookie HttpOnly com validade longa, ligado ao visitante. Esse identificador sobrevive à limpeza de localStorage e persiste a jornada de forma bem mais estável que o cookie client-side do Pixel. É a base sobre a qual as outras camadas se apoiam.
2. Decorator nos links de checkout
Como o cookie não atravessa o domínio, quem atravessa é a URL. O tracker decora automaticamente os links de saída para Hotmart, Kiwify, Eduzz e Voomp, anexando os identificadores de sessão e de visitante nos parâmetros. O fbclid e os UTMs viajam junto no clique. Quando o tracker também está do outro lado, ele lê esses parâmetros na chegada e restaura a mesma sessão — a origem do anúncio segue amarrada à compra em vez de sumir no redirect.
3. Fingerprint para reconciliar o que o cookie não carrega
Nem todo fluxo passa por um link decorado — tem popup, tem embed, tem o comprador que abriu o checkout num aba nova. Para esses casos, o tracker calcula uma impressão do navegador a partir de sinais estáveis (canvas, user agent, tela, GPU). Esse fingerprint permite reconhecer o mesmo visitante mesmo quando o cookie foi apagado ou não atravessou, e casar retroativamente a sessão que chegou com fbclid na LP com a compra que fechou depois. É a rede que segura o dado quando as duas primeiras camadas falham.
4. O webhook do checkout como fonte da verdade
A última camada é a mais importante e a mais ignorada. Quando a compra é aprovada, a plataforma dispara um webhook — PURCHASE_APPROVED na Hotmart, order.paid na Kiwify — com os dados reais do pedido: valor, e-mail e telefone do comprador. Esse webhook é o fato contábil, o dinheiro que entrou de verdade. Ao receber a compra pelo servidor, você reconcilia esse pedido com a sessão de origem que o tracker capturou e dispara o Purchase pela API de Conversões com o fbclid e o e-mail hasheado já anexados. O Meta recebe a venda com matching alto, deduplicada, com origem amarrada — não a versão cega que a integração nativa mandaria.
Juntas, essas quatro camadas transformam o checkout externo de ponto cego em ponto medido. Nenhuma delas sozinha resolve; é a combinação que faz o fbclid chegar em mais de 85% das vendas. Para o panorama completo de como montar essa base, o guia completo de traqueamento cobre cada camada, e o funcionamento da API de Conversões da Meta está detalhado num artigo dedicado.
Um caso real de checkout cego
Numa operação de infoproduto que acompanhei, o gestor jurava que o problema era criativo: o Meta reportava um ROAS que não fechava com o extrato da Hotmart, e ele estava prestes a matar uma campanha inteira. Quando olhamos o dado bruto, a campanha estava indo bem — o que estava quebrado era a ponte. A LP mandava para o checkout da Hotmart sem decorar o link, e a integração nativa disparava um Purchase sem fbclid. Na minha experiência, esse é o padrão: a conta parece pior do que é porque metade das vendas chega sem origem.
Depois de decorar os links de saída e ligar o webhook como fonte da verdade, a fração de vendas com clique amarrado subiu de um patamar baixo para a casa dos 85%. A campanha que ele quase pausou era a que mais vendia. O criativo nunca foi o problema — o problema era que o sinal morria no redirect e ninguém tinha medido isso.
Perguntas frequentes
Por que o Pixel não dispara no checkout da Kiwify?
Porque o checkout da Kiwify carrega de um domínio diferente da sua LP, muitas vezes em popup ou embed. Os cookies _fbc e _fbp são first-party e não atravessam domínios, então o script do checkout não lê o fbclid nem os UTMs da sua página. A compra chega sem a origem amarrada.
A integração nativa da Hotmart resolve a atribuição?
Só em parte. Ela dispara o evento de Purchase, mas a partir do domínio do checkout, sem o fbclid e o _fbc da sua LP. O Event Match Quality cai e o Meta não casa a venda com o anúncio de origem. Serve como piso, não como atribuição completa.
Como o fbclid chega no checkout se o cookie não atravessa?
Pela URL. O link de saída para o checkout precisa carregar o fbclid e os UTMs como parâmetros, e o tracker do lado do checkout lê esses valores na chegada. É o que um decorator de links faz automaticamente. Sem ele, os parâmetros somem no redirect e a venda fica órfã.
Por que o webhook do checkout é importante para o Pixel?
Porque ele traz a compra real com e-mail e telefone do comprador, direto do servidor da plataforma. Com esse dado você reconcilia a venda com a sessão de origem e dispara o Purchase pela API de Conversões com fbclid e e-mail hasheado, gerando matching alto e evento deduplicado no Gerenciador de Eventos.
O próximo passo
O Pixel some no checkout externo porque o sinal morre na fronteira entre o seu domínio e o da plataforma de pagamento — e a integração nativa só disfarça o buraco. Recuperar a atribuição é fazer o fbclid atravessar essa fronteira e reconciliar a compra com a sessão que a originou, usando o webhook como fonte da verdade. É a diferença entre um ROAS que você adivinha e um que você mede. O Tracker monta essas quatro camadas e reconcilia a venda com o checkout real — comece os 30 dias grátis e veja quantas das suas vendas estão chegando sem origem hoje.