Testes A/B

A técnica de teste A/B ou implantação canário permite que os desenvolvedores experimentem duas ou mais variantes de uma página da Web. Variantes são mostradas aleatoriamente aos usuários e, em seguida, análises estatísticas são usadas para determinar qual variante tem melhor performance para uma determinada meta de negócios. Por exemplo, uma variante de UI de uma página de produto pode ser testada com o objetivo de aumentar as vendas de produtos.

Você pode implementar testes A/B de diferentes maneiras, de acordo com seus requisitos técnicos e de negócios. Uma das principais decisões técnicas é onde executar a lógica de seleção de variantes: no lado do cliente, no lado do servidor de borda (no nível da CDN) ou no lado do servidor de origem.

Seleção de variantes no lado do servidor de origem. Nessa abordagem, a seleção A/B é executada diretamente no servidor de origem que hospeda sua aplicação Web. Embora essa abordagem seja independente da CDN, ela é incompatível com o cache de CDN ou com a hospedagem estática de arquivos. É uma opção para aplicações Web renderizadas no lado do servidor que são totalmente dinâmicos.

Seleção de variantes no lado do servidor de borda. Nessa abordagem, você toma a decisão de seleção de variantes no nível da CDN. Essa abordagem requer o mínimo ou nenhuma alteração na aplicação e é compatível com o cache de CDN. No CloudFront, você pode implementar a lógica de teste A/B usando funções de borda. Uma função de borda pode usar os atributos da solicitação (país, cookie etc.), além da API externa de teste A/B para selecionar uma das variantes e fazer com que o CloudFront a forneça a partir do cache.

Seleção de variantes no lado do cliente. Nessa abordagem, seu front-end primeiro faz uma solicitação a uma API de teste A/B para decidir qual variante fornecer e, depois, com base na resposta, baixa essa variante e a renderiza no navegador. Nessa abordagem, seu teste A/B é independente da CDN, mas está fortemente acoplado à sua aplicação e introduz latência adicional devido a etapas adicionais no lado do cliente. Observe também que nem sempre é uma opção, como para testes A/B de sites gerados estaticamente (SSG). Para implementar o teste A/B no lado do cliente, você pode usar o CloudWatch Evidently. Ele fornece o SDK do cliente e a UI para controlar experimentos de testes A/B. Para um tutorial prático sobre o CloudWatch Evidently, considere este workshop.

Vamos nos concentrar em testes A/B no lado do servidor de borda. Para projetar a melhor implementação para os seus negócios, considere as seguintes perguntas adicionais:

• Você precisa de aderência (por exemplo, o mesmo usuário sempre terá a mesma variante)? A aderência geralmente é implementada com o uso de cookies.
• Quais dimensões são usadas para selecionar uma variante para um usuário? país, ID de usuário, etc.
• Com que frequência você faz testes A/B? O uso intenso de testes A/B, com muitos experimentos executados em paralelo por equipes diferentes, exige uma implementação mais sofisticada em comparação com testes A/B mais simples e ocasionais.

Para saber mais sobre algumas das implementações de testes A/B no lado do serviço de borda usando funções de borda do CloudFront, considere este workshop prático. Na seção a seguir, compartilharemos duas implementações comuns de testes A/B usando o CloudFront, extraídas do workshop mencionado acima.

Para necessidades ocasionais de testes A/B, como a melhoria trimestral do design de um site institucional, considere uma solução baseada no CloudFront Functions para a duração do seu experimento. A solução é baseada em duas funções configuradas no comportamento de cache que correspondem à página na qual você deseja executar o teste A/B:

• Uma função de solicitação do visualizador, que inspeciona o valor do cookie experimental das solicitações recebidas e, com base nele, reescreve o URL para a variante de página selecionada. Se o cookie não estiver presente, a função seleciona a variante usando sua lógica personalizada, como 60% para a variante A e 40% para a variante B, somente para solicitações vindas da França.
• Uma função de resposta do visualizador, que define o cookie no cliente com base na variante selecionada, se o cookie ainda não estiver presente. O cookie de experimento é usado para garantir que um único usuário sempre receba a mesma variante da página para evitar interromper sua experiência na web.

Alterar a lógica de seleção de variantes, como aumentar a porcentagem da Variante B, requer uma atualização do código de função do evento do visualizador, que geralmente leva segundos para ser concluída. Quando terminar o experimento de teste A/B, você poderá remover as funções de borda para economizar custos.

Se você tem uma prática contínua de testes A/B em seu site, com experimentos realizados diariamente, ainda poderá usar a solução anterior baseada no CloudFront Function. No entanto, é recomendável desacoplar os parâmetros de seleção da variante (por exemplo, pesos das variantes) do código da função. Você pode usar um CloudFront KeyValueStore para armazenar esses parâmetros, fora do código da função. O KeyValueStore é ideal como uma leitura global (cada PoP) de baixa latência,
datastore de valor chave em grande escala (milhões de solicitações por segundo).

Observe que seu caso de uso deve respeitar as cotas de KeyValueStore, como o tamanho máximo (5 MB) ou o limite de velocidade de alteração de algumas chamadas de API por segundo.

Considere uma solução baseada em Lambda@Edge se uma solução baseada no CloudFront Function não atender às suas necessidades de testes A/B, por exemplo, se as cotas de KeyValueStore forem limitantes para seu caso de uso. Esse pode ser o caso se você estiver operando um grande site de comércio eletrônico, com muitas equipes executando experimentos simultâneos em diferentes partes do site em alta velocidade.  Nesse cenário, use o Lambda@Edge em vez do CloudFront Function, com uma fonte de dados externa (por exemplo, tabelas globais do DynamoDB) para armazenar os parâmetros de teste A/B. Ferramentas de gerenciamento de atributos, como o LaunchDarkly, fornecem integrações com o DynamoDB para manter os parâmetros de teste A/B.

• Workshop: Testes A/B no lado do cliente usando o Evidently
• Workshop: Workshop de testes A/B no lado do servidor de borda usando funções de borda do CloudFront
• Estudo de caso da TrueCar: testes A/B no lado do servidor de borda usando o Lambda@Edge, o DynamoDB e o LaunchDarkly
• Estudo de caso da Ryanair: testes A/B no lado do servidor de borda usando o Lambda@Edge, o DynamoDB e o LaunchDarkly