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 a booking.com (onde trabalhei antes) executam centenas de testes A / B em seus sites com 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 lançar pequenas mudanças que agreguem 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 entregar valor contínuo por meio de melhorias, essa abordagem permite que uma equipe de produto obtenha feedback contínuo dos usuários e, em seguida, 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 correção de curso e abordagem iterativa para a criação valor do produto .
Ao enviar um recurso para os usuários, é fundamental validar as suposições sobre o design e os 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 descreve uma hipótese para uma mudança e, em seguida, define o sucesso. Por exemplo, se um gerente de produto de dados na Amazon tem a hipótese de que mostrar imagens maiores de produtos aumentará as taxas de conversão, então o sucesso é definido por taxas de conversão mais altas.
Um dos principais aspectos do teste de hipóteses é o isolamento de diferentes variáveis na experiência do produto para poder atribuir o sucesso (ou fracasso) às mudanças feitas. Portanto, se nosso gerente de produto da Amazon tivesse outra hipótese de que mostrar comentários de clientes ao lado de imagens de produtos melhoraria a conversão, não seria possível testar as duas hipóteses ao mesmo tempo. Fazer isso resultaria em falha na atribuição adequada de causas e efeitos; portanto, as duas alterações devem ser isoladas e testadas individualmente.
Assim, as decisões do produto sobre os recursos devem ser apoiadas por testes de hipóteses para validar o desempenho dos recursos.
Os casos de uso mais comuns podem ser validados por testes A / B aleatórios, nos quais uma mudança ou recurso é liberado aleatoriamente para metade dos usuários (A) e retido para a outra metade (B). Voltando à hipótese de imagens de produtos maiores 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 maiores do produto, a conclusão seria que a hipótese original estava correta e a mudança pode ser implementada para todos os usuários.
O ideal é que cada variável seja isolada e testada separadamente para atribuir as mudanças de forma conclusiva. 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 maiores de produtos 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, um teste multivariado pode ser adotado, no qual os usuários não são divididos pela metade, mas em múltiplas variantes. Por exemplo, quatro grupos (A, B, C, D) são compostos por 25% dos usuários cada, onde os usuários do grupo A não verão nenhuma mudança, enquanto aqueles nas 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.
Às vezes, não é possível dividir os usuários pela metade (ou em várias variantes), pois pode haver efeitos de rede no local. Por exemplo, se o teste envolve determinar se uma lógica para formular preços de pico no Uber é melhor do que outra, os drivers não podem ser divididos em diferentes variantes, já que a lógica leva em consideração o descompasso entre demanda e oferta de toda a cidade. Nesses casos, um teste deverá comparar os efeitos antes 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 momento t , de modo que a lógica A é usada antes e a lógica B é usada depois. Enquanto os efeitos antes e depois do tempo t podem ser comparados, não há garantia de que os efeitos são devidos exclusivamente à 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.
As desvantagens do teste antes / depois podem ser superadas em grande medida com a implantação de testes on / off baseados em tempo, em que a mudança é apresentada a todos os usuários por um determinado período de tempo, desligada por igual período de tempo, e em seguida, repetido por um período mais longo.
Por exemplo, no caso de uso do Uber, a alteração pode ser mostrada aos motoristas na segunda-feira, retirada na terça, mostrada novamente na quarta 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.
Escolher o teste certo para o caso de uso em questão é uma etapa essencial para validar uma hipótese da maneira mais rápida e robusta. Uma vez feita a escolha, os detalhes do design do teste podem ser descritos.
O design do teste é simplesmente um esboço coerente de:
No caso da hipótese de que imagens maiores de produtos levarão a uma conversão melhorada 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 correto é escolhido e projetado, e os critérios de sucesso e métricas são identificados, os resultados devem ser analisados. Para fazer isso, alguns conceitos estatísticos são necessários.
Ao executar testes, é importante garantir que as duas variantes escolhidas para o teste (A e B) não tenham um viés com relação à métrica de sucesso. Por exemplo, se a variante que vê as imagens maiores já tem uma conversão maior do que a variante que não vê a mudança, o teste é tendencioso e pode levar a conclusões erradas.
A fim de 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.
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 a importância da mudança na métrica de sucesso.
Em termos leigos, significado mede a frequência com que o teste mostra que imagens maiores levam a uma conversão maior, quando na verdade não o fazem. Poder mede a frequência com que o teste nos diz que imagens maiores levam a uma conversão maior, quando realmente o fazem.
Portanto, 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ótese de produto esteja fora do escopo aqui, as seguintes ações são recomendadas para aprimorar o conhecimento nesta frente:
Para fornecer continuamente valor aos usuários, é imperativo testar várias hipóteses, para o qual vários tipos de teste de hipótese de produto podem ser empregados. Cada hipótese precisa ter um design de teste de acompanhamento, conforme descrito acima, a fim de validar ou invalidar conclusivamente.
Essa abordagem ajuda a quantificar o valor entregue por novas mudanças e recursos, trazer o foco para os recursos mais valiosos e entregar iterações incrementais.
Uma hipótese de produto é uma suposição de que alguma melhoria no produto trará um aumento em métricas importantes, como receita ou estatísticas de uso do produto.
As três partes necessárias de uma hipótese são a suposição, a condição e a previsão.
Fazemos testes A / B para garantir que qualquer melhoria no produto aumente nossas métricas rastreadas.
O teste A / B é usado para verificar se as melhorias do produto criam a mudança desejada nas métricas.
O teste A / B e o teste multivariado são tipos de teste de hipótese. O teste A / B verifica como as métricas importantes mudam com e sem uma única mudança no produto. O teste multivariável pode rastrear várias variações da mesma melhoria do produto.