Teste A/B em um site: defina uma hipótese e uma regra de decisão

8 min de leitura

Um teste A/B em um site compara variantes em um dispositivo preparado, com uma hipótese, uma distribuição de visitantes e uma regra de análise definida antes do teste. Não consiste em mudar de página, esperar um aumento e depois atribuí-la ao novo texto. Comece com um problema documentado, escolha uma mudança interpretável e verifique a medida do resultado. Prepare também os critérios técnicos de parada e limites estatísticos com pessoa competente. Se o tráfego ou a recolha não permitirem uma conclusão fiável, prefira um teste qualitativo ou uma correcção óbvia em vez de um falso veredicto experimental.

Lembre-se: uma variante ainda não é um experimento

O resultado pode variar de acordo com o canal, horário ou perfil do visitante. O NIST explica que fatores secundários podem afetar a medição e devem ser identificados, controlados ou considerados no projeto experimental.^[29] Sua comparação deve abordar esse problema e não apenas produzir duas versões visualmente diferentes.

Formule a hipótese para o teste A/B do seu site

Descreva o problema encontrado: uma condição de oferta não encontrada, uma ação ambígua ou um formulário de difícil compreensão. Confie nas observações disponíveis, sem inventar um ponto de partida. “O botão não converte” é muito vago se você não sabe qual etapa está falhando.

Escreva uma hipótese ligando a mudança e o resultado: tornar a condição do serviço mais visível pode ajudar os visitantes afetados a enviar uma solicitação válida. A palavra “poderia” reflete a incerteza que o teste procura examinar. Não transforme esta suposição numa promessa de aumento.

Escolha uma variação cujo significado seja interpretável. Se você alterar título, preço, forma e visual ao mesmo tempo, uma diferença no resultado não permite identificar o elemento responsável. Um conjunto coerente de mudanças pode ser testado como uma oferta completa, mas você deve então anunciar esse escopo e evitar atribuir o resultado a um detalhe isolado.

Definir resultado principal e proteções

O resultado principal deve corresponder a uma ação validada: solicitação aceita, comando ou outro evento definido com precisão. Uma progressão como o clique principal pode ajudar no diagnóstico, mas não demonstra automaticamente a conclusão bem-sucedida da jornada. Confira o evento no sistema final.

Adicione proteções comerciais e técnicas. Uma variação não deve aumentar os erros de formulário, degradar o acesso às informações ou produzir solicitações fora da licitação para melhorar uma métrica superficial. W3C recomenda instruções, validações e notificações para compreender e corrigir erros de formulário.^[33]

O Guia da página de destino 4SYSTEM ajuda a verificar a consistência entre promessa e ação. Esta consistência deve permanecer verdadeira em todas as variações. Uma versão que remove uma condição essencial não é uma otimização aceitável, mesmo que mais visitantes cliquem.

Prepare a tarefa e os fatores de confusão

A comparação deve distribuir as unidades de acordo com uma regra desenhada para a questão e manter uma exposição consistente. Examine a persistência da variante para uma pessoa ou sessão, dependendo do seu dispositivo. A alternância não intencional entre versões pode dificultar a interpretação do resultado.

O NIST resume seu princípio experimental controlando fatores controláveis ​​e randomizando outros; também descreve o bloqueio de certos fatores parasitários.^[29] Este guia não é um manual de instruções pronto para qualquer site. Fornece uma base para conceber uma comparação que não confunda variante e composição de populações.

Documente as fontes de contaminação: alterações de campanha, visitantes internos, retomada de sessão, cache ou integração externa. Uma versão mostrada principalmente em dispositivos móveis e a outra principalmente em computadores não cria uma comparação clara simplesmente exibindo duas taxas. Verifique o dispositivo antes de expor visitantes reais.

Gravar protocolo antes do lançamento

Definir unidade, resultado principal, exclusões, modo de atribuição e regra de análise. Estime as necessidades de dados com base no nível observado, no efeito que se pretende detectar e no método escolhido. Nenhum número universal de visitas ou dias é oferecido aqui.

Planeje um resultado “inconclusivo”. A ausência de prova de diferença não demonstra a equivalência das versões. Uma amostra insuficiente, uma colheita interrompida ou um efeito demasiado incerto devem permanecer descritos como tal. Este resultado é um resultado honesto do dispositivo, não uma falha em esconder.

Distinguir entre parada de emergência e fim de análise. Um erro funcional ou exposição inadequada pode justificar o desligamento imediato, dependendo dos seus critérios. Por outro lado, parar assim que um gráfico parecer favorável pode tornar a interpretação enganosa se o método não previr esse exame. Escreva a regra antes de ver os resultados.

