Como Conseguir Apoio da Diretoria para Testes A/B
Apoio da diretoria para teste A/B: as três objeções reais, o modelo de ROI com o teto honesto e o piloto que encerra a discussão.
📚 Este artigo faz parte do guia Como Construir uma Cultura de Experimentação (2026).
O apoio da diretoria para teste A/B raramente se perde no mérito da experimentação, e quase sempre se perde no formato do pedido. “Queremos começar a testar” chega como pedido de orçamento e paciência sem retorno definido. “Subir mudança sem teste neste fluxo custa uma estimativa X por ano, e aqui está um piloto de duração fixa que vai dizer se essa estimativa está certa” chega como gestão de risco, que é uma língua que a diretoria já fala. Este artigo cobre as três objeções que você vai enfrentar de verdade, um modelo de ROI com o teto declarado em voz alta, o argumento de perda evitada que a maioria dos business cases omite, e como dimensionar um piloto capaz de dar certo no próprio cronograma. Faz parte do guia de como construir uma cultura de experimentação.
Apoio da diretoria para teste A/B: as três objeções que você vai ouvir
As conversas de aprovação parecem variadas e não são. Quase toda recusa se reduz a uma de três preocupações, e cada uma tem uma resposta específica.
| Objeção | O que costuma significar | A resposta que funciona |
|---|---|---|
| “Isso vai nos deixar lentos” | Medo de que toda entrega passe a esperar semanas por um veredito | Teste as mudanças em que errar é caro; suba o resto. Teste é filtro para mudança de alto risco, não portão para todo o trabalho |
| “A gente já sabe o que funciona” | Experiência passada sendo tratada como evidência | Concorde, e proponha testar a própria crença. Se a crença estiver certa, o teste custa duas semanas e produz um fato documentado |
| “A ferramenta custa caro demais” | O custo é visível e o retorno não | Ponha os dois na mesma linha: receita anual do fluxo ao lado do custo do programa. A ferramenta costuma ser arredondamento perto do fluxo que ela protege |
A segunda objeção é a que merece o engajamento mais sério, porque muitas vezes é parcialmente verdadeira. Gente sênior costuma saber muito do negócio. O reenquadramento produtivo não é “você está errado”, é “a discordância que existe nesta sala é exatamente o que um teste resolve barato”. Um teste que confirma a intuição da liderança é um bom resultado para o programa: converte opinião em fato documentado, e a próxima discussão começa de um patamar mais alto.
Coloque o programa em dinheiro
O modelo é simples o bastante para defender num quadro branco. Receita anual do fluxo testado vezes o ganho relativo total esperado no ano, menos o custo anual do programa. O ganho relativo total é testes por ano, vezes taxa de vitória, vezes o ganho médio de um teste vencedor.
Rode com os seus próprios números antes de citar qualquer coisa:
Modelo: cada vencedor soma seu uplift à conversão; o 1º ano realiza cerca de metade do regime (rampa). Ajuste os campos e veja o impacto ao vivo.
Exemplo trabalhado
Uma operação de e-commerce com 90.000 visitantes por mês no fluxo testado, taxa de conversão de 2,2% e valor médio de R$ 180 por conversão. O time consegue rodar 1,3 teste por mês, assume taxa de vitória de um terço, em linha com os dados publicados da Microsoft, e espera ganho médio de 4% relativo por vitória. O programa custa R$ 4.000 por mês entre ferramenta e horas.
- Receita mensal base do fluxo: 90.000 vezes 2,2% vezes R$ 180, ou seja, R$ 356.400.
- Receita anual base: R$ 4.276.800.
- Testes por ano: 1,3 vezes 12, ou seja, 15,6.
- Vitórias por ano: 15,6 vezes 0,33, ou seja, 5,15.
- Ganho relativo total no ano: 5,15 vezes 4%, ou seja, 20,6%.
- Receita incremental em regime: R$ 4.276.800 vezes 20,6%, ou seja, R$ 880.679 por ano.
- Realizado no ano 1 (cerca de metade, porque as vitórias entram ao longo do ano): R$ 440.339.
- Custo anual do programa: R$ 48.000.
- Ganho líquido no primeiro ano: R$ 392.339, um ROI de primeiro ano de cerca de 817%.
Por que esse número é um teto, não uma previsão
Apresentar o número acima sem o parágrafo seguinte é como programas de experimentação perdem credibilidade no segundo ano. O modelo soma ganhos linearmente, e a realidade não colabora em três frentes separadas.
A maldição do vencedor. Uma mudança só é implementada quando o efeito observado passa de um limiar, então as vencedoras que sobem são sistematicamente as que também pegaram um sorteio favorável. O ganho medido fica, portanto, enviesado para cima, e o viés é maior exatamente onde dói mais: em testes com poder insuficiente, em que só um sorteio incomumente sortudo conseguiria cruzar a linha. É uma das razões de testar com amostra curta sair caro mesmo quando produz vencedoras, ponto tratado em os erros que invalidam um teste A/B.
Ganhos se sobrepõem. Duas vitórias no mesmo funil frequentemente capturam parte do mesmo ganho. Melhorar a página de produto e melhorar o carrinho recuperam ambos parte dos mesmos usuários que abandonariam, então subir as duas raramente entrega a soma dos dois efeitos medidos.
Alguns efeitos decaem. Ganho movido por novidade some conforme o usuário recorrente se acostuma com a mudança, e efeito sazonal não se repete igual ao longo do ano.
A forma honesta de apresentar isso é dois cenários no mesmo slide. Mantendo todo o resto idêntico e realizando 60% do ganho medido em vez de 100%, a receita incremental em regime fica em R$ 528.407, o realizado no ano 1 em R$ 264.204, e o ganho líquido de primeiro ano em R$ 216.204, um ROI de cerca de 450%.
O argumento que quase ninguém faz: perdas evitadas
Todo business case acima conta apenas o terço vencedor. O argumento mais forte para um programa de testes mora no terço perdedor, e costuma ficar completamente de fora.
Segundo dados publicados por Ronny Kohavi sobre experimentos na Microsoft, aproximadamente um terço das ideias testadas melhora a métrica alvo, um terço não muda nada e um terço piora (Kohavi, Online Controlled Experiments: Lessons from Running A/B/n Tests for 12 Years, KDD 2015). Leia o terceiro item devagar: são mudanças que um time competente desenhou, acreditou e construiu. Sem teste, elas sobem. Com teste, elas são pegas numa fração do tráfego e revertidas.
Nos mesmos 15,6 testes por ano, isso dá cerca de cinco mudanças por ano que teriam degradado o fluxo e não degradaram, porque foram pegas expostas a metade do tráfego por duas semanas em vez de a todo o tráfego por tempo indeterminado. Você não pode lançar isso como receita, e não deveria tentar. O que dá para dizer com precisão é o seguinte: num fluxo que carrega R$ 4,3 milhões por ano, um programa que barra cerca de cinco mudanças nocivas por ano está comprando um seguro cujo prêmio é R$ 48.000.
Existe um corolário que vale dizer na mesma reunião, porque desarma a objeção do “isso vai nos deixar lentos” de vez: sem programa de testes, essas cinco mudanças acontecem do mesmo jeito. Elas só são descobertas mais tarde, por uma queda de métrica que ninguém consegue atribuir, normalmente depois que várias outras coisas também mudaram.
A comparação que encerra a discussão: programa contra compra de tráfego
Em quase toda empresa brasileira que já investe em mídia, existe um comparativo mais concreto do que o ROI percentual, e ele muda o tom da conversa porque coloca o programa dentro de um orçamento que já foi aprovado antes.
O ganho do exemplo acima, R$ 880.679 por ano em regime, equivale a R$ 73.390 por mês. Como cada visitante do fluxo vale, em média, 2,2% vezes R$ 180, ou seja R$ 3,96, chegar ao mesmo resultado comprando audiência exigiria trazer cerca de 18.533 visitantes a mais por mês, todo mês, para sempre, sem melhorar nada na página.
| Caminho para o mesmo ganho | O que exige | Quando para de render |
|---|---|---|
| Programa de experimentação | R$ 4.000 por mês em ferramenta e horas | O ganho fica na página depois que a mudança sobe |
| Compra de tráfego equivalente | 18.533 visitantes a mais por mês, de forma sustentada | No dia em que o investimento em mídia é cortado |
O ponto de equilíbrio é fácil de calcular e vale levar impresso: R$ 4.000 divididos por 18.533 visitantes dão R$ 0,22 por visitante. Comprar audiência só sairia mais barato que o programa se o seu custo por visitante estivesse abaixo disso, o que é raro em qualquer canal pago com intenção de compra.
Vale fechar essa seção sem exagero, porque a comparação é útil e não é uma disputa real: os dois caminhos se somam. Melhorar a conversão do fluxo aumenta o retorno de cada real que já está sendo gasto em mídia, e é por isso que o argumento costuma ser bem recebido justamente por quem defende o orçamento de aquisição.
Desenhe um piloto que consiga dar certo
A forma mais comum de um programa bem argumentado morrer é um piloto prometido num prazo que o tráfego não sustenta. Dimensione antes de assumir uma data.
Pegue o mesmo fluxo: 90.000 visitantes por mês, base de 2,2%, e a ambição de detectar um ganho relativo de 15% a 95% de confiança e 80% de poder.
- Amostra por variação: 33.284 visitantes.
- Amostra total (2 variações): 66.568 visitantes.
- Tráfego diário: 3.000 visitantes.
- Duração: 66.568 divididos por 3.000 dão 22,2, arredondando para dias inteiros de coleta, ou seja, 23 dias por teste.
Calcule para o seu próprio fluxo antes de marcar data:
Cálculo por aproximação normal de duas proporções, 2 variações (50/50). Mexa nos campos e veja o impacto ao vivo.
Esse único número reformula a proposta. Um piloto de três testes é aproximadamente 10 semanas de tempo rodando, sem contar o tempo de construção entre os testes, então o pedido honesto é um trimestre. Prometer “resultado em 30 dias” neste fluxo garante ou uma parada antecipada (que produz resposta não confiável e destrói a credibilidade do programa no primeiro resultado) ou um prazo estourado.
Quatro compromissos deixam um piloto defensável antes de começar:
| Compromisso | Por que protege o programa |
|---|---|
| Um fluxo, escolhido por tráfego | Piloto em página de pouco tráfego não produz veredito em prazo nenhum |
| Duração fixada antes de subir | Elimina a tentação de parar na primeira leitura favorável |
| Regra de decisão escrita | “Implementamos se o intervalo excluir zero e as métricas de guarda seguirem estáveis” é acordado enquanto ninguém sabe o resultado |
| Derrota reportada igual à vitória | A primeira derrota é o teste de credibilidade do programa inteiro |
O terceiro compromisso é o que mais paga, porque é acordado no único momento em que todo mundo é imparcial: antes de o dado existir. Registrar a regra de decisão antes também elimina o modo de falha mais comum de programas iniciantes, que é parar o teste no instante em que o painel fica bonito. A mecânica e o custo real desse hábito estão em o problema do peeking em testes A/B.
O relatório de uma página que a diretoria lê
Hábito de reporte decide se o segundo trimestre é financiado. Três regras cobrem o assunto:
- Comece pela decisão, não pela estatística. Implementado, revertido ou inconclusivo, na primeira linha.
- Reporte o intervalo, não o ponto. “+4,1% relativo, intervalo de +0,5% a +7,7%” cria uma expectativa que o realizado consegue cumprir. “+4,1%” cria uma promessa que normalmente ele não cumpre.
- Traduza as duas pontas do intervalo em receita anual. Diretoria pensa em faixa quando a faixa é oferecida, e em número único quando não é.
Um quarto hábito vale adotar assim que o programa estiver rodando: reportar resultado acumulado do programa a cada trimestre, incluindo empates e derrotas, com o cenário deflacionado de ROI ao lado do teto original. Esse é o artefato que converte um piloto em linha permanente de orçamento, porque mostra o programa corrigindo as próprias estimativas em vez de defendê-las.
Erros comuns ao apresentar o programa
| Erro | Por que se volta contra você | Movimento melhor |
|---|---|---|
| Citar a taxa de vitória de um concorrente como sua previsão | O tráfego, o time e a base deles não são os seus | Modele com os números do seu fluxo e declare as premissas |
| Prometer um ganho específico de conversão | O ganho é exatamente o que se desconhece | Prometa a qualidade da decisão, não o resultado |
| Apresentar só o teto | O realizado do ano 2 vai parecer fracasso | Mostre teto e cenário deflacionado juntos |
| Pilotar numa página de pouco tráfego | Nenhum veredito é possível na janela do piloto | Escolha o fluxo por tráfego, depois por valor de negócio |
| Esconder a primeira derrota | Derrota é o produto; esconder sinaliza o contrário | Reporte a primeira derrota alto e explique o que ela evitou |
| Pedir uma ferramenta em vez de um programa | Ferramenta não produz decisão, processo produz | Peça um trimestre, um fluxo, uma regra de decisão e um relatório |
Faça isso automático na Donnu
Os dois números que decidem essa discussão são a duração estimada antes de você assumir uma data, e o intervalo de confiança que você reporta no lugar de uma estimativa pontual. A Donnu produz os dois por padrão: dimensiona cada teste pelo seu tráfego real e mostra a duração esperada antes de começar, e todo resultado vem com o intervalo e a leitura das métricas de guarda, então o relatório que você leva para a reunião é o relatório que a ferramenta já gerou. Ninguém precisa reconstruir o business case a partir de um painel.
Comece um teste grátis de 14 dias e rode o piloto com a duração nomeada logo de saída. Para planejar a fila que um programa financiado vai precisar, veja o template de roadmap de experimentação.
Referências
- Kohavi, R. Online Controlled Experiments: Lessons from Running A/B/n Tests for 12 Years. Keynote, ACM SIGKDD 2015. exp-platform.com/Documents/2015-08OnlineControlledExperimentsKDDKeynoteNR.pdf.
- 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.
- Kohavi, R., Tang, D. e Xu, Y. Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press, 2020. cambridge.org.
Leia também:
Perguntas frequentes
- Como conseguir apoio da diretoria para um programa de teste A/B?
- Pare de pedir permissão para testar e comece a precificar a decisão. Diretoria aprova programa que reduz o custo de errar, então o pitch que funciona tem três partes: a receita anual que passa pelo fluxo que você quer testar, a fração de mudanças que historicamente pioram a métrica quando sobem sem teste, e um piloto com duração fixa e regra de decisão registrada antes. Pedir orçamento de ferramenta sem nenhuma das três é pedir um ato de fé.
- Qual é o argumento mais forte para um programa de experimentação?
- Perdas evitadas, não vitórias. Segundo dados publicados por Ronny Kohavi sobre experimentos na Microsoft, aproximadamente um terço das ideias testadas piora a métrica alvo. São mudanças em que o time acreditou o suficiente para construir, e o teste é o que impediu que elas chegassem a todos os usuários. A maioria dos business cases conta só o terço vencedor, o que subestima o programa em cerca de metade e o faz parecer bem mais especulativo do que é.
- Como calcular o ROI de um programa de teste A/B?
- Multiplique a receita anual do fluxo testado pelo ganho relativo total esperado no ano, em que o ganho total é testes por ano vezes taxa de vitória vezes ganho médio de uma vitória. Subtraia o custo anual do programa (ferramenta mais horas). Trate o resultado como teto, não como previsão: esse modelo soma ganhos linearmente, e ganhos reais se sobrepõem, decaem e vêm inflados pela maldição do vencedor.
- Por que modelos de ROI superestimam o retorno da experimentação?
- Três motivos se empilham. Ganhos medidos são enviesados para cima, porque uma variação só é implementada quando o efeito observado cruza um limiar, então as vencedoras tendem a ser justamente as que pegaram um sorteio favorável. Ganhos não somam: duas vitórias no mesmo funil frequentemente capturam parte do mesmo ganho duas vezes. E alguns efeitos decaem depois do lançamento, principalmente os movidos por novidade. Um business case defensável mostra o teto e um cenário deflacionado lado a lado.
- Quanto tempo deve durar um piloto de experimentação?
- O suficiente para produzir uma resposta estatisticamente válida num fluxo com tráfego, o que normalmente é um trimestre, não um mês. Calcule a amostra por variação do fluxo escolhido antes de assumir uma data: se o fluxo precisa de 23 dias por teste, um piloto de três testes é um compromisso de 10 semanas, e prometer resultado em 30 dias condena o programa no próprio cronograma.
- O que precisa estar no relatório que a diretoria realmente lê?
- Uma página por teste: a decisão tomada, o efeito observado com o intervalo de confiança, a implicação em receita anual das duas pontas desse intervalo, e as métricas de guarda. Reportar só a estimativa pontual convida a uma promessa que o dado não sustenta. Reportar o intervalo cria uma expectativa que os resultados conseguem cumprir.
- Vale mais investir em teste A/B ou em comprar mais tráfego?
- A pergunta tem uma resposta aritmética, e ela costuma encerrar a discussão. No exemplo trabalhado deste guia, o ganho anual do programa equivale a comprar cerca de 18.533 visitantes a mais por mês, todo mês. Como o programa custa R$ 4.000 por mês, comprar esse tráfego só sairia mais barato se o seu custo por visitante fosse menor que R$ 0,22. Os dois caminhos não competem de verdade: melhorar a conversão aumenta o retorno de cada real gasto em mídia.