Bloqueios Organizacionais ao Teste A/B (e como remover)

A maioria dos programas de teste A/B não trava porque a estatística é difícil. Trava por bloqueios organizacionais: falta de tráfego para dimensionar o teste, um processo de entrega que trata teste como portão, uma pessoa sênior que reverte resultado, ninguém dono da métrica primária, uma fila de engenharia, portões de aprovação em série, um time sem memória do que já testou e, no mercado brasileiro, uma página que pertence a uma agência externa. Sete desses oito são problemas de processo, e é por isso que trocar de ferramenta quase nunca destrava nada. Este artigo percorre cada bloqueio, o que o mantém vivo e o movimento específico que o remove, com calculadoras ao vivo para os dois que são aritmética disfarçada. Faz parte do guia de como construir uma cultura de experimentação.

Os oito bloqueios, e quais são reais

Antes de percorrer um a um, ajuda ver todos ordenados pelo tipo de problema que realmente são. A distinção importa porque a correção é completamente diferente: problema aritmético se resolve com uma conta e uma decisão sobre o que você aceita detectar, enquanto problema de processo se resolve mudando quem decide o quê e quando.

Bloqueio	Como soa na reunião	O que é de verdade	Onde mora a correção
Tráfego insuficiente	“Somos pequenos demais para teste A/B”	Aritmética, mais uma expectativa não declarada sobre tamanho de efeito	Dimensionar o teste e renegociar o MDE
Testar atrasa	“Não dá pra esperar três semanas por entrega”	Processo: teste aplicado como portão em vez de filtro	Decidir quais mudanças merecem teste
Resultado revertido	“O dado diz B mas vamos subir A”	Governança: sem regra para quando o veto de negócio é legítimo	Regra de decisão acordada antes de rodar
Métrica sem dono	“Marketing diz que venceu, produto diz que não”	Titularidade: dois times lendo dois números diferentes	Um dono nomeado por métrica primária
Fila de engenharia	“A variação está no backlog do próximo trimestre”	Processo: toda variação tratada como funcionalidade de produto	Um caminho de construção que não consome sprint
Aprovação em série	“O jurídico precisa revisar cada variação”	Processo: aprovação colocada depois do trabalho em vez de em volta dele	Guarda-corpos pré-aprovados em vez de revisão caso a caso
Sem memória institucional	“Já testamos isso? Ninguém sabe”	Conhecimento: resultado guardado por nome de teste, não por pergunta	Repositório organizado por página e hipótese
Página da agência	“A landing é da agência, não temos acesso”	Contrato: quem opera a página não é quem mede	Cláusulas de acesso, congelamento e implementação

Só o primeiro é genuinamente um problema de estatística, e mesmo assim não do jeito que as pessoas esperam. O resto é decidido pela forma como a organização está ligada.

Bloqueio 1: “não temos tráfego suficiente”

Este é o único bloqueio com resposta calculável, e a resposta costuma ser mais matizada do que qualquer um dos dois lados espera. A frase “não temos tráfego suficiente” quase nunca é verdadeira sozinha. O que é verdade é “não temos tráfego suficiente para detectar o tamanho de efeito que assumimos implicitamente, na janela que assumimos implicitamente”. Uma vez que essas duas premissas escondidas são ditas em voz alta, a conversa deixa de ser sobre sensação.

Pegue um fluxo de cadastro com taxa base de 3,1% e 9.200 visitantes por semana. A 95% de confiança e 80% de poder, num teste bilateral:

Ganho relativo que você quer detectar	Amostra por variação	Duração a 9.200 visitas por semana
10%	51.438	79 dias
15%	23.387	36 dias
25%	8.796	14 dias

Taxa de conversão atual%Efeito mínimo detectávelrelativo (%)absoluto (pp)Confiança909599%Poder8090%Visitantes por semana (total)Testebilateralunilateral

-Visitantes por variação

-Total (2 variações)

-Duração estimada

Cálculo por aproximação normal de duas proporções, 2 variações (50/50). Mexa nos campos e veja o impacto ao vivo.