Folha de protocolo para compartilhar

Um protocolo completo permite distinguir a experiência real de uma demonstração gráfica. Mantenha as versões e configurações das páginas correspondentes ao teste: sem estes elementos, o resultado não pode ser vinculado a uma alteração específica.

Receita técnica e estrutura de coleta

Teste versões em dispositivos, teclados e caminhos de erro relevantes. Confira a distribuição, a manutenção da variante e o acionamento do resultado. Uma página que aparece corretamente ainda pode enviar um evento diferente dependendo da versão.

Rastreadores de revisão usados ​​para atribuir ou medir visitantes. A CNIL recorda o princípio do consentimento prévio para determinados depósitos e leituras de traçadores, com exceções limitadas.^[31] Uma ferramenta apresentada como “teste A/B” não dispensa você de analisar seu funcionamento e suas finalidades.

Prepare-se para remover alterações. Pausar o teste deve deixar um site funcional e não deixar scripts desnecessários. Acesso a documentos, versão de devolução e controle pós-desligamento. O protocolo experimental e a segurança do site devem ser abordados em conjunto.

Exemplo fictício: tornar visível uma condição B2B

Uma empresa imaginária recebe solicitações fora da área de intervenção. Ele pressupõe que a condição geográfica é difícil de identificar em uma página de oferta. Ela prepara uma variação que apresenta essa condição próxima à ação principal, sem alterar a oferta ou acrescentar falsa promessa.

No cenário ilustrativo, a equipe escolhe solicitações válidas com base em sua definição como resultado principal e monitora solicitações fora do escopo e erros de formulário. Ela tem o método de atribuição e análise verificado antes do lançamento. O número de cliques continua sendo um sinal secundário.

Se a variação atrair menos cliques, mas solicitações mais personalizadas, a decisão deverá seguir os critérios planejados, e não um alvo de clique adicionado posteriormente. Se os dados forem insuficientes, o teste permanece inconclusivo. Não são inventados números, níveis de confiança ou ganhos de clientes; O exemplo mostra apenas a lógica do protocolo.

Leia o resultado e decida sem história oportunista

Manter volumes, exclusões, incidentes e limites de métodos. Procure diferenças de exposição e quebras de coleta antes de escolher uma versão. Um resultado favorável não autoriza ignorar uma salvaguarda degradada.

Prepare três decisões possíveis: adotar de acordo com os critérios, manter o sistema anterior ou concluir que o teste não permite tomar uma decisão. Se você implantar uma versão, verifique a operação após interromper o teste. As configurações experimentais, caches e scripts podem diferir da versão final.

Em um site de baixo tráfego, uma observação qualitativa, uma receita de acessibilidade ou um esclarecimento de conteúdo podem ser mais úteis do que um teste longo sem potência adequada. Não transforme um erro óbvio em um experimento para atrasar sua correção. O teste serve à incerteza real e a uma decisão viável.

Perguntas frequentes

Quanto tempo deve durar um teste?

A duração depende das necessidades dos dados, do tráfego, da variabilidade e do método de análise. Defina-os antes do lançamento, com uma regra final explícita. Nenhum prazo universal prova confiabilidade. Um período decorrido não elimina uma atribuição defeituosa ou uma coleta inconsistente entre variantes.

Podemos testar apenas um botão?

Sim, se você tiver uma hipótese sobre sua compreensão ou função e um resultado medido corretamente. Porém, verifique se as versões permanecem consistentes com a oferta e acessíveis. Uma mudança de cor sem problema identificado pode produzir uma comparação difícil de interpretar e desviar a atenção de um obstáculo mais concreto no percurso.

O que fazer se os resultados permanecerem próximos?

Aplique o método e a regra fornecidos e mantenha a incerteza quando os dados não permitirem uma decisão. Não escolha outra métrica posteriormente para criar um vencedor. Você pode examinar os limites do dispositivo e preparar um teste diferente, mas deve partir de uma nova hipótese claramente anunciada.

Próxima etapa: validar o protocolo

Prepare uma hipótese, uma ficha completa e variantes funcionais antes de qualquer exposição. O Serviços 4SYSTEM pode ajudar a enquadrar o curso e a medição. Tenha a análise estatística qualificada de acordo com sua dúvida; nenhum botão “executar teste” garante uma conclusão viável.

Fontes

• 5.3.3.2. Randomized block designs (acessado em 2026-10-08)
• Cookies et traceurs : que dit la loi ? | CNIL (acessado em 2026-10-08)
• Forms Tutorial | Web Accessibility Initiative (WAI) | W3C (acessado em 2026-10-08)