Envio de seu produto em iterações: um guia para testes de hipóteses

Uma olhada na Play Store/App Store em qualquer telefone revelará que a maioria dos aplicativos instalados teve atualizações lançadas na última semana. Uma visita ao site após algumas semanas pode mostrar algumas alterações no layout, na experiência do usuário ou na cópia.

Os produtos de software hoje são enviados em iterações para validar suposições e hipóteses sobre o que torna a experiência do produto melhor para os usuários. A qualquer momento, empresas como booking.com (onde eu trabalhei antes) executam centenas de testes A/B em seus sites para essa finalidade.

Para aplicativos entregues pela Internet, não há necessidade de decidir sobre a aparência de um produto com 12 a 18 meses de antecedência e, em seguida, construí-lo e, eventualmente, enviá-lo. Em vez disso, é perfeitamente prático liberar pequenas mudanças que agregam valor aos usuários à medida que são implementadas, eliminando a necessidade de fazer suposições sobre as preferências do usuário e soluções ideais - pois cada suposição e hipótese pode ser validada projetando um teste para isolar o efeito de cada mudança.

Além de fornecer valor contínuo por meio de melhorias, essa abordagem permite que uma equipe de produto colete feedback contínuo dos usuários e corrija o curso conforme necessário. Criar e testar hipóteses a cada duas semanas é uma maneira mais barata e fácil de construir uma abordagem iterativa e de correção de curso para criar valor do produto.

O que é teste de hipóteses?

Ao enviar um recurso para os usuários, é imperativo validar suposições sobre design e recursos para entender seu impacto no mundo real.

Essa validação é tradicionalmente feita por meio de testes de hipóteses de produtos, durante os quais o experimentador delineia uma hipótese para uma mudança e, em seguida, define o sucesso. Por exemplo, se um gerente de produtos de dados da Amazon tem uma hipótese de que mostrar imagens de produtos maiores aumentará as taxas de conversão, então o sucesso é definido por taxas de conversão mais altas.

Um dos aspectos-chave do teste de hipóteses é o isolamento de diferentes variáveis ​​na experiência do produto para poder atribuir sucesso (ou fracasso) às mudanças realizadas. Portanto, se nosso gerente de produto da Amazon tivesse outra hipótese de que mostrar as avaliações dos clientes ao lado das imagens do produto melhoraria a conversão, não seria possível testar as duas hipóteses ao mesmo tempo. Fazer isso resultaria na falha em atribuir causas e efeitos adequadamente; portanto, as duas alterações devem ser isoladas e testadas individualmente.

Assim, as decisões do produto sobre recursos devem ser apoiadas por testes de hipóteses para validar o desempenho dos recursos.

Diferentes tipos de teste de hipóteses

Teste A/B

Os casos de uso mais comuns podem ser validados por testes A/B aleatórios, nos quais uma alteração ou recurso é liberado aleatoriamente para metade dos usuários (A) e retido da outra metade (B). Voltando à hipótese de imagens maiores de produtos melhorando a conversão na Amazon, metade dos usuários verá a mudança, enquanto a outra metade verá o site como era antes. A conversão será então medida para cada grupo (A e B) e comparada. No caso de um aumento significativo na conversão para o grupo com imagens de produtos maiores, a conclusão seria que a hipótese original estava correta e a mudança pode ser implementada para todos os usuários.

Testes multivariados

Idealmente, cada variável deve ser isolada e testada separadamente para atribuir conclusivamente as mudanças. No entanto, essa abordagem sequencial de teste pode ser muito lenta, especialmente quando há várias versões para testar. Para continuar com o exemplo, na hipótese de que imagens de produtos maiores levam a taxas de conversão mais altas na Amazon, “maior” é subjetivo e várias versões de “maior” (por exemplo, 1,1x, 1,3x e 1,5x) podem precisar ser testado.

Em vez de testar esses casos sequencialmente, pode-se adotar um teste multivariado, no qual os usuários não são divididos ao meio, mas em múltiplas variantes. Por exemplo, quatro grupos (A, B, C, D) são compostos por 25% de usuários cada, onde os usuários do grupo A não verão nenhuma alteração, enquanto os das variantes B, C e D verão imagens maiores em 1,1x, 1,3x e 1,5x, respectivamente. Neste teste, várias variantes são testadas simultaneamente em relação à versão atual do produto para identificar a melhor variante.

Antes/Depois do Teste

Às vezes, não é possível dividir os usuários ao meio (ou em várias variantes), pois pode haver efeitos de rede. Por exemplo, se o teste envolve determinar se uma lógica para formular preços de pico no Uber é melhor que outra, os motoristas não podem ser divididos em diferentes variantes, pois a lógica leva em consideração o descompasso de demanda e oferta de toda a cidade. Nesses casos, um teste terá que comparar os efeitos antes da mudança e depois da mudança para chegar a uma conclusão.

