Como ir de zero a um em sua jornada de experimentação do lado do servidor

Pense em sua jornada como usuário da Netflix. Se você for como eu, você pode assistir a um documentário sobre a vida selvagem em seu telefone enquanto toma seu café da manhã. O jantar pode ser acompanhado por um favorito dos velhos tempos como Forrest Gump no laptop. As noites de fim de semana seriam passadas alternando entre o seu perfil e o dos seus filhos, enquanto experimentava novos programas da Netflix, de preferência em uma tela maior.

Agora, digamos que a Netflix esteja executando uma campanha de desconto específica para o país. Se você faz parte desta campanha experimental realizada pela Netflix, como eles garantem que você faça parte da mesma campanha sempre que fizer login, independentemente do dispositivo e perfil que estiver usando, e veja a mesma promoção em todos os lugares? Como eles garantem que sua experiência com a variação que está sendo atendida seja perfeita a cada vez e que a forma como você se envolve com a variação seja rastreada de forma consistente?

A resposta está na experimentação omnichannel, que é um caso de uso típico de testes no lado do servidor.

Você deve preferir o teste do lado do servidor em vez do lado do cliente?

O exemplo da Netflix mencionado acima seria extremamente complicado de executar no lado do cliente e poderia prejudicar a experiência do usuário. No lado do servidor, é relativamente fácil de executar e garante uma experiência consistente para os usuários. Também garante um impacto mínimo no desempenho da página. Além disso, elimina quaisquer problemas relacionados à privacidade porque não há atividade no navegador como tal.

Existem outros casos de uso em que o teste do lado do servidor é recomendado por sua robustez e flexibilidade. Vamos falar sobre eles neste artigo. Mas primeiro, o que exatamente é o teste do lado do servidor e, mais importante, para quem é?

No teste do lado do servidor, as variações de teste são processadas no servidor web. Quando um visitante chega a uma página que está sendo testada, uma variação é buscada diretamente do servidor e entregue ao navegador do visitante. Nenhuma modificação subsequente ocorre no front-end ou no navegador. Ao contrário disso, nos testes do lado do cliente, a página original é carregada primeiro no navegador do visitante e sua plataforma de experimentação cria a variação no próprio front-end usando JavaScript. Vamos entender o escopo dessas duas formas de teste com um exemplo.

Imagine que Mike e Bob são dois amigos que estão tentando experimentar o funcionamento de um carro novo. Mike está ao volante e tem acesso a freios, acelerador, painel e afins. Bob tem uma visão dos componentes internos como motor, radiador, bateria, etc. Ambos podem influenciar o carro de maneiras diferentes. O que Bob faz com seu acesso aos componentes do carro pode refletir no exterior para Mike. As mudanças que Mike testa são baseadas em sua visibilidade do carro. Do ponto de vista do comprador do carro, o resultado dos experimentos conduzidos por Bob e Mike pode servir a propósitos igualmente importantes, mas diferentes.

Portanto, você não precisa escolher uma forma de teste em detrimento da outra. Os casos de uso são diferentes e as equipes que usam as ferramentas são diferentes. O teste do lado do servidor é uma via de experimentação para desenvolvedores e gerentes de produto, assim como o teste do lado do cliente é usado com mais frequência pelos profissionais de marketing.

Quais problemas podem ser resolvidos com testes no lado do servidor?

Os testes do lado do servidor executados por equipes de produto resolvem problemas relativos a uma infinidade de setores, de comércio eletrônico e SaaS a bancos e mídia. Alguns casos de uso importantes em que o teste do lado do servidor é recomendado em relação ao teste do lado do cliente em diferentes setores estão descritos abaixo:

Recomendação de produto

Qual conjunto de produtos recomendados atrai seus visitantes a comprar mais? O teste do lado do servidor permite testar vários algoritmos de recomendação de produtos para determinar a seleção que leva a um aumento nas vendas e na receita. Por exemplo, você pode testar se um layout que promove produtos semelhantes funciona melhor do que um layout que promove os mais populares. Você também pode decidir se fará upsell ou cross-sell com base nas descobertas do seu experimento do lado do servidor.

Taxa de envio

