O tráfego cresceu, os pedidos aumentaram e a taxa de conversão continua dentro do esperado. Ainda assim, a receita não acompanhou o mesmo movimento. Quando isso acontece, é comum voltar a análise para a mídia, para a página do produto ou para o próprio índice de conversão. Mas existe uma etapa importante entre o pedido criado e a venda efetivamente concluída: a aprovação do pagamento.
Um pedido pode ser registrado pela loja sem que a transação seja aprovada. Por isso, acompanhar apenas a relação entre acessos e pedidos mostra uma parte do funil, não necessariamente quanto daquele tráfego terminou em uma venda aprovada.
A taxa de conversão continua sendo um indicador importante. A questão é entender exatamente o que ela está medindo e até onde ela consegue explicar o resultado da operação. Neste artigo, você vai entender como calcular a taxa de conversão no e-commerce, separar pedido de pagamento aprovado e identificar em qual etapa a venda está sendo perdida.
O que é taxa de conversão no e-commerce e como calcular?
De acordo com o Google Analytics, a taxa de eventos principais da sessão representa a porcentagem de sessões em que uma ação definida como importante para o negócio aconteceu. A ferramenta calcula esse indicador dividindo o número de sessões em que ocorreu um evento principal pelo total de sessões.
Isso ajuda a entender por que a expressão “taxa de conversão” precisa vir acompanhada de contexto. Antes de comparar percentuais, é necessário saber qual ação a operação está considerando como conversão. Em um e-commerce, pode ser a geração de um pedido, o registro de uma compra ou outro evento definido como relevante para aquela análise.
Se a operação quer acompanhar quantas sessões resultaram em pedidos, por exemplo, o cálculo pode relacionar o número de pedidos ao total de sessões. Em um cenário hipotético com 100 mil sessões e 2 mil pedidos registrados, a taxa de conversão em pedido é de 2%.
O número é útil porque responde a uma pergunta específica: quanto do tráfego chegou até a geração de um pedido? Porém, ele ainda não responde quantos desses pedidos tiveram o pagamento aprovado.
Essa diferença importa porque cada etapa do funil tem uma função. O tráfego mostra quantas oportunidades chegaram à loja. O pedido mostra quantas avançaram até a intenção de compra registrada pela operação. A aprovação mostra quantas tentativas de pagamento passaram pelo processo necessário para que a transação fosse aceita.
Antes de concluir que uma conversão de 2% é boa ou ruim, portanto, é preciso saber o que esse percentual representa, em qual etapa foi calculado e como se relaciona com os indicadores que vêm depois.
Pedido criado significa venda concluída?
Não necessariamente. O pedido pode existir na plataforma antes que a operação tenha a confirmação financeira da transação. Essa diferença aparece com frequência quando dados de loja, analytics e pagamento são analisados como se representassem o mesmo momento da jornada.
No Google Analytics, um dos eventos usados para medir vendas on-line é o puschase. Segundo a documentação oficial do Google, esse evento indica que um ou mais itens foram comprados e pode carregar informações como valor, moeda, itens e o identificador da transação. Em termos simples, é o sinal que a implementação envia ao Analytics para registrar uma compra.
O ponto de atenção está justamente na implementação. Ainda de acordo com a documentação do Google, eventos são configurados para medir interações específicas no site ou aplicativo. Isso significa que o momento em que o purchase é disparado depende da forma como a operação estruturou a medição. Se o evento for enviado antes da confirmação financeira, o painel pode registrar uma compra mesmo que aquela tentativa de pagamento não termine aprovada.
Outro conceito importante é o transaction_id. Ele é o identificador exclusivo de uma transação e ajuda a evitar que o mesmo evento de compra seja contabilizado mais de uma vez. Na prática, funciona como um identificador único que permite reconhecer aquela transação nos dados e relacionar o evento aos demais registros da operação.
Esses dois conceitos não precisam transformar a análise em um projeto técnico. O que o dono do e-commerce precisa saber é em que momento o pedido é criado, quando o evento de compra é enviado e quando a confirmação do pagamento retorna. Se essas etapas não estiverem conectadas, o número exibido no analytics pode representar uma realidade diferente da encontrada no financeiro.
É por isso que pedido criado, purchase registrado e pagamento aprovado não devem ser tratados automaticamente como sinônimos. Eles podem representar momentos distintos da mesma jornada.
Qual é a diferença entre conversão e aprovação de pagamento?
Não parece, mas essa é uma dúvida muito comum. Conversão e aprovação medem etapas diferentes. A conversão mostra quanto do volume avançou até a ação que a operação decidiu acompanhar. A aprovação mostra o resultado das transações enviadas para processamento.
De acordo com a Resolução nº 150 do Banco Central, a autorização de uma transação de pagamento é o processo que confirma se a transação atende aos requisitos estabelecidos pelo arranjo, especialmente os relacionados ao gerenciamento de risco, para que possa ser aprovada. A regulamentação também diferencia transações autorizadas, rejeitadas e situações posteriores, como estornos e reversões.
Na prática, uma operação pode acompanhar pelo menos três leituras diferentes ao longo do funil. A conversão do site mostra quanto do tráfego avançou até a ação escolhida, como a geração do pedido. A conversão do checkout mostra quantas pessoas que entraram nessa etapa conseguiram avançar até sua conclusão. Já a taxa de aprovação mostra quantas tentativas ou pedidos enviados para pagamento chegaram a uma confirmação, de acordo com a base definida pela empresa.
Para ficar mais claro, vamos retomar ao exemplo hipotético: imagine 100 mil sessões, 2 mil pedidos e 1.700 pagamentos aprovados. A taxa de conversão em pedido é de 2%. Considerando todo o tráfego recebido, 1,7% das sessões terminaram em uma transação aprovada.
A diferença entre os dois números representa 300 pedidos que apareceram em uma etapa do funil, mas não chegaram à aprovação do pagamento. Isso não torna a taxa de conversão de 2% incorreta. Ela continua respondendo quantas sessões geraram pedidos. O problema começa quando esse indicador é usado, sozinho, para representar vendas efetivamente aprovadas.
Esse recorte também ajuda a evitar comparações erradas. Uma operação pode melhorar a geração de pedidos e, ao mesmo tempo, perder parte desse ganho na etapa financeira. Da mesma forma, uma mudança na aprovação pode aumentar a quantidade de vendas concluídas sem alterar o volume de tráfego recebido.
Como acompanhar o caminho entre acesso, pedido e receita?
Segundo a documentação de e-commerce do Google Analytics, eventos podem ser usados para acompanhar interações como visualização de produto, adição ao carrinho, início do checkout e compra. Esses registros ajudam a entender como o usuário avança pela jornada e em que ponto o volume começa a cair.
Para o e-commerce, a leitura fica mais útil quando a jornada não termina no pedido. Um fluxo de análise pode acompanhar sessões, visualização de produto, carrinho, início do checkout, pedido criado e pagamento aprovado. Cada etapa responde a uma pergunta diferente e aponta para uma área diferente da operação.
| Etapa | O que mostra | Pergunta para a operação |
|---|---|---|
| Sessão | Volume que entrou no site | O tráfego está chegando? |
| Produto e carrinho | Avanço nas etapas de interesse | Onde o usuário deixa de avançar? |
| Checkout | Entrada e conclusão da jornada de compra | A perda acontece antes do pedido? |
| Pedido | Intenção de compra registrada | Quantos pedidos foram gerados? |
| Pagamento aprovado | Resultado da tentativa de pagamento | Quantos pedidos chegaram à aprovação? |
Se o tráfego chega, mas poucas pessoas avançam para produtos ou carrinho, a investigação começa nas etapas iniciais da jornada. Se o volume chega ao checkout e cai antes da geração do pedido, a análise muda. Quando os pedidos são criados, mas uma parcela relevante não chega à aprovação, o diagnóstico precisa avançar para a camada de pagamento.
No nosso artigo “Gateway e checkout: qual a diferença” aprofundamos essa separação entre experiência e processamento. O checkout organiza a etapa em que o consumidor revisa informações e envia a tentativa de pagamento. A infraestrutura de pagamento assume outras funções no processamento e na autorização. Misturar os dois pontos pode levar a uma correção na camada errada.
A mesma lógica vale para a mensuração. De acordo com o Google Analytics, eventos de e-commerce precisam ser implementados para que a ferramenta receba dados como itens, valores e transações. Se pedido, evento de compra e status de pagamento não compartilham referências consistentes, a conciliação entre marketing, operação e financeiro fica mais difícil.
Por isso, identificar onde as vendas estão sendo perdidas ajuda a entender se a investigação deve começar no tráfego, no checkout ou no pagamento. O objetivo não é criar um painel com dezenas de indicadores, mas acompanhar os números que permitem localizar o ponto de perda antes de decidir o que mudar.
Onde identificar a perda de receita da operação?
A queda pode acontecer antes, durante ou depois do checkout. O comportamento dos indicadores ajuda a direcionar a investigação.
Se a loja recebe sessões, mas poucas pessoas avançam para produtos, carrinho ou checkout, a análise deve olhar para as etapas anteriores à tentativa de compra. Oferta, origem do tráfego, navegação, página do produto e experiência precisam ser avaliadas dentro do contexto da operação.
Se existe volume de pessoas iniciando o checkout, mas poucos pedidos são gerados, a atenção muda para a própria jornada de compra. Campos, mensagens, erros, carregamento, meios de pagamento disponíveis e funcionamento da página entram na análise. No artigo “Checkout transparente: o que é, vantagens e quando vale” mostramos como o nível de controle sobre o checkout influencia a capacidade de testar e corrigir esses pontos.
Quando o volume de pedidos permanece saudável, mas existe uma diferença relevante até a aprovação, a análise precisa avançar para pagamentos. No conteúdo “Como aumentar a taxa de aprovação no checkout” detalhamos como medir a aprovação e investigar fatores como dados, regras de risco, rotas, retentativas e respostas do processamento.
Isso não significa que todo pedido recusado represente uma falha que poderia ser recuperada. Também não significa que uma única taxa consiga explicar todo o resultado. O ponto é separar as etapas para que cada indicador seja lido pelo que realmente mede.
Uma taxa de conversão pode mostrar que o e-commerce conseguiu transformar tráfego em pedidos. A taxa de aprovação mostra o que aconteceu quando essas intenções chegaram ao pagamento. Quando os dois números são analisados juntos, fica mais fácil enxergar a distância entre a ação registrada no site e a venda confirmada.
A conversão precisa chegar até a aprovação
A taxa de conversão continua sendo um indicador central para o e-commerce, mas o pedido não precisa ser o último número observado. Para entender quanto do tráfego efetivamente chegou ao fim da jornada de compra, a operação precisa acompanhar também o que aconteceu depois que o consumidor clicou em pagar.
A leitura fica mais completa quando sessões, checkout, pedido e aprovação fazem parte do mesmo diagnóstico. Assim, uma queda de receita deixa de ser tratada como um problema genérico de conversão e passa a ser investigada na etapa em que realmente apareceu.
