Desenho de Experimentos de Crescimento: Da Hipótese ao MDE à Leitura

Na primeira vez que entreguei um "vencedor" que nos fez perder 3% dos trials foi em um teste de CTA na página de preços. Três dias, 240 visitantes, variante B com 6,2% a mais. O PM mandou o emoji de troféu no Slack. Duas semanas depois, nosso volume semanal de trials parecia errado, rodei a matemática de novo, e o "vencedor" original estava dentro da banda de ruído o tempo todo. Tínhamos entregado nada, exceto um trimestre de roadmap construído sobre uma sensação.

Esse é o trabalho, honestamente. Não o teste. A parte de não-ser-enganado.

Este guia é o playbook que eu gostaria que alguém tivesse me dado no primeiro dia: como escrever uma hipótese que pode ser eliminada de verdade, como fazer a matemática de tamanho de amostra em um guardanapo, como escolher entre ICE e RICE sem mentir para si mesmo e como escrever uma leitura que seu CFO vai realmente abrir. Se você levar uma coisa disso, leve esta: o teste não é o entregável. A leitura é. Na maioria dos trimestres, isso são 4 leituras, não 40.

Por que a maioria dos experimentos B2B falham

Auditei cerca de 60 experimentos de crescimento em empresas SaaS e PLG nos últimos anos. Os modos de falha se agrupam em cinco coisas, e quatro delas são decididas antes do teste ir ao ar.

1. Subdimensionado desde o primeiro dia. A equipe executa um teste de 5 dias em 800 usuários com uma taxa de conversão base de 8%, vê um ganho de 0,4 pontos percentuais e o chama de vencedor. O MDE real nesse tamanho de amostra é algo como 3 pontos percentuais relativos à base. Qualquer coisa menor do que isso é estatisticamente indistinguível de cara ou coroa. Eles não executaram um experimento ruim. Executaram um teste incapaz de detectar o efeito que estavam esperando.

2. Hipótese escrita como to-do. "Vamos testar um novo headline na página de preços." Isso não é uma hipótese. Uma hipótese prevê o que muda, em quanto, para quem e por quê. Se sua hipótese não pode ser falsificada pelos dados, o teste vai produzir uma história independente do que acontecer.

3. Sem plano de rollback. A variante é entregue, a conversão cai 4%, ninguém é dono da decisão de rollback, a variante roda por mais 6 semanas porque "queremos mais dados." Você não precisa de mais dados. Você precisa de uma regra de parada pré-registrada.

4. Sem métrica primária pré-registrada. Três dias depois, a conversão está neutra mas o tempo-na-página subiu 22%, então de repente o tempo-na-página é a métrica. Isso tem um nome: HARKing (Hypothesizing After Results are Known, ou seja, criar hipóteses depois de ver os resultados). Toda equipe faz isso. Toda equipe que faz isso produz leituras não confiáveis.

5. O PM olha o gráfico no dia 3. Espionagem. O teste sequencial existe exatamente por esse motivo, e a maioria das equipes não o está usando. Um teste de horizonte fixo padrão perde suas garantias estatísticas no momento em que você toma decisões com base em olhares intermediários.

Os primeiros quatro são resolvidos por um template de hipótese. O quinto é resolvido por uma calculadora de tamanho de amostra e a disciplina de deixar o dashboard em paz.

O template de hipótese

Copie isso. Cole no rastreador de experimentos da sua equipe. Faça-o o único template que qualquer um tem permissão de usar.

EXPERIMENTO: [nome curto, ex: "Bloco de prova social na página de preços"]

PROBLEMA (o que observamos nos dados):
  Vemos o comportamento X no segmento Y. Especificamente:
  - Ponto de dados 1: [de analytics, tickets de suporte, calls de vendas, qual]
  - Ponto de dados 2: [confirmando ou triangulando]

MUDANÇA PREVISTA (o que faremos, para quem):
  Para [segmento], vamos [mudança], porque [mecanismo que acreditamos estar em ação].

MÉTRICA DE SUCESSO:
  Primária:  [uma métrica, com número de base atual]
  Guarda-chuva 1: [não deve mover pior do que X]
  Guarda-chuva 2: [não deve mover pior do que Y]

MDE (o menor efeito que acionaríamos):
  Precisamos detectar um ganho relativo de [N%] na métrica primária.
  Abaixo disso, a mudança não vale o custo de engenharia / risco de marca / foco.