Qual é o valor ideal do carrinho que deve qualificar os pedidos para frete grátis? Você pode testar vários limites para determinar aquele que influencia positivamente as decisões de compra dos clientes.

Algoritmos de pesquisa

Experimentar com seu algoritmo de pesquisa requer modificação em seu código existente e flexibilidade para testar profundamente. Você deseja que seus visitantes possam encontrar rapidamente o que estão procurando e você pode testar seu algoritmo de pesquisa no lado do servidor para conseguir isso.

Comprimento do formulário

Os formulários de solicitação de teste e demonstração gratuitos são cruciais para as empresas de SaaS. Mas qual é o comprimento ideal do formulário que garante menos desistências e, ao mesmo tempo, captura todas as informações necessárias? Você pode testar os campos não obrigatórios por meio de testes do lado do cliente. Se o seu campo for obrigatório, apenas ocultar o campo usando JavaScript não funcionará, pois a validação do formulário usando a lógica do lado do servidor falhará. Portanto, o teste do lado do servidor é recomendado para experimentar campos obrigatórios para otimizar o comprimento e a complexidade do formulário.

Ofertas e descontos

Embora o estilo, a aparência e o posicionamento das ofertas em sua página inicial possam ser testados facilmente no lado do cliente, há outros fatores importantes, como o valor do desconto, sua duração ou critérios de qualificação a serem considerados. Você pode testar no lado do servidor para determinar o valor ideal e garantir que eles sejam consistentes em todos os canais para um visitante específico.

Incentivos de vendas

O teste de incentivos dinâmicos, como ofertas por período limitado ou liberação de estoque, exige a flexibilidade dos testes no lado do servidor devido à granularidade envolvida.

Fluxos de assinatura

Quantas etapas idealmente devem estar envolvidas em um processo de assinatura? Os logins sociais devem ser fornecidos? Fazer experiências com o fluxo de assinaturas pode ajudar a responder a essas perguntas.

Paredes de pagamento

O teste do lado do servidor permite testar várias configurações de paywall de maneira infalível. Como editor, você pode executar testes no lado do servidor para experimentar seu conteúdo fechado e monetizá-lo. A execução do mesmo teste no lado do cliente não é recomendada, porque os visitantes podem contornar um paywall excluindo ou desativando cookies.

Banco móvel

Vários elementos podem ser otimizados no processo de inscrição para um empréstimo ou cartão de crédito. Mas quando se trata de mobile banking, a segurança dos dados se torna primordial. Com os testes do lado do cliente, os dados confidenciais coletados por bancos ou instituições financeiras podem estar em risco de vulnerabilidade. Para evitar esse risco, os experimentos no lado do servidor geralmente são recomendados para aplicativos bancários.

Vamos agora entender como você pode executar testes de recursos no lado do servidor e as vantagens de fazê-lo com o VWO.

Como o VWO facilita os testes do lado do servidor

Para os casos de uso do lado do servidor descritos acima, o VWO oferece a flexibilidade de estruturar sua campanha como testes A/B ou testes de recursos. Testes de recursos são usados ​​para validar valores de parâmetros de recursos e dar a você o controle para configurar rapidamente um recurso, sem escrever código. Em alguns casos de uso, como testar qual algoritmo de pesquisa é melhor, é possível estruturar a campanha como um teste A/B ou um teste de recursos.

Por exemplo, digamos que você queira avaliar três fornecedores para o algoritmo de pesquisa que eles criaram para o seu site.

O teste de recursos permite que um gerente de produto como você teste e conclua rapidamente com dependência mínima de engenharia e controle máximo da configuração. Com os recursos de teste de recursos do VWO, você obtém uma estrutura definida em que precisa escrever menos código porque a plataforma faz a maior parte do trabalho pesado para você. No teste de recurso, o algoritmo pode ser definido como uma variável de recurso e ser configurado no controle e variação de um experimento a partir do próprio fluxo de configuração da plataforma para testar qual algoritmo de busca é mais eficiente.

Esse experimento também pode ser feito por meio de testes A/B do lado do servidor. O VWO facilita a distribuição de tráfego e a capacidade do modelo de estatísticas de experimentação por meio de seus SDKs do lado do servidor. As equipes de engenharia podem usar o mesmo para inserir o código dos algoritmos de busca e testar qual é mais impactante.

