Escrito por Bruno Kubiack.
Entendendo a Conversão
Quando se fala em CRO, muito se comenta sobre otimizar o processo de compra. A ideia de modificar a jornada do usuário, fazendo ajustes (sutis ou não) que melhorem a sua navegação, direcione-o para a compra, é de fato muito importante. Essa relevância de aumentar o número de compras vem, obviamente, do interesse dos e-commerces em aumentar as vendas, afinal, é isso que os principais stakeholders querem: mais transações significa mais receita entrando, certo? Pode ter certeza que sim! Entretanto, esta não é necessariamente a única maneira de aumentar os lucros.
O conceito de conversão é bastante amplo. Cada empresa tem suas particularidades, além de ter um ou mais objetivos de negócio. Estes objetivos são traduzidos em conversões nos pontos de contato da empresa com o mercado. Para um e-commerce, o mais comum são de fato as vendas, que muitas vezes são, por si só, sinônimo de conversão. No entanto, um site pode ter como objetivo, por exemplo, captar leads. Nesse caso, a conversão acaba sendo captar as informações de contato dos usuários, na maioria das vezes, através de um formulário. O que é comum, porém, captar leads e transações não são os únicos exemplos de conversão.
Com isso em mente, um dos nossos clientes nos contatou com um problema de negócio que veio de uma reunião estratégica com os gestores da empresa. A questão era referente ao tipo de conta que os clientes selecionavam ao contratar um serviço com plano de pagamentos mensais. Nesse cenário, existem dois métodos de pagamento: via conta digital enviada por e-mail e via conta impressa enviada pelo correio.
Dentre essas opções de pagamento, a via e-mail é muito mais interessante, pois elimina os custos operacionais de enviar o boleto em papel. No método via correio existe o custo da impressão, o de envio e o da mão de obra. Para o método de pagamento via conta digital, os custos eram bem menores, uma vez que o processo era totalmente automatizado, além de ser muito mais escalável.
Neste cenário, podemos considerar que o nosso objetivo era o de fazer mais usuários selecionarem o método de pagamento mais interessante para a empresa, diminuindo custos e, assim, aumentando os seus lucros. Ou seja, no caso deste cliente, a conversão que queremos otimizar com o CRO é a de aumentar a proporção de contas com o método de pagamento via conta digital enviada por e-mail.
Agora que já entendemos o objetivo e o contexto por trás do problema, podemos planejar ações para atingir o melhor resultado. Estamos prontos para otimizar esta taxa de conversão!
Criando a Hipótese: o que pode aumentar esta conversão?
A partir disso, devemos entender como era o seletor de método de pagamento que estava gerando mais contas impressas do que o desejado:
Na versão original do site, o seletor do método de pagamento é através de dois blocos retangulares no formato conhecido como Radio Button. Apesar de termos selecionado, por padrão, o método de pagamento via e-mail, ainda assim, muitas pessoas selecionam a conta impressa.
Vamos escolher então a metodologia para otimizar esta conversão. Como queremos que mais usuários escolham o método de pagamento via e-mail, podemos alterar o layout da página para direcionar os usuários ao método desejado. Talvez alterar este seletor, para algo que dê mais peso para o método de e-mail, sem forçar o usuário a uma escolha, o faça manter a seleção padrão. Esta é uma boa abordagem, e mudanças deste tipo podem impactar significativamente na experiência do usuário com o seletor.
Para responder a pergunta do subtítulo com precisão, vamos criar um Teste AB. Com este experimento, esperamos entender exatamente o impacto de uma versão de layout alternativa na seleção de métodos de pagamento. Assim, as perguntas que queremos responder com o experimento são:
- Há diferença entre a performance do layout original para o novo?
- Se há uma diferença, qual deleEs é mais eficiente?
- Qual o tamanho desta diferença de performance?
Com a metodologia escolhida, podemos formular o novo layout para usar neste teste. A partir de brainstormings entre os times, foi escolhido o estilo de botão Swipe para ser a versão alternativa neste Teste AB. Portanto, a hipótese que será verificada no experimento é: utilizando o seletor Swipe, faremos com que o cliente se sinta mais inclinado a optar pelo método de pagamento via e-mail.
O plano é manter o Teste AB ativo por um tempo pré-determinado ou até que tenhamos a confiança estatística suficiente para declarar que as duas versões têm uma diferença significativa de performance. Para isso, faremos um teste de inferência estatística para comparação de médias (taxas de conversão). Foi utilizada a ferramenta Oracle Maxymiser para operacionalizar, subimos o teste e partimos para a análise de resultados.
Analisando os Resultados
Para nossa surpresa, com menos de duas semanas de teste, a ferramenta Oracle Maxymiser já tinha dado o veredito final para este experimento: as duas versões eram significativamente diferentes para o número total de contas com método de pagamento via e-mail selecionadas!
Ok, conseguimos mexer no ponteiro e percebemos que estamos no caminho certo. Mas, afinal, o que é mais vantajoso, o Swipe ou os seletores em formato de Radio Button? O que os dados na ferramenta nos dizem é que tivemos um aumento de 15,30% no número total de contas com método de pagamento via e-mail selecionadas.
O aumento foi expressivo, gerando uma confiança estatística suficiente para declarar o fim do teste. E o melhor de tudo é que o cálculo do Maxymiser já considera, que esta alteração não ocorreu ao acaso, ou seja, não foi sorte, foi um layout consideravelmente mais eficiente em atingir os objetivos de negócio do cliente.
Conclusão
Considerando os resultados apresentados, podemos tirar um aprendizado principal deste experimento. Basicamente, o Swipe é mais eficiente do que os Radio Buttons em gerar mais contas com método de pagamento via e-mail nesta etapa do fluxo de compra e para este tipo de serviço. Isso quer dizer que o Swipe é efetivo para todos os cenários? Não! O aprendizado é bem específico e por um motivo muito claro.
Cada produto, cada negócio, cada etapa do funil e cada público têm suas próprias particularidades. O que funciona para um perfil de usuário, pode não funcionar para outro; o que funciona para um produto, pode não funcionar para outro, e assim por diante. Cada experimento lida com as particularidades da página em que ele foi executado, logo o que vale de insight para um pode não valer para outro. O teste executado garante uma maior performance neste cenário, ou seja, Swipe pode ser mais efetivo em outros cenários, mas precisamos testar para ter certeza!
CRO é sobre criar conhecimento. A cada Teste AB o cliente pode entender mais sobre o seu contexto específico. A solução para ter certeza de algo sempre será o Teste AB, pois é um ambiente de análise controlado, sem variações que podem tendenciar a análise (tal como a variação sazonal, por exemplo). No entanto, ao entender o público com vários testes, podemos fazer a tomada de decisão baseada em dados e com mais certeza dos resultados. Portanto, trabalhar com CRO é tomar decisões com respostas certeiras sobre como o seu público se comporta.