TAMANHO DE AMOSTRA E DURAÇÃO:
  Por braço: [N] usuários
  Duração estimada com o tráfego atual: [N semanas]

CRITÉRIOS DE ROLLBACK:
  Eliminamos a variante imediatamente se:
  - A primária piora em mais de [X]
  - Qualquer guarda-chuva ultrapassa seu limite por mais de 48h
  - A engenharia encontra um bug P0/P1

DATA DE DECISÃO: [uma data real, não "quando tivermos dados suficientes"]
RESPONSÁVEL: [uma pessoa]

Duas observações. Primeiro, a linha de MDE não é um desejo. É o limite abaixo do qual você não entregaria a mudança de qualquer forma, mesmo que fosse "real." Se um ganho de 1,5% na ativação não vale o custo de manutenção de carregar a variante no código para sempre, então 1,5% não é seu MDE. Seu MDE é o número que realmente supera o custo. Seja honesto aí.

Segundo, a data de decisão mata mais zumbis do que qualquer outra coisa neste template. Sem ela, todo teste roda eternamente.

Matemática de MDE que você pode fazer em um guardanapo

Aqui está a fórmula que uso para planejamento, com a qual um estatístico real teria uma objeção leve, mas que chega dentro de 10% da verdade e é rápida o suficiente para que você realmente a use:

n por braço  ≈  16 × p × (1 - p) / MDE²

Onde:

• p é sua taxa de conversão base (como decimal, ex: 0,08 para 8%)
• MDE é o ganho absoluto que você quer detectar (como decimal, ex: 0,008 para um movimento de 8,0% para 8,8%, que é um ganho relativo de 10%)
• 16 incorpora 80% de poder e 95% de confiança (dois lados)

É isso. Sem software necessário. Vamos rodar um real.

Exemplo prático: conversão trial-para-pago de 8%

Seu produto B2B SaaS tem 600 cadastros semanais. Trial-para-pago é 8% (então p = 0,08). Você quer detectar um ganho relativo de 10%, ou seja, 8,0% para 8,8% absoluto (então MDE = 0,008).

n por braço  =  16 × 0,08 × 0,92 / (0,008)²
             =  16 × 0,0736 / 0,000064
             =  1,1776 / 0,000064
             ≈  18.400 usuários por braço

Dois braços = 36.800 usuários. Com 600 cadastros/semana divididos 50/50 no teste, isso é aproximadamente 6 a 8 semanas de tráfego para um experimento. Não 5 dias.

Agora, se você quer detectar um ganho relativo de 25% (8,0% para 10,0%), a matemática fica mais amigável:

n por braço  =  16 × 0,08 × 0,92 / (0,02)²
             =  1,1776 / 0,0004
             ≈  2.944 por braço

Cerca de 6.000 usuários no total. Com 600 por semana, aproximadamente 2 semanas. O problema: ganhos relativos de 25% em trial-para-pago são basicamente unicórnios em funis B2B maduros. Você terá um ou dois por ano se for bom. A maioria das vitórias reais são de 3 a 8% relativo, o que significa que a maioria dos seus testes precisam de meses de tráfego, não dias.

Essa é a parte que ninguém quer ouvir: seu funil não se move 25%, então seus experimentos precisam ser dimensionados para os ganhos que realmente existem. Ignore isso e todo teste se torna um Rorschach.

Quando "vamos só rodar por mais tempo" está errado

Se um teste era subdimensionado desde o primeiro dia, rodá-lo por mais tempo em configurações de horizonte fixo não conserta. Isso infla sua taxa de falso-positivo, porque você está efetivamente espionando. Se você realmente precisa de flexibilidade na duração, mude para:

• Teste sequencial (msPRT, p-values sempre válidos): permite parar cedo ou estender sem quebrar a matemática. Statsig, GrowthBook e Eppo todos suportam nativamente.
• CUPED (redução de variância usando dados pré-experimento): pode reduzir o tamanho de amostra necessário em 30 a 50% em métricas com forte sinal pré-período. Vale a pena ativar para qualquer teste importante.

Não tente fazer isso manualmente. Use a plataforma.

Diagnósticos comuns a conhecer pelo nome

Se você consegue nomear o modo de falha, consegue argumentar contra ele em uma revisão de leitura. Os cinco que mais vejo:

• HARKing: escolher a métrica depois de ver o resultado. Resolvido com pré-registro de primária e guarda-chuvas antes do lançamento.
• Espionagem: tomar decisões com base em olhares intermediários em testes de horizonte fixo. Resolvido por teste sequencial ou genuinamente não olhar até a data de decisão.
• Efeito novidade: a variante vence por duas semanas porque é nova, depois regride. Resolvido estendendo testes em mudanças de UI e observando o comportamento da semana 3 em diante.
• Paradoxo de Simpson: a variante vence no geral, mas perde em cada segmento, porque o mix mudou. Resolvido sempre pré-segmentando sua leitura (novos vs. recorrentes, por plano, por fonte).
• Viés de sobrevivência em métricas de coorte: medir "retenção na semana 4" apenas em usuários que chegaram à semana 4 infla o número. Resolvido ancorarando coortes no evento de entrada.

Priorização: ICE vs RICE vs PIE

Três frameworks, ingredientes ligeiramente diferentes, todos mentindo para você de formas diferentes.

Minha avaliação honesta: ICE está ótimo para uma equipe de 2 pessoas e mente para uma equipe de 20. Quando sua equipe é pequena o suficiente para que todos tenham lido todos os documentos, ICE é apenas uma forma de escrever uma conversa que você teria de qualquer forma. Quando a equipe é grande o suficiente para que a pontuação ICE seja o único artefato que uma parte interessada lê, todo PM joga com ela.

A armadilha com todos os três: você está pontuando seus próprios experimentos. Os donos superponderam a Confiança nas próprias ideias. Os engenheiros subponderam a Facilidade nas de outra pessoa. A pontuação se torna um proxy para política de escritório.

O que executo em vez disso em escala: uma matriz 2x2 Confiança x Alcance sem matemática. Canto superior direito (alta confiança, alto alcance) entrega agora. Canto superior esquerdo (alta confiança, alcance estreito) entrega se for barato. Canto inferior direito (baixa confiança, amplo alcance) vira investimento em pesquisa paga. Vamos financiar o teste com base no valor de aprendizado, não no ganho esperado. Canto inferior esquerdo morre. Revisado semanalmente, em uma reunião de 30 minutos, com o head of growth segurando o marcador.

Não é um número. É um mecanismo de forçar conversas honestas.

Limite de WIP: máximo de 3 a 5 testes ativos

Para a maioria das equipes B2B com menos de 500 funcionários, o número certo de experimentos concorrentes é de 3 a 5. Acima disso, você consome seu próprio tráfego, seus efeitos de interação ficam inrastreáveis e sua equipe não consegue realmente prestar atenção às leituras. A restrição não é a velocidade de engenharia. É tráfego e atenção.

O documento de leitura (esse é o entregável real)

Todo teste entregado, eliminado ou inconclusivo recebe uma leitura de uma página. Não um dashboard. Um documento. Salvo na mesma pasta para sempre.

LEITURA: [nome do experimento]
DATAS: [início] → [fim]
RESPONSÁVEL: [nome]
STATUS: Entregue / Eliminado / Inconclusivo

O QUE FOI ENTREGADO
  A variante B substituiu [X] por [Y] em [página/fluxo], para [segmento], de [data] a [data].

O QUE MEDIMOS
  Primária:    [métrica], controle [N], variante [N], delta [+X% / -Y%], p = [N], IC [N, N]
  Guarda-chuva 1: [métrica], neutro / ultrapassado
  Guarda-chuva 2: [métrica], neutro / ultrapassado
  Amostra:     [N por braço], dimensionado para ganho relativo de [MDE]%

O QUE APRENDEMOS
  - Interpretação do resultado em 2 a 3 frases. Sem "arrasamos." Sim: "trial-para-pago moveu
    +4,2% (IC 1,1–7,3%), dentro do nosso MDE pré-registrado de 4%, então entregamos."
  - Divisões por segmento: [onde o efeito foi mais forte / mais fraco]
  - Qualquer coisa estranha: [sinal de novidade? ruído de guarda-chuva? qualidade de dados?]

O QUE FAREMOS EM SEGUIDA
  - Plano de entrega/holdout para a variante
  - Testes de acompanhamento (máximo 2)
  - Qualquer coisa que precise de atenção de eng, produto ou design

ESTÁVAMOS ERRADOS SOBRE ___
  Uma frase. A coisa que acreditávamos ao entrar que os dados refutaram (ou se recusaram a confirmar).