Aqui estão alguns outros cenários em que o teste de recursos é útil. Digamos que um fornecedor terceirizado que lida com recargas de celular deseja cobrar um valor nominal dos usuários por recarga. Eles querem testar a quantidade adequada para o mesmo. Ou uma empresa como o Airbnb, onde as cobranças da propriedade são tratadas pelo proprietário, deseja adicionar uma taxa de limpeza e ver se isso afeta o número de reservas. Este é um caso de uso de experimentação típico para várias empresas encontrarem o ponto ideal onde uma taxa de serviço pode ser inserida sem afetar a métrica da estrela do norte. Pode ser na forma de uma taxa de conveniência, taxa de instalação, taxa de covid, taxa de embalagem ou algo semelhante.

Casos de uso complexos como o descrito acima são super fáceis de testar no VWO. Aqui está um vídeo explicativo que mostra como você pode criar rapidamente um recurso de taxa de conveniência e atribuir um valor a ele (neste caso, o valor da taxa). Você pode vincular sua hipótese de identificar a taxa que aumenta a receita sem afetar o número de reservas, escolher o ambiente em que está executando o teste e habilitar suas variações. Depois de fazer isso, você recebe um código de campanha que vai para o seu servidor. Tudo o que resta é você definir as metas que deseja acompanhar e segmentar seu público, se desejar – é isso, sua campanha está pronta.

Se você é um gerente de produto e vê no painel que a variação 3 não está funcionando para os usuários; está impactando negativamente a receita, você pode matá-lo ali mesmo simplesmente desabilitando a variação no VWO. Conforme mostrado na captura de tela abaixo, isso não afeta o código e não exige que sua equipe de engenharia faça alterações. Você precisa desativá-lo, clicar em 'salvar' e a variação para de receber tráfego.

Essencialmente, o código precisa ser implementado apenas uma vez por campanha.

Você deve construir ou comprar uma plataforma para executar testes do lado do servidor?

Vamos acabar com o debate construir vs. comprar. O VWO não é apenas um gerador de números aleatórios que mostra diferentes variações para diferentes públicos e captura eventos de conversão. VWO é uma plataforma de experimentação completa com um modelo estatístico robusto. Para avaliar se deve construir um mecanismo de teste do lado do servidor internamente ou investir em uma plataforma como a VWO, você precisa considerar três fatores principais:

1. Custo de propriedade

Mesmo quando as empresas conseguem construir a infraestrutura necessária internamente, elas ainda precisam gerenciá-la e escalá-la. Pagar suas equipes de desenvolvimento para construir e manter um mecanismo de experimentação como o VWO em vez de se concentrar em suas tarefas principais provavelmente acabará sendo mais demorado e caro para você do que investir no VWO.

2. Fácil de usar

Você poderia construir uma solução que mostrasse uma certa variação para um determinado público – mas você teria uma interface fácil de usar que pudesse ser controlada não apenas pelas equipes de engenharia, mas também pelos gerentes de produto? Caso contrário, esse é outro bloqueador para você executar testes no lado do servidor.

3. Relatórios intuitivos

Normalmente, uma solução interna forneceria informações básicas, como o número de visitantes e as conversões provenientes de uma variação específica. Mas o que você precisa é de um resultado estatisticamente significativo. Você precisa que seus relatórios sejam alimentados por um mecanismo de estatísticas Bayesianas como o VWO SmartStats. É aí que está a lacuna – você pode criar uma solução básica que é difícil de manter e pode gastar tempo e recursos para decifrar os valores-p. Ou você pode escolher uma solução como o VWO, onde há uma equipe dedicada a mantê-lo e dimensioná-lo e passou anos no algoritmo Bayesiano para fornecer resultados facilmente interpretáveis. O painel no aplicativo no VWO permite que até mesmo os membros não técnicos da equipe entendam os resultados; eles não precisam depender da equipe do Analytics para acompanhar os experimentos ou criar painéis de resultados – economizando tempo e reduzindo o custo da experimentação.

4. Mecanismo sem erros

