Dois checkouts na mesma página: como eu unifiquei o funil do meu produto de pet

Dois botões de compra na mesma página custam mais do que parecem. Não é branding, é conversão: quem hesita entre dois checkouts geralmente não escolhe nenhum.

Eu tinha isso no meu site de pet. A mesma página vendia o guia por dois caminhos diferentes, com dois preços diferentes, e nenhum dos dois era o checkout que eu queria de verdade. Levou uma auditoria com curl para eu ver a bagunça que eu mesmo criei.

Como um funil quebra sem fazer barulho

A página /guia vendia um PDF de 51 páginas por R$ 47 através do Stripe. A página /guias/, listando os artigos, tinha um link de afiliado da Kiwify para um produto de R$ 27 que nem existia mais na conta. E o /petshop mostrava o PataPass com oito botões de WhatsApp e um preço de R$ 99, sem nenhuma demonstração pública.

Três caminhos de compra, três preços, um único produto por baixo. Nenhum deles estava quebrado — todos respondiam 200. É esse o problema: funil fragmentado não dá erro, ele só vaza.

O número que revela isso não é o de visitas, é o de checkout iniciado. E 200 na página não significa nada quando existem dois botões.

O que eu troquei, e por quê

Consolidei tudo em um checkout só: Mercado Pago, na loja que roda no meu domínio próprio. A escolha não foi por preferência de marca. Foi por três motivos verificáveis:

Pix. Aprovação no mesmo instante. Um produto de R$ 47 com boleto ou cartão de terceiro dia perde o comprador no caminho.

Um lugar para a garantia. O artigo 49 do Código de Defesa do Consumidor dá 7 dias de arrependimento, com devolução de 100%. Isso já era prometido no Stripe. Mas prometer em dois checkouts significa que só um dos dois realmente cumpre — e eu não tinha como garantir qual.

Um lugar para a contagem. Com dois checkouts, cada venda paga ficava dividida em duas contagens diferentes, e eu não conseguia responder "quantas vendas esse post gerou". Com um, a resposta é uma consulta.

O preço único ficou R$ 47 — o mesmo que a página já anunciava. O de R$ 27 nunca esteve no ar como produto comprável; era um cadastro pronto que não foi publicado na conta da Kiwify. Deixar os dois números no mesmo funil só ensinava o visitante a esperar uma promoção que não existia.

O erro que aprendi a não repetir

Antes de redirecionar o botão antigo, eu precisei de uma coisa chata e necessária: confirmar que o produto novo existia na loja de verdade. Não a página, o produto.

O código da loja tem uma rota /products que serve o catálogo. Foi ela que respondeu:

GET /products -> 12 itens, nenhum com id "pet-em-casa"

Se eu tivesse só criado a página e apontado o botão, o resultado seria pior que o problema original. A rota /item?id=<slug> fazia items.find(...) || items[0] — quando o id não existia, caía no primeiro produto da lista. O visitante clicava no guia de pet e via um ebook de engenharia de software, com preço e estoque do produto errado.

Consertei a causa: id que não existe agora é "produto indisponível", com os botões desabilitados, em vez de fingir que é o primeiro item da lista. É um bug de uma linha que vende o produto errado — o tipo de coisa que teste de unidade não pega, porque a página responde 200 e parece certa.

O que isso ensina sobre "publicar" produto digital

Três verificações, na ordem, que eu deveria ter feito desde o começo:

1. O produto existe no catálogo servido? Não no arquivo, não na configuração: na resposta HTTP que o checkout usa.
2. A preferência de pagamento é criada com o valor certo? Uma POST no endpoint de criação devolve o total. total: 47 e installments: 6 são a prova. "O botão está lá" não é prova.
3. Todas as portas antigas fecham? Se um link velho continua vendendo, o funil continua partido. Redirecionar é parte da entrega, não faxina posterior.

É a mesma lógica do post anterior sobre agentes que dizem "feito". O botão de compra é a versão mais cara dessa mentira: um checkout que existe na página mas não no catálogo é um "feito" que custa venda.

O detalhe que quase passa

A primeira versão do meu redirecionamento não funcionou. Eu coloquei a regra de /item?id=pet para /pet depois do mapa de rotas estáticas, então a rota antiga respondia antes dela e o 301 nunca disparava. O curl mostrou 200 onde eu esperava 301, e o texto loc= vazio.

Sem medir, eu teria anunciado a correção e ela não existiria. O teste local e o de produção deram o mesmo resultado, o que é o único jeito de saber que a regra pegou.

Series start (if you landed here first): https://dev.to/samuelfmedeiros/a-marketplace-price-is-retail-not-cost-how-not-to-build-margin-on-the-wrong-number-2oek

O guia está em focinho.seu.pet/guia, e o checkout em safmarket.seu.pet/pet. Se você tem loja própria e mais de um botão de compra na mesma página, o teste é simples: conte quantos checkouts o seu funil abre. Se a resposta for maior que um, o vazamento já começou.