Projeto: um programa de CRO de ponta a ponta

Este módulo é um exercício de construção. Escolha um produto real, seu ou de um cliente, com tráfego suficiente para rodar ao menos um teste, e monte o programa de CRO inteiro. Ao terminar, você tem um documento que um diretor consegue aprovar e um analista consegue executar na segunda-feira.

Trabalhe com um único fluxo, escolhido pelo valor que carrega. Programa que começa pelo site inteiro não termina.

Etapa 0. Orçamento e alçada, que é o que o diretor assina antes de o programa existir

As sete etapas seguintes descrevem como o programa opera. Nenhuma delas responde à primeira pergunta de quem aprova, que é quanto custa e quem responde. Você já atravessou essa conta nos módulos "Montar ou não montar: a decisão de abrir um programa", "Governança: quem decide, quem veta e com que cadência" e "Maturidade, metas e como cobrar o programa"; aqui ela vira uma folha do documento que vai à reunião.

Quatro linhas compõem o custo, e as duas últimas são justamente as que somem da apresentação ao CFO. Licença de plataforma. Pessoas dedicadas, entre duas e três em um programa que roda de verdade. Tempo de engenharia de front-end, que é o gargalo real de velocity. E o custo de oportunidade do backlog de produto que deixa de ser entregue enquanto a mesma equipe constrói variante. A tabela abaixo traz essas quatro linhas e acrescenta uma quinta entrada, o modelo de entrega, que não é linha de orçamento: é o critério de arranjo que determina como as quatro se distribuem.

Não leve cifra copiada de material de curso, inclusive deste. O que se defende é a proporção: se a licença passa de cerca de 25% do total, a empresa comprou plataforma sem capacidade de operá-la, e essa frase um CFO entende sem precisar do seu número. Os limiares de volume que separam ferramenta, agência e time interno, com o piso abaixo do qual a recomendação honesta é não montar programa, estão no módulo "Montar ou não montar: a decisão de abrir um programa".

A segunda metade dessa folha é a alçada, e ela precisa estar escrita antes do primeiro teste. Duas nomeações resolvem a maior parte dos conflitos que aparecem no terceiro mês. A primeira é o sponsor: pessoa com autoridade para aprovar orçamento e remover um bloqueio de área sem convocar reunião. A segunda é o veto técnico, que pertence a quem responde por validade, instrumentação e Sample Ratio Mismatch, e que não se confunde com a decisão de negócio, que pertence ao dono da superfície.

A distinção só é testada no dia em que um teste com SRM confirmado encontra uma campanha com data marcada. O veto técnico afirma que a leitura é inválida, e essa afirmação não reprova a variante: ela constata que não existe resultado a discutir. Lançar assim mesmo é uma decisão legítima de negócio, desde que tenha nome e fique registrada como lançamento sem evidência. Se a liderança reserva poder de override, isso vai ao papel antes do primeiro teste, porque override não declarado destrói a credibilidade do programa mais rápido que teste ruim. O desenho completo, com a matriz por faixa de risco e o fluxo de escalonamento do conflito, está no módulo "Governança: quem decide, quem veta e com que cadência".

Etapa 1. Diagnóstico quantitativo e qualitativo

Comece pelo quantitativo, mapeando o funil do fluxo escolhido e medindo a queda entre etapas. São três números por etapa: entradas, saídas e taxa de passagem. A etapa com maior perda absoluta, ponderada pelo valor que ela carrega, é a candidata natural.

Venha depois com o qualitativo, que responde o porquê que o número não conta. Grave sessões da etapa problemática, leia mensagens de suporte da mesma janela e rode uma pesquisa de saída curta. Anote a linguagem exata do usuário, porque ela costuma virar a copy da variante.

Entregue esta etapa em uma página: o funil com números datados, as três queixas mais frequentes com citação literal, e a etapa-alvo escolhida com justificativa.

Etapa 2. OEC e guardrails

Defina uma métrica de avaliação geral que capture valor de longo prazo. Receita por visitante costuma servir melhor que taxa de conversão, porque bloqueia a variante que aumenta o número de pedidos e derruba o ticket.

Escreva os guardrails na mesma folha, cada um com o limiar que dispara interrupção. A Airbnb roda um framework de guardrails que sinaliza cerca de 25 experimentos por mês; 80% seguem para lançamento após discussão e 20% são interrompidos. A proporção revela o propósito do mecanismo: ele existe para forçar a conversa, com veto automático como exceção.