Construir uma solução de teste do lado do servidor internamente pode estar sujeito a erros e, nessa escala, os erros podem não ser facilmente detectáveis. Compare isso com a qualidade de uma plataforma usada por marcas globais e você terá certeza de que as chances de erros são minúsculas. Quaisquer erros, se houver, são sinalizados e corrigidos o quanto antes por uma equipe de suporte capaz disponível para você.

Além disso, quando você investe em uma plataforma gerenciada como o VWO, práticas recomendadas importantes são incorporadas ao produto. Você não precisa se preocupar em remover os valores discrepantes de seus resultados, visualizar seus dados ou com problemas decorrentes de atualizações de versão.

Recursos obrigatórios para executar testes complexos do lado do servidor com integridade

A execução de experimentos no lado do servidor pode ser muito proveitosa quando executada corretamente. Para fazer isso, você precisa ter o conjunto certo de recursos de recursos. Algumas delas estão dispostas abaixo:

1. Randomização de visitantes em cada teste – Nos testes, quando você está agrupando seu público em campanhas, a randomização de visitantes precisa ser realmente aleatória e não pseudo-aleatória.
2. Experiência omnicanal consistente – Embora o agrupamento de usuários precise ser aleatório, você também precisa garantir que um usuário experimente a mesma variação sempre que fizer login, independentemente do dispositivo que estiver usando. O experimento deve continuar sem falhas.
3. Campanhas mutuamente exclusivas – Digamos que você tenha três fatores a serem considerados ao determinar se um usuário deve fazer parte do seu teste. Estes podem ser regularidade de uso, baixa probabilidade de rotatividade e fuso horário. Além de levar em consideração essas variáveis, você também precisa determinar a exclusividade – então, de quantos testes o usuário que atende a essas condições pode fazer parte? Isso precisa ser determinado de uma forma que não leve a dados distorcidos e permita que você atribua a melhoria na taxa de conversão à campanha certa sem viés.
4. Convenção de nomenclatura padronizada – Esteja você configurando um novo recurso para testar ou um sinalizador de recurso, você precisa seguir uma convenção de nomenclatura padrão para evitar confusões e casos de inicialização de recursos ou testes errados.
5. Identificadores de campanha exclusivos e sem complicações – Você deve usar uma chave alfanumérica para identificar exclusivamente o teste em seu código e evitar aborrecimentos em um estágio posterior.
6. Escolhendo o ambiente certo – Você deve especificar o ambiente no qual está executando seu teste – por exemplo, você pode implantar o teste no ambiente de teste ou controle de qualidade para sua equipe de controle de qualidade validar o experimento. Uma verificação de sanidade do seu teste é crucial para seu sucesso e você deve ter a opção de escolher o ambiente certo para ele.
7. Alocação lógica de tráfego – Quando você está executando várias campanhas ou quando tem um anúncio de evento importante como uma Black Week Sale, por exemplo, você não precisa incluir todo o conjunto de visitantes que chegam à sua página em seu teste. Você deve escolher a porcentagem de tráfego que deseja incluir em sua campanha de teste e também como deseja distribuir esse tráfego entre as variações.
8. Cálculo do tempo para atingir significância estatística – Seu tempo estimado para seu teste atingir significância estatística deve ser determinado pela taxa de conversão atual de sua meta principal e a melhoria mínima que você deseja alcançar por meio de suas variações. Também deve considerar uma probabilidade de 95% de superar a taxa de conversão da linha de base.

Essas são algumas das práticas recomendadas e recursos obrigatórios dos testes do lado do servidor – a lista real é muito maior. Como mencionado anteriormente, você pode criar esses recursos internamente ou usar o VWO, onde fazemos o trabalho para você.

Para concluir

Seja você um desenvolvedor ou um gerente de produto, não precisa limitar suas ideias de teste. Você pode executar testes complexos sem temer problemas de desempenho ou privacidade com testes no lado do servidor e resolver problemas reais enfrentados por seus clientes. Você pode otimizar cada ponto de contato digital para que seus clientes experimentem apenas o melhor.

Se você estiver usando uma plataforma como o VWO, a complexidade do teste não o sobrecarregará – porque cada entrada sua na campanha é intuitiva e uma boa prática que potencializa seu teste. Para entender mais sobre como executar testes do lado do servidor com facilidade usando o VWO, solicite uma demonstração com nossos especialistas em produtos.