Ajuste a calculadora para taxa base 3,1, efeito mínimo detectável 15 (relativo) e 9.200 visitantes por semana para reproduzir a linha do meio. O formato dessa tabela é a lição inteira: a amostra exigida cresce aproximadamente com o inverso do quadrado do efeito que você quer detectar, então cortar pela metade a ambição sobre o efeito faz muito mais pela viabilidade do que dobrar a sua paciência.

Existem três saídas honestas desse bloqueio, e uma desonesta.

• Teste mudanças maiores. Uma etapa redesenhada produz efeito maior que a cor de um botão, e efeito maior é mais barato de detectar. Pouco tráfego é argumento a favor de variações ousadas, não tímidas.
• Suba a métrica no funil. Adição ao carrinho acontece muito mais que compra, então fecha amostra bem mais rápido. O trade-off é honesto e precisa ser declarado: você está medindo um proxy, e proxy pode se mover sem a receita vir junto.
• Aceite a janela. Um teste de 36 dias não é fracasso, é um fato sobre o seu tráfego. O que quebra programas é prometer resposta em duas semanas e depois parar no dia 14 um teste de 36 dias.

A saída desonesta é rodar o teste assim mesmo e ler cedo. Isso está detalhado no guia de CRO para sites de baixo tráfego, e o bloqueio seguinte mostra o formato exato do estrago.

Bloqueio 2: “testar deixa a gente lento”

Essa objeção costuma mirar no alvo errado. Testar não deixa um time lento; testar tudo deixa. Programas que aplicam experimentação como portão em todo o trabalho terminam com uma fila de entrega atrás de um processo estatístico que nunca foi feito para carregá-la.

A regra que funciona é que experimentação é filtro para mudanças de alto risco, não portão para toda mudança. Três perguntas decidem se algo merece teste:

1. Errar é caro? Uma mudança no checkout de uma loja que processa receita real é um risco diferente de uma mudança num link de rodapé.
2. É difícil de reverter? Uma mudança na página de preços que ancora expectativa é mais difícil de desfazer do que um ajuste de texto.
3. Pessoas razoáveis discordam? Se todo mundo na sala prevê o mesmo desfecho, o teste compra menos informação do que custa, a não ser que o risco seja alto o bastante para justificar verificar o consenso.

Tudo que reprova nas três deveria subir sem teste. Essa única regra costuma cortar a “fila de testes” pela metade, e remove a causa estrutural mais comum da reclamação.

A segunda causa é rodar teste um de cada vez. Superfícies independentes podem rodar experimentos simultâneos sem interferir, e um programa que roda três testes em paralelo em fluxos não relacionados tem o triplo da taxa de aprendizado com o mesmo tráfego por teste. O limite prático é a sobreposição: dois testes tocando a mesma etapa do funil podem interagir, e isso é um problema de desenho a resolver, não uma razão para serializar tudo. O guia de quantos testes A/B rodar por mês cobre como definir essa cadência contra o tráfego real.

A terceira causa é a que ninguém diz em voz alta: o time para o teste cedo porque o prazo chegou, e só então descobre que o resultado não sustenta a decisão. Veja como isso fica com números reais. O fluxo de cadastro acima precisava de 23.387 visitantes por variação para um efeito relativo de 15%. Suponha que ele seja parado em 13.200 por variação porque o trimestre está fechando, com 409 conversões no controle e 478 na variação:

Controle (A)

VisitantesConversões

Variação (B)

VisitantesConversões

Confiança90%95%99%

Controle (A) · Taxa-

Variação (B) · Taxa-

Melhora relativa-

valor-p-

IC 95% da diferença-

Teste z bilateral de duas proporções. "Sem significância" quase sempre quer dizer que falta amostra, não que as versões são iguais.

