Velocidade de Experimentação: como calcular a sua (template)
Template grátis para calcular a sua velocidade de experimentação: teto estatístico, tempo de ciclo real, aproveitamento e os 4 indicadores que importam.
📚 Este artigo faz parte do guia Como Construir uma Cultura de Experimentação (2026).
Velocidade de experimentação é quantos experimentos válidos o seu time conclui por ano, medidos ponta a ponta. Quase todo mundo calcula isso errado, porque conta só os dias em que o teste ficou no ar e ignora os dias de construção, de espera e de resultado parado esperando alguém decidir. O resultado é um programa que acredita ter capacidade de 26 testes por ano e entrega 11. Este artigo traz o template completo para calcular os dois números que importam, o teto estatístico que o seu tráfego permite e a velocidade real que o seu processo entrega, mais o indicador que sai da razão entre eles e diz exatamente onde o programa está vazando. Faz parte do guia de como construir uma cultura de experimentação.
Os dois números que formam a velocidade de experimentação
Velocidade de experimentação não é um número, são dois, e a diferença entre eles é o diagnóstico.
Teto estatístico. Quantos testes o seu tráfego banca por ano, se o processo fosse instantâneo. Sai da amostra necessária dividida pelo tráfego diário, respeitado o piso de duração de duas semanas. É um limite físico: nenhum processo, por melhor que seja, passa dele.
Velocidade real. Quantos testes o time efetivamente conclui por ano, contando o ciclo completo de cada um. Sai de 365 dividido pelo tempo de ciclo médio.
Aproveitamento. A razão entre os dois. É onde a conversa fica útil, porque diz se o próximo ganho vem de comprar tráfego ou de arrumar o processo. Um aproveitamento de 40% significa que 60% do potencial do seu tráfego está sendo desperdiçado em fricção, e nenhum aumento de audiência recupera isso.
Passo 1: calcule o teto estatístico
O teto sai de três entradas: a taxa de conversão base do fluxo, o efeito mínimo detectável que você quer conseguir enxergar e o tráfego diário nesse fluxo. Vale lembrar que é o tráfego do fluxo testado, nunca o do site inteiro.
Rode com os seus números:
Amostra por variação a 95% de confiança e 80% de poder (bilateral), pela sua taxa e MDE. Ajuste os campos e veja a capacidade ao vivo.
Um detalhe do teto surpreende quase todo mundo na primeira vez: acima de certo ponto, ficar mais ambicioso no MDE não compra mais testes. No exemplo trabalhado abaixo, com 90.000 visitantes por mês, dimensionar para +15% relativo e dimensionar para +25% relativo dão exatamente a mesma capacidade, porque nos dois casos o piso de duas semanas manda. A ambição extra vira só perda de sensibilidade, sem nenhum ganho de cadência.
Passo 2: meça o tempo de ciclo de verdade
O tempo de ciclo é o relógio que começa quando a hipótese é aprovada e para quando a decisão é registrada. Ele tem quatro pedaços, e três deles não coletam nenhum dado.
| Etapa do ciclo | O que conta | Sinal de que essa etapa é o seu gargalo |
|---|---|---|
| Construção | Da hipótese aprovada até a variação no ar | A fila de testes prontos para rodar está sempre vazia |
| Coleta | Do início ao fim da janela fixada | O teste roda menos que o piso de duas semanas |
| Leitura e decisão | Do fim da coleta até a decisão registrada | Resultados prontos esperando uma reunião |
| Espera | Dias entre a decisão e o próximo teste começar | O slot fica vazio enquanto a próxima variação é discutida |
Anote os quatro para cada teste concluído. Três ou quatro testes bastam para a média ficar informativa, e o padrão aparece rápido: na maioria dos programas iniciantes, construção e espera juntas superam a coleta.
Um cuidado de medição que muda o resultado: a etapa de espera é a mais fácil de esquecer, porque ninguém é responsável por ela. Ela não aparece em nenhum ticket, não tem dono e por isso raramente entra na conta. É também, com frequência, a maior das quatro.
Passo 3: o template preenchível
Copie a tabela abaixo para a sua planilha. As três primeiras linhas são entradas, o resto é cálculo.
| Campo | Como preencher | Exemplo |
|---|---|---|
| Visitantes por mês no fluxo | Só quem entra no fluxo testado | 90.000 |
| Taxa de conversão base | Métrica primária do fluxo | 3,5% |
| MDE alvo | Efeito relativo que vale detectar | +15% |
| Amostra por variação | Saída da calculadora | 20.622 |
| Amostra total (2 variações) | Amostra por variação vezes 2 | 41.244 |
| Tráfego diário | Visitantes por mês dividido por 30 | 3.000 |
| Dias de coleta | Maior valor entre amostra total dividida pelo tráfego diário e o piso | 14 |
| Teto estatístico anual | 365 dividido pelos dias de coleta | 26,1 |
| Dias de construção (média) | Medido nos últimos testes | 8 |
| Dias de leitura e decisão (média) | Medido nos últimos testes | 4 |
| Dias de espera (média) | Medido nos últimos testes | 8 |
| Tempo de ciclo | Soma das quatro etapas | 34 |
| Velocidade real anual | 365 dividido pelo tempo de ciclo | 10,7 |
| Aproveitamento | Velocidade real dividida pelo teto | 41% |
| Testes com hipótese registrada | Proporção no trimestre | anotar |
| Resultados documentados | Proporção no trimestre, incluindo empates | anotar |
As duas últimas linhas não entram no cálculo de velocidade e estão ali de propósito. Velocidade sem qualidade de hipótese é só produzir empates mais rápido, e um número de cadência exibido sozinho vira meta perversa em questão de semanas.
Exemplo trabalhado: um SaaS de 90 mil visitantes por mês
O fluxo de cadastro recebe 90.000 visitantes por mês, converte 3,5% em início de trial, e o time dimensiona para detectar +15% relativo com 95% de confiança e 80% de poder.
- Amostra por variação: 20.622 visitantes.
- Amostra total (2 variações): 41.244 visitantes.
- Tráfego diário: 90.000 dividido por 30, ou seja, 3.000 visitantes por dia.
- Dias exigidos pelo tráfego: 41.244 dividido por 3.000 dá 13,7, arredondado para cima em dias inteiros de coleta, ou seja, 14 dias.
- Duração real: 14 dias, empatando com o piso.
- Teto estatístico: 365 dividido por 14, aproximadamente 26 testes por ano.
Confira a amostra com a sua própria taxa base:
Cálculo por aproximação normal de duas proporções, 2 variações (50/50). Mexa nos campos e veja o impacto ao vivo.
Agora o outro lado. Medindo os últimos quatro testes desse time: 8 dias de construção, 14 de coleta, 4 de leitura e decisão, 8 de espera até o próximo começar. Tempo de ciclo de 34 dias.
- Velocidade real: 365 dividido por 34, aproximadamente 10,7 testes por ano.
- Aproveitamento: 10,7 dividido por 26,1, aproximadamente 41%.
O time está deixando 15 testes por ano na mesa, e nenhum deles exige um visitante a mais. Vale notar o que a conta diz sobre a alternativa mais cara: se esse mesmo time dobrasse o tráfego do fluxo para 180.000 visitantes por mês, o teto continuaria em 26 testes por ano, porque a coleta já está no piso de duas semanas. O tráfego extra compraria sensibilidade (a chance de enxergar efeitos menores), o que é valioso, mas não compraria nenhum teste a mais. A cadência só melhora atacando os 20 dias fora da coleta.
O que fazer com cada gargalo
| Gargalo | Alavanca | Custo real |
|---|---|---|
| Construção longa | Manter a próxima variação pronta antes do slot vagar | Exige decidir a fila com antecedência |
| Construção longa | Padronizar as mudanças mais frequentes em componentes reutilizáveis | Investimento inicial de engenharia |
| Coleta acima do piso | Subir a métrica primária no funil ou aumentar o MDE alvo | Perde sensibilidade ou mede um proxy |
| Leitura demorada | Escrever a regra de decisão antes de rodar | Exige combinar critério quando ninguém sabe o resultado |
| Espera entre testes | Paralelizar em fluxos independentes | Só funciona se os fluxos não compartilharem público |
| Espera entre testes | Reservar o slot no calendário antes do teste anterior acabar | Exige tratar o slot como recurso, não como intenção |
A alavanca mais subestimada é a regra de decisão escrita antes do teste. Ela encurta a etapa de leitura porque remove a discussão mais cara do ciclo, que é decidir o critério depois de já conhecer o resultado. Como efeito colateral, ela também protege contra a troca de métrica primária, que é um dos caminhos silenciosos para inflar a taxa de vitória do programa. O custo estatístico de decidir depois de ver os dados está detalhado em o problema do peeking em testes A/B.
Uma advertência sobre paralelizar: rodar dois testes ao mesmo tempo aumenta a velocidade real sem tocar no ciclo individual, mas só quando os dois fluxos não disputam o mesmo público e a mesma métrica primária. Dois testes na mesma jornada dividem a amostra entre quatro combinações, alongam os dois e embutem a interação no resultado de ambos. A regra prática é um teste por fluxo.
Quanto custa um aproveitamento de 41%
Discussão de processo costuma perder para discussão de mídia porque o custo da fricção nunca é expresso em número. Neste caso ele é fácil de expressar.
O time do exemplo deixa 15,4 testes por ano na mesa (26,1 de teto contra 10,7 de velocidade real). Aplicando a proporção que Ronny Kohavi documentou para experimentos na Microsoft, aproximadamente um terço das ideias testadas melhora a métrica alvo (Kohavi, KDD 2015), esses 15,4 testes não rodados equivalem a cerca de 5 melhorias por ano que o time nunca vai encontrar, mais outras 5 mudanças ruins que ele não vai descobrir a tempo de evitar.
O terceiro bloco é o mais fácil de esquecer e costuma ser o mais caro. Testes que não rodam não deixam a mudança parada: a mudança sobe assim mesmo, sem medição, e o prejuízo aparece meses depois como uma queda de métrica que ninguém consegue atribuir.
Duas armadilhas ao encurtar o ciclo
Encurtar o ciclo é a alavanca certa, mas duas formas de encurtá-lo destroem o programa em vez de acelerá-lo.
Encurtar a coleta. É a tentação óbvia, porque a coleta é a maior fatia contígua do ciclo. Também é a única fatia que produz dado. Cortar a coleta de 14 para 8 dias aumenta a cadência no papel e derruba o poder do teste, o que aumenta a taxa de vitória aparente enquanto reduz a proporção de vitórias reais. As outras três etapas podem ser comprimidas sem custo estatístico nenhum; essa não.
Construir antes de aprovar a hipótese. Manter a próxima variação pronta é uma boa prática, mas só depois que a hipótese, a métrica primária e a duração estiverem escritas. Construir antes disso inverte a ordem: o time passa a escolher a hipótese que justifica a variação que já existe, e o roadmap vira uma fila de coisas prontas em vez de uma fila de perguntas.
Como acompanhar sem virar meta perversa
Velocidade é um indicador de meio, não de fim, e exibi-lo sozinho num painel produz o comportamento errado em poucas semanas: testes encurtados para caber no mês, hipóteses frouxas para preencher o slot, empates reclassificados como vitória. Três cuidados evitam isso:
- Reporte sempre em par. Velocidade ao lado da proporção de testes com hipótese registrada antes de rodar. Um número sobe às custas do outro quando o programa começa a se apressar.
- Meça por ano, não por mês. Com poucos testes na janela, um único resultado move a média inteira. A leitura anual é a única estável para quem roda menos de 20 testes por período.
- Separe teto de velocidade no relatório. São problemas diferentes com donos diferentes: o teto é uma conversa sobre tráfego e ambição de MDE, a velocidade é uma conversa sobre processo. Misturar os dois faz o time pedir mídia quando o problema era a fila.
Para ordenar a fila que essa capacidade comporta, o template de roadmap de experimentação já traz a coluna de duração estimada, que é a ponte entre este cálculo e o planejamento. E para saber o que esperar dos testes que couberem, vale ler a taxa de vitória em teste A/B e o que os dados mostram, porque cadência multiplicada por uma expectativa irreal de acerto produz promessa que a matemática não sustenta.
Faça isso automático na Donnu
Metade deste template é conta que a ferramenta deveria fazer sozinha. A Donnu dimensiona cada teste contra o seu tráfego real e mostra a duração estimada antes de você começar, o que já entrega o teto estatístico sem planilha, e mantém a duração fixada para que a etapa de coleta não seja encurtada no meio por uma espiada no painel. O que sobra para o time medir são os dias fora da coleta, que é exatamente onde está o ganho de velocidade que ninguém compra com mídia.
Comece um teste grátis de 14 dias e veja a duração de cada teste antes de comprometer o trimestre. Para dimensionar a cadência que o seu tráfego banca, veja quantos testes A/B você deveria rodar por mês.
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 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.
- Bing Search Quality Insights. Large Scale Experimentation at Bing. Microsoft. blogs.bing.com/search-quality-insights/August-2013/Large-Scale-Experimentation-at-Bing.
- Kohavi, R. ExP Platform: accelerating innovation through trustworthy experimentation. exp-platform.com.
Leia também:
Perguntas frequentes
- O que é velocidade de experimentação?
- É quantos experimentos válidos o time conclui por unidade de tempo, medida ponta a ponta e não só pelo tempo em que o teste ficou no ar. A distinção importa porque a maior parte da lentidão de um programa não está na coleta de dados: está nos dias de construção, de espera por aprovação e de teste terminado que ninguém leu. Um programa que roda testes de 14 dias e entrega 10 experimentos por ano tem um problema de processo, não de tráfego.
- Como calcular a velocidade de experimentação?
- São dois números e uma divisão. O teto estatístico é 365 dividido pela duração de cada teste, onde a duração é o maior valor entre a amostra necessária dividida pelo tráfego diário e o piso de duas semanas. A velocidade real é 365 dividida pelo tempo de ciclo completo, que soma os dias de construção, de coleta, de leitura e de espera. O aproveitamento é a razão entre as duas, e quase sempre fica bem abaixo de 100%.
- Qual é uma boa velocidade de experimentação?
- A referência útil não é um número absoluto, é o seu próprio teto. Um time que aproveita 70% da capacidade que o tráfego permite está indo bem, mesmo rodando 12 testes por ano; um time que aproveita 35% de um teto de 26 está perdendo metade do programa em fricção que nenhum aumento de tráfego resolve. Compare-se com o seu teto antes de comparar-se com qualquer empresa.
- O que fazer quando o gargalo é o tempo de construção, não o tráfego?
- Atacar a fila, não a duração dos testes. As alavancas que funcionam: manter uma variação já construída aguardando o slot livre, padronizar as mudanças mais frequentes em componentes reutilizáveis, e separar a decisão de subir do fim da coleta, definindo a regra de decisão antes de começar. Nenhuma delas exige mais tráfego, e as três encurtam o ciclo sem encurtar o teste.
- Aumentar a velocidade de experimentação sempre aumenta o resultado?
- Não. Velocidade multiplica a qualidade das hipóteses, então dobrar a cadência de um programa com hipóteses fracas apenas produz mais empates mais rápido. 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 fica neutro e um terço piora. Acelerar sem melhorar a origem das hipóteses acelera principalmente os dois últimos terços.
- Com que frequência recalcular o template de velocidade?
- Uma vez por trimestre para o teto estatístico, porque tráfego e taxa base mudam devagar, e a cada teste concluído para o tempo de ciclo, que é onde as melhorias aparecem. Registrar o tempo de ciclo teste a teste é o que transforma o template de um diagnóstico único em um indicador acompanhável.