Testes do lado do servidor

O teste do lado do servidor é uma experimentação na qual a atribuição e a renderização de variantes ocorrem no servidor antes que a resposta chegue ao navegador. O visitante recebe a marcação completa para a versão que lhe foi atribuída, sem que nenhum script do lado do cliente reescreva a página após o carregamento. Isso difere do teste do lado do cliente, onde a página original é carregada primeiro e um script de teste a modifica no navegador.

As vantagens técnicas são substanciais. Não há oscilação na imagem, pois o visitante nunca vê o original antes da variante aparecer. Não há dependência da execução bem-sucedida do JavaScript, portanto, bloqueadores de anúncios, configurações de privacidade que bloqueiam scripts e dispositivos lentos não distorcem a amostra. Não há nenhum script adicional bloqueando a renderização, então o experimento não degrada a velocidade da página e, consequentemente, não compromete seus próprios resultados. Mais importante ainda, a variante não se limita ao que pode ser manipulado no DOM: testes do lado do servidor podem alterar preços, lógica de estoque, classificação de pesquisa, modelos de recomendação, respostas de API, regras de negócios e qualquer outra coisa que o aplicativo computa.

Os custos são organizacionais, e não técnicos. Os testes do lado do servidor exigem capacidade de engenharia para construir cada variante, o que significa que os experimentos entram na lista de pendências de desenvolvimento e competem com outros trabalhos. O tempo entre a concepção da ideia e o teste em produção é medido em sprints, e não em horas. As equipes de marketing e otimização perdem a autonomia que têm com os editores visuais, e o número de experimentos que um programa pode executar em um trimestre é limitado pela produtividade da engenharia, e não pelo tráfego. Organizações que migram para testes do lado do servidor sem ajustar seu ritmo de planejamento geralmente veem a velocidade de execução dos experimentos cair drasticamente antes que os ganhos de qualidade se tornem visíveis.

Na prática, programas maduros executam ambos os métodos. Os testes do lado do cliente continuam sendo apropriados para alterações de texto, layout, hierarquia visual e apresentação que podem ser implementadas com segurança no navegador e que as equipes de marketing precisam iterar rapidamente. Os testes do lado do servidor são reservados para tudo o que afeta a lógica de negócios, tudo em que a oscilação da tela comprometeria o resultado, tudo em um caminho de alto tráfego onde o custo de desempenho de um script de teste é inaceitável e tudo o que precisa funcionar de forma consistente na web, em aplicativos móveis e em e-mails. Decidir a qual categoria um teste pertence faz parte do planejamento do experimento, e não de uma política da plataforma como um todo.

Os testes do lado do servidor também alteram as funções da camada de análise. Como a atribuição ocorre no servidor, o identificador da variante deve ser transmitido de forma confiável para as camadas de análise e de armazenamento de dados para viabilizar a análise, e deve ser associado de forma consistente a todos os eventos subsequentes, incluindo aqueles que ocorrem dias depois, por e-mail ou em um aplicativo móvel. Acertar essa instrumentação geralmente é a parte mais difícil da migração, e erros resultam em experimentos cuja atribuição é tecnicamente correta, mas cujos resultados não podem ser reconstruídos.

A abordagem também estende a experimentação além do site, alcançando superfícies que as ferramentas do lado do cliente não conseguem acessar. Aplicativos móveis não podem ser modificados após o lançamento sem o envio para a loja de aplicativos, portanto, qualquer experimentação neles deve ser conduzida por configurações controladas pelo servidor. Conteúdo de e-mail, mensagens transacionais, lógica de precificação, classificação de pesquisa e modelos de recomendação são igualmente determinados pelo servidor. Uma vez que a atribuição ocorre de forma centralizada, o mesmo experimento pode abranger a web, o aplicativo e o sistema de mensagens com agrupamento consistente, o que permite que uma empresa teste uma mudança na experiência do cliente como um todo, em vez de apenas na renderização de um canal específico. Para organizações cujos clientes transitam entre canais rotineiramente, essa consistência não representa um refinamento: um experimento que atribui uma pessoa a uma variante no site e a outra no aplicativo não mede nada interpretável.

Como a mudança envolve tanto a arquitetura de engenharia quanto o funcionamento da função de otimização, geralmente é abordada como um exercício conjunto. A infraestrutura reside em desenvolvimento de produtos, a camada de medição com análise de dadose o planejamento e priorização dos experimentos com o Serviço CRO Para organizações que operam comércio em grande escala, essa combinação é o que possibilita testar as partes da experiência que realmente geram receita, em vez de apenas as partes que podem ser editadas em um navegador.