Etapa 3. Backlog priorizado com hipóteses estruturadas

Cada linha do backlog é uma hipótese em quatro partes: porque observamos determinada evidência, acreditamos que determinada mudança vai produzir determinado efeito em determinada métrica, e saberemos que estamos certos se determinado critério for atendido. A primeira parte é a que separa hipótese de palpite bem escrito, e é também a que costuma faltar. Linha sem evidência de origem não entra na fila: ela volta para o diagnóstico.

Etapa 4. Instrumentação e validação da coleta

Entre o backlog e o primeiro teste existe a etapa que a maioria dos programas pula e que responde pela maior parte dos resultados inválidos. Um teste só vale o que vale a medição que o sustenta, e medição não nasce pronta: ela é construída. É aqui que o Sample Ratio Mismatch é evitado na origem, em vez de diagnosticado depois de semanas perdidas.

Quatro entregas fecham esta etapa. A camada de dados, que define de onde cada número sai. A nomenclatura de eventos, para que carrinho_adicionado signifique a mesma coisa em toda a operação. O dicionário de métricas, que fixa a definição exata de cada número, incluindo a janela e o denominador. E a validação da coleta, que confere se o que o sistema registra corresponde ao que acontece na tela.

Etapa 5. Desenho do primeiro teste, com tamanho de amostra calculado

Antes de configurar qualquer coisa, calcule quantos visitantes por variante o teste exige. Você precisa da taxa-base atual da métrica, do efeito mínimo detectável que considera relevante, e dos parâmetros de erro. Se a conta apontar duração acima de um mês, há três saídas legítimas: aceitar um efeito mínimo maior, aplicar redução de variância com CUPED, ou testar numa etapa de maior volume.

Ancore o efeito mínimo na realidade. Desenhar um teste para detectar 15% de uplift é desenhar um teste que nunca conclui nada, porque efeitos desse tamanho quase não ocorrem em e-commerce.

Etapa 6. Método de monitoramento, escolhido conscientemente

Registre no documento qual método você vai usar e por quê, porque essa escolha determina o que é permitido olhar enquanto o teste roda.

• A/B fixo com horizonte definido: a duração é decidida antes e o resultado intermediário não é consultado. Serve quando a decisão é durável e precisa ser auditável.
• Sequencial (mSPRT ou Group Sequential): permite monitorar continuamente sem inflar o falso positivo. A Spotify escolheu Group Sequential Testing (Lan e DeMets, 1983) por ter mais poder quando os dados chegam em lotes diários e o tamanho amostral máximo é estimável; a Booking.com também adotou GST.
• Bandit (Thompson Sampling): aloca tráfego para o que parece melhor enquanto aprende. Serve a alto volume e decisão não durável, como escolha de criativo, e falha quando a inferência causal precisa ser limpa.

Etapa 7. Repositório de aprendizado

Registre todo teste concluído, inclusive perdedores e inconclusivos, com sete campos: hipótese, evidência de origem, desenho, tamanho de amostra, resultado com intervalo, decisão tomada, e o que se aprendeu sobre o usuário. O último campo dá composição ao programa, porque transfere entre testes um conhecimento que a métrica isolada não carrega.

O retorno aparece na segunda vez que alguém propõe uma ideia já testada. Sem repositório, o time roda de novo e gasta a mesma amostra para chegar à mesma conclusão.

O registro acima documenta um teste. Falta o documento que documenta o programa, e é ele que o diretor assina. A diferença entre os dois explica por que tantos programas bem executados não conseguem renovar orçamento: o time chega à reunião com método e evidência de método, quando quem aprova precisa de custo, dono, alçada e data.

A folha abaixo é a terceira e última do conjunto, e vem depois das outras duas por dependência, não por ordem de importância. A aprovação do investimento, do módulo "Montar ou não montar: a decisão de abrir um programa", decide se o programa existe. A política do módulo "Governança: quem decide, quem veta e com que cadência" fixa quem decide o quê. Esta descreve como o ciclo vai operar, e transcreve daquelas duas o custo e a alçada em vez de reabrir os dois assuntos. Preencha-a com os outros dois documentos abertos ao lado e leve-a impressa à reunião em que o sponsor assina o ciclo.