Como configurar um ambiente de experimento para desenvolvimento de produto baseado em dados

Como product owner, é comum se deparar com a dúvida entre a opção A ou a opção B. Ou qual versão da tela deve ser implementada para obter melhores resultados? Tomar essas decisões pode ser desafiador, especialmente quando você está com prazos apertados e recursos limitados. Além disso, tais decisões são tomadas com base no julgamento pessoal ou na cópia da abordagem de um concorrente, o que pode levar a resultados abaixo do ideal.

A boa notícia é que é possível evitar essas armadilhas configurando um ambiente de experimento simples que exija esforço relativamente baixo. Neste artigo, descreveremos como você pode conseguir isso.

Índice

• Por que configurar um ambiente de experimento é importante.
• mitos
• Configurando seu ambiente de experimento
  • Definindo o objetivo de seu experimento futuro
  • Projetando a arquitetura do seu ambiente de experimento
  • Análise e interpretação de resultados
  • Ampliando a opção preferida.
• Conclusão.

Por que configurar um ambiente de experimento é importante?

A configuração de um ambiente de experimento é importante por dois motivos:

• Em primeiro lugar, ele permite que você tenha certeza de que, depois de implementar a nova funcionalidade, você escolherá a melhor opção com base em uma abordagem baseada em dados.

  
  

• Em segundo lugar, ele permite que você melhore continuamente a funcionalidade existente do seu produto, comparando opções 'como está' com opções hipotéticas 'a ser' e fazendo uma análise 'e se'.

mitos

Antes de prosseguirmos com a abordagem, vamos desmascarar alguns dos mitos que geralmente desorientam os proprietários de produtos:

Preciso de muitos recursos para montar um ambiente complexo que permita fazer experimentos e testes A/B

Errado : A abordagem descrita leva menos de uma semana dos recursos do seu engenheiro de software.

Preciso de um processo de coleta de dados bem estabelecido e rastreamento detalhado de eventos

Errado : você pode contar com um banco de dados existente que armazena informações sobre o ciclo de vida da entidade principal do seu produto. Por exemplo, status do pedido se você for um serviço de entrega.

Preciso de uma equipe dedicada de analistas que atendam minhas solicitações diariamente

Errado : depois de entender a abordagem e as métricas de seu experimento, você pode extrair dados por conta própria regularmente usando uma consulta SQL simples.

Abordagem

Para configurar seu ambiente de experimento, é recomendável seguir estas etapas:

1. Defina o objetivo de seu experimento futuro, entenda as opções e escolha as métricas

Antes de entrar em contato com o designer de produto, defina as metas e métricas a serem medidas como parte de seu experimento. No caso de uma questão clássica de 'Opção A ou Opção B', geralmente é direto o que você deseja alcançar implementando uma mudança. Por exemplo, você pode estar abordando uma parte específica do funil.

Para fins ilustrativos, vamos supor que você esteja trabalhando em uma empresa de entrega e atualmente focado no formulário de criação de pedidos. Você deseja abordar uma porcentagem relativamente baixa de usuários que fornecem seu endereço de entrega e, em seguida, selecionam um método de entrega. Além disso, imagine que você tem duas novas versões da jornada:

1. Versão atual : Uma tela requer a inserção de endereços e exibição do mapa com um alfinete com base no endereço fornecido. A próxima tela permite selecionar um método de envio com base no endereço fornecido.

   
   

2. Nova versão : A tela única requer inserir o endereço e selecionar o método de envio.

O objetivo é determinar qual das opções leva a uma parcela maior de usuários que forneceram seu endereço e selecionaram um método de envio. As métricas são bastante diretas: % dos usuários que forneceram seu endereço e selecionaram um método de envio.

Na verdade, existem 2 maneiras de medir esses dados :

1. Com base nos dados que já estão disponíveis pelo design do seu back-end . Por exemplo, considere um banco de dados que tenha informações sobre o ciclo de vida do pedido. Seu pedido pode ter estados ou status como:

   
   

   1. Rascunho criado

   2. Tente encontrar métodos de envio

   3. Opções de envio encontradas/ Opções de envio não encontradas

      
      

2. Rastreamento de eventos - isso não é algo que funcionará imediatamente e, portanto, requer esforço extra para ser implementado. No entanto, o rastreamento de eventos permitirá uma análise mais granular para você, por exemplo, o tipo de dispositivo e o nome do navegador podem ser passados como um parâmetro de seus eventos.

Nas próximas seções deste artigo, estaremos focados na primeira abordagem, ou seja, arquitetura de dados existente, sem rastreamento de eventos.

2. Projete a arquitetura do seu ambiente de experimento

Duas etapas principais devem ser concluídas no fluxo do experimento:

• Criar uma experiência com parâmetros selecionados
• Defina um estágio da jornada do usuário quando o usuário deve ser atribuído a um dos grupos e garanta que a interface do usuário relevante seja exibida como resultado