A linha "estávamos errados sobre" é a arma secreta. Faz três coisas:

1. Constrói confiança na equipe. Líderes veem que você não está embalando derrotas como vitórias.
2. Compõe aprendizados. Ao longo de um ano você tem 30 ou mais linhas de "estávamos errados sobre," e padrões emergem ("continuamos superestimando o impacto de mudanças na página de preços").
3. Calibra pontuações futuras de Confiança. Seus priors ficam mais precisos.

Se suas leituras não têm uma linha de "estávamos errados" para pelo menos 60% dos testes concluídos, você está ou testando apenas coisas seguras ou reescrevendo a história. Ambos são ruins.

De onde vem o backlog de hipóteses

Um pipeline de testes morre de fome se a equipe não tem uma forma estruturada de gerar ideias. Cinco fontes em que confio, em ordem aproximadamente decrescente de sinal:

1. Diferenças de funil: o segmento X converte à metade da taxa do segmento Y na mesma etapa. Descubra por quê. É aqui que vivem as maiores vitórias mais defensáveis.
2. Entrevistas qualitativas: 5 clientes que saíram, gravados e transcritos. Você vai ouvir o mesmo atrito em 3 deles. Esse atrito é sua próxima hipótese.
3. Gravações de calls de vendas: Gong/Chorus é uma mina de ouro. Pesquise "eu gostaria que pudesse" ou "o que me confundiu." Cada um é uma hipótese com confiança pré-incorporada.
4. Tickets de suporte: mesma ideia, funil mais baixo. Agrupe por tópico. O maior grupo muitas vezes é uma correção de 2 semanas de engenharia que eleva a ativação mais do que seus últimos 6 testes combinados.
5. Teardowns de concorrentes: úteis, mas perigosos. Você vai superpesar a novidade. Marque estes como baixa Confiança por padrão.

Pontue cada ideia contra o template de hipótese antes que entre na fila de priorização. Se você não consegue preencher a seção de Problema com dois pontos de dados reais, a ideia não está pronta. É um palpite. Devolva para pesquisa.

Eliminando experimentos zumbis

Toda equipe de crescimento que já vi tem eles: testes ainda servindo tráfego para uma variante que ninguém possui, atrás de uma flag que ninguém lembra, em uma página que ninguém audita. Três regras:

• A regra dos 90 dias. Se um teste está ativo por mais de 90 dias sem uma leitura, é eliminado por padrão na próxima revisão trimestral. Sem exceções para "estamos esperando por mais dados." Se um teste precisa de 4 meses para atingir significância, estava subdimensionado no lançamento e a resposta certa é parar e redesenhar.
• Revisão trimestral de cemitério. Uma vez por trimestre, audite cada flag ativa em sua plataforma de experimentação. Corresponda cada uma a um responsável e um documento de leitura. Qualquer coisa sem dono volta ao controle e a flag é deletada do codebase.
• A auditoria de "ainda servindo tráfego". Puxe a lista de todas as URLs elegíveis para experimento e faça referência cruzada com testes ativos na plataforma. Cada lacuna é um bug de configuração ou um zumbi. Corrija ambos.

A equipe que executa essa auditoria honestamente vai descobrir que 30 a 40% de seus testes "ativos" são peso morto. Eliminá-los libera tráfego e atenção para testes que podem realmente aprender.

O trabalho real do Growth IC

Vou fechar onde abri. O trabalho do IC não é entregar mais testes. É entregar mais aprendizados. Na maioria dos trimestres, isso são 4 testes bem projetados, adequadamente dimensionados e honestamente lidos, não 40 encolhimentos de ombros.

Uma boa prática de experimentação parece lenta de fora. A equipe está rodando 3 testes, não 30. Metade das leituras diz "estávamos errados." O PM que defende espionagem recebe um empurrão de volta. O CFO realmente abre o documento de leitura e faz uma pergunta sobre a métrica de guarda-chuva.

Esse é o trabalho funcionando. Os troféus no Slack vêm depois, e são reais porque a matemática foi real.

Saiba Mais

• Descrição de Cargo de Growth Marketing Manager
• Diagnóstico de Funil PLG para o Growth IC
• Seleção de Métrica de Ativação: Escolhendo o Único Número
• Lendo uma Curva de Retenção de Coorte Sem Mentir para Si Mesmo