Digite 13.200 visitantes e 409 conversões em A, e 13.200 visitantes e 478 conversões em B. A calculadora devolve um valor p de cerca de 0,018, um ganho relativo de cerca de +16,9%, e um intervalo de confiança de 95% para a diferença absoluta indo de aproximadamente +0,09 ponto percentual a +0,96 ponto percentual. O teste é estatisticamente significativo, e continua sendo base ruim para promessa de receita: traduzido para termos relativos, o intervalo se estica de aproximadamente +2,8% a +30,9%. Um time financeiro que ouve “isso vale 17% mais cadastros” está recebendo o ponto médio de uma faixa que inclui um ganho quase desprezível.

Esse é o custo honesto do atalho. Não uma resposta errada, uma resposta inutilmente imprecisa, apresentada com a confiança de uma precisa. A correção não é parar de reportar o número, é reportar o intervalo ao lado dele, o que está no guia de significância estatística.

Bloqueio 3: resultado revertido por hierarquia

Todo programa de experimentação uma hora produz um resultado de que alguém sênior não gosta. O que acontece em seguida determina se o programa sobrevive.

O erro é tratar toda reversão como a mesma coisa. Três situações distintas são confundidas, e só uma delas é de fato um problema.

Situação	O que está acontecendo	Legítimo?	O que fazer
Veto de negócio	A decisão depende de algo que o teste não mediu: restrição jurídica, compromisso de marca, acordo com parceiro	Sim	Suba a decisão de negócio, registre o motivo no repositório, preserve o resultado do teste
Desconfiança da medição	A pessoa suspeita que o próprio teste está quebrado	Sim	Responda com um teste A/A ou uma checagem de proporção de amostra, não com discussão
Discordância pura	O resultado é válido, entendido, e revertido porque alguém sênior prefere a outra opção	Não	É o caso que mata programas, e é falha de governança, não de personalidade

A sigla do terceiro caso é HiPPO, “highest paid person’s opinion”, a opinião de quem ganha mais, popularizada por Avinash Kaushik e Ronny Kohavi por volta de 2006. O problema nunca é uma pessoa da diretoria ter opinião. O problema é reverter um resultado publicado sem uma razão fora da métrica, porque numa única decisão isso ensina a todo mundo que rodar o teste foi encenação.

A correção estrutural é chata e eficaz: acordar a regra de decisão antes de o teste rodar. Quem decide, sobre qual métrica, em qual limiar, e sob quais condições um veto de negócio é aceitável. Uma regra escrita antes de alguém saber o desfecho é uma regra que todo mundo aceita. A mesma regra escrita depois do resultado é uma negociação. O artigo sobre como conseguir apoio da diretoria cobre como estabelecer esse acordo sem transformá-lo em confronto.

Bloqueio 4: ninguém é dono da métrica primária

Esse bloqueio é silencioso e caro. Ele aparece como uma reunião em que marketing diz que o teste venceu e produto diz que não, e os dois estão certos, porque estão lendo números diferentes.

A causa raiz é uma só: a métrica primária nunca foi nomeada e apropriada antes de o teste começar. Quando isso acontece, cada pessoa envolvida traz a métrica que melhor combina com o objetivo dela, e a discussão vira uma negociação sobre qual número conta, realizada depois de todo mundo já saber qual número favorece a própria posição.

A correção tem três partes, e as três precisam acontecer antes de o teste rodar:

1. Uma métrica primária por teste, nomeada por escrito. Não um painel, um número.
2. Um dono nomeado para essa métrica. Uma pessoa, não uma área.
3. Métricas de guarda declaradas de antemão. As coisas que não podem piorar, listadas antes de dar para ver se pioraram.

Guarda-corpos são o que permite dizer não a uma vencedora com honestidade. Uma variação que sobe adição ao carrinho em 8% e derruba receita por visitante em 3% não é vencedora, e sem uma métrica de guarda declarada essa troca fica invisível até alguém notar o gráfico de receita semanas depois.

Bloqueio 5: a fila de engenharia

Em muitas organizações o gargalo real não é estatística nem aprovação, é que toda variação é tratada como funcionalidade de produto, entrando no mesmo backlog de todo o resto. Uma ideia de teste que leva vinte minutos para desenhar espera seis semanas para ser construída.

