Como instalar o pixel do Facebook com a Stripe

A Stripe é a exceção do cluster de pixel, e por um motivo estrutural: ela não é plataforma de loja, é processadora de pagamento. Não existe campo para informar o identificador do pixel, e o Checkout hospedado dela não executa script de terceiros.

Isso não é limitação a ser contornada com truque. É decisão de arquitetura — a página onde o cartão é digitado não roda código de fora, e isso é bom para todos. O que muda é de onde o seu evento de compra vai sair.

Os dois caminhos possíveis

Página de retorno. Depois do pagamento, a Stripe redireciona para uma URL sua de sucesso. Você dispara o evento de compra ali, com o seu pixel, que já está instalado no site.

Webhook no servidor. A Stripe avisa o seu servidor que o pagamento foi concluído. O seu servidor envia a compra ao Meta pela API de conversões, sem depender do navegador.

Os dois funcionam. Eles não medem a mesma coisa, e a diferença é grande o bastante para decidir por ela.

Por que a página de retorno perde venda

O redirecionamento depende de a pessoa voltar. Três situações comuns em que ela não volta:

• Fecha a aba assim que vê a confirmação da Stripe.
• Paga por Pix ou boleto, em que a aprovação chega minutos ou dias depois, fora daquela sessão.
• Perde a conexão no meio do redirecionamento.

Em todas, o dinheiro entrou e o Meta não soube. O efeito no relatório é sempre o mesmo: a plataforma mostra menos vendas do que a Stripe registrou, e a campanha parece pior do que é. Quem decide verba por esse número corta campanha lucrativa.

Por que o webhook é o caminho certo

O webhook não depende do navegador de ninguém. A Stripe avisa o seu servidor quando o pagamento é concluído, o servidor envia o evento ao Meta, e o registro acontece independentemente do que a pessoa fez depois de pagar.

Isso resolve as três perdas da seção anterior de uma vez. Resolve também o caso de pagamento assíncrono: a compra é registrada quando o dinheiro cai, que é quando ela existe de verdade.

O custo é que exige desenvolvimento — alguém precisa escrever o código que ouve o webhook e chama a API de conversões. Não é trabalho grande, mas não é configuração de painel. O funcionamento da API está em API de conversões do Meta.

O desenho que a maioria deveria usar

Na prática, o arranjo mais robusto usa os dois:

1. Pixel no site, medindo visita, visualização de produto e início de checkout. Isso você já tem.
2. Webhook no servidor, disparando a compra pela API de conversões.
3. Um identificador de evento comum entre as duas fontes, para o Meta descartar duplicata se o mesmo evento chegar duas vezes.

O item 3 é o que evita o problema da próxima seção. Sem ele, os dois caminhos ligados ao mesmo tempo contam a venda em dobro.

O erro que duplica a venda

Ligar a página de retorno e o webhook sem identificador comum. O sintoma é o dobro exato das vendas reais no relatório, com ROAS excelente e caixa que discorda.

A correção não é desligar um dos dois: é enviar o mesmo identificador de evento nos dois caminhos, para que o Meta reconheça que é a mesma compra chegando por duas portas. Esse é exatamente o problema que a deduplicação por identificador existe para resolver.

Se você não tem como gerar esse identificador, escolha um caminho só — e escolha o webhook.

O valor e a moeda

Dois parâmetros que costumam faltar em instalação feita por servidor, e que mudam o relatório inteiro:

Valor. Sem ele, um pagamento de R$ 50 e um de R$ 2.000 contam igual. O algoritmo otimiza para volume de eventos em vez de receita.

Moeda. A Stripe processa em várias moedas. Se o evento chega sem a moeda declarada, ou com a moeda errada, o Meta soma valores de grandezas diferentes e o ROAS fica sem sentido.

Confira os dois no Gerenciador de Eventos, dentro do evento de compra, antes de confiar em qualquer número de retorno.

Como confirmar que ficou certo

1. Gerenciador de Eventos, atividade recente do pixel.
2. Faça um pagamento de teste no modo de teste da Stripe.
3. Confirme o evento de compra chegando, com valor e moeda.
4. Feche a aba antes do redirecionamento e faça outro pagamento de teste. Se a compra ainda aparecer, o webhook está funcionando.
5. Compare o total do mês entre o painel da Stripe e o Gerenciador de Eventos.

O passo 4 é o único teste que distingue os dois caminhos, e é o que quase ninguém faz. O roteiro geral está em como testar o pixel do Facebook.

Por que os números nunca batem exatamente

O painel da Stripe conta cobranças; o Meta conta conversões atribuídas a anúncio dentro de uma janela. Assinatura recorrente, venda orgânica e cobrança fora da janela existem no primeiro e não no segundo.

Recorrência merece atenção especial: se você cobra mensalmente, cada renovação é uma cobrança na Stripe. Enviar todas ao Meta como compra infla o número de conversões e engana a otimização. O padrão razoável é enviar só a primeira cobrança como compra, e tratar renovação separadamente.

Diferença de 10% a 20% é normal. Diferença de 90% é instalação quebrada. O prazo que cria parte da diferença está em janela de atribuição.

Assinatura: o caso que quase todo mundo erra

Se você vende recorrência pela Stripe, há uma decisão a tomar antes de enviar o primeiro evento, e ela muda o significado de todo o relatório.

Enviar só a primeira cobrança como compra. O Meta passa a otimizar para aquisição de cliente novo, que é quase sempre o que você quer do anúncio. As renovações não entram como conversão.

Enviar todas as cobranças. O número de conversões infla mês a mês sem nenhuma venda nova, o custo por resultado cai artificialmente, e a otimização começa a perseguir um evento que o anúncio não causou.

A segunda opção é a que acontece por acidente, porque o webhook de pagamento concluído dispara em toda renovação. Quem não filtra acaba com um relatório que melhora sozinho todo mês — e uma verba crescendo em cima de um número falso.

O filtro é simples no código: tratar como compra só quando for a primeira cobrança daquele cliente. Se você quiser medir renovação, use um evento personalizado com outro nome, fora da otimização.

O que fazer quando nada chega

Na ordem, do mais comum ao menos:

1. Webhook apontando para URL errada ou ainda em ambiente de teste enquanto a loja está em produção.
2. Token de acesso da API de conversões expirado. Ele tem validade, e o evento passa a ser rejeitado em silêncio.
3. Identificador do pixel ou da conta trocado no código, apontando para um pixel que não é o que você olha.
4. Evento rejeitado por falta de parâmetro obrigatório. O Gerenciador de Eventos mostra isso na aba de diagnóstico, e quase ninguém abre essa aba.

O item 4 é o mais silencioso: a requisição responde com sucesso e o evento é descartado depois. Vale abrir o diagnóstico do pixel antes de suspeitar do código.

Antes de escalar

Com a compra chegando pelo servidor, com valor e moeda, acumule volume suficiente para ler resultado antes de aumentar verba. O critério está em quando escalar campanha, e o acompanhamento semanal, em relatório de tráfego pago.