Teste A/B revolucionário com Varnish e CDN

O último semestre do ano foi cheio de novidades no GetNinjas. Nós decidimos fazer um novo tipo de teste A/B. Por sermos um grande marketplace de serviços no Brasil, nossa expertise com dados e análises é bem ampla. Sempre que vamos criar novas funcionalidades, fazemos teste A/B para que sejam menos arriscadas e possamos validá-las.

Mas o que é um teste A/B? Apresentamos versões de uma mesma funcionalidade, com pequenas variações, de modo aleatório para os visitantes. Assim, podemos analisar qual delas conquistou um resultado melhor.

No lado do frontend, o JavaScript nos ajuda com certa tranquilidade. Abba.js é uma ferramenta que facilita nosso processo de controle de versões de testes e os comportamentos esperados do nosso experimento.

Mas, em alguns casos, precisamos testar mais do que um simples pedaço de HTML ou CSS. Tivemos grandes mudanças no nosso layout e UI com o Gaiden, nosso styleguide, então, em algumas páginas nós precisamos testar essas mudanças sem comprometer as taxas de conversão e o tráfego orgânico e de marketing.

Somando a isso, tínhamos enfrentado por algumas vezes o fracasso de subir páginas totalmente novas em produção, mas que performaram bem menos que as antigas. Isso porque não fazíamos testes a/b revolucionários por conta das camadas de cache, que vou explicar logo mais nesse texto. Problemas

Geralmente, testes no frontend apresentam um problema clássico, que é o FOOC (Flash of Original Content). Existem algumas maneiras de contornar isso, como adicionar estilos de CSS no HEAD que escondam o trecho de alvo do teste, que sofrerá a alteração de conteúdo após o teste ser carregado. Isso para que, ao carregar o HTML, somente se exiba a versão final, decidida pela ferramenta de A/B, no caso, o Abba.js. Ainda assim, é uma tarefa arriscada, já que existe a possibilidade do usuário não ver o trecho do layout até que haja o split das versões.

Outro problema, desencadeado pelo problema apresentado acima, eram as métricas relacionadas a visualização completa da página. Como escondíamos alguns elementos, e só exibíamos quando o JS fazia o "sorteio" da versão, o usuário tinha a impressão de que a página não tinha terminado de carregar ou até mesmo tinha "travado". Isso aconteceu em alguns testes que fizemos na primeira dobra de algumas páginas.

Aliado a isso, tínhamos um último problema, que era o de performance. A versão original acabava recebendo mais coisas (JS, CSS, imagens) do que tinha anteriormente, o que poderia prejudicar a fiel análise dos dados. Como resolver (?)

A solução era fazer um split de versão no nosso backend, que é o Rails. Quando o request chega no controller, por meio de um header, o split acontece entre as versões de HTML que irão ser servidas para o cliente.

Adicionalmente, há duas camadas de cache no site: Varnish e CDN. Então, quando o primeiro usuário batia no backend, o Varnish e a CDN cacheavam uma das duas versões. O próximo usuário não iria "bater" no backend (Rails), porque a CDN e o Varnish estavam na frente, e apenas uma das versões seria servida para todos os próximos clientes. Isso parecia não fazer sentido.

CDN e Varnish para nos salvar — Para resolver isso, foi preciso mudar a VCL do Varnish, para tornar possível armazenar dois objetos de cache, baseados em um cookie. Mas, ainda tínhamos a CDN na frente. Com isso, começamos as conversas com o provedor, a Azion, para ver a possibilidade de dividir o tráfego e assinar o request do cliente com um cookie.

Explicando um pouco mais sobre CND, Varnish e tempo de backend

A Azion desenvolveu uma nova funcionalidade que divide as versões, e assim, nossa camada mais alta estava enviando ao Varnish um cookie. Quando esse cookie chega para o Varnish, criamos um header para avisar ao backend sobre qual versão era para ser servida de volta.

Dessa forma temos a possibilidade de testar novas funcionalidades grandes, sem o risco de sobrescrever uma página antiga que poderia ter uma taxa de conversão maior.

Versões com layouts diferentes na página. Novas possibilidades de testes no backend, ao invés do client-side Resultados

O time de design consegue hoje criar mais possibilidades de testes, não se limitando apenas a trechos do layout, mas sim de uma página totalmente remodelada. A limitação técnica que havia antes não precisa mais ser impeditivo para a criação de ideias ou novas propostas de interface.

Do lado de desenvolvimento, diminuímos os riscos de implementar uma página do zero, substituindo completamente nosso código por um novo. Agora, como a página ainda é um experimento, não precisamos nos dedicar em remover código antigo e otimizar ou reaproveitar algo do nosso codebaseâ??—â??isso até que o teste ganhe. Possíveis problemas

Embora o teste tenha suas vantagens, existem alguns poréns na hora de aplicá-lo. Um deles é que limitamos um pouco o número de testes que podem acontecer numa mesma página. Tivemos um caso de teste revolucionário na mesma página de um teste de front-end, utilizando JavaScript, que também estava funcionando lá. Quando começamos a ver esse cenário, já vimos como foi difícil entender os experimentos e pegar as métricas de resultado. O problema sempre vai ser manter os dois tipos de teste na mesma página.

Outro ponto de atenção é com relação a desenvolvimento de uma página toda, do zero, apenas para efetuar um teste. Não é difícil pensar em um teste menos agressivo para usar, mas quando a página toda é o alvo, o tempo de desenvolvimento pode ser gasto "à toa", pois o teste pode não ganhar. Isso é um fator que pode desmotivar o time ao trabalhar com esse tipo de abordagem.

Conclusões — Com essa nova abordagem, os testes de páginas novas são entregues de forma mais rápida e com menos risco para a saúde do negócio. Dessa forma, somente páginas que realmente convertem mais são adicionadas no site.

Se você tem um tempo disponível para poder fazer um teste desse tipo, antes de subir definitivamente para produção, faz muito sentido tentar. Se tiver um teste menor, que não altere a página toda, mas um trecho considerável, talvez faça sentido duas páginas para isso. Lembre-se que o fator tempo de carregamento da página, ou o próprio First Meaningful Paint, nesse caso, pode ser determinante no teste.

Outro ponto positivo é poder se beneficiar do split que uma CDN faz. Chegando dois headers diferentes, é mais simples fazer o split entre dois objetos de cache (pensando no Varnish aqui).

Enfim, esse tipo de abordagem pode ser uma boa para evitar qualquer queda de métricas do produto ou site que você trabalha.

. Por: Eduardo Matos, formado em Ciências da Computação pela Faculdade de Jaguariúna. É desenvolvedor web desde 2004, quando começou a trabalhar como professor e programador. Passou por empresas como R7.com, JWT, Medicinia, Creditas e por projetos como Philips, Adidas, entre outros. Hoje atua como Tech Lead no GetNinjas e é um dos administradores da organização do Frontend Brasil, no Github.

Enviar Imprimir