O movimento que destrava é separar as ideias de teste pelo que elas de fato tocam. Mudanças de texto, layout, ordenação e enquadramento de oferta vivem na camada de apresentação e podem ser construídas e publicadas pelo time de experimentação com uma ferramenta baseada em snippet, sem consumir capacidade de sprint. Mudanças que tocam regra de preço, modelo de dados ou lógica de checkout precisam de engenharia de verdade, e devem seguir essa rota. Na maioria dos programas a primeira categoria é a grande maioria do backlog, o que significa que a fila nunca foi realmente sobre capacidade de engenharia.

Dois guarda-corpos evitam que isso vire bagunça: um revisor técnico para qualquer coisa que toque uma página com receita real em cima, e uma regra dura de que experimento de camada de apresentação é removido quando o teste termina, com as vencedoras implementadas direito no código.

Bloqueio 6: aprovação em série

Revisão jurídica, revisão de marca e revisão de conformidade são legítimas. Aplicá-las caso a caso, depois de a variação estar construída, é o que as transforma em bloqueio: cada teste espera numa fila cujo comprimento ninguém controla, e a espera fica invisível em qualquer métrica de velocidade.

A correção é mover a aprovação do artefato para a fronteira. Em vez de revisar cada variação, acordar uma vez o que está pré-aprovado: quais afirmações podem ser feitas, quais páginas estão fora do escopo, quais elementos sempre exigem revisão. Uma página de guarda-corpos assinada pelo jurídico transforma 90% dos testes em trabalho que não precisa de revisão nenhuma, e concentra o esforço de revisão nos 10% que de fato carregam risco.

Desenho da aprovação	O que é revisado	Efeito típico na velocidade
Caso a caso, depois de construir	Cada variação, individualmente	Espera alta e imprevisível, invisível no reporte
Guarda-corpos pré-aprovados	A fronteira, uma vez; depois só as exceções	A maioria dos testes não precisa de revisão; os arriscados recebem atenção real
Nenhuma revisão	Nada	Rápido até o primeiro incidente, e depois normalmente substituído por revisão caso a caso

A linha do meio é a única que sobrevive ao contato com uma organização real, e ela exige uma conversa desconfortável no início em vez de uma conversa confortável repetida para sempre.

Bloqueio 7: sem memória institucional

O último bloqueio clássico é o que se acumula. Um time que não consegue responder “o que já sabemos sobre esta página” reteste hipótese refutada, discute por anedota, e perde tudo que aprendeu quando uma pessoa sai.

O modo de falha normalmente não é a ausência de documentação. É documentação organizada em torno da pergunta errada. Um repositório ordenado por nome de teste e trimestre responde “o que rodamos no Q3”, que ninguém pergunta. Ele deveria responder “o que já sabemos sobre esta etapa do checkout”, que todo mundo pergunta, e isso significa indexar por página e por hipótese, não por experimento.

A outra metade é o hábito: consultar o repositório precisa ser o primeiro passo de escrever uma hipótese, não uma gentileza opcional. O guia de repositório de experimentos que ninguém ignora cobre a estrutura em detalhe; a versão curta é que um repositório que ninguém lê é custo, não ativo.

Bloqueio 8: a página é da agência

Este oitavo bloqueio quase não aparece na literatura internacional e é rotineiro no Brasil, porque uma parte grande das landing pages e das lojas é operada por agência ou por fornecedor de plataforma, não pelo time interno. Ele soa como problema técnico e é problema de contrato.

Na prática ele aparece de três formas, e cada uma tem um sintoma diferente:

Como aparece	Sintoma	O que resolve
Sem acesso para instalar a tag	O teste nunca começa	Cláusula de acesso do time interno para inserir o snippet, com revisão técnica da agência
A página muda no meio do teste	O resultado vem estranho e ninguém sabe por quê	Janela de congelamento acordada por escrito para a página testada
A vencedora nunca é implementada	O teste termina e nada muda no site	Definição prévia de quem implementa a vencedora e em qual prazo

