A/B Testing – Testes A/B

Considere que para atingir um determinado objetivo, você pode utilizar duas abordagens distintas (A e B). Ao medir os resultados e entendendo as diferenças entre as abordagens, você pode aprimorar como você alcança este objetivo.

Esta prática é comum em Marketing e Inteligência de Negócios (Business Intelligence). Vamos utilizar um exemplo do mundo de desenvolvimento de software:

Fluxo A:

1. Dado que eu sou um comprador
2. Quando eu seleciono uma Televisão 42 polegadas
3. E adiciono o produto no carrinho de compras
4. E prossigo para o pagamento
5. Então minha compra e efetuada com sucesso.

E se eu quisesse que parte dos compradores do meu e-commerce utilizassem um fluxo alternativo para atingir o mesmo objetivo (no exemplo, comprar um produto)?

Uma abordagem possível, seria dividir o trafego do meu e-commerce em duas partes, a nível de exemplo, vamos dizer que 50% dos usuários irão se manter no “Fluxo A” (fluxo padrão, atual e descrito acima) e os outros 50% quando forem comprar um produto não irão adicionar o mesmo em um carrinho de compras. Para o comprador adquirir um item na minha loja, ele e’ limitado a comprar um produto por vez.

Fluxo B:

1. Dado que eu sou um comprador
2. Quando eu seleciono uma Televisão 42 polegadas
3. E prossigo para o pagamento
4. Então minha compra e efetuada com sucesso

Os fluxos A e B são diferentes embora atendam as necessidades do usuário que quer comprar uma televisão. Este e’ o conceito de A/B Testing, também chamado de “Canary Releasing” [termo utilizado no livro Entrega Continua / Continuous Delivery de Jez Humble]

Neste nosso exemplo, teríamos um software (no caso, a loja e-commerce) rodando em produção com duas versões (ou dois fluxos) distintos. Este processo é um processo de experimentação e validação baseado em dados concretos e decisões tomadas por grupos de usuários. Um possível cenário seria descobrir que para os produtos que a minha loja vende, remover o carrinho de compras faz com que eu venda mais.

Agora você pode pensar: “Que ideia idiota, porque um e-commerce não teria um carrinho de compras? A Amazon tem essa funcionalidade então o meu e-commerce também tem que ter!”

Baseado no “Lean Spirit. Summary of Lean Start Up & Lessons Learned from Another Failed Venture”

Get Out of the Building (Saia do prédio!) – não encontramos fatos olhando apenas dentro das nossas organizações, encontramos apenas opiniões e suposições. É imprescindível testar hipóteses através de entrevistas individuais para entender os clientes e a sua respectiva dor ao utilizar o produto. Se trata de uma tentativa de minimizar o risco de um grande fracasso, verificando teorias na pratica, antes de implementa-las de forma abrangente e permanente.

Saindo do prédio e saindo da “Terra das Opiniões e dos Achismos”, nos colocamos em uma posição diferenciada. Ter estatísticas e dados concretos e reais são muito mais valiosos do que a opinião de um indivíduo. Entretanto, para determinados cenários, ter em paralelo duas versões (A e B) em produção pode ser demasiado caro e não compensar o investimento.

Case de A/B Testing e um exemplo de que o óbvio nem sempre é óbvio

Um caso real onde tive a oportunidade de participar do projeto, implementamos uma funcionalidade para 5 lojas de uma mesma rede de e-commerce. Nos parecia óbvio que todas teriam um ganho nas vendas. A empresa utilizava A/B Testing e como estratégia de entrega do software em produção a mesma passou por um período de piloto onde parte do seu trafego passaria pela nova versão e os demais se manteriam inalterados. Os resultados foram expressivos para 4 das 5 marcas, mas uma delas não funcionou como todos “achavam” que iria. Neste caso, em uma das lojas as vendas reduziram para esta nova funcionalidade. Resultado final: foi liberado para produção nas 4 lojas e a quinta loja permaneceu sem esta funcionalidade.

O que é importante nos resultados de um Teste A/B?