No entanto, a restrição aqui é a incapacidade de isolar os efeitos da sazonalidade e da externalidade que podem afetar de forma diferente os períodos de teste e controle. Suponha que uma mudança na lógica que determina o preço de pico no Uber seja feita no tempo t , de modo que a lógica A seja usada antes e a lógica B seja usada depois. Embora os efeitos antes e depois do tempo t possam ser comparados, não há garantia de que os efeitos sejam apenas devidos à mudança na lógica. Pode ter havido uma diferença na demanda ou outros fatores entre os dois períodos de tempo que resultaram em uma diferença entre os dois.

Teste de ligar/desligar baseado em tempo

As desvantagens dos testes antes/depois podem ser superadas em grande parte com a implantação de testes on/off baseados em tempo, nos quais a alteração é introduzida a todos os usuários por um determinado período de tempo, desativada por um período igual e em seguida, repetido por um período mais longo.

Por exemplo, no caso de uso Uber, a alteração pode ser exibida aos motoristas na segunda-feira, retirada na terça-feira, exibida novamente na quarta-feira e assim por diante.

Embora esse método não remova totalmente os efeitos da sazonalidade e da externalidade, ele os reduz significativamente, tornando esses testes mais robustos.

Projeto de teste

Escolher o teste certo para o caso de uso em questão é um passo essencial para validar uma hipótese da maneira mais rápida e robusta. Uma vez que a escolha é feita, os detalhes do projeto de teste podem ser descritos.

O projeto de teste é simplesmente um esboço coerente de:

• A hipótese a ser testada: mostrar aos usuários imagens maiores de produtos os levará a comprar mais produtos.
• Métricas de sucesso para o teste: conversão de clientes
• Critérios de tomada de decisão para o teste: O teste valida a hipótese de que os usuários da variante apresentam uma taxa de conversão maior do que os do grupo controle.
• Métricas que precisam ser instrumentadas para aprender com o teste: conversão de clientes, cliques em imagens de produtos

No caso da hipótese de que imagens maiores de produtos levarão a uma melhor conversão na Amazon, a métrica de sucesso é a conversão e o critério de decisão é uma melhoria na conversão.

Depois que o teste certo é escolhido e projetado, e os critérios e métricas de sucesso são identificados, os resultados devem ser analisados. Para isso, alguns conceitos estatísticos são necessários.

Amostragem

Ao executar testes, é importante garantir que as duas variantes escolhidas para o teste (A e B) não tenham um viés em relação à métrica de sucesso. Por exemplo, se a variante que vê as imagens maiores já tiver uma conversão mais alta do que a variante que não vê a alteração, o teste é tendencioso e pode levar a conclusões erradas.

Para garantir que não haja viés na amostragem, pode-se observar a média e a variância da métrica de sucesso antes que a mudança seja introduzida.

Significado e Poder

Uma vez observada uma diferença entre as duas variantes, é importante concluir que a mudança observada é um efeito real e não aleatório. Isso pode ser feito calculando o significado da mudança na métrica de sucesso.

Em termos leigos, a significância mede a frequência com que o teste mostra que imagens maiores levam a uma conversão mais alta quando na verdade não o fazem. O poder mede a frequência com que o teste nos diz que imagens maiores levam a uma conversão mais alta quando realmente o fazem.

Assim, os testes precisam ter um alto valor de poder e um baixo valor de significância para resultados mais precisos.

Embora uma exploração aprofundada dos conceitos estatísticos envolvidos no teste de hipóteses do produto esteja fora do escopo aqui, as seguintes ações são recomendadas para aprimorar o conhecimento nessa frente:

• Analistas de dados e engenheiros de dados geralmente são peritos em identificar os projetos de teste corretos e podem orientar os gerentes de produto, portanto, certifique-se de utilizar sua experiência no início do processo.
• Existem vários cursos on-line sobre testes de hipóteses, testes A/B e conceitos estatísticos relacionados, como Udemy, Udacity e Coursera.
• O uso de ferramentas como Firebase e Optimizely do Google pode facilitar o processo graças a uma grande quantidade de recursos prontos para uso para executar os testes certos.

Usando o teste de hipóteses para o gerenciamento de produtos bem-sucedido

A fim de entregar valor continuamente aos usuários, é imperativo testar várias hipóteses, com o objetivo de que vários tipos de testes de hipóteses de produtos possam ser empregados. Cada hipótese precisa ter um desenho de teste de acompanhamento, conforme descrito acima, para validá-la ou invalidá-la conclusivamente.

Essa abordagem ajuda a quantificar o valor entregue por novas alterações e recursos, focar nos recursos mais valiosos e fornecer iterações incrementais.