O sintoma do meio é o mais perigoso, porque não faz barulho. Se a agência troca a imagem principal no dia 6 de um teste de 21 dias, o experimento passou a comparar duas coisas diferentes das que começou comparando, e o resultado não é interpretável, mas continua parecendo um resultado. Vale registrar toda mudança de página como evento datado ao lado do teste, exatamente para conseguir descartar o teste com honestidade quando isso acontecer.

Nada disso é conflito com a agência. É o mesmo tipo de acordo operacional que qualquer contrato de mídia já tem, aplicado a uma superfície que passou a ser instrumento de medição além de ser peça de comunicação.

O bloqueio escondido atrás de todos: julgar o programa pela taxa de vitória

Uma crença mantém vivos todos os bloqueios acima: a suposição de que um bom programa de experimentação vence a maior parte das vezes. Ele não vence, e não deveria vencer.

Ronny Kohavi, Diane Tang e Ya Xu, em “Trustworthy Online Controlled Experiments” (Cambridge University Press, 2020), relatam que mesmo entre ideias bem desenhadas e bem executadas na Microsoft, apenas cerca de um terço de fato melhorou a métrica alvo, aproximadamente um terço ficou estável, e o restante piorou. Isso não é evidência de time fraco. É o padrão esperado quando a intuição humana tenta prever comportamento real de usuário.

Uma organização que julga o programa pela taxa de vitória sempre vai concluir que o programa está falhando, e vai começar a pressionar por testes mais curtos, amostras menores e leituras mais simpáticas, que é como todos os bloqueios acima são reforçados de uma vez. O enquadramento alternativo é simples e defensável: o valor do programa é a soma das vitórias implementadas e das derrotas evitadas, e a segunda metade é invisível a não ser que alguém a reporte de propósito.

O que é medido	O que isso premia	Modo de falha
Taxa de vitória	Testar mudanças seguras e óbvias	O programa parece bem-sucedido e não aprende nada
Testes concluídos por trimestre	Volume	Testes sem poder rodados para bater a contagem
Decisões tomadas com evidência	Usar o resultado, para qualquer lado que ele aponte	Exige reportar derrota, o que exige governança
Receita em risco protegida	Pegar as mudanças que teriam feito mal	Precisa da estimativa de perda registrada no momento da decisão

Faça isso automático na Donnu

Quase todo bloqueio deste artigo piora quando a mecânica de testar é cara. Se construir uma variação leva um sprint, ninguém testa; se ler o resultado exige uma planilha, cada um lê o número que prefere. A Donnu remove essa fricção: roda a variação com um snippet que não consome capacidade de sprint, e devolve o veredito com o intervalo de confiança ao lado, segurando a declaração de vencedora até a variação ter pelo menos 200 visitantes e 7 dias no ar, para que a conversa sobre o que o resultado sustenta comece do mesmo número para todo mundo.

Comece um teste grátis de 14 dias e tire um bloqueio da lista esta semana. Para o framework completo em volta disso, veja como construir uma cultura de experimentação.

Referências

• Kohavi, R., Tang, D. e Xu, Y. Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press, 2020. Material complementar em experimentguide.com.
• Kohavi, R. The Origin of HiPPO: Highest Paid Person’s Opinion. LinkedIn Pulse. linkedin.com/pulse/origin-hippo.
• Thomke, S. Building a Culture of Experimentation. Harvard Business Review, março-abril de 2020. hbr.org/2020/03/building-a-culture-of-experimentation.
• Kohavi, R. e Thomke, S. The Surprising Power of Online Experiments. Harvard Business Review, 2017. hbr.org/2017/09/the-surprising-power-of-online-experiments.

Leia também:

• Como construir uma cultura de experimentação: um framework prático
• Como conseguir apoio da diretoria para testes A/B
• Quantos testes A/B você deveria rodar por mês?
• CRO para sites de baixo tráfego: como testar assim mesmo
• Read in English