Depende. Um dos aspectos críticos sobre Testes A/B é medir os resultados.  Se o negócio e o domínio de negócio fosse um restaurante, alguns números relevantes seriam: número (#) de pessoas fazendo refeições no seu restaurante, # de pessoas comprando comida para levar para suas respectivas casas, valor médio da conta por mesa, custos para manter o restaurante aberto e muitas outras que sejam relevantes para o negócio. Esta lista de métricas pode crescer de acordo com as hipóteses que venham a ser testadas para de fato conseguir validar se um experimento agregou resultados positivos ou negativos.

Quanto tempo você deve investir em um experimento?

Recursos são finitos (e escassos) e dependendo do seu negócio definir o intervalo de tempo do experimento pode ser um fator crítico de sucesso. Se o seu objetivo é inovar, provar hipóteses através de experimentos pode representar um desacoplamento dos competidores. Fazer algo diferente ou de forma diferente, reduzindo os riscos de implantação hoje é um diferencial competitivo relevante.

“Dado que eu sou o dono do Restaurante Dîner Eu quero contratar um Chef Francês para que eu aumente o número de clientes em 25%”

Qual o resultado esperado?

Quais são os custos associados a implementar este requisito?

Qual é o ROI (retorno sobre o investimento) deste requisito?

Como dono, minha expectativa é de que sempre que houver um Chef Francês fazendo os pratos, o número médio de clientes por dia aumentará de 40 para 50. Uma das alternativas é eu investir em propaganda para que os meus clientes saibam quando o Chef estará presente. Ao mesmo tempo, preciso ter conhecimento sobre o potencial retorno que vou ter com estes 10 clientes a mais por dia. O experimento e seus custos tem de fazer sentido a curto, médio ou longo prazo.

Mas e se todos experimentos falharem sempre?

Bom, na minha humilde opinião, inovação e a tentativa de praticar a melhoria contínua supera a abordagem do “time que está ganhando não se mexe”. Ao fracassar, na pior das hipóteses, você irá entender mais sobre o seu negócio, sobre os seus clientes e isto pode significar um serviço ou produto melhor para os seus clientes finais.

Devo repetir experimentos que fracassaram no passado?

Sim. As pessoas mudam, o mundo muda e as necessidades e os interesses dos indivíduos mudam. Talvez um produto, serviço, funcionalidade de hoje seja a resposta para um problema de amanhã.

Algumas Startups tem utilizado Testes A/B com o intuito de definir seus respectivos negócios. Inclusive, existem empresas sendo lançadas com nomes diferentes, mesmas funcionalidades, com preços diferenciados para entender o mercado e seus potenciais usuários e clientes.

• É mais rentável vender para jovens com um preço reduzido?
• É mais rentável vender para um público mais velho que tem um poder de compra maior?
• Ou é mais rentável uma combinação de ambos?
• Qual vende mais?
• Meu produto é escalável até quanto? Qual o limite?
• Eu quero vender mais? Eu posso vender mais?
• Testes A/B nunca terão um impacto positivo na qualidade do meu produto (software)?

Errado. Se você estiver praticando A/B Testing, existe uma grande probabilidade de que você tenha de forma automatizada estatísticas sobre os seus usuários (algo similar a Analytics). Quais funcionalidades estão sendo mais utilizadas, da onde vem a receita financeira do seu produto e outros. Imagine que neste cenário, por algum motivo alguma funcionalidade deixou de ser utilizada ou um botão da interface se tornou obsoleto. Manter no repositório código obsoleto gera custo e gera impacto na manutenibilidade do software.

Qual o custo de dar suporte a qualquer funcionalidade que seja necessidade de qualquer usuário para o seu negócio?

Correções de problemas e incidentes e melhorias também podem ser apresentadas a um grupo de usuários finais através de Testes A/B. Caso ter múltiplas versões do seu software não seja uma opção, uma outra abordagem seria utilizar Feature Toggles, “interruptores” (como os de ligar e desligar as luzes das nossas casas), para habilitar e desabilitar certas funcionalidades do sistema.

Publicidade