Criando um experimento:

A ideia é criar um framework leve de testes A/B que seja o mais simples possível e que permita criar experimentos com os seguintes parâmetros:

• ID da experiência
• Amostra máxima
• Número e nomes de cada grupo
• Probabilidade de cair em cada grupo

A possibilidade de configurar esses parâmetros permite definir um limite amostral e escolher aleatoriamente os candidatos para o experimento até atingir o tamanho amostral desejado.

Tanto o cliente quanto o servidor precisam de mudanças para isso: o servidor deve rastrear o número de candidatos por experimento e o back-end decidirá se o usuário atual deve fazer parte de um experimento ou não. O back-end decidirá se o usuário autenticado deve fazer parte do experimento com base no tamanho da amostra atual e em uma probabilidade fixa. Além disso, o back-end deve manter uma coleção de usuários que fazem parte de um determinado experimento para fornecer experiências consistentes aos usuários e calcular adequadamente os resultados do experimento.

É assim que o endpoint para a configuração do experimento pode ser:

POST /api/your-service/experiment-create

Solicitar:

 { experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e", maximum_sample_size: 250, groups: { { group_name: "old_journey", probability_of_falling_in: 0.5 }, { group_name: "new_journey", probability_of_falling_in: 0.5 },}

Resposta:

{

200,

experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e"

}

Decidir quando e como o usuário deve ser atribuído a grupos experimentais:

Você precisará de um endpoint separado que será responsável por atribuir um usuário específico ao experimento e ao grupo correspondente. Vamos chamá-lo experiment-enrollments .

Ao projetar todo o ambiente, você deve ter uma compreensão clara em qual estágio da jornada do usuário o endpoint experiment-enrollments deve ser chamado. Além disso, pode ser que nem todos os usuários devam participar do experimento. É por isso que seria útil fornecer um token de autenticação de usuário em um endpoint também.

Em nosso exemplo, se quisermos focar apenas em novos usuários que estão fazendo seu primeiro pedido, user-auth nos permitirá determinar que tipo de usuário é e se algum deve ser inscrito no experimento. Além disso, certifique-se de que, assim que o endpoint for chamado, todas as informações necessárias estejam disponíveis e considere as especificidades de sua jornada e ciclo de vida.

O endpoint experiment-enrollments é descrito abaixo. Ele pode ser chamado em um estágio específico da jornada (por exemplo, antes de aterrissar na tela que exige o endereço de entrega) para tipos específicos de usuários (por exemplo, apenas novos usuários que ainda não forneceram o endereço) e calculará se o usuário atual deve participar em um determinado experimento ou não:

POST /api/your-service/experiment-enrollments , o token de autenticação do usuário é necessário

Solicitar:

\ {

experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e"

}

Resposta:

 {200, enrolled: true/false, group_name: group_1,}

Para ilustrar como seria o fluxo de dados teórico, suponha o mesmo exemplo de fluxo de criação de pedido na empresa de entrega. Você está selecionando entre 2 opções de tela de criação de pedidos.

Os seguintes endpoints são mencionados no diagrama abaixo, ou seja:

• /criar rascunho do pedido (etapa 3)

• /localizar método de envio (etapa 16)

• /enviar pedido (etapa 20)

  
  

são fornecidos para dar suporte ao exemplo ilustrativo e não são partes necessárias do ambiente do experimento

Além disso, a arquitetura ilustrativa e simplificada dos bancos de dados é fornecida abaixo.

Existem 3 tabelas principais:

1. Experiments set - contém todos os experimentos que você criou anteriormente. O banco de dados é atualizado toda vez que você chama o endpoint /experiment-create .

   
   

2. Experiments database - contém todos os registros associados a cada inscrição de um usuário específico. O banco de dados é atualizado toda vez que você chama o terminal experiment-enrollments

   
   

3. Order lifecycle database - é fornecido para dar suporte ao exemplo ilustrado de como os dados relacionados ao experimento podem ser armazenados. O ponto é que esta tabela (ou qualquer tabela semelhante que corresponda às especificidades do seu produto) permitirá que você veja se a entrada (por exemplo, criação do pedido) foi bem-sucedida ou não para o usuário específico inscrito em um dos grupos experimentais que você definimos. Em nosso exemplo, podemos contar com o status do método de envio selecionado que permite concluir que o usuário forneceu os detalhes de envio com sucesso e selecionou um dos métodos de envio sugeridos.

   
   

   
   

Visão geral da abordagem de design e implementação

Prós:

1. A amostra resultante é heterogênea
2. O tamanho da amostra é conhecido antecipadamente
3. Os resultados podem ser calculados rapidamente, dependendo da probabilidade de amostragem fixa

Contras:

1. Requer mudanças de front-end e back-end
2. A computação dos resultados dependerá de vários bancos de dados , alguns dos quais não puderam ser inicialmente projetados para fins analíticos

Tarefas e estimativas indicativas:

• [ ] indefinido [Backend] Crie um modelo e exponha o ponto final do contador de busca: ~ 2 pontos de história
• [ ] indefinido [Backend] Expor ponto final do contador de incremento: ~2 pontos de história
• [] indefinido [Backend] Expor endpoints para buscar e incrementar o contador: ~1 ponto de história
• [ ] indefinido [Frontend] Pontos de extremidade do contador de chamadas para alternar entre os fluxos de inscrição: ~ 3 pontos de história

Depois de projetar seu back-end, alinhe-se com sua equipe de front-end sobre a melhor maneira de receber as informações e em qual estágio do fluxo.

Tenha em mente e mitigue as principais dependências :

• Certifique-se de que suas equipes estejam alinhadas em um contrato com antecedência para que a parte do front-end possa ser implementada em paralelo com o back-end.
• Tente evitar que seu front-end seja bloqueado até que todo o back-end esteja pronto
• Independentemente do ambiente do experimento, todas as opções de interface do usuário devem ser implementadas de qualquer maneira

3. Análise e interpretação dos resultados

Depois que seu experimento estiver em execução por um período de tempo suficiente, é importante analisar e interpretar os resultados para tirar conclusões significativas.

Defina a lista de campos necessários para calcular o impacto nas métricas que você decidiu focar anteriormente.

A partir do exemplo ilustrativo acima, as fontes de dados seriam 2 tabelas:

• Experiments database :

  • Entrada : ID da experiência que você está procurando resultados

  • Saída : lista de todos os IDs de usuários que são participantes de um experimento específico, o grupo ao qual cada usuário foi atribuído e carimbo de data/hora quando o usuário foi atribuído

    
    

• Order lifecycle database
  • Entrada : lista de usuários que estão no escopo de sua experiência e carimbo de data/hora quando eles foram inscritos para experimentar
  • Saída : status final de todos os pedidos associados a esses usuários e que foram processados depois que o usuário foi inscrito para experimentar

Com base nesses dados, você pode calcular a porcentagem de pedidos criados com sucesso para cada um dos grupos experimentais.

Ao analisar seus resultados, é importante olhar além dos números brutos. Você também deve procurar por significância estatística para garantir que quaisquer diferenças observadas entre os grupos de teste não se devam apenas ao acaso. Não vou me concentrar muito nessa parte, pois já vejo muitos artigos relacionados a esse tópico com este e outros recursos online. De qualquer forma, não é necessário conhecimento excessivo aqui: na minha opinião, bastaria poder aplicar o Z-Test ou o T-Test para verificar a significância da diferença entre os 2 grupos.

No entanto, depois de determinar que seus resultados são estatisticamente significativos, você pode começar a tirar conclusões sobre qual opção de seu produto teve melhor desempenho.

4. Ampliando a opção preferida

Depois de executar um experimento com sucesso e obter um grau de confiança suficiente em relação à melhor opção, a próxima etapa é ampliar suas alterações em todo o produto. Pode haver várias abordagens:

• A mais fácil é ajustar a configuração de sua experiência para que 100% dos usuários se enquadrem no grupo que apresenta melhores resultados . Você precisará reservar algum tempo para limpar o código no futuro, para que a exibição dessa parte específica da IU seja independente do ambiente de experimento

  
  

• O menos direto é se o seu produto estiver disponível em várias plataformas. Seja extremamente cuidadoso ao presumir que os resultados dos experimentos no fluxo da Web se aplicam ao fluxo do aplicativo móvel (e vice-versa). Às vezes, é melhor prevenir do que remediar e executar um experimento separado de maneira semelhante, mas em outra plataforma.

Concluir

Ter seu próprio ambiente de experimento é uma ferramenta muito útil para qualquer gerente de produto. Independentemente do estágio de maturidade do seu produto atual, a criação de um ambiente de experimento não deve levar muito tempo. Pagar um custo único bastante baixo para fazê-lo funcionar mostrará rapidamente o retorno do investimento.

Finalmente, aqui estão algumas dicas para garantir que os resultados do experimento façam sentido:

• Em primeiro lugar, entenda quais métricas serão afetadas (se houver) ao implementar a mudança que você está considerando.
• Defina claramente suas metas e métricas antes de iniciar sua experiência
• Mantenha seu experimento o mais simples possível, concentrando-se em uma mudança importante por vez
• Tenha cuidado ao considerar a extrapolação dos resultados de seu experimento em outras plataformas ou outros serviços semelhantes
  

Ao seguir essas práticas recomendadas, você pode configurar um ambiente de experimentação eficaz que pode ajudá-lo a tomar decisões baseadas em dados e impulsionar suas taxas de conversão ao longo do tempo.