Pix e boleto: por que a conversão não chega no Meta e no Google
Vendeu por Pix, o dinheiro entrou, e o Gerenciador não registrou. Ou registrou boletos que ninguém pagou. As duas coisas têm a mesma causa e a mesma correção.
Atualizado em 8 de setembro de 2026 · por WYB Trackers
Por que a conversão de Pix e boleto se perde
O evento de Purchase disparado na página de obrigado representa um pedido criado, não um pedido pago. Com Pix e boleto, a aprovação chega minutos ou dias depois, com o navegador do comprador já fechado. O resultado é um de dois erros: ou a conta conta conversões que nunca foram pagas, ou não conta nada.
A correção tem duas metades e precisa das duas ao mesmo tempo. Usar o webhook de pagamento como fonte de verdade do Purchase, e persistir os identificadores de atribuição no momento da criação do pedido, para que o evento server-side ainda tenha _fbp, _fbc e gclid quando o pagamento for confirmado.
Por que quase não existe material sobre isso
As duas falhas opostas, e as duas são graves
Toda operação brasileira que vende por Pix ou boleto está em uma das duas. Elas são simétricas e o prejuízo é diferente em cada uma.
Falha A: disparar o Purchase na página de obrigado
O evento sai no momento em que o pedido é criado, antes de qualquer pagamento. Conversões que nunca foram pagas entram na otimização. A campanha aprende a comprar gente que gera boleto e não paga, porque foi exatamente isso que você ensinou a ela a valorizar.
Falha B: não disparar nada até o pagamento
A conversão passa a existir apenas no servidor, no momento da aprovação. Sem os cookies de atribuição capturados antes, ela chega sem _fbp, sem _fbc e sem gclid. A plataforma registra que houve uma venda e não sabe de qual clique ela veio.
Resolver só a metade temporal pode piorar
Como diagnosticar qual das duas está acontecendo
A verificação leva poucos minutos e distingue as duas falhas sem ambiguidade.
- 1Compare, no mesmo período, os pedidos APROVADOS no seu checkout com os eventos de Purchase registrados na plataforma de anúncio.
- 2Se o número de Purchase for maior que o de pedidos aprovados, e próximo do total de pedidos CRIADOS, você está na falha A: está contando cobrança emitida.
- 3Se o número de Purchase for próximo do de pedidos aprovados, abra um desses eventos e inspecione os dados do usuário.
- 4Procure _fbc e _fbp no payload. Vazios em uma venda que veio de clique em anúncio indicam a falha B.
- 5No Google Ads, confira se as conversões de pedidos pagos por boleto aparecem com atraso e sem campanha atribuída.
- 6Confirme a origem do tráfego antes de concluir: em sessão que não veio de clique da Meta não existe fbclid, então _fbc ausente ali é esperado e não é defeito.
A arquitetura correta: webhook mais persistência
O detalhe que quase ninguém documenta é este: o problema não é disparar o evento depois. É que quando você dispara depois, os identificadores de atribuição já não existem mais. A arquitetura precisa resolver as duas metades ao mesmo tempo, momento certo e identificador preservado.
A gravação acontece enquanto o navegador ainda está aberto, na criação do pedido, usando o identificador do pedido como chave. A leitura acontece quando o webhook de pagamento chega, usando a mesma chave. É isso que permite um Purchase server-side com _fbp, _fbc e gclid íntegros mesmo com o comprador fora da jogada há dias.
Os nomes dos webhooks divergem entre plataformas
Errar o nome é falha silenciosa: nada quebra, o webhook simplesmente nunca dispara. Os três padrões mais comuns no e-commerce brasileiro:
| Plataforma | Evento | Formato |
|---|---|---|
| Nuvemshop / Tiendanube | order/paid | barra, singular |
| Shopify | orders/paid | barra, plural. ORDERS_PAID no enum da Admin API |
| Yampi | order.paid | ponto no lugar da barra |
O que o payload do webhook não traz
Esta é a limitação central e ela não tem contorno. O webhook vem do servidor da plataforma de checkout, não do navegador do comprador. Logo, o payload não carrega:
_fbpe_fbc, que são cookies do navegador.gclid,gbraidewbraid, que chegam na URL do clique.- O endereço IP real do comprador.
- O
user_agentreal do navegador dele.
Enviar direto do webhook para a Conversions API, sem um store no meio, produz um evento com casamento ruim e sem atribuição de clique. É por isso que integração nativa de checkout, por mais conveniente que seja, não substitui a arquitetura descrita aqui.
O IP e o user agent também precisam ser remapeados
Deduplicação: não contar o mesmo pedido duas vezes
A chave é o identificador da transação. No Meta, ele vai como event_id; no Google Ads, como transaction_id, que aparece na requisição de conversão como oid. Precisa ser o mesmo valor nos dois caminhos, e precisa ser determinístico: o identificador do pedido serve, um valor aleatório gerado pelo GTM Web não serve, porque o servidor não consegue reproduzi-lo.
Há uma condição na deduplicação da Meta que costuma passar batida: ela funciona apenas dentro do mesmo pixel. Evento de navegador em um conjunto de dados e evento de servidor em outro não deduplicam de jeito nenhum, e cada um conta a venda uma vez.
O limite de 7 dias da Conversions API
A documentação da Meta define que o event_time pode ter no máximo 7 dias no momento do envio, e recomenda enviar assim que o evento ocorre, idealmente dentro de uma hora. Para boleto, que pode levar dias para ser pago, esse prazo é apertado e precisa ser tratado explicitamente.
Um evento velho derruba o lote inteiro
event_time no lote estiver a mais de 7 dias no passado, a Meta retorna erro para a requisição inteira e não processa nenhum evento. Uma rotina que envia em lote e inclui um boleto pago no oitavo dia derruba junto dezenas de conversões que estavam dentro do prazo. O sintoma confunde, porque some um bloco de vendas válidas por causa de um único registro velho. A correção é filtrar por event_time antes de montar o lote.Eventos com action_source igual a physical_store têm prazo maior, de 62 dias. Isso não se aplica a venda online, então não use essa exceção para tentar contornar o limite de 7 dias.
O que essa arquitetura não resolve
Vale registrar, porque promessa de paridade total é o sinal mais confiável de proposta ruim.
| Situação | Resolve? |
|---|---|
| Purchase contando cobrança não paga | Sim. É o caso de uso principal. |
| Purchase pago chegando sem identificador de clique | Sim, com o store gravado antes. |
| Pagamento confirmado depois de 7 dias | Não. É limite documentado da API, não de implementação. |
| Pagamento fora da janela de atribuição da plataforma | Não. A venda existe, a atribuição não. |
| gclid ou fbc que nunca foi capturado | Não. O servidor não inventa identificador que não existiu. |
| Paridade de 100% entre loja e gerenciador | Não existe, e não deve ser prometida. |
O objetivo realista é reduzir a divergência a uma faixa explicável, não zerá-la. Parte da diferença que sobra não é erro: a plataforma conta o pedido no dia do pedido, e a Meta conta no dia do clique.
Perguntas relacionadas
Devo disparar o Purchase quando o Pix é gerado ou quando ele é pago?
Quando é pago. O Pix gerado pode virar um evento separado de intenção, com outro nome, mas não deve ocupar o Purchase. O Purchase é o evento pelo qual a campanha otimiza: se ele representar pedido criado, o algoritmo aprende a buscar gente que gera cobrança e não paga.
Dá para resolver isso só no client-side?
Não. O navegador do comprador já não está aberto quando o pagamento é confirmado. Qualquer solução que dependa de código rodando na página do usuário falha por definição em pagamento assíncrono, porque não existe página aberta no momento da aprovação.
O evento server-side atrasado ainda é atribuído à campanha?
Sim, com duas condições. Ele precisa chegar dentro da janela de atribuição da plataforma e precisa carregar os identificadores de clique capturados no momento certo, lá atrás, quando o navegador ainda estava aberto. Evento pontual sem identificador é registrado como conversão, mas sem origem.
E se o cliente pagar o boleto depois da janela de atribuição?
A venda existe, a atribuição não. É uma perda estrutural do modelo de pagamento assíncrono, não um erro de implementação. Nenhuma arquitetura recupera um clique que já saiu da janela da plataforma.
Existe prazo máximo para enviar o evento pela Conversions API?
Sim. A documentação da Meta define que o event_time pode ter no máximo 7 dias no momento do envio. E há um detalhe que pega muita gente: se um único evento do lote estourar esse prazo, a Meta retorna erro para a requisição inteira e não processa nenhum dos outros. Por isso o filtro por data precisa vir antes de montar o lote.
O webhook de pagamento tem o mesmo nome em todas as plataformas?
Não, e errar o nome é uma falha silenciosa porque o webhook simplesmente nunca dispara. Na Nuvemshop o evento é order/paid, com barra e no singular. Na Shopify é orders/paid, com barra e no plural, correspondente a ORDERS_PAID no enum WebhookSubscriptionTopic da Admin API. Na Yampi é order.paid, com ponto no lugar da barra.
Documentacao de referencia
Continuar lendo
O que é tracking avançado
A definição da categoria, os quatro critérios e os níveis de maturidade.
Tracking para Facebook Ads
Deduplicação, event_id determinístico e a condição do mesmo pixel.
Tracking para Google Ads
GCLID, gbraid, wbraid e a chave de dedup transaction_id.
Como escolher uma empresa de tracking
Critérios objetivos e perguntas a fazer antes de contratar.
Vende por Pix ou boleto e desconfia dos números?
No diagnóstico gratuito comparamos pedidos aprovados com conversões registradas e identificamos em qual das duas falhas a sua conta está.
Agendar diagnostico gratuito